應用上云可以有多快？

1       摘要

本文介紹了為什么在一個好的公有云或私有云中必須要有一個編排系統(tǒng)來支持云上自動化，以及實現(xiàn)這個編排系統(tǒng)的困難和各家的努力。同時提供了一套實現(xiàn)編排系統(tǒng)的原型，它包括了理論分析及主體插件框架，還給出一些細節(jié)控制的建議。希望有助于大家對“資源編排 & 應用編排”概念有更深的了解，也希望以開放的心態(tài)與大家一起努力，使得云真的像水電一樣自然和普及。

2       為什么需要云上自動化

IT 領域的 自動化 要求無需多言，每個程序員都知道這是必須品。自動化腳本，自動化測試，自動化部署等等，都是為了程序及圍繞此程序的各類程序員跑的更加歡快。那么在云上我們是否還需要自動化？簡單而言，初次使用無需考慮；深度用戶需要云上自動化。具體體現(xiàn)在：

2.1       重復性的執(zhí)行動作

在云上驗證應用上線的工作中，有很多的事情是需要重復操作的。比如環(huán)境的銷毀和重建；或者擴容的場景下，重復地完成多個新實例的配置動作。一旦此類操作的頻率變高，比如一天一次或者一天多次的時候，你一定會覺得繁瑣，并且開始嘗試如何使得整個流程變的自動化，從而保證每一次執(zhí)行是可重復的。也許你會寫些 Shell 或者 Python 腳本，或者你主動調(diào)用云提供商的 API ，甚至借助某些工具如 Chef ， Puppet 來完成這個目的。

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

2.2       節(jié)約時間

在云上使用服務，有些操作是非常耗時的，比如創(chuàng)建數(shù)據(jù)庫，創(chuàng)建 VM ，都需等待分鐘級別的時間。一旦需要串行的創(chuàng)建多個耗時任務，就需要用戶持續(xù)等待一段時間。而此時如果可以將整個流程自動化，則可以釋放人為的等待過程，使程序員去完成其他更有價值的任務。

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

2.3       基礎環(huán)境的復制

這里的基礎環(huán)境是指 Infrastructure ，是指應用跑在云上所需要的所有云服務的集合。例如一個典型 Web 網(wǎng)站的 3 層架構，前端 + 后臺 + 數(shù)據(jù)庫。在云上的某個區(qū)（例如華北區(qū)）域搭建好一套完整的系統(tǒng)后，遇到需要在華南區(qū)甚至另一個云提供商的云上，重新搭建一樣的環(huán)境的時候，就會有系統(tǒng)復制的需求。是靠程序員手動一個一個組件的安裝？還是自動化的一鍵重復部署？在有后者能力的情況下，當然后者是首選。

現(xiàn)在很多云廠商都推行一個叫做 Infrastructure As Code 的概念，使用機器可以理解的配置文件，來代替人工交互式的配置動作。并且這種配置文件可以通過版本管理系統(tǒng)像代碼一樣進行版本管理。這樣對于企業(yè)的好處主要體現(xiàn)有 3 個：減小成本、提高效率、降低風險。

減小成本很好理解，如上提到的，自動化可以將人力轉移到其他任務上，提高程序員的產(chǎn)出。而效率的提升主要體現(xiàn)在通過自動化的配置可以將環(huán)境安裝的實施過程縮短，如果有多個組件或者團隊交互的話，提升效率就更明顯了。同時自動化可以消除人為的錯誤，可重復的執(zhí)行特性也提升實施過程的可靠性。

2.4       自助式服務

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

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

2.5       小結：自動化的成本

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

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

云上的自動化提供了一種可靠性，它使得云資源，云服務的每一次創(chuàng)建的行為都是一致的，任何用戶，任何組織的執(zhí)行都是可重復的；同時也消除了由于人為操作可能的失誤所帶來的問題，是云上深度用戶的必需品。

3       云上自動化演進

3.1       自動化面臨的困難

（ 1 ）云服務的種類豐富多樣，導致想要完成全面的自動化并非易事。一個典型的云平臺會提供了 ECS （虛機）， EVS （硬盤）， VPC （網(wǎng)絡）， RDS （數(shù)據(jù)庫）， ELB （負載均衡）等等一系列數(shù)都數(shù)不清的服務。有一個新的術語叫做 AWS fatigued ，就是說 AWS 每年都會上線各種新服務 & 新特性，使得用戶對新上線的服務 & 特性都感到了“ AWS 疲乏”，疲于使用。

（ 2 ）云服務間的創(chuàng)建存在復雜的依賴關系。最典型的例子就是，當創(chuàng)建 EIP 的時候，需綁定 VM ，而創(chuàng)建 CM 的時候，又需要先創(chuàng)建 Subnet ，建 Subnet 的前提就是需要先有 VPC 。層層的依賴，以及交叉依賴，都為開發(fā)者在企圖自動化的道路設置了攔路虎，使得完成自動化的成本大大提高。根據(jù)前面提到的成本大于重復性收益的時候，自動化就會被放棄。

（ 3 ）云上資源的使用方式與傳統(tǒng)方式不同。用戶從資源的完全擁有者變成資源的使用者，后臺權限的降低，導致你無法掌控一切，使得不那么方便的定位資源初始化失敗原因（也許云平臺本身的 Bug 導致）。有時候不得不聯(lián)系云提供商求助了解失敗原因。另外在使用流程上也會稍有改變，原來你的軟件包一次拷貝就到了驗證環(huán)境，而在云上，也許你需要中轉跳板才能達到目的。這些都加劇了自動化的實施困難。

3.2       自動化的嘗試

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

4       終極的自動化體系 - 編排

自動化是指一個任務流程中不需要人為的干預，而編排則是指多個任務流程可以提前規(guī)劃，任務間可以互相配合，并行或者串行的執(zhí)行 ?？梢詮淖钪苯拥亩x上看到，只有做到任意的自動化流程控制才能稱之為編排，是一個自動化的升級版。由此可見，如果某云廠商的一個編排系統(tǒng)，連一些基礎的自動化流程都無法滿足，那么它就不是一個好的編排系統(tǒng)。

4.1       云上的編排標桿

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

它的主要原理就是用戶提供創(chuàng)建對象的各種屬性，然后 CFN 協(xié)助完成對象的創(chuàng)建。例如初始化 EC2 ，就是相當于創(chuàng)建 VM 虛擬機。那么用戶就得提供屬性：主機名，用什么鏡像，硬盤多大，用什么網(wǎng)絡，主機規(guī)格，安全組等。有了這些屬性， CFN 就可以確定如何調(diào)用 EC2 的 API 來創(chuàng)建 VM 了。

它之所以能力很強是因為它除了提供執(zhí)行順序的控制能力以外，在語法層面還提供了很多的內(nèi)置函數(shù)，用戶可以通過函數(shù)來引用變量，拼接變量值，控制執(zhí)行細節(jié)。超豐富的編排對象，使得使用 CFN 基本可以滿足任意 AWS 資源的自動化創(chuàng)建。

4.2       云上編排系統(tǒng)對比

這里分析三家典型的提供編排能力的云廠商能力分析表，不對之處也請聯(lián)系糾正。（ 亞馬遜 CFN 、 阿里 ROS 、 華為 AOS ）

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

注： OpenStack 的 Heat 編排能力類似 AWS ，但是無圖形化設計器，這里就不列舉了。

4.3       編排系統(tǒng)的不足

當前的編排系統(tǒng)都需要一個描述文件，來描述用戶希望的執(zhí)行流程。一般都會把這個描述文件稱之為“模板”。通過模板來控制執(zhí)行邏輯，這并不是一個問題，因為你能看到的業(yè)界編排系統(tǒng)都有自己的 “ 模板 ” 語法規(guī)則。問題在于，從無到有的寫作一個新的模板，會比較困難，需要使用者學習一定的門檻，大家的第一感覺總是像在學習一門新的編程語言。

這個是由編排的目標對象的復雜度決定的：創(chuàng)建一個 RDS 數(shù)據(jù)庫，就是會比單獨創(chuàng)建一臺 VM ，需要有更多的控制參數(shù)。于是一種新的模板語法，相當于一種新的編程語言。寫過代碼的你肯定知道，想要快速的編碼，當然需要合適的 IDE 支撐。也正因此，一些有實力的編排系統(tǒng)就會推出相應的圖形化設計器，其定位就是配套的模板寫作 IDE 。

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

5       如何實現(xiàn)云上編排系統(tǒng)

一個編排系統(tǒng)的核心就是一個工作流引擎，負責分析各個步驟間的依賴關系，并按照 DAG （有向無環(huán)圖）模型來控制這些流程的執(zhí)行順序。而云上的編排，更加的具化，就是按依賴順序創(chuàng)建各個云服務。

算法層面，我們可以稱每個云服務為元素。創(chuàng)建各種云服務的過程，就是按順序創(chuàng)建各個元素的過程。

5.1       有向無環(huán)圖 DAG

有向無環(huán)圖 （ Directed Acyclic Graph, DAG ） , 是有向圖的一種，字面意思的理解就是圖中沒有環(huán)。常常被用來表示 事件之間的依賴關系 ，用于管理任務之間的調(diào)度。

圖：一個有向無環(huán)圖的例子

其中所有節(jié)點的 拓撲排序 是有向無環(huán)圖中經(jīng)常需要使用到的算法，我們的系統(tǒng)原型也是按照此理論基礎進行實現(xiàn)的。就是把所有元素按照 DAG 依賴關系確定好誰先誰后的順序，具體算法大家可以在網(wǎng)上或者資料中搜索獲得，這里就不細介紹了。排好序后，接下里的實現(xiàn)就是先完成底層的元素，再完成上層元素，直到所有元素都初始化完畢。以上就是我們的編排系統(tǒng)模型的理論參照。

5.2       編排系統(tǒng)原型

在這里我們假設有一個系統(tǒng)的初始化流程如下：

要實現(xiàn)所有元素按照設定好的順序創(chuàng)建，我們遵從兩個要點：（ 1 ）默認并行執(zhí)行。（ 2 ）無依賴的先執(zhí)行。具體算法實現(xiàn)上，我們首先將元素啟動順序分解為有向圖，并遍歷計算得到每個節(jié)點的依賴數(shù)。如下：

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

遵循之前的兩個原則：那么元素 B 和元素 D 的依賴數(shù)是 ，所以這兩個元素可以先執(zhí)行初始化。同時 B 和 D 之間無關，可以并行執(zhí)行。

在任意一個元素執(zhí)行完之后，所有依賴這些節(jié)點的依賴數(shù)減一，重新得到所有節(jié)點的依賴數(shù)：

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

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

5.3       元素間信息傳遞

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

     這里舉例說明，調(diào)度框架維護一個全局信息，記錄每個元素需要哪些參數(shù)才能初始化。上圖綠色的需要用戶提供，紅色的則在被依賴對象創(chuàng)建后自動獲得。比如創(chuàng)建 VM 需要 VPC 的 ID ，那么在 VPC 創(chuàng)建后， VPC 的 ID 就知道了，這個字段不用用戶提供。

所以在元素 D 初始化完成后，元素 C 就可以開始初始化了。這個時候，所有創(chuàng)建 C 的參數(shù)，都應該是確認的值。在調(diào)用 C 服務的初始化 API 的時候，不缺任何信息。這樣在實現(xiàn) C 的創(chuàng)建 API 和銷毀 API ，就非常獨立，只與 C 服務本身打交道。

  如上圖，在開發(fā)新服務的時候，只需要了解新服務自身就可以了，所有想要的信息（可以直接要求用戶提供，或者通過依賴獲得），都會通過框架管理和傳遞。

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

5.4       插件設計

5.4.1         元素的生命周期

每一種云服務對象，在編排系統(tǒng)看來都是一個元素。新增一種元素的編排，就需要該元素提供增刪改查等基礎執(zhí)行能力。編排系統(tǒng)的插件管理框架會根據(jù)用戶執(zhí)行動作，比如創(chuàng)建 or 銷毀，來調(diào)用元素對應的 API 。

有了上一節(jié)的元素執(zhí)行流程框架后，新增一個編排對象，只需要完成該元素的各種行為驅動就可以。例如：只要有創(chuàng)建和銷毀 VM 的方法（ API ），那么就可以在編排元素里面增加一個 EC2 服務，就可以在模板里面增加這種元素的編排了。調(diào)度框架只是把它當做一個普通元素來對待。

5.4.2         用戶自定義插件

    基于插件框架每個元素驅動獨立的優(yōu)勢，同時考慮到 Kubernetes 中的 Resource 對象也有自定義擴展特性（ custom resource definition ），可以設計一種元素插件支持用戶定義自己的 K8S 編排對象的能力。即把用戶提供的 “ 信息 ” 原封不動的傳遞給底層 API 。由底層系統(tǒng)去解釋用戶的 “ 信息 ” 。編排系統(tǒng)退化為只負責流程控制 + 信息傳遞通道。

5.4.3         操作的等待 & 進度

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

5.5       TOSCA 模型

有了調(diào)度框架 & 插件框架，剩下的就是配置文件的語法了，目前主要的可借鑒語法就是 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 的。鑒于容器技術的流行，越來越多的應用以獨立容器出現(xiàn)，不再強調(diào)需要傳統(tǒng)的 VM 。我們覺得模板語法使用 TOSCA 是個不錯的選擇。

實際上，在自動化的過程中，你會發(fā)現(xiàn)：模板的語法并不是關鍵點。只要能自動化，模板寫出來都不會相差太大，所以關鍵還是看自動化能力。這個就好比編程語言的選擇， Java 和 Go ，寫二叉樹遍歷不會在意是用 for 還是用 while 。各種編程語言的主要區(qū)別在內(nèi)置函數(shù) / 庫上，所以在模板的語法上提供豐富的自動化便利性才是目的。這一點需要向 AWS 學習，它提供了很多的 內(nèi)置函數(shù) 。

6       總結

在云上，自動化其實是剛需，只有完成了自動化這個基座，才能構建出完整的云生態(tài)。而編排作為一種高級自動化能力，需要負起推動云生態(tài)走向完整的重任。是檢驗一個云廠商實力的硬通貨。

華為 PaaS 團隊在云上，特別是 PaaS 云上的自動化 & 編排領域，有多年的探索和積累。在此希望能與業(yè)界一起分享并推動云上編排領域的發(fā)展，使得在云的使用過程中能帶來更好的用戶體驗，讓云上自動化能真正如云這個趨勢一樣無處不在。

目前，華為云AOS產(chǎn)品正在舉行一場應用最快上云的挑戰(zhàn)賽。

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

現(xiàn)在開始，創(chuàng)建你的應用模板，贏取豐厚禮品吧~

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