雲上自動化 vs 雲上編排

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表示「沒有此特性」。

注：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雲上的自動化&編排領域，有多年的探索和積累。在此但願能與業界一塊兒分享並推進雲上編排領域的發展，使得在雲的使用過程當中能帶來更好的用戶體驗，讓雲上自動化能真正如雲這個趨勢同樣無處不在。

若是有好的想法&建議，也能夠跟咱們交流。

本文做者：華爲PaaS架構師 唐老師

點擊關注，第一時間瞭解華爲雲新鮮技術~