如何跨云實(shí)現(xiàn)應(yīng)用部署管理

時(shí)至今日，云計(jì)算憑借其彈性、可擴(kuò)展性、易維護(hù)性，已經(jīng)被大多數(shù)的企業(yè)所采用，而多云管理將成為企業(yè)云戰(zhàn)略的下一個(gè)熱點(diǎn)。多云擁有諸多優(yōu)點(diǎn)的同時(shí)也帶來了挑戰(zhàn)，比如管理復(fù)雜。在多云環(huán)境下，用戶希望屏蔽底層資源的復(fù)雜性，擁有一個(gè)可統(tǒng)一管理各種應(yīng)用的服務(wù)平臺(tái)，來降低運(yùn)維和管理的復(fù)雜性。

OpenPitrix 是一個(gè)多云應(yīng)用管理系統(tǒng)，目標(biāo)是 Run Any Application at Any Scale on Any Infrastructure(能夠?qū)⑷魏螒?yīng)用以任何規(guī)模部署在任何基礎(chǔ)設(shè)施上)，能夠一站式管理企業(yè)各種類型的應(yīng)用，讓用戶可以把精力專注于核心業(yè)務(wù)層。

本次內(nèi)容為青云QingCloud 應(yīng)用平臺(tái)顧問工程師遲連義在 2018 年 QCon 全球軟件開發(fā)大會(huì)北京站上演講內(nèi)容整理而來。

以下為本次分享的內(nèi)容整理

多云 Multiple Runtime，是指多個(gè)云服務(wù)提供商的服務(wù)應(yīng)用管理平臺(tái)，和一般云管理平臺(tái) (CMP) 的區(qū)別是：一般的云管理平臺(tái)是管理云的基礎(chǔ)資源也就是我們俗稱的 IaaS，而應(yīng)用管理平臺(tái)是管理應(yīng)用程序, 這些應(yīng)用程序可以是單節(jié)點(diǎn)，可以是多節(jié)點(diǎn)、多角色的，節(jié)點(diǎn)之間交互時(shí)需要配合上網(wǎng)絡(luò)、負(fù)載均衡器、存儲(chǔ)等資源，也就是我們俗稱的 PaaS。

多云部署與管理是趨勢(shì)

我們?yōu)槭裁匆プ龆嘣茟?yīng)用管理平臺(tái)。

今年 1 月份的時(shí)候，在知名云服務(wù)商 RightScale 公布的一份年度云狀況調(diào)查報(bào)告中顯示，采用多云管理的企業(yè)占受訪的 81%，這充分說明多云是未來企業(yè)上云的一個(gè)大趨勢(shì)。

多云的好處很多，很重要的一個(gè)因素防止被單個(gè)云服務(wù)提供商綁定，跨多個(gè)云服務(wù)提供商可以對(duì)沖風(fēng)險(xiǎn)，再者，每個(gè)云服務(wù)商的產(chǎn)品各有優(yōu)劣，比如有的云存儲(chǔ)功能強(qiáng)大，有的云數(shù)據(jù)庫產(chǎn)品更穩(wěn)定，采用多云可以充分利用其優(yōu)勢(shì)產(chǎn)品。

使用單云架構(gòu)時(shí)，可以直接用這個(gè)云提供商所提供的成熟的管理工具或管理界面就可以了，但在多云環(huán)境下，用戶希望能有一個(gè)統(tǒng)一的界面管理多個(gè)云服務(wù)，來降低運(yùn)維和管理的復(fù)雜性。

應(yīng)用是最貼近需求的，所以一個(gè)多云應(yīng)用管理系統(tǒng)更具有市場(chǎng)需求，這樣用戶可以把更多的精力放在核心的業(yè)務(wù)層。同時(shí)企業(yè)可能有各種類型的應(yīng)用需要管理，包括傳統(tǒng)的應(yīng)用，像數(shù)據(jù)庫、Tomcat、Hadoop，還有基于微服務(wù)架構(gòu)的應(yīng)用、以及近來發(fā)展迅猛的 Serverless 應(yīng)用等。企業(yè)需要一個(gè)可以管理不同類型應(yīng)用程序的一站式管理平臺(tái)。

俗話講「格局有多大，成就就有多大」，做項(xiàng)目也是這樣，既然我們做「多云應(yīng)用管理平臺(tái)」，我們的目標(biāo)就是形成一個(gè)應(yīng)用市場(chǎng)生態(tài)系統(tǒng)，各種企業(yè)開發(fā)者都可以在這個(gè)平臺(tái)上開發(fā)他們擅長(zhǎng)的 App，并便捷的提供在線運(yùn)維和幫助，這些開發(fā)好的 App 提供給其他企業(yè)用戶去使用，開發(fā)者可以盈利，使用者可以跳過手動(dòng)搭建和維護(hù)的流程，使用現(xiàn)成的產(chǎn)品。

為了做成生態(tài)這個(gè)目標(biāo)，從一開始這個(gè)項(xiàng)目就是以開源的方式進(jìn)行，包括討論、設(shè)計(jì)、代碼都是在 GitHub 上完成的。

還有一個(gè)很主要的原因，我們幾年前就開始開發(fā)應(yīng)用上云的平臺(tái)，2015 年 5 月發(fā)布了 AppCenter 的第一個(gè)正式版本，在 2017 年初發(fā)布了 AppCenter 2.0，旨在讓開發(fā)者以最低的學(xué)習(xí)成本幾天將應(yīng)用部署到云平臺(tái)上，這個(gè)平臺(tái)提供應(yīng)用的服務(wù)感知、彈性伸縮、配置變更等云計(jì)算基礎(chǔ)特性。而且還為開發(fā)者提供便捷的管理、日志、監(jiān)控、財(cái)務(wù)、工單等功能，最終用戶在應(yīng)用市場(chǎng)很便捷的找到自己需要的各種應(yīng)用，通過一鍵部署來使用。

AppCenter 平臺(tái)自去年 3 月份發(fā)布以來，已經(jīng)陸續(xù)上線了一百多個(gè)不同企業(yè)開發(fā)者所開發(fā)的 App，其中涵蓋了：大數(shù)據(jù)、AI、容器、 區(qū)塊鏈等各種領(lǐng)域的應(yīng)用。但 AppCenter 底層只兼容青云的 IaaS，我們的私有云用戶也有 AppCenter 的需求，但私有云一般有多個(gè)云部署環(huán)境，所以客戶提出 AppCenter 兼容其它云廠商的要求。

多云+應(yīng)用+開源

這就是多云應(yīng)用管理平臺(tái)誕生的由來，我們給他起的名字叫做：OpenPitrix，集多云，應(yīng)用管理，開源于一身的項(xiàng)目。這個(gè)名字的由來，Pitrix 是 PaaS + IaaS + Matrix (矩陣) 三個(gè)詞的一個(gè)集合，這個(gè)其實(shí)是青云內(nèi)部的項(xiàng)目的名字。我們拿來用了，前面加上 Open 即表示這個(gè)項(xiàng)目是開源的，也表明我們開放的心態(tài)。

OpenPitrix 想實(shí)現(xiàn)的是 Run any application at any scale on any infrastructure，也就是通過 OpenPitrix 這個(gè)平臺(tái)可以將任何類型的應(yīng)用部署到任何類型的基礎(chǔ)設(shè)施上面。對(duì)于開發(fā)者來說就是 Build Once，Run Anywhere。

OpenPitrix 所能提供的功能，主要有 4 大塊。

首先是多云平臺(tái)的支持。

云平臺(tái)可以是 AWS，可以使 OpenStack，既可以是基于 VM 的，也可以是基于容器的， 可以是公有云，也可以是私有云。 針對(duì)于平臺(tái)提供商，OpenPitrix 會(huì)提供相應(yīng)的 ProviderPlugin 插件，去調(diào)用相應(yīng)云平臺(tái)提供商的 API 來管理運(yùn)行在其上的應(yīng)用。

第二個(gè)是多應(yīng)用類型的支持。

各種類型的應(yīng)用都會(huì)支持，很多企業(yè)使用的是傳統(tǒng)應(yīng)用，他們希望在不改變其現(xiàn)有架構(gòu)的情況下將其應(yīng)用上云，所以這些傳統(tǒng)應(yīng)用是需要支持的。

這些傳統(tǒng)應(yīng)用既可以是典型的基于三層架構(gòu)的軟件，也可以是各種分布式軟件：Hadoop 這種主從結(jié)構(gòu)、ZooKeeper 這種 Peer to Peer 結(jié)構(gòu)、Redis Cluster 這種分片結(jié)構(gòu)都可以被 OpenPitrix 所管理。

微服務(wù)架構(gòu)是大趨勢(shì)，所以微服務(wù)類型的應(yīng)用我們也會(huì)支持，微服務(wù)應(yīng)用往往是容器化的，在容器的編排方面，開源項(xiàng)目 Kubernetes 已經(jīng)是事實(shí)上的標(biāo)準(zhǔn)，因此，OpenPitrix 會(huì)支持 Kubernetes。Helm 是一個(gè)非常不錯(cuò)的 Kubernetes 包管理器，提供了打包、部署等功能。 在第一版 OpenPitrix 中，我們使用 Helm 作為 Kubernetes 應(yīng)用程序的部署工具，來提供微服務(wù)類型應(yīng)用的部署。

Serverless 應(yīng)用我們也會(huì)支持，但目前來講，由于 Severless 應(yīng)用還沒有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)，第一個(gè)版本暫不支持，會(huì)持續(xù)關(guān)注其發(fā)展。

第三個(gè)功能就是高度可擴(kuò)展和可插拔。

既包括云平臺(tái)的支持，也包括應(yīng)用類型的支持，這樣無論未來出現(xiàn)了何種新的云服務(wù)商，或者是新的應(yīng)用類型，都可通過添加相應(yīng)插件的方式支持它。

第四是可商業(yè)運(yùn)營(yíng)。

我們最大限度解耦應(yīng)用和應(yīng)用所運(yùn)行的云環(huán)境，一方面讓開發(fā)者便捷的開發(fā) App，同時(shí)平臺(tái)為其提供管理和運(yùn)維、計(jì)量計(jì)費(fèi)、查看報(bào)表及統(tǒng)計(jì)信息等，應(yīng)用可以放到公共市場(chǎng)，或者專有市場(chǎng)上去售賣。 另一方面用戶可以在其所擁有的云運(yùn)行環(huán)境上，部署相應(yīng)的 App。任何基于 OpenPitrix 開發(fā)的應(yīng)用， 都可以在任何基于 OpenPitrix 的應(yīng)用管理平臺(tái)上售賣。

OpenPitrix 架構(gòu)

OpenPitrix 在設(shè)計(jì)之初，就決定以微服務(wù)框架的方式進(jìn)行開發(fā)。微服務(wù)相較于單體應(yīng)用有很多優(yōu)點(diǎn)，比如降低復(fù)雜性，可獨(dú)立開發(fā)、部署、升級(jí)和擴(kuò)展等。

在 OpenPitrix 里面，我們拆分出了五個(gè)微服務(wù)：Repo、App、Runtime、Cluster、Pilot。

App 是提供應(yīng)用開發(fā)，注冊(cè)等功能的服務(wù);

1:Repo 上是有很多個(gè) App、App 組，類似于市場(chǎng)的概念。

2:Runtime 是一個(gè)具體的云運(yùn)行時(shí)環(huán)境，可以是某個(gè)公有云的某個(gè) Zone，也可以是私有云的某個(gè) Zone。

3:Cluster 服務(wù)是管理部署在某個(gè) Runtime 里應(yīng)用實(shí)例生命周期的服務(wù)，包括創(chuàng)建、升級(jí)、擴(kuò)容、刪除等操作。

4:Pilot 這個(gè)服務(wù)提供了 OpenPitrix 可以和部署到某個(gè) Runtime 里面應(yīng)用實(shí)例進(jìn)行雙向請(qǐng)求的能力。

每個(gè)微服務(wù)有自己的服務(wù)進(jìn)程，有自己的數(shù)據(jù)庫，一個(gè)服務(wù)的數(shù)據(jù)庫也不可以被其他服務(wù)直接訪問，因?yàn)槊總€(gè)服務(wù)是獨(dú)立開發(fā)的，這樣可以確保單個(gè)服務(wù)的表結(jié)構(gòu)修改不會(huì)影響到其他服務(wù)。

持久層框架選擇的 DBR，是因?yàn)檫@個(gè)框架沒有其他依賴，代碼簡(jiǎn)單，易于維護(hù)。

數(shù)據(jù)庫遷移工具，選擇的 Flyway，可以在子服務(wù)啟動(dòng)之前構(gòu)建好數(shù)據(jù)庫以及表結(jié)構(gòu)，并可處理后續(xù)的數(shù)據(jù)庫遷移工作。

對(duì)外提供 DashBoard 和命令行工具 CLI，外部訪問都是通過 Restful API，經(jīng)由統(tǒng)一的 API Gateway。Api Gateway 在經(jīng)過內(nèi)部路由將請(qǐng)求轉(zhuǎn)發(fā)給具體的某個(gè)微服務(wù)上，各服務(wù)之間的通信屬于內(nèi)部通信，通過 GRPC 來實(shí)現(xiàn)，選擇 GRPC 而沒有用 Restful，由于其是二進(jìn)制協(xié)議，相比于 Restful 的 HTTP 協(xié)議性能更高。

各服務(wù)之間會(huì)使用統(tǒng)一的一套 ETCD 服務(wù)，該服務(wù)提供配置更新\全局鎖\消息隊(duì)列等功能。

采用微服務(wù)設(shè)計(jì)，OpenPitrix 可以很方便的容器化，部署在容器平臺(tái)中，比如 Kubernetes，并享用 Kubernetes 所提供的微服務(wù)治理功能，像服務(wù)發(fā)現(xiàn)、監(jiān)控、負(fù)載均衡等。

解耦應(yīng)用和其所運(yùn)行的云環(huán)境

先看右下角，Runtime 是云的運(yùn)行時(shí)環(huán)境，有 Provider 的屬性，也就是云提供商，根據(jù) Provider 用具體的 ProviderPlugin 去操作，Runtime 可以打標(biāo)簽 Labels。

每個(gè) App 都可以用一個(gè)應(yīng)用配置包來描述，這個(gè)配置包的內(nèi)容后面會(huì)介紹。應(yīng)用的配置包都是位于 App Repo 上面，App Repo 可以是 GitHub，也可以是某個(gè)云服務(wù)商提供的對(duì)象存儲(chǔ)。

App Repo 也可以打標(biāo)簽，比如 Sorftware = DataBase 表示這個(gè) Repo 上的 App 都是數(shù)據(jù)庫相關(guān)的，App Repo 有個(gè) Provider 屬性，這是為了標(biāo)記當(dāng)前 Repo 上的 App 能夠部署到哪些 Provider 的 Runtime 中去。Selector 是可以針對(duì) Runtime 的 Label 進(jìn)行檢索的屬性。

舉個(gè)例子，開發(fā)者正在開發(fā)一款 MySQL 應(yīng)用，開發(fā)中狀態(tài)也就不是穩(wěn)定版本，開發(fā)者將這個(gè) App 上傳到了第二個(gè) App Repo 里面，Label 是 Sorftware = DataBase，這個(gè) Repo 的 Provider 屬性是 OpenStack 和 AWS，同 Key 是 or 的關(guān)系，不同 Key 是 and 的關(guān)系，也就是可以部署在這兩個(gè) Provider 的 Runtime 中，Selector 是 Env=Developing。

這時(shí)假如最終用戶要部署這個(gè) App， 系統(tǒng)會(huì)自動(dòng)根據(jù) Provider 信息，以及應(yīng)用所在 Repo 的 Selector 和 Runtime 的 Label，自動(dòng)選擇可用的 Runtime，在右側(cè)這些 Runtime 中，只有最后一個(gè)符合條件，可以部署這個(gè) App。

Repo 子服務(wù)

看完了整體的架構(gòu)，接下來重點(diǎn)介紹幾個(gè)子服務(wù)的架構(gòu)。

Repo 子服務(wù)采用了松耦合的設(shè)計(jì)，分為三個(gè)組件：Repo Manager、Repo Indexer、App Repo。

圖中中間這部分是 App Repo， 可以是 Google 的 Storage，也可以是青云QingCloud 的 QingStor™對(duì)象存儲(chǔ) ，上面就是一個(gè)個(gè)的應(yīng)用配置包。

左側(cè)是 Repo Manager，負(fù)責(zé) Repo 的增刪改查功能，擁有自己的數(shù)據(jù)庫，記錄著 Repo 存儲(chǔ)的地址、登錄用的憑證、可見性等信息，可以是公開，可以是私有，也可以是特定用戶組內(nèi)共享。

最右側(cè)的 Repo Indexer 會(huì)周期性地掃描注冊(cè)的 Repo，發(fā)現(xiàn) Repo 上的配置包有任何更新，就會(huì)將 App 信息同步到 App 子服務(wù)中。

我們可以看出，Repo 的存儲(chǔ)是獨(dú)立于 OpenPitrix 平臺(tái)的，所以，倉庫存儲(chǔ)的應(yīng)用可以共享給任何基于 OpenPitrix 的應(yīng)用管理平臺(tái)使用甚至售賣。

App 子服務(wù)

App 子服務(wù)控制一個(gè)應(yīng)用，以及應(yīng)用的具體版本的生命周期， 在這里我們會(huì)將應(yīng)用的版本劃分為很多個(gè)狀態(tài)，狀態(tài)切換會(huì)有相應(yīng)的 API 觸發(fā)。 OpenPitrix 擁有對(duì)應(yīng)用的全生命周期管理。

只有 Repo 的可見性是 Public 的上面的 App 才是需要管理員進(jìn)行審核的，這也能夠確保最終用戶使用到的 App 都是可用的 App。

Cluster & Pilot 子服務(wù)

接下來會(huì)介紹 Cluster 子服務(wù)和 Pilot 子服務(wù)的架構(gòu)，也就是 OpenPitrix 整套架構(gòu)的核心，也是最為復(fù)雜的一塊。

在看實(shí)現(xiàn)和架構(gòu)之前，先看幾個(gè)部署時(shí)需要解決的問題，以及我們所采用的解決方案，從而解答我們?yōu)槭裁催@樣設(shè)計(jì) Cluster 子服務(wù)和 Pilot 子服務(wù)。

第一個(gè)問題就是規(guī)范的問題，怎么樣很好的標(biāo)識(shí)一個(gè)應(yīng)用，比如要開發(fā) Kubernetes 的應(yīng)用要學(xué)習(xí)他那套 Yaml 文件的書寫格式，OpenPitrix 讓開發(fā)者在這個(gè)平臺(tái)上開發(fā)應(yīng)用，也需要有一套簡(jiǎn)單易學(xué)的標(biāo)準(zhǔn)。

我們是沿用了之前青云QingCloud AppCenter 上應(yīng)用開發(fā)成熟的定義模式，這是一個(gè)標(biāo)準(zhǔn)的配置包的目錄結(jié)構(gòu)，是一個(gè) WordPress 應(yīng)用，里面有這些固定名稱的配置文件，后綴名標(biāo)識(shí)了文件的類型：

1:package.json 里面記錄著一些應(yīng)用元數(shù)據(jù)，比如 Version 信息，Description 信息，開發(fā)者信息， 圖標(biāo)信息等;

2:cluster.json.tmpl 定義了具體應(yīng)用架構(gòu)，生命周期管理，監(jiān)控報(bào)警等信息，也就是這個(gè)應(yīng)用包含哪些角色，每個(gè)角色在啟動(dòng)時(shí)需要執(zhí)行什么命令，關(guān)閉時(shí)執(zhí)行什么命令，如何監(jiān)控應(yīng)用實(shí)例的健康狀態(tài)等信息;

3:config.json 里面會(huì)定義一些用戶部署應(yīng)用實(shí)例時(shí)需要作出填充和選擇的信息，比如 CPU、Memory，應(yīng)用本身的環(huán)境變量等信息。

4:后面還有一些 Option 的文件，比如 License、Readme 還有語言包。

前三個(gè)文件是一個(gè)應(yīng)用配置包必須要有的文件， 后三個(gè)則是可選的。這其中 cluster.json.tmpl 和 config.json 和應(yīng)用的關(guān)系尤為緊密，定義看起來比較長(zhǎng)，但卻極易理解。

上圖一個(gè) config.json 的例子，記錄了在這個(gè) App 中 MySQL 這個(gè)角色的資源定義，CPU Default 是 1，也就是默認(rèn)是 1 核，Range 里面定義了其可選配置，可以是 1 核、2 核、4 核、8 核、16 核。

Memory 的默認(rèn)值是 2048 也就是 2G，Range 里面定義了 Memory 的可選配置。在用戶創(chuàng)建這個(gè)應(yīng)用的實(shí)例時(shí)，DashBoard 會(huì)根據(jù) config.json 里面的定義渲染頁面，也就是右側(cè)的截圖， 可以讓用戶根據(jù)開發(fā)者提供的配置， 選擇自己要?jiǎng)?chuàng)建的應(yīng)用實(shí)例類型。

上圖是一個(gè) cluster.json.tmpl 的例子， 雙花括號(hào)里面的是引用自 config.json 里面的值，一鍵創(chuàng)建時(shí)，用的是 config.json 里面變量的 Default 值，當(dāng)然如果用戶創(chuàng)建時(shí)通過命令行或者 DashBoard 修改了變量的值，則按照新的值渲染并創(chuàng)建。

這里定義了這個(gè)應(yīng)用有一個(gè)叫 ZK 的角色，這個(gè)角色創(chuàng)建時(shí)需要用到 Docker 的這個(gè) Image，下面 Service 部分則描述了應(yīng)用創(chuàng)建，刪除等生命周期所需要執(zhí)行的指令，比如這里定義了創(chuàng)建時(shí)要執(zhí)行的 Init 指令和 Start 指令。

開發(fā)者通過簡(jiǎn)單的配置包定義，就完成了應(yīng)用的開發(fā)，可以通過 OpenPitrix，讓不同云平臺(tái)的用戶去部署使用。

第二個(gè)問題：開發(fā)者的應(yīng)用映像如何分發(fā)到多云環(huán)境？

其實(shí)容器類的應(yīng)用在映像分發(fā)方面做的很好，可以有統(tǒng)一的容器映像倉庫，啟動(dòng)時(shí)去倉庫 Pull Image，所以微服務(wù)應(yīng)用支持不存在映像分發(fā)的問題。

而傳統(tǒng)應(yīng)用通常是部署到虛擬機(jī)中的，傳統(tǒng)應(yīng)用多云部署時(shí)就面臨映像分發(fā)的問題，開發(fā)者定義在應(yīng)用 Package 里面的映像 ID，如何分發(fā)到多云的環(huán)境中去?

我們知道，每個(gè)公有云都會(huì)有很多的 Region 和 Zone，如果讓開發(fā)者自己在每個(gè)里面上傳或創(chuàng)建映像，是一件很困難的事情，為了解決這個(gè)問題，我們想了很多解決方案，但都還不成熟。

比如讓開發(fā)者將 VM Image 的制作流程寫成腳本，需要某些軟件包，則從公網(wǎng)上下載，這樣在用戶第一次創(chuàng)建這個(gè)應(yīng)用實(shí)例的時(shí)候，OpenPitrix 平臺(tái)自動(dòng)創(chuàng)建這個(gè) Image，然后在跨 Zone 將 Image 遷移到其他 Zone，并共享給用戶確保其能夠啟動(dòng)應(yīng)用。

在第一版本傳統(tǒng)應(yīng)用我們會(huì)先采用 VM 里面跑 Docker 的方式來解決映像分發(fā)的問題。

第三個(gè)問題，如何操作云主機(jī)執(zhí)行命令，是個(gè)網(wǎng)絡(luò)問題。

OpenPitrix 自身是可以部署到任何地方的，而最終用戶要部署的應(yīng)用是運(yùn)行在各個(gè)云環(huán)境上的 IaaS 資源上，那兩者之間如何通信，以及發(fā)送指令的呢?

我們的解決方案是通過公共互聯(lián)網(wǎng)，也就是兩者通過公網(wǎng)打通，現(xiàn)在的云平臺(tái)主機(jī)資源為了安全性， 一般都是運(yùn)行在專有網(wǎng)絡(luò)里面的，也就是位于 VPC 下面，我們 OpenPitrix 也會(huì)將應(yīng)用實(shí)例默認(rèn)部署到 VPC 下，具體解決方案是分別在 OpenPitrix 框架內(nèi)，位于 VPC 下應(yīng)用實(shí)例主機(jī)里定義了 3 個(gè)組件：Pilot、Frontgate、Drone。

Pilot 領(lǐng)航員的意思，是 OpenPitrix 在部署 VM 類型應(yīng)用時(shí)所使用的一個(gè)服務(wù)，作用就是下發(fā)命令給具體部署在某個(gè) Provider 提供的云服務(wù)的 Runtime 的 Instance。

Drone，無人機(jī)，是運(yùn)行在應(yīng)用程序所在的主機(jī)上的，該組件由 Agent 和 Confd 所構(gòu)成，Confd 是一個(gè)開源的項(xiàng)目，能夠自動(dòng)完成 App 服務(wù)配置文件更新，并在配置發(fā)生變化時(shí)觸發(fā)特定的操作。Agent 負(fù)責(zé)接受 OpenPitrix 框架發(fā)過來的指令，并上報(bào)指令的執(zhí)行狀態(tài)。

Pilot 沒辦法直接發(fā)指令給 Drone，因?yàn)橐粋€(gè)在 OpenPitrix 上，一個(gè)在具體 Runtime 上， 環(huán)境不同，沒法直接通信， 所以需要一個(gè) Proxy，來轉(zhuǎn)發(fā)請(qǐng)求， 這個(gè)功能就是 Frontgate 提供的。

Frontgate，直譯是前門，也就是最外層的大門，在有應(yīng)用運(yùn)行的 VPC 中都會(huì)存在一個(gè) Frontgate，這個(gè) VPC 內(nèi)的所有應(yīng)用集群共享這個(gè) Frontgate。

該組件包含 Proxy 和 ETCD，Proxy 起著承上啟下的轉(zhuǎn)發(fā)功能，F(xiàn)rontgate 主機(jī)創(chuàng)建時(shí)，會(huì)將 Pilot 的地址寫入，F(xiàn)rontgate 啟動(dòng)時(shí)可以和 Pilot 建立一個(gè)雙向的 Grpc Stream，建立這個(gè)連接后，兩個(gè)組件之間可以任意通信了。

后面 Pilot 就可以發(fā)指令給 Frontgate，而 Frontgate 和 Drone 位于同一 VPC 內(nèi)，屬于內(nèi)網(wǎng)，可以將請(qǐng)求發(fā)給 Drone 并執(zhí)行，執(zhí)行結(jié)果也可以經(jīng)由 Frontgate 上報(bào)給 Pilot。

Frontgate 里面的 ETCD 會(huì)存儲(chǔ)應(yīng)用部署實(shí)例的元數(shù)據(jù)信息， Drone 里面的 Confd 也是通過 Watch ETCD 從而實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和自動(dòng)配置變更的。

這里有必要說一下, 既然 Pilot 只是一個(gè)下發(fā)指令的服務(wù)，從 Cluster 里面獨(dú)立出來，是為了靈活的擴(kuò)展性。Pilot 控制多云 VM Based 的 Runtime 里面的主機(jī)，量會(huì)越來越多。

目前第一版本，我們沒有考慮多云應(yīng)用的編排, 比如 AWS 上的一個(gè) Kafka，使用的 OpenStack 上部署的一個(gè) ZooKeeper。但由于 Pilot 可以和任何一個(gè) Runtime 交互，所以后面的版本我們可以基于 Pilot 做多云應(yīng)用的編排。

現(xiàn)在假設(shè)有一個(gè)用戶要在 OpenPitrix 上部署一個(gè)應(yīng)用，他選擇應(yīng)用，選擇 Runtime，填寫應(yīng)用所必須的資源信息和環(huán)境變量后，點(diǎn)擊創(chuàng)建，OpenPitrix 會(huì)如何工作呢?

首先，發(fā)送 API 到 API 網(wǎng)關(guān)，API 網(wǎng)關(guān)會(huì)將之轉(zhuǎn)發(fā)給 Cluster 子服務(wù);

然后，Cluster 子服務(wù)收到請(qǐng)求之后，會(huì)先解析配置包，注冊(cè) Cluster 的數(shù)據(jù)庫信息，然后將請(qǐng)求封裝為一個(gè) JOB，并放到 JOB 消息隊(duì)列中等待調(diào)度執(zhí)行，JOB Controller 會(huì)異步的解析 JOB，拆分成多層 Task，每一層 Task 是可以并行執(zhí)行的，多層 Task 是有依賴關(guān)系需要順序執(zhí)行的，這樣就將一個(gè) JOB 解析成了 Task 的工作流，Task Controller 可以逐層的去調(diào)度執(zhí)行 Task，保障依賴順序。

其次，Task 是根據(jù)當(dāng)前 Runtime 的 Provider 的 Provider Plugin 來執(zhí)行的，Task 有幾種類型：

一種是調(diào)用云服務(wù)的 API 來執(zhí)行 RunInstance、CreateVolume 的操作，如果是容器類的應(yīng)用，Task 會(huì)將請(qǐng)求發(fā)給 Helm 的 Server 端，Tiller 去執(zhí)行，這個(gè)后面會(huì)介紹。

如果是基于 VM 的應(yīng)用，有些 Task 是需要經(jīng)由 Pilot 下發(fā)到 Drone 的，這些 Task 的依賴 Task 就會(huì)完成前序工作。

也就是創(chuàng)建好 Frontgate 并和 Pilot 建立雙向 Grpc Stream 連接。通過他們之間的交互，完成創(chuàng)建步驟后續(xù)的元數(shù)據(jù)注冊(cè)，Confd 服務(wù)啟動(dòng)，開發(fā)者定義的 Init 和 Start 指令的執(zhí)行等操作。

OpenPitrix 同樣支持容器類型的應(yīng)用，我們第一版本中的 K8S Provider Plugin 是通過 Helm Client 實(shí)現(xiàn)的，容器應(yīng)用會(huì)通過 Helm 部署到 Kubernetes 集群中。

目前 Helm 的服務(wù)端 Tiller 只支持將 Chart 的實(shí)例部署到單一 Kubernetes 中去，所以需要在 Kubernetes 的 Runtime 里安裝 Tiller 這個(gè)服務(wù)。

OpenPitrix 應(yīng)用實(shí)踐

剛才介紹了 OpenPitrix 的功能以及技術(shù)架構(gòu)，接下來一同看下 OpenPitrix 的主要應(yīng)用場(chǎng)景。

由于 OpenPitrix 的 Runtime 既可以是公有云，也可以是私有云的，所以最普遍的一種場(chǎng)景就是為采用多云或者混合云系統(tǒng)的企業(yè)，提供一站式的應(yīng)用管理平臺(tái)，讓企業(yè)的員工可以不關(guān)心 IaaS 層，直接使用應(yīng)用，且只用一套管理界面。

再一個(gè)就是一些云管理平臺(tái)，只有多云 IaaS 資源的管理， 那可以將 OpenPitrix 整合進(jìn)去，從而增加多云應(yīng)用管理的功能。

第三個(gè)是 OpenPitrix 可以作為 Kubernetes 的一個(gè)應(yīng)用管理系統(tǒng)。

OpenPitrix 和 Helm 有著本質(zhì)上的不同，雖然 OpenPitrix 底層用了 Helm 來部署 Kubernetes 應(yīng)用，但 OpenPitrix 著眼于應(yīng)用的全生命周期管理，比如在企業(yè)中，通常會(huì)按照應(yīng)用的狀態(tài)來分類，如開發(fā)、測(cè)試、預(yù)覽、生產(chǎn)等，同時(shí)還有應(yīng)用市場(chǎng)的管理功能，這些是 Helm 所沒有的。

OpenPitrix 未來發(fā)展

OpenPitrix 這個(gè)項(xiàng)目在去年 8 月份啟動(dòng)，到今年 2 月 24 日完成各個(gè)模塊的設(shè)計(jì)和討論工作并開始開發(fā)，目前已經(jīng)完成了第一版大部分功能的開發(fā)，我們目前已經(jīng)上線了官網(wǎng)：

openpitrix.io

希望感興趣的朋友們加入我們，共同構(gòu)建這個(gè)多云應(yīng)用管理平臺(tái)的生態(tài)。未來，OpenPitrix 希望逐步發(fā)展為多云環(huán)境下應(yīng)用程序管理系統(tǒng)的全方位的解決方案。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。