我跟OpenStack從ABC、HI到KO

2010年底，因電信級支撐平臺和業務對虛擬化的需要，我在ZTE開始了從嵌入式Linux向云計算的轉型。

當時的OpenStack版本還處于A、B、C階段，與端莊有型的CloudStack，簡潔明快的OpenNebula，高端大氣的Eucalyptus相比，可以合稱IaaS初生年代的四小龍。其中的Eucalyptus在學術圈被高談闊論，中國移動的大云用上了OpenNebula，CloudStack被Citrix給收了，免備案空間 香港服務器，OpenStack卻還在蹣跚學步。轉眼八年過去了，如今的那三位或淡出江湖，或銷聲匿跡，只有OpenStack獨霸高處，至少在開源界是四顧無人敵，所以一時難免心生唏噓。

我跟OpenStack 1-8年，從ABC到HI、到KO

由于當年這四個開源IaaS項目的前景未明，難分上下，所以我們都嘗試做了編譯部署和源碼級預研，代碼看得最多的是OpenNebula，一是因其簡單易懂的輕量級架構，二是因其采用C++實現，對于嵌入式C開發出身的團隊比較容易上手，畢竟那些年Python還沒火起來。最后集眾家之所長，我們從零起步開發了一個電信級的虛擬化管理平臺TECS，底層先是采用了Xen，后來才支持了KVM，發布之后就用在了ZTE的GoTa系統、核心網等通信業務場景中。

TECS平臺的通用支撐層中就有基于Qpid的AMQP消息隊列，利用了OpenNebula的方案，并進一步改造成了支持多線程、多進程、多節點、層次更豐富的通信模式，并利用該機制實現了一個有向無環圖的操作事務系統，支持異常事務的多個并行化步驟的集體操作回滾。當然作為支撐層，除了通信，還有Shell、定時器、序列化、數據庫、異常處理等通用組件，記得當時光是針對這個支撐層的設計方案文檔就寫了100多頁。

到了2013年，OpenStack相繼發布了Havana、IceHouse版本，仿佛暗示著該從入門ABC到了說Hi的時候了。由于電信運營商重視NFV，需要一個開放的虛擬化平臺提供支撐，演化出一個更廣闊的技術生態鏈。所以當時的團隊只能忍痛放棄了自己打造了三年的虛擬化平臺，轉向了維護OpenStack的I版本。起初總歸是有些心理排斥感，看到OpenStack的什么功能都是自己曾經玩過的，而且它對細節穩定性的要求跟電信級平臺沒法比。但是隨著業務新功能的二次開發，對OpenStack的統一服務網關入口，高度靈活的實現層動態插件化機制，單線程多協程的服務框架，頗具微服務形態的擴展思路，以及Python語言的快速實現嘆為觀止，感覺它是在用一種高屋建瓴、大開大合的理念，如同玩樂高積木一樣把無數既有的開源項目機動性地拼裝成一個達到商用級要求的龐大平臺，經過兩年的研發與維護投入，從中汲取到了豐富的架構設計經驗。

再后來，和OpenStack的緣分繼續延伸到了如今的云桌面領域。從初創時的Kilo，到2.0版本的Ocata，OpenStack已經把其它的開源IaaS項目給徹底KO了，自身也到了守江山穩社稷的階段。OpenStack代碼中最核心的五大件，keystone、nova、glance、cinder、neutron，已經牢固成型，不同版本之間主要是在實現層進行細節微調，可用性早已不是問題了。很多云平臺的實際使用者也已經很少去關注這些代碼級變化，更加關注的是自身的應用場景。

相對甘守寂寞的Linux內核圈，作為上層管理平臺級開源項目的OpenStack，操作流程性的代碼讓新人上手的速度很快，又趕上了如日中天的云計算技術高速發展期，很容易讓開發者們浮想聯翩，集體爆發，所以核心組件剛站穩腳跟，從sahara，heat開始的各種大帳篷項目便層出不窮，整體架構上的技術杠桿伸得有點長了。其實這種統一的基礎平臺性的東西，不像微信小程序、手機APP那樣的互聯網應用，它更需要豐富的現實運維經驗加上對底層實現機制的精通，匆忙趕制出來的項目，其穩定性與生產環境的可用性值得商榷。當然，這樣的形勢并不能否認其開源性質的優勢，既然是做一個普適性的大平臺，就意味著要兼收并蓄，有容乃大。它能讓無數的組件、插件、技術點來來往往，應時順勢，甚至自生自滅，但是那個核心的框架一直存在，就像帕特農神廟一樣永遠矗立著，本身就是很了不起的事。就像波普爾在《開放社會及其敵人》里面說的那樣，好的社會是開放的，開放社會就意味著會有形形色色相互矛盾的觀念。正是這種相互矛盾，讓社會具有多種選擇，多種可能，越變越好。相反，封閉的社會，是一元的、單純的，但因為這種社會失去了矛盾的對峙，失去選擇，就會一錯到底，走向倒退。

在桌面上談談OpenStack