國內的雲計算平台有沒有不是依靠 OpenStack 搭建的？

01-20

作為一個開源的項目，國內幾乎知名的雲平台都是依靠著openstack搭建的，也導致了許多知名雲平台，常發生宕機事故，有沒有靠著自身技術搭建的？

騰訊雲是自研的系統。

-------------------------------------

這正好是我在騰訊雲多年以來做過的一個微小工作。

有一天，領導跟我說：中央已經決定了，由你來參與設計和建立騰訊雲新的後台框架。我心想，我一個做名字服務的碼農，怎麼就調到虛擬機那邊去了呢？正想吟誦兩句詩，發現領導已經離開了。

面對突如其來的硬點，作為原教旨主義的開源信徒，我確信要採用OpenStack，正如我曾力排眾議把ZooKeeper引入系統當中。

當時我已經研究OpenStack有好長一段時間了，也曾多次指手劃腳吐槽現有系統的設計，倒也從來沒想過這種在電視劇中活不過兩集的態度竟然給我帶來這樣一個機會。（感謝我司的企業文化）

但是，當我真的要做這樣一件事的時候，我確越來越困惑，直到最後我認為OpenStack並不適合我們的場景，甚至是公有雲。（我的決定也是很重要的）

首先，我們當時的問題是什麼，OpenStack的優勢是什麼？

正如我所說過的（在雲計算公司工作是什麼樣的體驗？ - 李力的回答），雲是一個大型的系統級的工程，它看不慣過往一切無法用軟體定義的基石，所以雲的終極目標是同時要保證穩定與靈活。具體來看騰訊雲當時的系統，流程繁瑣、調用冗長，眾多模塊逐漸形成一個mesh的脆弱結構，容災能力、可追溯能力、部署能力都存在極大的挑戰。與之相比，OpenStack就顯得先進得多：restful的介面設計、獨立互不依存的模塊劃分、清晰有意義的分層結構以及完整而靈活的driver設計，是一個逼格滿分的解決方案。

然而，經過仔細分析，OpenStack的諸多閃光點卻並未照亮我們急需解決的幾個問題，主要包括：

1. 可維護性

OpenStack是大而全的解決方案，不論是什麼雲它都希望能幫得上忙。這導致其設計極度考慮靈活性，在一切可能變化的地方都會為了擴展和改進做大量的工作。

但是，OpenStack的任何使用者都只需要使用它極小的一部分配置集合，而且其它開發者也不一定願意在理解了它完美的層次再進行開發（參照neturon的部分廠商代碼）

這導致OpenStack的部署與配置十分複雜，而且這讓你感覺很疲憊，它無法非常直接地解決你的問題，而總是要正襟危坐、小心翼翼地通過各種包裝、代理、驅動才接觸到問題，還不一定符合期望。

而且OpenStack作為docker以前開源社區最熱的項目，代表了開源項目的最高峰，有一個顯著的特點：盡一切可能把開源的兄弟們拉入伙！於是你看到OpenStack會盡量與各種開源工具融合起來，這無形中增加了運維的成本。OpenStack本來就不簡單，需要理解大量你可能未曾預料的巧妙，還需要學習各種其它的開源項目。

對於雲的後台框架，我們必需要對其理解得十分透徹，如果光是打開代碼都會導致內存不足，我是不願意在半夜起來處理故障時面對它們的。

2. 容災能力與高可用

跟上一條類似，早期OpenStack似乎壓根沒有想過高可用部署，這實在是讓人匪夷所思的一個考慮。

直到我到香港參加OpenStack Summit時，有一個專場是討論高可用部署，我才發現OpenStack的高可用方案又拉了一堆的大型的開源軟體進到你的生產系統。

在騰訊，高可用是後台服務必備的能力，我們從未想過通常不需要花費太多精力的工作在OpenStack上竟然有點讓人畏懼。

3. 可追溯能力與流程回滾

可追溯能力是複雜的分散式系統中非常重要的一點。在我們的『全mesh』雲平台中經常會遇到一個流程突然中斷，卻很難找出在哪裡失敗，為何失敗，更重要的是如何回滾。

這在早期OpenStack中我並未看到任何更先進之處。看似隨意的rpc、邏輯的散落、精巧但是難以追溯的eventlet都增加了異常發生時你定位的困難和惱怒的情緒。

也許是我沒入對門，即便是我看過很長時間代碼，仍然很難快速定位出哪怕是因為配置錯誤導致的流程失敗。

想到以後要天天加班到凌晨，我趕緊跟領導說：我們自己來吧！

4. 性能與穩定性

重要的事情再說一遍：隨意的rpc。

消息隊列受到影響，甚至無法保障通信的可靠。

凡是有用OpenStack管理過大規模宿主機的，應該都踩過這個大坑。

----------------------------

事不關己時談笑風生，事到臨頭卻無可奉告，眼看自己聲名盡毀的速度跑得比誰都快，甚至還會被領導和同事批判一番。於是，我和我的小夥伴們閉關研究一個月、開發一個月，做了騰訊雲新系統的第一版。考慮到保密性，下文姑且叫它MS-FDC（悶聲-發大財）

在設計上，FDC系統主要有幾下幾點：

1. 尊重消息流轉。可追溯性是第一優先順序。

mesh結構類似於網路工程中節點互相訪問的場景，如果都是點到點通信，那麼節點規模的線性增長會導致信道的指數級增長。

FDC使用RabbitMQ做為統一的通信匯流排（類似於乙太網的思路），並且明確模塊監聽的主題名稱。強一致性的RabbitMQ保證了消息的準確送達，並且通過主題名稱實現系統中的服務發現，還自帶了足夠穩健的負載均衡與失敗重傳。而且，由於模塊間的通信隊列是固定的，我們可直接使用RabbitMQ的已有功能對消息進行追溯、統計、監控。

雖然都用了消息隊列，但FDC與OpenStack在這方面的設計原則是完全不同的。OpenStack弱化消息流轉的過程，試圖讓你忘記你處在分散式的系統中，簡化代碼調用的同時鼓勵了不必要的模塊間調用，並且在災難發生時你不得不面對這層外衣下的真實世界。

2. task flow的支持。異常和災難對雲是常態，但不要讓用戶感知到。

既然我們沒有把MQ僅僅當作是一個更好用的socket，而是對消息流轉有了嚴格的編排，那麼框架就能很容易地發現異常發生的時間、模塊以及模塊返回的具體錯誤信息，實現task flow的功能。

那麼框架同樣也可以編排異常發生時的消息流轉圖。對於大部分模塊，只需要它的每個原子介面都有對應的回滾介面，那麼回滾的邏輯就很簡單了，只需要在當前失敗步驟開始，逆序調用所有步驟的回滾介面即可。

我在知乎上發招聘廣告的時間，都是這樣省出來的。

3. 簡潔可靠閉環。『Batteries Included』，拿來就用。

為了有更多發廣告的時間，我們還希望項目規模能簡潔，不要有太多過早優化；能可靠，代碼不多但都經得起考驗；能閉環，自帶電池直接就發光發熱。

『Batteries Included』是Python的一個設計哲學。與外部組件的融合往往會帶來大量的適配工作，而且你只需要外部組件的一個功能子集卻要維護它整個組件。不能拳拳到肉的做法通常是項目偏離需求的開始。對於很多簡單直接的需求，直接用幾十行幾百行代碼來實現，至少比引入幾萬行代碼的依賴要好得多，在你需要的時候也能完備的方法替代電池（如Python有哪些黑魔法？ - 李力的回答）。關於『Batteries Included』與『Don"t Repeat』並不衝突的探討這裡就先不深入了。

FDC的task flow是自帶的，回滾是自帶的，通信介面是自帶的，容災和高可用也是自帶的。

4. 模塊解耦。邏輯上的解耦勝過形式上的解耦，對模塊開發者，盡量減少約束。

每一個程序員都有關於框架的夢想，它的意義在於對使用框架者的約束，約束意味著權力，權力意味著階級。

框架的開發者們說：快看，我找到解決xx問題的最佳實踐，只要你按照我的框架，就能寫出跟我一樣牛逼的代碼。這個思想最早體現在巴別塔建造工程上，也體現在網易評論里：如果全國人民都給我1塊錢，我就有13億了！

嗯，回到雲的框架。雲的框架和大部分的框架還不一樣，它更複雜，更無法預料哪裡未來要發生變化，畢竟software define everything，那麼越是過早優化越是難以回頭，越是限制太多就越容易脫離控制。就像是網路硬體廠商想要接入neturon，工程師為了早點下班，根本就不願意像OpenStack本身的核心開發一樣去理解它的龐大而且精細的類層次和設計，直接找到個入口就把代碼全塞進去了。

我想起我第一次寫CGI時總是理解不了，CGI代碼里沒有任何與web server、http相關的東西，它是怎麼能被瀏覽器訪問到的呢？

FDC的模塊要求類似於CGI，模塊本身不需要理解MQ，也不需要理解task flow，也不需要考慮容災和高可用，這些都完全由框架和RabbitMQ做完了。甚至模塊只有一個入口，以回調函數或者可執行文件的方式提供，框架負載輸入，模塊返回輸出即可。模塊甚至也不知道自己將會被框架attach進去，這對現有系統的接入和改造的成本也是極低的。

5. 高性能，可平行擴展。至少要支持十萬級別的宿主機。

其實這點真的不難，真的。

--------------------

我寫這些，並不是想抨擊或貶低OpenStack，相反，我自始至終是OpenStack的狂熱粉絲。一直以來我們都拿OpenStack的作為參照物，盡量地讓我們的系統能吸收更多的養分。

從一開始，我們就參照了nova對libvirt的處理邏輯，RabbitMQ也是最早在nova的架構中看到，這都是我們系統的核心立足點。OpenStack吸引了全世界最優秀的工程師，有很多的具體設計都讓人耳目一新，也被我逐漸地學習和在騰訊雲中推廣開來，比如調度的各種策略、wsgi的filter、依賴倒置的設計模式。而且隨著OpenStack的發展，它的部署和運維能力越來越強、容災和高可用已經不是那麼繁瑣，與業界主流的sdn和塊存儲方案緊密貼合，我不禁開始想像，如果是在今天再做一次決策，情況會是怎麼樣！

另外，OpenStack的野心也比我想像得要太得多，它現在已經不僅再是雲的後台系統，而是真正的『軟體定義一切』的集合體，在OpenStack Mitaka中，我們看到了大量激動人心的新項目，比如大數據分析模塊、容器相關模塊、搜索引擎模塊，甚至是文件系統、消息隊列和域名解析的支持。這些功能與主框架耦合較少、功能獨立，倒是可以嘗試直接使用，滿足一下我這麼多年對OpenStack欲求而不可得的願望。

而最讓我激動的是OpenStack的taskflow，讓tm不就是我們這麼多年心心念念的流程引擎嗎？Openstack的taskflow和騰訊雲系統中的任務管理十分相似（但顯得OpenStack要完備也複雜得多），似乎是我們的系統與OpenStack在精神上又走到了一起。

面對原有系統的動員戡亂，面對OpenStack的鋼鐵洪流，面對某些系統的自由民主，這是我對公有雲計算平台的一些微小的工作。如果說還有什麼，那就是用戶鏡像一律不得inject

-------------------------------

多年以後，我已經換上了黑框眼鏡、鬢角已長起白髮、褲腰帶也提到了腋下，我仍然能記起在那個外面瓢潑大雨，室內卻日光燈明媚的下午，我望著領導的背影，吟誦的兩句詩：苟利……啊不對，是兩句論語：

天下有道，丘不與易也

（完）

阿里雲不是，搜索飛天平台。

題主哪裡來的自信？這麼信誓旦旦說國內所有知名雲平台都是基於openstack的竟然？

以我小小的了解範圍，主流的阿里，騰訊，ucloud，核心系統沒有一家不是完全自研的。據說華為早期用過 openstack,痛苦不可名狀。開源的產品做個私有雲我覺得挺合適，做共有雲那真是不可描述。

這問題問的。我倒真想知道誰家是用openstack 了。

基本都不是用openstack搭的，但吸收了openstack的框架思想

　　其實國內主流的公有雲平台，從公開宣稱的來看，除開有雲之外，還真沒有什麼是宣稱採用OpenStack搭建的。當然，除開有雲之外，據我所知，也有一些公有雲最初的研發是「借鑒」了OpenStack的架構體系（至於借鑒到何程度，由於沒有看過相關產品具體的代碼，也無從判斷。）

　　我想題主的意思是，似乎覺得OpenStack不靠譜，很多雲平台基於OpenStack搭建之後，經常出問題，真正靠著自己研發的技術或許可以避免這個問題。

　　我想要強調一點的是，很多人誤解了OpenStack，認為OpenStack似乎是一個類似數據中心操作系統的開源產品，只要拿過來自己安裝就可以用。

　　但是，事實上這個所謂的數據中心操作系統，只是OpenStack的結果，OpenStack嚴格來說，只是提供了一套定義數據中心操作系統搭建的框架，例如作為一個數據中心，在存儲上需要實現那些目標？在計算上需要實現那些目標？在網路上需要實現那些目標？

　　然後基於這些目標，開源社區將他們分成不同的項目，最後通過社區的力量，在目標確定的前提下，大家貢獻自己的代碼和解決方案，然後通過某些評審機制，將相關解決方案加入到最終官方認可的參考發行版本中。這些方方面面的項目最後拼接在一起，就形成了我們通常認知上的OpenStack解決方案，可以安裝之後成為一個管理數據中心計算、存儲、網路、虛擬機等等相關資源的產品。

　　強調完以上的內容後，我覺得題主問題要分成兩個方面，和4點來看。純粹個人觀點，有任何繆誤，請隨意拍磚，知錯就改的好孩子一枚。

第一個方面，OpenStack到底靠譜不靠譜。

　　1.OpenStack由於出現的時間並不長，所以不像Linux一樣，有一些比較靠譜的發行版本，如論RedHat企業版、CentOS、Debian、Ubuntu。這些靠譜髮型版本經歷過歷史的考驗，在穩定性易用性和可靠性上都做到有口界碑。但即便是Liunx，方向也是有所不同的，RedHat企業版還有CentOS都是運行伺服器為主，所以功能上可能沒有那麼花哨，力求穩定，ReaHat是一個商業發行版本，所以你要付費，但是能夠獲得支持。CentOS是企業級RedHat的重構版，可以簡單的認為是非商業版本的RedHat企業版。包括Debian也是如此。Ubuntu由於在界面上做的更好，所以比較迎合初級用戶的需求，當然並不是說它不能幹更加高級的活兒。

　　但是問題在於，OpenStack沒有類似Linux世界中RedHat、CentOS、Debian、Ubuntu這些發行版本。主要原因還是在於，它的歷史太短了。所謂穩定性如何證明，簡單來說就是我在100萬台不同配置的伺服器中最長運行了超過10年，最短運行了2、3年。但是OpenStack以如此之短的歷史來說，要有同樣的宣稱，幾乎是不現實的。

　　2.OepnStack一定不靠譜？這個問題其實沒有標準答案。因為OpenStack其實只是提供了一個框架，並在這個框架下面發展了很多項目，有些你可以拿過來就用，甚至你自己一點不開發，完全用別人的組件都OK。

　　但是請記得一個問題，OpenStack是一個開源項目，且目前基本沒有商業發行版本。這意味著，你可以完全拿過來用，一點沒有問題，但是出了問題，你也要自己搞定，不會有人幫你的。

　　簡單來說，你可以在網上下載到AK47的詳細製作圖紙，你完全可以自己製造一把AK47，但是這把製造出來的AK47如果出現準度很低，後坐力過大，甚至爆膛的問題，你也只能自己默默接受，沒有任何人可以幫到你。但是如果你是合法正規途徑買來的AK47，當它出現各種問題的時候，你的供應商或者製造廠家會幫你搞定。

　　所以其實製造一把AK47並不是很困難的事情，但是要製造一把精準、後坐力小、射速快且不會爆膛的AK47，就非常考研你金屬的加工工藝、你是否能夠獲得更好的製造材料，以及你是否清晰你期望的AK47特性，並不斷向著那個特性去打磨和優化。

　　OpenStack也是類似，一個OpenStack系統如果要真正做到靠譜並能夠商業化運作，其實需要大量後期優化、測試和調試的過程。所以目前來說，大部分使用OpenStack的都是互聯網公司，因為這些的公司的程序員數量足夠多，出現問題可以投入人力物力去解決。

　　特別是OpenStack很多功能的實現，就只是功能的實現而已，有可能只是開發這個功能的團隊針對某幾個特定場景進行了功能實現，並沒有考慮多場景適配、兼容穩定性等問題。事實上，相關開發者也沒有義務考慮這些問題。

　　OpenStack放在哪裡，現狀很多人都知道，如果你沒有考慮清楚OpenStack可以幫你幹啥，出現問題你是否能夠Hold住。個人認為，即便用了OpenStack出現問題，那也是用的人、團隊或者公司有問題，而不能單純怪罪OpenStack。

第二個方面，自研難道就靠譜了么?

　　3.這個話題分開兩說，基本上我不認為目前國內各家的雲平台有所謂真正意義上的自研。代碼從0開始都是自己敲出來的。這實際上是不現實的，而且也沒有任何意義。各家的雲平台，可以說都是借鑒了各類開源組件，例如底層基於Liunx去做，hypervisor層面多數都是用的KVM，存儲基於ceph或者gsfs，網路有各種所謂SDN，系統監控基於Zabbix等等。

　　但是我又要回到第一個方面的話題了，靠譜不靠譜其實看的是人、團隊和公司。國內大量的自研，其實基本和OpenStack差不多，就是我把這些開源的軟體拿過來，拼湊起來，能夠跑起來，然後換一層皮，就算自研了。

　　4.真正意義上靠譜的自研雲平台，或者靠譜的OpenStack應該是什麼樣子的？

　　我認為，從現實的角度出發，應該基於開源去做，因為確實有很多基礎和重複的勞動完全沒有必要再去重頭做起。我們應該站在巨人的肩膀上讓自己走的更遠。

　　但是這個研發團隊，需要對那些你base on的開源組件有充分的了解，完全吃透它們。就像你會安裝Linux和你熟讀了Linux內核代碼能夠解決問題，都可以算作你會用Linux，但是兩者之間的程度和距離是大相徑庭的。

　　自研雲平台，我用現在我在的公司舉例，來說明一下什麼是靠譜的雲平台。這個雲平台也是base on各類開源組件的，但真的只是ｂase on而已，在這些開源組件的基礎上，研發團隊投入了大量的精力將這些開源組件真正「融合」到一起。

　　公司的技術創始人，也是老闆，是微軟和FaceBook出生大牛，在微軟十幾年的時間中做過數個重要產品線的首席架構師，C#、.Net Storage、AD、MSN Communities、WCF等，加入Facebook後，Facebook最初開始做分散式系統的時候，他也是主導的架構師之一。算是夠牛的一個人了吧。

　　但是他在上海創立的這家公司從2011年底成立，一直專心在雲平台的研發上，直到上個月，老闆才認為，我們在今年內可以交付一個「真正的」雲平台了，整整花了5年左右的時間。

　　所以，現在國內很多公司成立不過1、2年，就宣稱自己研發了最領先的雲平台，有多靠譜？自己感受下吧。

　　真正靠譜的自研雲平台或者雲平台，其實要驗證很簡單。我覺得兩個方面足夠。

　　1）不同組件之間是不是真正融合了。以我公司的雲平台為例，所有的計算、存儲、網路、虛擬機等等IT基礎設施的管理工作，用戶只需要用一個Portal來管理，並且非常靈活，你想要實現的所有的功能和設定，只需要打勾或者填寫參數即可，靈活到不要不要的。並且不同資源之間的相互作用都是可以看到的。並且非常有意思的一點是，老闆自己定義了一個網路協議，叫NSP，將所有相關的網路協議打包在一起，大大的簡化了網路傳輸，完全不用煩惱什麼配置埠了，安全問題也被簡化了，你主要看住這一個埠即可，其它的埠可以全部關閉。

　　多少所謂自研的雲平台，管理Portal，還都是分開的？做的好一點，把UI風格統一化，但是依舊基本是計算的歸計算、存儲的歸存儲、網路的歸網路、虛擬機的歸虛擬機，在搭建的時候還要分別配置。

　　2）上面多多少少很多人都還是懷疑。最簡單的是，解決問題的能力。

　　我還是拿公司舉例，老闆為了驗證自己的雲平台靠譜不靠譜，在2012年的時候，發布了第一個基於雲平台的應用，虛擬桌面雲，簡單來說就是VDI。VDI可能是目前企業級IT里最難做的應用。因為以下三點。

　　a.VDI和所有的最終使用者高度相關。你IT在後面搞個什麼伺服器升級、存儲升級，其實對前台使用的公司里的普通用戶而言，基本是無感的。但是VDI用虛擬桌面取代了物理機，這個和他們的體驗是高度相關的，體驗稍微差一點，大量的投訴和飛刀就向IT部門丟過來了。

　　b.VDI這個玩意兒，同時涉及到計算、存儲和網路資源的調配，任何一方面做的不好，VDI就好不起來。最簡單的，上班和下班的時候，大量用戶開機關機，導致對存儲系統有一個極大的峰值壓力，就是所謂的開機、關機風暴。以至於VDI在過去很多年，都有一個怪現象，你單一部署的規模越大，單點成本反而會上去，因為開關機風暴的峰值壓力，導致規模大了以後，你必須買EMC或者NETAPP的高端存儲才能頂得住，而高端存儲設備的價格可是數倍於普通存儲。

　　c.很多企業的關鍵傳統應用，在開發的時候只考慮了物理機環境，因此在VDI環境中部署會有各種奇葩的問題。特別是國內很多行業所謂關鍵應用，某些協議都是所謂私有協議，遇到這種問題的幾率非常之高。

　　然後，么想到的是，我們這個公司基於自己的雲平台研發的虛擬雲桌面，也就是VDI，在公司三無（沒歷史、沒名氣、沒關係）的情況下，拿下了航空、銀行、保險、教育很多行業客戶，為什麼？就是因為平台都是自己真正研發出來的，套用格力的廣告語就是掌握了核心科技，能夠解決別人解決不了的客戶問題。

　　a和b兩個難點，兩個問題是基於我們的雲平台搞定的，因為足夠好，且是分散式系統，所以計算、網路、存儲的資源都被管理運營的很好，並且由於是分散式系統，基本上VDI規模要增加，只需要單純的加伺服器就可以，目前實際最大客戶單一集群部署超過1000個點，這在國內都是不多見的，實際上要數倍於這個規模，老闆也是很有信心，只是現在沒有客戶有那麼大的需求。

　　難點c，解決用戶問題的，我就舉兩個客戶。

　　第一個是基地在上海的國內最大航空公司呼叫中心，呼叫中心上VDI的很常見，但是在我們公司服務之前，國內我是沒有聽說誰家的呼叫中心真正在生產環境實現帶內語音，也就是呼叫中心的語音通話，也是放在虛擬機的數據網路上跑。這個是一個非常難解決問題，有多難呢，我就懶得細說了，但是我們搞定了，大概用了一個月的時間搞定POC，三個月內上生產環境。

　　Citrix、VMWare包括華為算是國內市場做VDI最牛的公司了吧，在國內做的呼叫中心大大小小不知道有多少，基本上語音依舊是通過電話線，然後再虛擬機客戶端上插一張電話卡一樣的東西，實現語音功能，也就是數據網路還是走數據網路，語音還是走的傳統語音線路。多的好處我就不說了，光是那張電話卡，採購成本要多少錢，懂行的來說說就可以了。

　　第二個是我們在上海上的一個學校的項目，就是我之前說的，目前實際最大的規模的部署，單一集群內超過1000個點。教育部門指定的英語聽力考試軟體是科大訊飛研發的，不知道為什麼，這個考試軟體部署在VDI環境下，噪音很大，這是一個歷史問題了，無論誰家的VDI環境都有問題，但是一直沒有解決。實際上要求科大訊飛來重新升級考試系統，在我國目前的局面下，基本是不現實的，理由不展開，懂得自然懂。但是在我們公司這裡，兩個禮拜解決。以至於上海好幾家做類似聽力考試的軟體廠商，聽說這個問題被我們解決了以後，都跑來找我們談，希望技術合作。

　　其實這些問題和自研不自研關係都不大，關鍵是你的研發團隊要能夠吃透背後的技術實現，才能知道如何去調整去匹配去解決問題。這就是同樣是玩linux的，能夠修改內核源代碼的、熟讀內核源代碼100遍的、讀過內核源代碼的和會安裝Linux之間的區別。這也就是，同樣都是base on開源的雲平台，但是靠譜不靠譜之間的差距。

這裡有一個，https://ccmp.clustertech.com 用Go寫的精簡私有雲，提供KVM虛擬機服務。

說說我們做的YY遊戲雲吧，第一版本用的openstack，網路用的provider network加上自研網關。重構了glance利用mogilefs做鏡像存儲，RDS和緩存服務自研，用到了keystone做組件之間的交互認證。

在經歷了計算節點越來越多的情況下，openstack逐漸不能滿足需求，運維難度也越來越大，我們自研了第二個版本，完全拋棄了openstack，鏡像存儲利用ceph，虛擬機可以在幾秒內完成，所以組件之間大部分利用到了同步交互，一些組件用的消息隊列封裝了RPC，VPC方面用到了純硬體的網路，HY只用到了OVS的簡單功能（打VLAN和創建vtap），屏蔽了複雜的OVS功能，類似openstack的虛擬網路的複雜路徑等。

總結來說，其實雲計算系統超龐大和複雜，做到每一個組件都清晰可控，提高可用率比起功能更加重要。不過系統如何設計，都能在openstack找到對應的模式。

bat都不是用的openstack，大規模用openstack的有：華為，京東，蘇寧，網易，中國移動，攜程，金山，樂視雲。

美團用了部分組件，小米在用，但是去年規模還不大，現在不清楚。

基本上都是私有雲在用，公有雲國內本來就不多，用oprnstack公有雲，有點規模的，我知道的只有金山雲和京東雲

坐等有比 OpenStack牛逼的國產軟體出來。

說著不用 OpenStack的。還不都是借鑒 OpenStack的思想和模板。

OpenStack沒有出來之前，我們連一個好用的雲平台都搭建不出來。這時我們國產軟體在做什麼呢？

別抄了人家的思想和設計，到頭來噴顯得優越。有能力請為開源改進，得了實惠也請為開源做貢獻。

請不要一味得秀優越感。說自己牛逼。代碼不敢開源的原因大家都知道。

據我所知，BAT都不是用的openstack(有知友指出百度的開放雲是基於openstack的，具體沒有仔細了解過)，除此之外，青雲，ucloud也沒有採用openstack。

華為目前以openstack做了公有雲，但是他們已經大量修改了內部源碼。

以上幾家都是做公有雲的公司，之所以不採用openstack，我認為除了大公司有實力自研之外，openstack的部署規模也會是個很大的問題…目前最多支持200台物理機，再往上資料庫和消息隊列的性能就會直線下降。所以目前來看openstack做私有雲比較合適。

所以openstack的下一個版本就會著重解決大規模部署的問題。

華為雲、移動雲底層是基於openstack

華為雲雖然是基於OpenStack架構但是他對其做了一些改進增加了一些列的API介面算是不錯的了華為雲

百度雲用的就是openstack，深度坑。。。

青雲貌似也是自研。

華為雲應該是目前最大規模的OpenStack公有雲服務和私有雲解決方案提供者，官方開放的API也完全符合OpenStack Defcore認證，具體的如ecs api可以參考: 彈性雲伺服器_ECS_ 雲主機 頁面中的介面參考鏈接，我也寫過幾篇文章發表在華為雲ecs論壇上，介紹了下如何用curl來調用這些介面，比如：華為雲ECS服務API使用指南(1)-獲取虛擬機列表-雲計算服務-華為雲論壇。

OpenStack在大規模部署用於支持公有雲的問題確實很多，我也做過一些不全面的總結，比如：

OpenStack大規模部署優化實踐--穩態優化 - 雲谷計算

OpenStack大規模部署優化實踐--並發業務優化 - 雲谷計算

在雲計算時代，隨著IT應用模式的轉變，IT部門的工作逐步從最初的技術部門變為業務變革的推動者和實施者，這使得IT部門將更多的精力投入到企業業務的支持上，而不僅僅是IT技術的發展上。

　在雲計算時代，隨著IT應用模式的轉變，IT部門的工作逐步從最初的技術部門變為業務變革的推動者和實施者，這使得IT部門將更多的精力投入到企業業務
的支持上，而不僅僅是IT技術的發展上。IT技術部門潛能的發揮，體現在CIO對運營成本、信息安全等問題的日益關註上。鑒於開源在這些方面存在與生俱來
的優勢，可以預見開源必將在這些方面扮演越來越重要的角色。國外雲計算開源軟體的發展思路和運營模式無疑會為國內開源廠商帶來諸多啟示，雲計算時代的開源
發展趨勢值得研究。

　　優勢：開源的靈活性和可擴展性將助推中國雲計算技術發展

　　雲計算時代的開源與生俱來的優勢何在？從基礎架構的角度來說，雲計算的優點來自於基礎架構的靈活性和可擴展性。

　靈活性體現在用戶新應用和服務的部署方便快捷程度，大多數雲基礎架構都廣泛採用伺服器虛擬化技術，虛擬整合、虛擬分拆、虛擬遷移這些技術使得用戶專註
於"虛擬伺服器"而不是「物理伺服器」，包括虛擬伺服器配置的運行能力、操作系統和應用程序的靈活性，或者由多少個「物理伺服器」組成「虛擬伺服器」類似
的問題。在這方面，開源的靈活性給予了更多的發展空間，相對於非開源的資源，用戶更容易應對複雜的硬體環境和特有的行業應用實施。

　雲計算的可擴展性，簡單說是用戶可以根據不斷變化的資源需求隨意配置相應設備，比如存儲資源的增容等。另外，大多數應用雲基礎架構的宿主虛擬機伺服器硬
件都比典型的單一功能的伺服器更為穩定，利用率也更高。架構清晰、內核透明的開源虛擬化技術或雲操作系統在此起到了關鍵作用。

　　鑒於開源的這些優勢，在中國雲計算時代發展開源，將有利於推進雲計算產業的發展：首先，開源將促進符合用戶需求的雲計算基礎架構的成熟；其次，由於開源的透明性和安全性，雲計算相關標準更加易於形成；第三，開源將更大的發揮雲計算技術靈活性、可擴展性的優勢。

　　啟示：國外開源的基金髮展模式對中國開源發展的啟示

　　縱觀國際雲計算領域開源的發展情況，目前OpenStack和CloudStack的發展思路和運營模式在雲計算領域格外醒目。

　OpenStack由網路主機服務商Rackspace和美國宇航局合作推出，是以制定一套開源軟體標準為目的一個雲計算項目，方便用戶自己搭建靈活的
雲計算環境，OpenStack目前由一個獨立基金運作，這一方面有利於廣泛收集反饋建議、選擇最合理的結構和流程、平衡項目管理，
另一方面吸引更多參與者的積極性。而Citrix旗下的CloudStack平台是一個基於Java的開源雲計算軟體，可以加速高伸縮性的公共雲和私有雲
（IaaS）的部署、管理、配置。2012年4月CloudStack開源軟體加入Apache軟體基金會，標誌著CloudStack將提升成為一個完
全開源的Apache項目。CloudStack此舉將打破OpenStack的壟斷，在強強競爭的情況下，將會促進OpenStack和
CloudStack的共同進步和協同創新，從而使得用戶最終受益。

　　中國用戶對開源產品並不陌生，在致力於IT系統的雲計算改造
升級中，除卻成本預算和信息安全的考慮之外，中國CIO關注的是開源產品或解決方案的彈性和延續性，同時，後期服務質量也成為CIO衡量一個產品價值的標
准所在。當前，伴隨開源雲產品或解決方案的服務提供商所具備的能力尚有欠缺，這成為雲計算相關開源技術推廣應用的障礙之一；此外，國內評定開源雲產品或解
決方案的標準體系缺失、組織缺乏也是一大障礙。我們期待中國雲計算科研院所、企業單位、基金機構，能夠培育類似的開源組織，推出相應的開源產品，以彌補雲
計算時代國產基礎軟體的不足，推進中國雲計算時代開源技術的發展。
　國內雲計算技術平台中不含有在雲計算時代，隨著IT應用模式的轉變，IT部門的工作逐步從最初的技術部門變為業務變革的推動者和實施者，這使得IT部門將更多的精力投入到企業業務的支持上，而不僅僅是IT技術的發展上。

　　優勢：開源的靈活性和可擴展性將助推中國雲計算技術發展
　雲計算的可擴展性，簡單說是用戶可以根據不斷變化的資源需求隨意配置相應設備，比如存儲資源的增容等。另外，大多數應用雲基礎架構的宿主虛擬機伺服器硬
件都比典型的單一功能的伺服器更為穩定，利用率也更高。架構清晰、內核透明的開源虛擬化技術或雲操作系統在此起到了關鍵作用。

　　鑒於開源的這些優勢，在中國雲計算時代發展開源，將有利於推進雲計算產業的發展：首先，開源將促進符合用戶需求的雲計算基礎架構的成熟；其次，由於開源的透明性和安全性，雲計算相關標準更加易於形成；第三，開源將更大的發揮雲計算技術靈活性、可擴展性的優勢。
　　中國用戶對開源產品並不陌生，在致力於IT系統的雲計算改造
升級中，除卻成本預算和信息安全的考慮之外，中國CIO關注的是開源產品或解決方案的彈性和延續性，同時，後期服務質量也成為CIO衡量一個產品價值的標
准所在。當前，伴隨開源雲產品或解決方案的服務提供商所具備的能力尚有欠缺，這成為雲計算相關開源技術推廣應用的障礙之一；此外，國內評定開源雲產品或解
決方案的標準體系缺失、組織缺乏也是一大障礙。

利益相關：個人站長、35互聯A級代理、百度開放雲用戶、阿里雲用戶、百度員工。

關聯廣告：Cloudin：CloudIn雲英 - 專業的雲主機，雲伺服器，雲硬碟，雲安全等IaaS及PaaS服務提供商。非常不錯值得嘗試：）

騰訊內部IT雲，中車時代電氣，招商局，國葯集團內部生產環境在用的是品高雲（BingoCloudOS）據說是純自主研發的，他們說的理由是2010年就有著作權了，而openstack在2012年前後才有穩定版。

另一個證據是他們的雲架構中的核心部件有雲控制器，sdn控制器，分散式存儲控制器，這三個東西好像openstack中沒有。api方面是與aws兼容的有ec2，vpc，cfn，cloudwatch，sns，rds，s3，elb，autoscaling這些，而openstack沒這麼多兼容的介面

完全不依靠openstack的我估計很少，之前給某運營商做項目的時候發現華為的FusionCompute的舊版本似乎沒有基於OpenStack，當時在做組件版本基線檢查的時候發現他們雖然沒有用OpenStack整體，但是或多或少用到了一些OpenStack的技術，比如RabbitMQ、OpenVSwitch等等，但是你也不好說他是不是基於OpenStack

p.s. 青雲qingcloud似乎是自己全部自研的，我是聽前輩說的，真偽無從考證

p.s.2 openstack的意義更多是為雲ISP廠商提供一個參考模型，內部都是模塊化設計，可以整體或部分採用模塊，這個問題其實沒啥糾結的

A家不是基於Openstack搭的，具體叫什麼想不起來了，B家好像也不是