如何實現雲上編排系統
一個編排系統的核心就是一個工作流引擎，負責分析各個步驟間的依賴關系，並按照DAG（有向無環圖）模型來控制這些流程的執行順序。而雲上的編排，更加的具化，就是按依賴順序創建各個雲服務。算法層面，我們可以稱每個雲服務為元素。創建各種雲服務的過程，就是按順序創建各個元素的過程。
有向無環圖DAG
有向無環圖（Directed Acyclic Graph, DAG）, 是有向圖的一種，字面意思的理解就是圖中沒有環。常常被用來表示事件之間的依賴關系，用於管理任務之間的調度。
其中所有節點的拓撲排序是有向無環圖中經常需要使用到的算法，我們的系統原型也是按照此理論基礎進行實現的。就是把所有元素按照DAG依賴關系確定好誰先誰後的順序，具體算法大家可以在網上或者資料中搜索獲得，這裏就不詳細介紹了。排好序後，接下裏的實現就是先完成底層的元素，再完成上層元素，直到所有元素都初始化完畢。以上就是我們的編排系統模型的理論參照。
編排系統原型
在這裏我們假設有一個系統的初始化流程如下：
要實現所有元素按照設定好的順序創建，我們遵從兩個要點：
?默認並行執行。
?無依賴的先執行。
具體算法實現上，我們首先將元素啟動順序分解為有向圖，並遍歷計算得到每個節點的依賴數。如下：
遵循之前的兩個原則：那麽元素B和元素D的依賴數是0，所以這兩個元素可以先執行初始化。同時B和D之間無關，可以並行執行。
在任意一個元素執行完之後，所有依賴這些節點的依賴數減一，重新得到所有節點的依賴數：
本次可以執行的元素就是C和F，因為它們的依賴數為0。在這兩個元素執行完後，將依賴他們的元素的依賴數減一，重新得到所有節點依賴數：
按照上述的邏輯遞歸執行，直到所有的元素都被執行完，整個工作流就完成了。它保證整個流程是按順序用時最短的。從工作流實現原理可知，編排的能力強弱並不強調流程控制，而是編排元素，及編排語法的豐富程度。好的編排系統，可以快速的完成新元素的驅動開發，從而提供新服務的編排能力。
元素間信息傳遞
如果每個元素初始化，都得記錄著其他元素的信息，這種在實現上元素間就很耦合。為了保持每個元素在執行時候的獨立性（即當前元素在初始化時，不用去了解其他元素的信息），主體框架需要保持一個全局信息，然後在初始化一個元素的時候，把這個元素需要的信息告訴它就行。它自己完全不知道還有哪些其他元素，反正它自己需要的信息都有了。
這裏舉例說明，調度框架維護一個全局信息，記錄每個元素需要哪些參數才能初始化。上圖綠色的需要用戶提供，紅色的則在被依賴對象創建後自動獲得。比如創建VM需要VPC的ID，那麽在VPC創建後，VPC的ID就知道了，這個字段不用用戶提供。
所以在元素D初始化完成後，元素C就可以開始初始化了。這個時候，所有創建C的參數，都應該是確認的值。在調用C服務的初始化API的時候，不缺任何信息。這樣在實現C的創建API和銷毀API，就非常獨立，只與C服務本身打交道。
在開發新服務的時候，只需要了解新服務自身就可以了，所有想要的信息（可以直接要求用戶提供，或者通過依賴獲得），都會通過框架管理和傳遞。
這就是我們的插件化框架，這個框架使得新增一種服務非常容易，因為服務的驅動開發是完全獨立的。
插件設計
1、元素的生命周期
每一種雲服務對象，在編排系統看來都是一個元素。新增一種元素的編排，就需要該元素提供增刪改查等基礎執行能力。編排系統的插件管理框架會根據用戶執行動作，比如創建or銷毀，來調用元素對應的API。
有了上一節的元素執行流程框架後，新增一個編排對象，只需要完成該元素的各種行為驅動就可以。例如：只要有創建和銷毀VM的方法（API），那麽就可以在編排元素裏面增加一個EC2服務，就可以在模板裏面增加這種元素的編排了。調度框架只是把它當做一個普通元素來對待。
2、用戶自定義插件
基於插件框架每個元素驅動獨立的優勢，同時考慮到Kubernetes中的Resource對象也有自定義擴展特性（custom resource definition），可以設計一種元素插件支持用戶定義自己的K8S編排對象的能力。即把用戶提供的“信息”原封不動的傳遞給底層API。由底層系統去解釋用戶的“信息”。編排系統退化為只負責流程控制+信息傳遞通道。
3、操作的等待&進度
之前提過，有些雲服務的操作非常耗時，如果不能提供整體進度的直觀反饋，用戶體驗就會非常的差，以為整個執行流程掛死。所以在元素驅動的編寫時，必須考慮進度和等待反饋，讓編排框架能感知執行進度。使得用戶可以知道當前在執行哪個元素，該元素的執行進度如何。從而確保整體的編排流程能夠給用戶最直接和友好的反映。
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學習，它提供了很多的內置函數。
在雲上，自動化其實是剛需，只有完成了自動化這個基座，才能構建出完整的雲生態。而編排作為一種高級自動化能力，需要負起推動雲生態走向完整的重任。是檢驗一個雲廠商實力的硬通貨。
華為PaaS團隊在雲上，特別是PaaS雲上的自動化&編排領域，有多年的探索和積累。在此希望能與業界一起分享並推動雲上編排領域的發展，使得在雲的使用過程中能帶來更好的用戶體驗，讓雲上自動化能真正如雲這個趨勢一樣無處不在。
如果有好的想法&建議，留言跟我們交流。添加weiixn群助手monicka，加入容器技術實戰交流群，更多群福利等著你
如何實現雲上編排系統