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

OpenPitrix 是一個多云應(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)用平臺顧問工程師遲連義在 2018 年 QCon 全球軟件開發(fā)大會北京站上演講內(nèi)容整理而來。

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

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

多云部署與管理是趨勢

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

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

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

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

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

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

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

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

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

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

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

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

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

首先是多云平臺的支持。

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

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

各種類型的應(yīng)用都會支持，很多企業(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)是大趨勢，所以微服務(wù)類型的應(yīng)用我們也會支持，微服務(wù)應(yīng)用往往是容器化的，在容器的編排方面，開源項(xiàng)目 Kubernetes 已經(jīng)是事實(shí)上的標(biāo)準(zhǔn)，因此，OpenPitrix 會支持 Kubernetes。Helm 是一個非常不錯的 Kubernetes 包管理器，提供了打包、部署等功能。 在第一版 OpenPitrix 中，我們使用 Helm 作為 Kubernetes 應(yīng)用程序的部署工具，來提供微服務(wù)類型應(yīng)用的部署。

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

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

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

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

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

OpenPitrix 架構(gòu)

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

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

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

1:Repo 上是有很多個 App、App 組，類似于市場的概念。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Repo 子服務(wù)

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

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

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

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

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

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

App 子服務(wù)

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

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

Cluster & Pilot 子服務(wù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

然后，Cluster 子服務(wù)收到請求之后，會先解析配置包，注冊 Cluster 的數(shù)據(jù)庫信息，然后將請求封裝為一個 JOB，并放到 JOB 消息隊(duì)列中等待調(diào)度執(zhí)行，JOB Controller 會異步的解析 JOB，拆分成多層 Task，每一層 Task 是可以并行執(zhí)行的，多層 Task 是有依賴關(guān)系需要順序執(zhí)行的，這樣就將一個 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 會將請求發(fā)給 Helm 的 Server 端，Tiller 去執(zhí)行，這個后面會介紹。

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

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

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

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

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

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

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

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

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

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

OpenPitrix 未來發(fā)展

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

openpitrix.io

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

生成海報

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