應用編排”概念有更深的瞭解，也希望以開放的心態與大家一起努力，使得雲真的像水電一樣自然和普及。

 

IT 領域的 要求無需多言，每個程式設計師都知道這是必須品。自動化指令碼，自動化測試，自動化部署等等，都是為了程式及圍繞此程式的各類程式設計師跑的更加歡快。那麼在雲上我們是否還需要自動化？簡單而言，初次使用無需考慮；深度使用者需要雲上自動化。具體體現在：

在雲上驗證應用上線的工作中，有很多的事情是需要重複操作的。比如環境的銷燬和重建；或者擴容的場景下，重複地完成多個新例項的配置動作。一旦此類操作的頻率變高，比如一天一次或者一天多次的時候，你一定會覺得繁瑣，並且開始嘗試如何使得整個流程變的自動化，從而保證每一次執行是可重複的。也許你會寫些 Shell 或者 Python 指令碼，或者你主動呼叫雲提供商的 API ，甚至藉助某些工具如 Chef ， Puppet 來完成這個目的。

    重複是催生自動化的首要條件。

在雲上使用服務，有些操作是非常耗時的，比如建立資料庫，建立 VM ，都需等待分鐘級別的時間。一旦需要序列的建立多個耗時任務，就需要使用者持續等待一段時間。而此時如果可以將整個流程自動化，則可以釋放人為的等待過程，使程式設計師去完成其他更有價值的任務。

雲上的流程自動化後，執行動作的總體耗時並不會減少，只是這段等待時間可以被轉移，比如放在深夜執行。也正是這個原因（耗時沒有減少，只是轉移了），所以自動化後時間的節省，還是要以重複性為前途的。假如只是一次性的操作，那麼“自動化節約的時間” vs “ 完成自動化的時間”一般都是不划算的。

 

這裡的基礎環境是指 Infrastructure ，是指應用跑在雲上所需要的所有云服務的集合。例如一個典型 Web 網站的 3 層架構，前端 + 後臺 + 資料庫。在雲上的某個區（例如華北區）域搭建好一套完整的系統後，遇到需要在華南區甚至另一個雲提供商的雲上，重新搭建一樣的環境的時候，就會有系統複製的需求。是靠程式設計師手動一個一個元件的安裝？還是自動化的一鍵重複部署？在有後者能力的情況下，當然後者是首選。

現在很多雲廠商都推行一個叫做 的概念，使用機器可以理解的配置檔案，來代替人工互動式的配置動作。並且這種配置檔案可以透過版本管理系統像程式碼一樣進行版本管理。這樣對於企業的好處主要體現有 3 個：減小成本、提高效率、降低風險。

減小成本很好理解，如上提到的，自動化可以將人力轉移到其他任務上，提高程式設計師的產出。而效率的提升主要體現在透過自動化的配置可以將環境安裝的實施過程縮短，如果有多個元件或者團隊互動的話，提升效率就更明顯了。同時自動化可以消除人為的錯誤，可重複的執行特性也提升實施過程的可靠性。

雲上服務，如果做得好，應該是自助式的，就像自來水和電一樣，即開即用，按需付費。只有這樣子才可以支援任意的自動化按需供給、按需擴容，也才是雲本身所具備的含義。

所以這一條理由其實是對雲提供商提出的要求，你的雲平臺要能夠支援使用者自助式的按需使用各種雲服務，並提供相應的使用計量資訊（賬單）和使用報告。只有當平臺的後端實現流程是全自動化的，才能做到給使用者的體驗是完全自助式的。這跟淘寶商家的“有貨隨便拍”一個道理，否則沒到下單前都得跟店家溝通，無法做到按需自助式使用。

 

任何需要自動化的東西，前提就是你需要重複的執行，只有當自動化的收益大於重複的成本，才會有自動化的需求出現。假如任務只是一次性的，那就不存在自動化的需求。相反我們相信從收益方面考慮，精心人工操作一遍會比將流程自動化更為划算。

好比有時候路上遇到口渴並不會想安裝一套自來水，還不如直接買一瓶礦泉水來的實在，而在家裡，則需要安裝一套自來水系統，因為你每天都需要使用水。

雲上的自動化提供了一種可靠性，它使得雲資源，雲服務的每一次建立的行為都是一致的，任何使用者，任何組織的執行都是可重複的；同時也消除了由於人為操作可能的失誤所帶來的問題，是雲上深度使用者的必需品。

 

（ 1 ）雲服務的種類豐富多樣，導致想要完成全面的自動化並非易事。一個典型的雲平臺會提供了 ECS （虛機）， EVS （硬碟）， VPC （網路）， RDS （資料庫）， ELB （負載均衡）等等一系列數都數不清的服務。有一個新的術語叫做 AWS fatigued ，就是說 AWS 每年都會上線各種新服務 & 新特性，使得使用者對新上線的服務 & 特性都感到了“ AWS 疲乏”，疲於使用。

（ 2 ）雲服務間的建立存在複雜的依賴關係。最典型的例子就是，當建立 EIP 的時候，需繫結 VM ，而建立 CM 的時候，又需要先建立 Subnet ，建 Subnet 的前提就是需要先有 VPC 。層層的依賴，以及交叉依賴，都為開發者在企圖自動化的道路設定了攔路虎，使得完成自動化的成本大大提高。根據前面提到的成本大於重複性收益的時候，自動化就會被放棄。

（ 3 ）雲上資源的使用方式與傳統方式不同。使用者從資源的完全擁有者變成資源的使用者，後臺許可權的降低，導致你無法掌控一切，使得不那麼方便的定位資源初始化失敗原因（也許雲平臺本身的 Bug 導致）。有時候不得不聯絡雲提供商求助瞭解失敗原因。另外在使用流程上也會稍有改變，原來你的軟體包一次複製就到了驗證環境，而在雲上，也許你需要中轉跳板才能達到目的。這些都加劇了自動化的實施困難。

這裡直接給一個圖來總結了雲上自動化的嘗試歷程，可以更加直觀的瞭解這一領域的發展情況。不過在資源供給自動化和資源編排上其實邊界也沒有那麼的明顯，可以看到主要的差異是在靈活的語法上。在已有的自動化模板裡面逐步增加一些靈活的語法，基本可以達到靈活編排的目的。

 

編排

自動化是指一個任務流程中不需要人為的干預，而編排則是指多個任務流程可以提前規劃，任務間可以互相配合，並行或者序列的執行 。可以從最直接的定義上看到，只有做到任意的自動化流程控制才能稱之為編排，是一個自動化的升級版。由此可見，如果某雲廠商的一個編排系統，連一些基礎的自動化流程都無法滿足，那麼它就不是一個好的編排系統。

 

提到雲上的編排系統，就不得不提老大哥 AWS 的 了，基本上它已經是 AWS 雲生態的一個標準，支撐應用市場以及服務目錄完成任意 IT 軟體和 IT 基礎設施的初始化流程。

它的主要原理就是使用者提供建立物件的各種屬性，然後 CFN 協助完成物件的建立。例如初始化 EC2 ，就是相當於建立 VM 虛擬機器。那麼使用者就得提供屬性：主機名，用什麼映象，硬碟多大，用什麼網路，主機規格，安全組等。有了這些屬性， CFN 就可以確定如何呼叫 EC2 的 API 來建立 VM 了。

它之所以能力很強是因為它除了提供執行順序的控制能力以外，在語法層面還提供了很多的內建函式，使用者可以透過函式來引用變數，拼接變數值，控制執行細節。超豐富的編排物件，使得使用 CFN 基本可以滿足任意 AWS 資源的自動化建立。

 

這裡分析三家典型的提供編排能力的雲廠商能力分析表，不對之處也請聯絡糾正。（ 、 、 華為 AOS ）

表示“強 / 做得好”， O 表示“一般 / 待增強”， X 表示“沒有此特性”。

功能	特性	AWS	ROS	AOS	說明
模板語法	入參/物件/輸出	√	√	√	編排基本功能
	查表引數	√	√	√	Mapping 表語法，提前確認變數值
	條件部署	√	√	O	Condition 條件語法，靈活控制物件是否建立
	編排物件	√	√	O	雲服務的種類
	內建函式	√	O	O	字串拼接: Fn::Join   獲取屬性： Fn::GetAtt
	內建變數	√	√	X	AWS 中：AWS::Region     ROS中：ALIYUN::StackName
	資源啟動順序	√	√	√	如 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 ，但是無圖形化設計器，這裡就不列舉了。

當前的編排系統都需要一個描述檔案，來描述使用者希望的執行流程。一般都會把這個描述檔案稱之為“模板”。透過模板來控制執行邏輯，這並不是一個問題，因為你能看到的業界編排系統都有自己的 “ 模板 ” 語法規則。問題在於，從無到有的寫作一個新的模板，會比較困難，需要使用者學習一定的門檻，大家的第一感覺總是像在學習一門新的程式語言。

這個是由編排的目標物件的複雜度決定的：建立一個 RDS 資料庫，就是會比單獨建立一臺 VM ，需要有更多的控制引數。於是一種新的模板語法，相當於一種新的程式語言。寫過程式碼的你肯定知道，想要快速的編碼，當然需要合適的 IDE 支撐。也正因此，一些有實力的編排系統就會推出相應的圖形化設計器，其定位就是配套的模板寫作 IDE 。

比如 AWS ，阿里和華為都提供了線上的模板編輯 IDE 。設計器好壞的評價標準就是能否支撐方便的寫作模板。

 

一個編排系統的核心就是一個工作流引擎，負責分析各個步驟間的依賴關係，並按照 DAG （有向無環圖）模型來控制這些流程的執行順序。而云上的編排，更加的具化，就是按依賴順序建立各個雲服務。

演算法層面，我們可以稱每個雲服務為元素。建立各種雲服務的過程，就是按順序建立各個元素的過程。

 

（ Directed Acyclic Graph, DAG ） , 是有向圖的一種，字面意思的理解就是圖中沒有環。常常被用來表示 事件之間的依賴關係 ，用於管理任務之間的排程。

圖：一個有向無環圖的例子

其中所有節點的 是有向無環圖中經常需要使用到的演算法，我們的系統原型也是按照此理論基礎進行實現的。就是把所有元素按照 DAG 依賴關係確定好誰先誰後的順序，具體演算法大家可以在網上或者資料中搜尋獲得，這裡就不細介紹了。排好序後，接下里的實現就是先完成底層的元素，再完成上層元素，直到所有元素都初始化完畢。以上就是我們的編排系統模型的理論參照。

在這裡我們假設有一個系統的初始化流程如下：

要實現所有元素按照設定好的順序建立，我們遵從兩個要點：（ 1 ）預設並行執行。（ 2 ）無依賴的先執行。具體演算法實現上，我們首先將元素啟動順序分解為有向圖，並遍歷計算得到每個節點的依賴數。如下：

注：依賴只需要計算臨近的節點就可以。

遵循之前的兩個原則：那麼元素 B 和元素 D 的依賴數是 ，所以這兩個元素可以先執行初始化。同時 B 和 D 之間無關，可以並行執行。

在任意一個元素執行完之後，所有依賴這些節點的依賴數減一，重新得到所有節點的依賴數：

本次可以執行的元素就是 C 和 F ，因為它們的依賴數為 。在這兩個元素執行完後，將依賴他們的元素的依賴數減一，重新得到所有節點依賴數：

按照上述的邏輯遞迴執行，直到所有的元素都被執行完，整個工作流就完成了。它保證整個流程是按順序用時最短的。從工作流實現原理可知，編排的能力強弱並不強調流程控制，而是編排元素，及編排語法的豐富程度。好的編排系統，可以快速的完成新元素的驅動開發，從而提供新服務的編排能力。

如果每個元素初始化，都得記錄著其他元素的資訊，這種在實現上元素間就很耦合。為了保持每個元素在執行時候的獨立性（即當前元素在初始化時，不用去了解其他元素的資訊）。主體框架需要保持一個全域性資訊，然後在初始化一個元素的時候，把這個元素需要的資訊告訴它就行。它自己完全不知道還有哪些其他元素，反正它自己需要的資訊都有了。

     這裡舉例說明，排程框架維護一個全域性資訊，記錄每個元素需要哪些引數才能初始化。上圖綠色的需要使用者提供，紅色的則在被依賴物件建立後自動獲得。比如建立 VM 需要 VPC 的 ID ，那麼在 VPC 建立後， VPC 的 ID 就知道了，這個欄位不用使用者提供。

所以在元素 D 初始化完成後，元素 C 就可以開始初始化了。這個時候，所有建立 C 的引數，都應該是確認的值。在呼叫 C 服務的初始化 API 的時候，不缺任何資訊。這樣在實現 C 的建立 API 和銷燬 API ，就非常獨立，只與 C 服務本身打交道。

  如上圖，在開發新服務的時候，只需要瞭解新服務自身就可以了，所有想要的資訊（可以直接要求使用者提供，或者透過依賴獲得），都會透過框架管理和傳遞。

這就是我們的外掛化框架，這個框架使得新增一種服務非常容易。因為服務的驅動開發是完全獨立的。

每一種雲服務物件，在編排系統看來都是一個元素。新增一種元素的編排，就需要該元素提供增刪改查等基礎執行能力。編排系統的外掛管理框架會根據使用者執行動作，比如建立 or 銷燬，來呼叫元素對應的 API 。

有了上一節的元素執行流程框架後，新增一個編排物件，只需要完成該元素的各種行為驅動就可以。例如：只要有建立和銷燬 VM 的方法（ API ），那麼就可以在編排元素裡面增加一個 EC2 服務，就可以在模板裡面增加這種元素的編排了。排程框架只是把它當做一個普通元素來對待。

    基於外掛框架每個元素驅動獨立的優勢，同時考慮到 Kubernetes 中的 Resource 物件也有自定義擴充套件特性（ custom resource definition ），可以設計一種元素外掛支援使用者定義自己的 K8S 編排物件的能力。即把使用者提供的 “ 資訊 ” 原封不動的傳遞給底層 API 。由底層系統去解釋使用者的 “ 資訊 ” 。編排系統退化為只負責流程控制 + 資訊傳遞通道。

進度

之前提過，有些雲服務的操作非常耗時，如果不能提供整體進度的直觀反饋，使用者體驗就會非常的差，以為整個執行流程掛死。所以在元素驅動的編寫時，必須考慮進度和等待反饋，讓編排框架能感知執行進度。使得使用者可以知道當前在執行哪個元素，該元素的執行進度如何。從而確保整體的編排流程能夠給使用者最直接和友好的反映。

模型

有了排程框架 & 外掛框架，剩下的就是配置檔案的語法了，目前主要的可借鑑語法就是 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 雲上的自動化 & 編排領域，有多年的探索和積累。在此希望能與業界一起分享並推動雲上編排領域的發展，使得在雲的使用過程中能帶來更好的使用者體驗，讓雲上自動化能真正如雲這個趨勢一樣無處不在。

目前，華為雲AOS產品正在舉行一場應用最快上雲的挑戰賽。

在這裡，你可以看到全面的場景化解決方案應用上雲模板。

現在開始，建立你的應用模板，贏取豐厚禮品吧~

https://bbs.huaweicloud.com/forum/thread-11376-1-1.html