1 摘要
本文介紹了爲什麼在一個好的公有云或私有云中必須要有一個編排系統來支持雲上自動化，以及實現這個編排系統的困難和各家的努力。同時提供了一套實現編排系統的原型，它包括了理論分析及主體插件框架，還給出一些細節控制的建議。希望有助於大家對“資源編排&應用編排”概念有更深的瞭解，也希望以開放的心態與大家一起努力，使得雲真的像水電一樣自然和普及。
2 爲什麼需要雲上自動化
IT領域的自動化要求無需多言，每個程序員都知道這是必須品。自動化腳本，自動化測試，自動化部署等等，都是爲了程序及圍繞此程序的各類程序員跑的更加歡快。那麼在雲上我們是否還需要自動化？簡單而言，初次使用無需考慮；深度用戶需要雲上自動化。具體體現在：
2.1 重複性的執行動作
在雲上驗證應用上線的工作中，有很多的事情是需要重複操作的。比如環境的銷燬和重建；或者擴容的場景下，重複地完成多個新實例的配置動作。一旦此類操作的頻率變高，比如一天一次或者一天多次的時候，你一定會覺得繁瑣，並且開始嘗試如何使得整個流程變的自動化，從而保證每一次執行是可重複的。也許你會寫些Shell或者Python腳本，或者你主動調用雲提供商的API，甚至藉助某些工具如Chef，Puppet來完成這個目的。
重複是催生自動化的首要條件。
2.2 節約時間
在雲上使用服務，有些操作是非常耗時的，比如創建數據庫，創建VM，都需等待分鐘級別的時間。一旦需要串行的創建多個耗時任務，就需要用戶持續等待一段時間。而此時如果可以將整個流程自動化，則可以釋放人爲的等待過程，使程序員去完成其他更有價值的任務。
雲上的流程自動化後，執行動作的總體耗時並不會減少，只是這段等待時間可以被轉移，比如放在深夜執行。也正是這個原因（耗時沒有減少，只是轉移了），所以自動化後時間的節省，還是要以重複性爲前途的。假如只是一次性的操作，那麼“自動化節約的時間” vs “完成自動化的時間”一般都是不划算的。
2.3 基礎環境的複製
這裏的基礎環境是指Infrastructure，是指應用跑在雲上所需要的所有云服務的集合。例如一個典型Web網站的3層架構，前端+後臺+數據庫。在雲上的某個區（例如華北區）域搭建好一套完整的系統後，遇到需要在華南區甚至另一個雲提供商的雲上，重新搭建一樣的環境的時候，就會有系統複製的需求。是靠程序員手動一個一個組件的安裝？還是自動化的一鍵重複部署？在有後者能力的情況下，當然後者是首選。
現在很多雲廠商都推行一個叫做 Infrastructure As Code 的概念，使用機器可以理解的配置文件，來代替人工交互式的配置動作。並且這種配置文件可以通過版本管理系統像代碼一樣進行版本管理。這樣對於企業的好處主要體現有3個：減小成本、提高效率、降低風險。
減小成本很好理解，如上提到的，自動化可以將人力轉移到其他任務上，提高程序員的產出。而效率的提升主要體現在通過自動化的配置可以將環境安裝的實施過程縮短，如果有多個組件或者團隊交互的話，提升效率就更明顯了。同時自動化可以消除人爲的錯誤，可重複的執行特性也提升實施過程的可靠性。
2.4 自助式服務
雲上服務，如果做得好，應該是自助式的，就像自來水和電一樣，即開即用，按需付費。只有這樣子纔可以支持任意的自動化按需供給、按需擴容，也纔是雲本身所具備的含義。
所以這一條理由其實是對雲提供商提出的要求，你的雲平臺要能夠支持用戶自助式的按需使用各種雲服務，並提供相應的使用計量信息（賬單）和使用報告。只有當平臺的後端實現流程是全自動化的，才能做到給用戶的體驗是完全自助式的。這跟淘寶商家的“有貨隨便拍”一個道理，否則沒到下單前都得跟店家溝通，無法做到按需自助式使用。
2.5 小結：自動化的成本
任何需要自動化的東西，前提就是你需要重複的執行，只有當自動化的收益大於重複的成本，纔會有自動化的需求出現。假如任務只是一次性的，那就不存在自動化的需求。相反我們相信從收益方面考慮，精心人工操作一遍會比將流程自動化更爲划算。
好比有時候路上遇到口渴並不會想安裝一套自來水，還不如直接買一瓶礦泉水來的實在，而在家裏，則需要安裝一套自來水系統，因爲你每天都需要使用水。
雲上的自動化提供了一種可靠性，它使得雲資源，雲服務的每一次創建的行爲都是一致的，任何用戶，任何組織的執行都是可重複的；同時也消除了由於人爲操作可能的失誤所帶來的問題，是雲上深度用戶的必需品。
3 雲上自動化演進
3.1 自動化面臨的困難
（1）雲服務的種類豐富多樣，導致想要完成全面的自動化並非易事。一個典型的雲平臺會提供了ECS（虛機），EVS（硬盤），VPC（網絡），RDS（數據庫），ELB（負載均衡）等等一系列數都數不清的服務。有一個新的術語叫做 AWS fatigued，就是說AWS每年都會上線各種新服務&新特性，使得用戶對新上線的服務&特性都感到了“AWS疲乏”，疲於使用。
（2）雲服務間的創建存在複雜的依賴關係。最典型的例子就是，當創建EIP的時候，需綁定VM，而創建CM的時候，又需要先創建Subnet，建Subnet的前提就是需要先有VPC。層層的依賴，以及交叉依賴，都爲開發者在企圖自動化的道路設置了攔路虎，使得完成自動化的成本大大提高。根據前面提到的成本大於重複性收益的時候，自動化就會被放棄。
（3）雲上資源的使用方式與傳統方式不同。用戶從資源的完全擁有者變成資源的使用者，後臺權限的降低，導致你無法掌控一切，使得不那麼方便的定位資源初始化失敗原因（也許雲平臺本身的Bug導致）。有時候不得不聯繫雲提供商求助瞭解失敗原因。另外在使用流程上也會稍有改變，原來你的軟件包一次拷貝就到了驗證環境，而在雲上，也許你需要中轉跳板才能達到目的。這些都加劇了自動化的實施困難。
3.2 自動化的嘗試
這裏直接給一個圖來總結了雲上自動化的嘗試歷程，可以更加直觀的瞭解這一領域的發展情況。不過在資源供給自動化和資源編排上其實邊界也沒有那麼的明顯，可以看到主要的差異是在靈活的語法上。在已有的自動化模板裏面逐步增加一些靈活的語法，基本可以達到靈活編排的目的。
4 終極的自動化體系-編排
自動化是指一個任務流程中不需要人爲的干預，而編排則是指多個任務流程可以提前規劃，任務間可以互相配合，並行或者串行的執行。可以從最直接的定義上看到，只有做到任意的自動化流程控制才能稱之爲編排，是一個自動化的升級版。由此可見，如果某雲廠商的一個編排系統，連一些基礎的自動化流程都無法滿足，那麼它就不是一個好的編排系統。
4.1 雲上的編排標杆
提到雲上的編排系統，就不得不提老大哥AWS的Cloudformation了，基本上它已經是AWS雲生態的一個標準，支撐應用市場以及服務目錄完成任意IT軟件和IT基礎設施的初始化流程。
它的主要原理就是用戶提供創建對象的各種屬性，然後CFN協助完成對象的創建。例如初始化EC2，就是相當於創建VM虛擬機。那麼用戶就得提供屬性：主機名，用什麼鏡像，硬盤多大，用什麼網絡，主機規格，安全組等。有了這些屬性，CFN就可以確定如何調用EC2的API來創建VM了。
它之所以能力很強是因爲它除了提供執行順序的控制能力以外，在語法層面還提供了很多的內置函數，用戶可以通過函數來引用變量，拼接變量值，控制執行細節。超豐富的編排對象，使得使用CFN基本可以滿足任意AWS資源的自動化創建。
4.2 雲上編排系統對比
這裏分析三家典型的提供編排能力的雲廠商能力分析表，不對之處也請聯繫糾正。（亞馬遜CFN、阿里ROS、華爲AOS）
√表示“強/做得好”，O表示“一般/待增強”，X表示“沒有此特性”。
|
功能 |
特性 |
AWS |
ROS |
AOS |
說明 |
|
模板語法 |
入參/對象/輸出 |
√ |
√ |
√ |
編排基本功能 |
|
查表參數 |
√ |
√ |
√ |
Mapping表語法，提前確認變量值 |
|
|
條件部署 |
√ |
√ |
O |
Condition條件語法，靈活控制對象是否創建 |
|
|
編排對象 |
√ |
√ |
O |
雲服務的種類 |
|
|
內置函數 |
√ |
O |
O |
字符串拼接: Fn::Join |
|
|
內置變量 |
√ |
√ |
X |
AWS中：AWS::Region
|
|
|
資源啓動順序 |
√ |
√ |
√ |
如 DependOn 依賴關係 |
|
|
頭文件引用 |
O |
X |
√ |
長模板文件拆分爲多模板文件管理 |
|
|
堆棧執行 |
資源策略 |
√ |
X |
X |
如堆棧銷燬時，部分堆棧資源是否保留 |
|
Metadata定義 |
√ |
O |
O |
爲對象填加自定義擴展屬性 |
|
|
堆棧嵌套 |
√ |
X |
√ |
堆棧包含另一個堆棧，大型協作場景(如解決方案)需要 |
|
|
幫助工具 |
√ |
X |
X |
如cfn-init/cfn-hup等，部署VM虛機應用的輔助工具 |
|
|
堆棧更新 |
√ |
O |
O |
ChangeSet，給出詳盡變更提示 |
|
|
K8S應用 |
X |
X |
√ |
編排Kubernetes生態中的應用 |
|
|
設計器 |
元素拖拽 |
√ |
√ |
√ |
|
|
依賴連線 |
√ |
√ |
√ |
|
|
|
縮放定位 |
√ |
√ |
√ |
|
|
|
圖文聯動編輯 |
√ |
X |
√ |
ROS不支持IDE純文本編輯 |
|
|
圖片預覽 |
√ |
√ |
√ |
|
|
|
單元素編輯 |
√ |
√ |
√ |
|
|
|
元素屬性聯想 |
X |
O |
√ |
光標自動聯想，給出元素可用屬性字段提示 |
|
|
屬性結構展示 |
X |
√ |
√ |
複雜的屬性定義，免記編輯 |
|
|
語法校驗 |
√ |
X |
√ |
|
|
|
函數快速插入 |
X |
O |
X |
|
|
|
元素文檔提示 |
O |
O |
√ |
|
注：OpenStack的Heat編排能力類似AWS，但是無圖形化設計器，這裏就不列舉了。
4.3 編排系統的不足
當前的編排系統都需要一個描述文件，來描述用戶希望的執行流程。一般都會把這個描述文件稱之爲“模板”。通過模板來控制執行邏輯，這並不是一個問題，因爲你能看到的業界編排系統都有自己的“模板”語法規則。問題在於，從無到有的寫作一個新的模板，會比較困難，需要使用者學習一定的門檻，大家的第一感覺總是像在學習一門新的編程語言。
這個是由編排的目標對象的複雜度決定的：創建一個RDS數據庫，就是會比單獨創建一臺VM，需要有更多的控制參數。於是一種新的模板語法，相當於一種新的編程語言。寫過代碼的你肯定知道，想要快速的編碼，當然需要合適的IDE支撐。也正因此，一些有實力的編排系統就會推出相應的圖形化設計器，其定位就是配套的模板寫作IDE。
比如AWS，阿里和華爲都提供了在線的模板編輯IDE。設計器好壞的評價標準就是能否支撐方便的寫作模板。
5 如何實現雲上編排系統
一個編排系統的核心就是一個工作流引擎，負責分析各個步驟間的依賴關係，並按照DAG（有向無環圖）模型來控制這些流程的執行順序。而云上的編排，更加的具化，就是按依賴順序創建各個雲服務。
算法層面，我們可以稱每個雲服務爲元素。創建各種雲服務的過程，就是按順序創建各個元素的過程。
5.1 有向無環圖DAG
有向無環圖（Directed Acyclic Graph, DAG）, 是有向圖的一種，字面意思的理解就是圖中沒有環。常常被用來表示事件之間的依賴關係，用於管理任務之間的調度。
圖：一個有向無環圖的例子
其中所有節點的拓撲排序是有向無環圖中經常需要使用到的算法，我們的系統原型也是按照此理論基礎進行實現的。就是把所有元素按照DAG依賴關係確定好誰先誰後的順序，具體算法大家可以在網上或者資料中搜索獲得，這裏就不細介紹了。排好序後，接下里的實現就是先完成底層的元素，再完成上層元素，直到所有元素都初始化完畢。以上就是我們的編排系統模型的理論參照。
5.2 編排系統原型
在這裏我們假設有一個系統的初始化流程如下：
要實現所有元素按照設定好的順序創建，我們遵從兩個要點：（1）默認並行執行。（2）無依賴的先執行。具體算法實現上，我們首先將元素啓動順序分解爲有向圖，並遍歷計算得到每個節點的依賴數。如下：
注：依賴只需要計算臨近的節點就可以。
遵循之前的兩個原則：那麼元素B和元素D的依賴數是0，所以這兩個元素可以先執行初始化。同時B和D之間無關，可以並行執行。
在任意一個元素執行完之後，所有依賴這些節點的依賴數減一，重新得到所有節點的依賴數：
本次可以執行的元素就是C和F，因爲它們的依賴數爲0。在這兩個元素執行完後，將依賴他們的元素的依賴數減一，重新得到所有節點依賴數：
按照上述的邏輯遞歸執行，直到所有的元素都被執行完，整個工作流就完成了。它保證整個流程是按順序用時最短的。從工作流實現原理可知，編排的能力強弱並不強調流程控制，而是編排元素，及編排語法的豐富程度。好的編排系統，可以快速的完成新元素的驅動開發，從而提供新服務的編排能力。
5.3 元素間信息傳遞
如果每個元素初始化，都得記錄着其他元素的信息，這種在實現上元素間就很耦合。爲了保持每個元素在執行時候的獨立性（即當前元素在初始化時，不用去了解其他元素的信息）。主體框架需要保持一個全局信息，然後在初始化一個元素的時候，把這個元素需要的信息告訴它就行。它自己完全不知道還有哪些其他元素，反正它自己需要的信息都有了。
這裏舉例說明，調度框架維護一個全局信息，記錄每個元素需要哪些參數才能初始化。上圖綠色的需要用戶提供，紅色的則在被依賴對象創建後自動獲得。比如創建VM需要VPC的ID，那麼在VPC創建後，VPC的ID就知道了，這個字段不用用戶提供。
所以在元素D初始化完成後，元素C就可以開始初始化了。這個時候，所有創建C的參數，都應該是確認的值。在調用C服務的初始化API的時候，不缺任何信息。這樣在實現C的創建API和銷燬API，就非常獨立，只與C服務本身打交道。
如上圖，在開發新服務的時候，只需要瞭解新服務自身就可以了，所有想要的信息（可以直接要求用戶提供，或者通過依賴獲得），都會通過框架管理和傳遞。
這就是我們的插件化框架，這個框架使得新增一種服務非常容易。因爲服務的驅動開發是完全獨立的。
5.4 插件設計
5.4.1 元素的生命週期
每一種雲服務對象，在編排系統看來都是一個元素。新增一種元素的編排，就需要該元素提供增刪改查等基礎執行能力。編排系統的插件管理框架會根據用戶執行動作，比如創建or銷燬，來調用元素對應的API。
有了上一節的元素執行流程框架後，新增一個編排對象，只需要完成該元素的各種行爲驅動就可以。例如：只要有創建和銷燬VM的方法（API），那麼就可以在編排元素裏面增加一個EC2服務，就可以在模板裏面增加這種元素的編排了。調度框架只是把它當做一個普通元素來對待。
5.4.2 用戶自定義插件
基於插件框架每個元素驅動獨立的優勢，同時考慮到Kubernetes中的Resource對象也有自定義擴展特性（custom resource definition），可以設計一種元素插件支持用戶定義自己的K8S編排對象的能力。即把用戶提供的“信息”原封不動的傳遞給底層API。由底層系統去解釋用戶的“信息”。編排系統退化爲只負責流程控制+信息傳遞通道。
5.4.3 操作的等待&進度
之前提過，有些雲服務的操作非常耗時，如果不能提供整體進度的直觀反饋，用戶體驗就會非常的差，以爲整個執行流程掛死。所以在元素驅動的編寫時，必須考慮進度和等待反饋，讓編排框架能感知執行進度。使得用戶可以知道當前在執行哪個元素，該元素的執行進度如何。從而確保整體的編排流程能夠給用戶最直接和友好的反映。
5.5 TOSCA模型
有了調度框架&插件框架，剩下的就是配置文件的語法了，目前主要的可借鑑語法就是AWS的Cloudformation和TOSCA語法。其中AWS-CFN是以資源初始化爲中心的，而TOSCA的定義爲TOSCA is a specification that aims to standardize how we describe software applications and everything that is required for them to run in the “cloud”，可見TOSCA是更加偏向於面向App的。鑑於容器技術的流行，越來越多的應用以獨立容器出現，不再強調需要傳統的VM。我們覺得模板語法使用TOSCA是個不錯的選擇。
實際上，在自動化的過程中，你會發現：模板的語法並不是關鍵點。只要能自動化，模板寫出來都不會相差太大，所以關鍵還是看自動化能力。這個就好比編程語言的選擇，Java和Go，寫二叉樹遍歷不會在意是用for還是用while。各種編程語言的主要區別在內置函數/庫上，所以在模板的語法上提供豐富的自動化便利性纔是目的。這一點需要向AWS學習，它提供了很多的內置函數。
6 總結
在雲上，自動化其實是剛需，只有完成了自動化這個基座，才能構建出完整的雲生態。而編排作爲一種高級自動化能力，需要負起推動雲生態走向完整的重任。是檢驗一個雲廠商實力的硬通貨。
華爲PaaS團隊在雲上，特別是PaaS雲上的自動化&編排領域，有多年的探索和積累。在此希望能與業界一起分享並推動雲上編排領域的發展，使得在雲的使用過程中能帶來更好的用戶體驗，讓雲上自動化能真正如雲這個趨勢一樣無處不在。
目前，華爲雲AOS產品正在舉行一場應用最快上雲的挑戰賽。
在這裏，你可以看到全面的場景化解決方案應用上雲模板。
現在開始，創建你的應用模板，贏取豐厚禮品吧~
https://bbs.huaweicloud.com/forum/thread-11376-1-1.html