1       摘要

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

創(chuàng)新互聯(lián)建站堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的平?jīng)鼍W(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

 

2       為什么需要云上自動(dòng)化

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

2.1       重復(fù)性的執(zhí)行動(dòng)作

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

    重復(fù)是催生自動(dòng)化的首要條件。

2.2       節(jié)約時(shí)間

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

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

 

2.3       基礎(chǔ)環(huán)境的復(fù)制

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

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

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

2.4       自助式服務(wù)

云上服務(wù)，如果做得好，應(yīng)該是自助式的，就像自來(lái)水和電一樣，即開即用，按需付費(fèi)。只有這樣子才可以支持任意的自動(dòng)化按需供給、按需擴(kuò)容，也才是云本身所具備的含義。

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

 

2.5       小結(jié)：自動(dòng)化的成本

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

好比有時(shí)候路上遇到口渴并不會(huì)想安裝一套自來(lái)水，還不如直接買一瓶礦泉水來(lái)的實(shí)在，而在家里，則需要安裝一套自來(lái)水系統(tǒng)，因?yàn)槟忝刻於夹枰褂盟?/p>

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

 

3       云上自動(dòng)化演進(jìn)

3.1       自動(dòng)化面臨的困難

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

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

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

3.2       自動(dòng)化的嘗試

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

 

4       終極的自動(dòng)化體系 - 編排

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

 

4.1       云上的編排標(biāo)桿

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

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

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

 

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

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

√ 表示“強(qiáng) / 做得好”， O 表示“一般 / 待增強(qiáng)”， X 表示“沒(méi)有此特性”。

功能	特性	AWS	ROS	AOS	說(shuō)明
模板語(yǔ)法	入?yún)?對(duì)象/輸出	√	√	√	編排基本功能
	查表參數(shù)	√	√	√	Mapping 表語(yǔ)法，提前確認(rèn)變量值
	條件部署	√	√	O	Condition 條件語(yǔ)法，靈活控制對(duì)象是否創(chuàng)建
	編排對(duì)象	√	√	O	云服務(wù)的種類
	內(nèi)置函數(shù)	√	O	O	字符串拼接: Fn::Join   獲取屬性： Fn::GetAtt
	內(nèi)置變量	√	√	X	AWS 中：AWS::Region     ROS中：ALIYUN::StackName
	資源啟動(dòng)順序	√	√	√	如 DependOn 依賴關(guān)系
	頭文件引用	O	X	√	長(zhǎng)模板文件拆分為多模板文件管理
堆棧執(zhí)行	資源策略	√	X	X	如堆棧銷毀時(shí)，部分堆棧資源是否保留
	Metadata 定義	√	O	O	為對(duì)象填加自定義擴(kuò)展屬性
	堆棧嵌套	√	X	√	堆棧包含另一個(gè)堆棧，大型協(xié)作場(chǎng)景(如解決方案)需要
	幫助工具	√	X	X	如cfn-init/cfn-hup等，部署VM虛機(jī)應(yīng)用的輔助工具
	堆棧更新	√	O	O	ChangeSet ，給出詳盡變更提示
	K8S 應(yīng)用	X	X	√	編排Kubernetes生態(tài)中的應(yīng)用
設(shè)計(jì)器	元素拖拽	√	√	√
	依賴連線	√	√	√
	縮放定位	√	√	√
	圖文聯(lián)動(dòng)編輯	√	X	√	ROS 不支持IDE純文本編輯
	圖片預(yù)覽	√	√	√
	單元素編輯	√	√	√
	元素屬性聯(lián)想	X	O	√	光標(biāo)自動(dòng)聯(lián)想，給出元素可用屬性字段提示
	屬性結(jié)構(gòu)展示	X	√	√	復(fù)雜的屬性定義，免記編輯
	語(yǔ)法校驗(yàn)	√	X	√
	函數(shù)快速插入	X	O	X
	元素文檔提示	O	O	√

注： OpenStack 的 Heat 編排能力類似 AWS ，但是無(wú)圖形化設(shè)計(jì)器，這里就不列舉了。

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

當(dāng)前的編排系統(tǒng)都需要一個(gè)描述文件，來(lái)描述用戶希望的執(zhí)行流程。一般都會(huì)把這個(gè)描述文件稱之為“模板”。通過(guò)模板來(lái)控制執(zhí)行邏輯，這并不是一個(gè)問(wèn)題，因?yàn)槟隳芸吹降臉I(yè)界編排系統(tǒng)都有自己的 “ 模板 ” 語(yǔ)法規(guī)則。問(wèn)題在于，從無(wú)到有的寫作一個(gè)新的模板，會(huì)比較困難，需要使用者學(xué)習(xí)一定的門檻，大家的第一感覺(jué)總是像在學(xué)習(xí)一門新的編程語(yǔ)言。

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

比如 AWS ，阿里和華為都提供了在線的模板編輯 IDE 。設(shè)計(jì)器好壞的評(píng)價(jià)標(biāo)準(zhǔn)就是能否支撐方便的寫作模板。

 

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

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

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

 

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

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

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

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

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

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

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

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

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

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

本次可以執(zhí)行的元素就是 C 和 F ，因?yàn)樗鼈兊囊蕾嚁?shù)為 。在這兩個(gè)元素執(zhí)行完后，將依賴他們的元素的依賴數(shù)減一，重新得到所有節(jié)點(diǎn)依賴數(shù)：

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

5.3       元素間信息傳遞

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

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

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

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

這就是我們的插件化框架，這個(gè)框架使得新增一種服務(wù)非常容易。因?yàn)榉?wù)的驅(qū)動(dòng)開發(fā)是完全獨(dú)立的。

5.4       插件設(shè)計(jì)

5.4.1         元素的生命周期

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

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

5.4.2         用戶自定義插件

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

5.4.3         操作的等待 & 進(jìn)度

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

5.5       TOSCA 模型

有了調(diào)度框架 & 插件框架，剩下的就是配置文件的語(yǔ)法了，目前主要的可借鑒語(yǔ)法就是 AWS 的 Cloudformation 和 TOSCA 語(yǔ)法。其中 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” ，可見(jiàn) TOSCA 是更加偏向于面向 App 的。鑒于容器技術(shù)的流行，越來(lái)越多的應(yīng)用以獨(dú)立容器出現(xiàn)，不再?gòu)?qiáng)調(diào)需要傳統(tǒng)的 VM 。我們覺(jué)得模板語(yǔ)法使用 TOSCA 是個(gè)不錯(cuò)的選擇。

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

6       總結(jié)

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

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

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

在這里，你可以看到全面的場(chǎng)景化解決方案應(yīng)用上云模板。

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

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

當(dāng)前名稱：應(yīng)用上云可以有多快？
轉(zhuǎn)載來(lái)于：http://chinadenli.net/article8/ppghip.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、面包屑導(dǎo)航、外貿(mào)建站、定制開發(fā)、網(wǎng)站內(nèi)鏈、

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)