OpenPitrix 是一個(gè)多云應用管理系統，目標是 Run Any Application at Any Scale on Any Infrastructure（能夠將任何應用以任何規模部署在任何基礎設施上），能夠一站式管理企業(yè)各種類(lèi)型的應用，讓用戶(hù)可以把精力專(zhuān)注于核心業(yè)務(wù)層。
本次內容為青云QingCloud 應用平臺顧問(wèn)工程師遲連義在 2018 年 QCon 全球軟件開(kāi)發(fā)大會(huì )北京站上演講內容整理而來(lái)。（正文共：9087 字 15 圖，預計閱讀時(shí)間： 23 分鐘）
以下為本次分享的內容整理
多云 Multiple Runtime，是指多個(gè)云服務(wù)提供商的服務(wù)應用管理平臺，和一般云管理平臺 （CMP） 的區別是：一般的云管理平臺是管理云的基礎資源也就是我們俗稱(chēng)的 IaaS，而應用管理平臺是管理應用程序， 這些應用程序可以是單節點(diǎn)，可以是多節點(diǎn)、多角色的，節點(diǎn)之間交互時(shí)需要配合上網(wǎng)絡(luò )、負載均衡器、存儲等資源，也就是我們俗稱(chēng)的 PaaS。
多云部署與管理是趨勢
我們?yōu)槭裁匆プ龆嘣茟霉芾砥脚_。
今年 1 月份的時(shí)候，在知名云服務(wù)商 RightScale 公布的一份年度云狀況調查報告中顯示，采用多云管理的企業(yè)占受訪(fǎng)的 81%，這充分說(shuō)明多云是未來(lái)企業(yè)上云的一個(gè)大趨勢。
多云的好處很多，很重要的一個(gè)因素防止被單個(gè)云服務(wù)提供商綁定，跨多個(gè)云服務(wù)提供商可以對沖風(fēng)險，再者，每個(gè)云服務(wù)商的產(chǎn)品各有優(yōu)劣，比如有的云存儲功能強大，有的云數據庫產(chǎn)品更穩定，采用多云可以充分利用其優(yōu)勢產(chǎn)品。
使用單云架構時(shí)，可以直接用這個(gè)云提供商所提供的成熟的管理工具或管理界面就可以了，但在多云環(huán)境下，用戶(hù)希望能有一個(gè)統一的界面管理多個(gè)云服務(wù)，來(lái)降低運維和管理的復雜性。
應用是最貼近需求的，所以一個(gè)多云應用管理系統更具有市場(chǎng)需求，這樣用戶(hù)可以把更多的精力放在核心的業(yè)務(wù)層。同時(shí)企業(yè)可能有各種類(lèi)型的應用需要管理，包括傳統的應用，像數據庫、Tomcat、Hadoop，還有基于微服務(wù)架構的應用、以及近來(lái)發(fā)展迅猛的 Serverless 應用等。企業(yè)需要一個(gè)可以管理不同類(lèi)型應用程序的一站式管理平臺。
俗話(huà)講「格局有多大，成就就有多大」，做項目也是這樣，既然我們做「多云應用管理平臺」，我們的目標就是形成一個(gè)應用市場(chǎng)生態(tài)系統，各種企業(yè)開(kāi)發(fā)者都可以在這個(gè)平臺上開(kāi)發(fā)他們擅長(cháng)的 App，并便捷的提供在線(xiàn)運維和幫助，這些開(kāi)發(fā)好的 App 提供給其他企業(yè)用戶(hù)去使用，開(kāi)發(fā)者可以盈利，使用者可以跳過(guò)手動(dòng)搭建和維護的流程，使用現成的產(chǎn)品。
為了做成生態(tài)這個(gè)目標，從一開(kāi)始這個(gè)項目就是以開(kāi)源的方式進(jìn)行，包括討論、設計、代碼都是在 GitHub 上完成的。
還有一個(gè)很主要的原因，我們幾年前就開(kāi)始開(kāi)發(fā)應用上云的平臺，2015 年 5 月發(fā)布了 AppCenter 的第一個(gè)正式版本，在 2017 年初發(fā)布了 AppCenter 2.0，旨在讓開(kāi)發(fā)者以最低的學(xué)習成本幾天將應用部署到云平臺上，這個(gè)平臺提供應用的服務(wù)感知、彈性伸縮、配置變更等云計算基礎特性。而且還為開(kāi)發(fā)者提供便捷的管理、日志、監控、財務(wù)、工單等功能，最終用戶(hù)在應用市場(chǎng)很便捷的找到自己需要的各種應用，通過(guò)一鍵部署來(lái)使用。
AppCenter 平臺自去年 3 月份發(fā)布以來(lái)，已經(jīng)陸續上線(xiàn)了一百多個(gè)不同企業(yè)開(kāi)發(fā)者所開(kāi)發(fā)的 App，其中涵蓋了：大數據、AI、容器、 區塊鏈等各種領(lǐng)域的應用。但 AppCenter 底層只兼容青云的 IaaS，我們的私有云用戶(hù)也有 AppCenter 的需求，但私有云一般有多個(gè)云部署環(huán)境，所以客戶(hù)提出 AppCenter 兼容其它云廠(chǎng)商的要求。
多云+應用+開(kāi)源
這就是多云應用管理平臺誕生的由來(lái)，我們給他起的名字叫做：OpenPitrix，集多云，應用管理，開(kāi)源于一身的項目。這個(gè)名字的由來(lái)，Pitrix 是 PaaS + IaaS + Matrix （矩陣） 三個(gè)詞的一個(gè)集合，這個(gè)其實(shí)是青云內部的項目的名字。我們拿來(lái)用了，前面加上 Open 即表示這個(gè)項目是開(kāi)源的，也表明我們開(kāi)放的心態(tài)。
OpenPitrix 想實(shí)現的是 Run any application at any scale on any infrastructure，也就是通過(guò) OpenPitrix 這個(gè)平臺可以將任何類(lèi)型的應用部署到任何類(lèi)型的基礎設施上面。對于開(kāi)發(fā)者來(lái)說(shuō)就是 Build Once，Run Anywhere。
OpenPitrix 所能提供的功能，主要有 4 大塊。
首先是多云平臺的支持。
云平臺可以是 AWS，可以使 OpenStack，既可以是基于 VM 的，也可以是基于容器的， 可以是公有云，也可以是私有云。 針對于平臺提供商，OpenPitrix 會(huì )提供相應的 ProviderPlugin 插件，去調用相應云平臺提供商的 API 來(lái)管理運行在其上的應用。
第二個(gè)是多應用類(lèi)型的支持。
各種類(lèi)型的應用都會(huì )支持，很多企業(yè)使用的是傳統應用，他們希望在不改變其現有架構的情況下將其應用上云，所以這些傳統應用是需要支持的。
這些傳統應用既可以是典型的基于三層架構的軟件，也可以是各種分布式軟件：Hadoop 這種主從結構、ZooKeeper 這種 Peer to Peer 結構、Redis Cluster 這種分片結構都可以被 OpenPitrix 所管理。
微服務(wù)架構是大趨勢，所以微服務(wù)類(lèi)型的應用我們也會(huì )支持，微服務(wù)應用往往是容器化的，在容器的編排方面，開(kāi)源項目 Kubernetes 已經(jīng)是事實(shí)上的標準，因此，OpenPitrix 會(huì )支持 Kubernetes。Helm 是一個(gè)非常不錯的 Kubernetes 包管理器，提供了打包、部署等功能。 在第一版 OpenPitrix 中，我們使用 Helm 作為 Kubernetes 應用程序的部署工具，來(lái)提供微服務(wù)類(lèi)型應用的部署。
Serverless 應用我們也會(huì )支持，但目前來(lái)講，由于 Severless 應用還沒(méi)有一個(gè)統一的標準，第一個(gè)版本暫不支持，會(huì )持續關(guān)注其發(fā)展。
第三個(gè)功能就是高度可擴展和可插拔。
既包括云平臺的支持，也包括應用類(lèi)型的支持，這樣無(wú)論未來(lái)出現了何種新的云服務(wù)商，或者是新的應用類(lèi)型，都可通過(guò)添加相應插件的方式支持它。
第四是可商業(yè)運營(yíng)。
我們最大限度解耦應用和應用所運行的云環(huán)境，一方面讓開(kāi)發(fā)者便捷的開(kāi)發(fā) App，同時(shí)平臺為其提供管理和運維、計量計費、查看報表及統計信息等，應用可以放到公共市場(chǎng)，或者專(zhuān)有市場(chǎng)上去售賣(mài)。 另一方面用戶(hù)可以在其所擁有的云運行環(huán)境上，部署相應的 App。任何基于 OpenPitrix 開(kāi)發(fā)的應用， 都可以在任何基于 OpenPitrix 的應用管理平臺上售賣(mài)。
OpenPitrix 架構
OpenPitrix 在設計之初，就決定以微服務(wù)框架的方式進(jìn)行開(kāi)發(fā)。微服務(wù)相較于單體應用有很多優(yōu)點(diǎn)，比如降低復雜性，可獨立開(kāi)發(fā)、部署、升級和擴展等。
在 OpenPitrix 里面，我們拆分出了五個(gè)微服務(wù)：Repo、App、Runtime、Cluster、Pilot。
- App 是提供應用開(kāi)發(fā)，注冊等功能的服務(wù)；
- Repo 上是有很多個(gè) App、App 組，類(lèi)似于市場(chǎng)的概念。
- Runtime 是一個(gè)具體的云運行時(shí)環(huán)境，可以是某個(gè)公有云的某個(gè) Zone，也可以是私有云的某個(gè) Zone。
- Cluster 服務(wù)是管理部署在某個(gè) Runtime 里應用實(shí)例生命周期的服務(wù)，包括創(chuàng )建、升級、擴容、刪除等操作。
- Pilot 這個(gè)服務(wù)提供了 OpenPitrix 可以和部署到某個(gè) Runtime 里面應用實(shí)例進(jìn)行雙向請求的能力。
每個(gè)微服務(wù)有自己的服務(wù)進(jìn)程，有自己的數據庫，一個(gè)服務(wù)的數據庫也不可以被其他服務(wù)直接訪(fǎng)問(wèn)，因為每個(gè)服務(wù)是獨立開(kāi)發(fā)的，這樣可以確保單個(gè)服務(wù)的表結構修改不會(huì )影響到其他服務(wù)。
持久層框架選擇的 DBR，是因為這個(gè)框架沒(méi)有其他依賴(lài)，代碼簡(jiǎn)單，易于維護。
數據庫遷移工具，選擇的 Flyway，可以在子服務(wù)啟動(dòng)之前構建好數據庫以及表結構，并可處理后續的數據庫遷移工作。
對外提供 DashBoard 和命令行工具 CLI，外部訪(fǎng)問(wèn)都是通過(guò) Restful API，經(jīng)由統一的 API Gateway。Api Gateway 在經(jīng)過(guò)內部路由將請求轉發(fā)給具體的某個(gè)微服務(wù)上，各服務(wù)之間的通信屬于內部通信，通過(guò) GRPC 來(lái)實(shí)現，選擇 GRPC 而沒(méi)有用 Restful，由于其是二進(jìn)制協(xié)議，相比于 Restful 的 HTTP 協(xié)議性能更高。
各服務(wù)之間會(huì )使用統一的一套 ETCD 服務(wù)，該服務(wù)提供配置更新\全局鎖\消息隊列等功能。
采用微服務(wù)設計，OpenPitrix 可以很方便的容器化，部署在容器平臺中，比如 Kubernetes，并享用 Kubernetes 所提供的微服務(wù)治理功能，像服務(wù)發(fā)現、監控、負載均衡等。
解耦應用和其所運行的云環(huán)境
先看右下角，Runtime 是云的運行時(shí)環(huán)境，有 Provider 的屬性，也就是云提供商，根據 Provider 用具體的 ProviderPlugin 去操作，Runtime 可以打標簽 Labels。
每個(gè) App 都可以用一個(gè)應用配置包來(lái)描述，這個(gè)配置包的內容后面會(huì )介紹。應用的配置包都是位于 App Repo 上面，App Repo 可以是 GitHub，也可以是某個(gè)云服務(wù)商提供的對象存儲。
App Repo 也可以打標簽，比如 Sorftware = DataBase 表示這個(gè) Repo 上的 App 都是數據庫相關(guān)的，App Repo 有個(gè) Provider 屬性，這是為了標記當前 Repo 上的 App 能夠部署到哪些 Provider 的 Runtime 中去。Selector 是可以針對 Runtime 的 Label 進(jìn)行檢索的屬性。
舉個(gè)例子，開(kāi)發(fā)者正在開(kāi)發(fā)一款 MySQL 應用，開(kāi)發(fā)中狀態(tài)也就不是穩定版本，開(kāi)發(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í)假如最終用戶(hù)要部署這個(gè) App， 系統會(huì )自動(dòng)根據 Provider 信息，以及應用所在 Repo 的 Selector 和 Runtime 的 Label，自動(dòng)選擇可用的 Runtime，在右側這些 Runtime 中，只有最后一個(gè)符合條件，可以部署這個(gè) App。
Repo 子服務(wù)
看完了整體的架構，接下來(lái)重點(diǎn)介紹幾個(gè)子服務(wù)的架構。
Repo 子服務(wù)采用了松耦合的設計，分為三個(gè)組件：Repo Manager、Repo Indexer、App Repo。
圖中中間這部分是 App Repo， 可以是 Google 的 Storage，也可以是青云QingCloud 的 QingStor?對象存儲 ，上面就是一個(gè)個(gè)的應用配置包。
左側是 Repo Manager，負責 Repo 的增刪改查功能，擁有自己的數據庫，記錄著(zhù) Repo 存儲的地址、登錄用的憑證、可見(jiàn)性等信息，可以是公開(kāi)，可以是私有，也可以是特定用戶(hù)組內共享。
最右側的 Repo Indexer 會(huì )周期性地掃描注冊的 Repo，發(fā)現 Repo 上的配置包有任何更新，就會(huì )將 App 信息同步到 App 子服務(wù)中。
我們可以看出，Repo 的存儲是獨立于 OpenPitrix 平臺的，所以，倉庫存儲的應用可以共享給任何基于 OpenPitrix 的應用管理平臺使用甚至售賣(mài)。
App 子服務(wù)
App 子服務(wù)控制一個(gè)應用，以及應用的具體版本的生命周期， 在這里我們會(huì )將應用的版本劃分為很多個(gè)狀態(tài)，狀態(tài)切換會(huì )有相應的 API 觸發(fā)。 OpenPitrix 擁有對應用的全生命周期管理。
只有 Repo 的可見(jiàn)性是 Public 的上面的 App 才是需要管理員進(jìn)行審核的，這也能夠確保最終用戶(hù)使用到的 App 都是可用的 App。
Cluster & Pilot 子服務(wù)
接下來(lái)會(huì )介紹 Cluster 子服務(wù)和 Pilot 子服務(wù)的架構，也就是 OpenPitrix 整套架構的核心，也是最為復雜的一塊。
在看實(shí)現和架構之前，先看幾個(gè)部署時(shí)需要解決的問(wèn)題，以及我們所采用的解決方案，從而解答我們?yōu)槭裁催@樣設計 Cluster 子服務(wù)和 Pilot 子服務(wù)。
第一個(gè)問(wèn)題就是規范的問(wèn)題，怎么樣很好的標識一個(gè)應用，比如要開(kāi)發(fā) Kubernetes 的應用要學(xué)習他那套 Yaml 文件的書(shū)寫(xiě)格式，OpenPitrix 讓開(kāi)發(fā)者在這個(gè)平臺上開(kāi)發(fā)應用，也需要有一套簡(jiǎn)單易學(xué)的標準。
我們是沿用了之前青云QingCloud AppCenter 上應用開(kāi)發(fā)成熟的定義模式，這是一個(gè)標準的配置包的目錄結構，是一個(gè) WordPress 應用，里面有這些固定名稱(chēng)的配置文件，后綴名標識了文件的類(lèi)型：
- package.json 里面記錄著(zhù)一些應用元數據，比如 Version 信息，Description 信息，開(kāi)發(fā)者信息， 圖標信息等；
- cluster.json.tmpl 定義了具體應用架構，生命周期管理，監控報警等信息，也就是這個(gè)應用包含哪些角色，每個(gè)角色在啟動(dòng)時(shí)需要執行什么命令，關(guān)閉時(shí)執行什么命令，如何監控應用實(shí)例的健康狀態(tài)等信息；
- config.json 里面會(huì )定義一些用戶(hù)部署應用實(shí)例時(shí)需要作出填充和選擇的信息，比如 CPU、Memory，應用本身的環(huán)境變量等信息。
- 后面還有一些 Option 的文件，比如 License、Readme 還有語(yǔ)言包。
前三個(gè)文件是一個(gè)應用配置包必須要有的文件， 后三個(gè)則是可選的。這其中 cluster.json.tmpl 和 config.json 和應用的關(guān)系尤為緊密，定義看起來(lái)比較長(cháng)，但卻極易理解。
上圖一個(gè) config.json 的例子，記錄了在這個(gè) App 中 MySQL 這個(gè)角色的資源定義，CPU Default 是 1，也就是默認是 1 核，Range 里面定義了其可選配置，可以是 1 核、2 核、4 核、8 核、16 核。
Memory 的默認值是 2048 也就是 2G，Range 里面定義了 Memory 的可選配置。在用戶(hù)創(chuàng )建這個(gè)應用的實(shí)例時(shí)，DashBoard 會(huì )根據 config.json 里面的定義渲染頁(yè)面，也就是右側的截圖， 可以讓用戶(hù)根據開(kāi)發(fā)者提供的配置， 選擇自己要創(chuàng )建的應用實(shí)例類(lèi)型。
上圖是一個(gè) cluster.json.tmpl 的例子， 雙花括號里面的是引用自 config.json 里面的值，一鍵創(chuàng )建時(shí)，用的是 config.json 里面變量的 Default 值，當然如果用戶(hù)創(chuàng )建時(shí)通過(guò)命令行或者 DashBoard 修改了變量的值，則按照新的值渲染并創(chuàng )建。
這里定義了這個(gè)應用有一個(gè)叫 ZK 的角色，這個(gè)角色創(chuàng )建時(shí)需要用到 Docker 的這個(gè) Image，下面 Service 部分則描述了應用創(chuàng )建，刪除等生命周期所需要執行的指令，比如這里定義了創(chuàng )建時(shí)要執行的 Init 指令和 Start 指令。
開(kāi)發(fā)者通過(guò)簡(jiǎn)單的配置包定義，就完成了應用的開(kāi)發(fā)，可以通過(guò) OpenPitrix，讓不同云平臺的用戶(hù)去部署使用。
第二個(gè)問(wèn)題：開(kāi)發(fā)者的應用映像如何分發(fā)到多云環(huán)境？
其實(shí)容器類(lèi)的應用在映像分發(fā)方面做的很好，可以有統一的容器映像倉庫，啟動(dòng)時(shí)去倉庫 Pull Image，所以微服務(wù)應用支持不存在映像分發(fā)的問(wèn)題。
而傳統應用通常是部署到虛擬機中的，傳統應用多云部署時(shí)就面臨映像分發(fā)的問(wèn)題，開(kāi)發(fā)者定義在應用 Package 里面的映像 ID，如何分發(fā)到多云的環(huán)境中去？
我們知道，每個(gè)公有云都會(huì )有很多的 Region 和 Zone，如果讓開(kāi)發(fā)者自己在每個(gè)里面上傳或創(chuàng )建映像，是一件很困難的事情，為了解決這個(gè)問(wèn)題，我們想了很多解決方案，但都還不成熟。
比如讓開(kāi)發(fā)者將 VM Image 的制作流程寫(xiě)成腳本，需要某些軟件包，則從公網(wǎng)上下載，這樣在用戶(hù)第一次創(chuàng )建這個(gè)應用實(shí)例的時(shí)候，OpenPitrix 平臺自動(dòng)創(chuàng )建這個(gè) Image，然后在跨 Zone 將 Image 遷移到其他 Zone，并共享給用戶(hù)確保其能夠啟動(dòng)應用。
在第一版本傳統應用我們會(huì )先采用 VM 里面跑 Docker 的方式來(lái)解決映像分發(fā)的問(wèn)題。
第三個(gè)問(wèn)題，如何操作云主機執行命令，是個(gè)網(wǎng)絡(luò )問(wèn)題。
OpenPitrix 自身是可以部署到任何地方的，而最終用戶(hù)要部署的應用是運行在各個(gè)云環(huán)境上的 IaaS 資源上，那兩者之間如何通信，以及發(fā)送指令的呢？
我們的解決方案是通過(guò)公共互聯(lián)網(wǎng)，也就是兩者通過(guò)公網(wǎng)打通，現在的云平臺主機資源為了安全性， 一般都是運行在專(zhuān)有網(wǎng)絡(luò )里面的，也就是位于 VPC 下面，我們 OpenPitrix 也會(huì )將應用實(shí)例默認部署到 VPC 下，具體解決方案是分別在 OpenPitrix 框架內，位于 VPC 下應用實(shí)例主機里定義了 3 個(gè)組件：Pilot、Frontgate、Drone。
Pilot 領(lǐng)航員的意思，是 OpenPitrix 在部署 VM 類(lèi)型應用時(shí)所使用的一個(gè)服務(wù)，作用就是下發(fā)命令給具體部署在某個(gè) Provider 提供的云服務(wù)的 Runtime 的 Instance。
Drone，無(wú)人機，是運行在應用程序所在的主機上的，該組件由 Agent 和 Confd 所構成，Confd 是一個(gè)開(kāi)源的項目，能夠自動(dòng)完成 App 服務(wù)配置文件更新，并在配置發(fā)生變化時(shí)觸發(fā)特定的操作。Agent 負責接受 OpenPitrix 框架發(fā)過(guò)來(lái)的指令，并上報指令的執行狀態(tài)。
Pilot 沒(méi)辦法直接發(fā)指令給 Drone，因為一個(gè)在 OpenPitrix 上，一個(gè)在具體 Runtime 上， 環(huán)境不同，沒(méi)法直接通信， 所以需要一個(gè) Proxy，來(lái)轉發(fā)請求， 這個(gè)功能就是 Frontgate 提供的。
Frontgate，直譯是前門(mén)，也就是最外層的大門(mén)，在有應用運行的 VPC 中都會(huì )存在一個(gè) Frontgate，這個(gè) VPC 內的所有應用集群共享這個(gè) Frontgate。
該組件包含 Proxy 和 ETCD，Proxy 起著(zhù)承上啟下的轉發(fā)功能，Frontgate 主機創(chuàng )建時(shí)，會(huì )將 Pilot 的地址寫(xiě)入，Frontgate 啟動(dòng)時(shí)可以和 Pilot 建立一個(gè)雙向的 Grpc Stream，建立這個(gè)連接后，兩個(gè)組件之間可以任意通信了。
后面 Pilot 就可以發(fā)指令給 Frontgate，而 Frontgate 和 Drone 位于同一 VPC 內，屬于內網(wǎng)，可以將請求發(fā)給 Drone 并執行，執行結果也可以經(jīng)由 Frontgate 上報給 Pilot。
Frontgate 里面的 ETCD 會(huì )存儲應用部署實(shí)例的元數據信息， Drone 里面的 Confd 也是通過(guò) Watch ETCD 從而實(shí)現服務(wù)發(fā)現和自動(dòng)配置變更的。
這里有必要說(shuō)一下， 既然 Pilot 只是一個(gè)下發(fā)指令的服務(wù)，從 Cluster 里面獨立出來(lái)，是為了靈活的擴展性。Pilot 控制多云 VM Based 的 Runtime 里面的主機，量會(huì )越來(lái)越多。
目前第一版本，我們沒(méi)有考慮多云應用的編排， 比如 AWS 上的一個(gè) Kafka，使用的 OpenStack 上部署的一個(gè) ZooKeeper。但由于 Pilot 可以和任何一個(gè) Runtime 交互，所以后面的版本我們可以基于 Pilot 做多云應用的編排。
現在假設有一個(gè)用戶(hù)要在 OpenPitrix 上部署一個(gè)應用，他選擇應用，選擇 Runtime，填寫(xiě)應用所必須的資源信息和環(huán)境變量后，點(diǎn)擊創(chuàng )建，OpenPitrix 會(huì )如何工作呢？
首先，發(fā)送 API 到 API 網(wǎng)關(guān)，API 網(wǎng)關(guān)會(huì )將之轉發(fā)給 Cluster 子服務(wù)；
然后，Cluster 子服務(wù)收到請求之后，會(huì )先解析配置包，注冊 Cluster 的數據庫信息，然后將請求封裝為一個(gè) JOB，并放到 JOB 消息隊列中等待調度執行，JOB Controller 會(huì )異步的解析 JOB，拆分成多層 Task，每一層 Task 是可以并行執行的，多層 Task 是有依賴(lài)關(guān)系需要順序執行的，這樣就將一個(gè) JOB 解析成了 Task 的工作流，Task Controller 可以逐層的去調度執行 Task，保障依賴(lài)順序。
其次，Task 是根據當前 Runtime 的 Provider 的 Provider Plugin 來(lái)執行的，Task 有幾種類(lèi)型：
一種是調用云服務(wù)的 API 來(lái)執行 RunInstance、CreateVolume 的操作，如果是容器類(lèi)的應用，Task 會(huì )將請求發(fā)給 Helm 的 Server 端，Tiller 去執行，這個(gè)后面會(huì )介紹。
如果是基于 VM 的應用，有些 Task 是需要經(jīng)由 Pilot 下發(fā)到 Drone 的，這些 Task 的依賴(lài) Task 就會(huì )完成前序工作。
也就是創(chuàng )建好 Frontgate 并和 Pilot 建立雙向 Grpc Stream 連接。通過(guò)他們之間的交互，完成創(chuàng )建步驟后續的元數據注冊，Confd 服務(wù)啟動(dòng)，開(kāi)發(fā)者定義的 Init 和 Start 指令的執行等操作。
OpenPitrix 同樣支持容器類(lèi)型的應用，我們第一版本中的 K8S Provider Plugin 是通過(guò) Helm Client 實(shí)現的，容器應用會(huì )通過(guò) Helm 部署到 Kubernetes 集群中。
目前 Helm 的服務(wù)端 Tiller 只支持將 Chart 的實(shí)例部署到單一 Kubernetes 中去，所以需要在 Kubernetes 的 Runtime 里安裝 Tiller 這個(gè)服務(wù)。
OpenPitrix 應用實(shí)踐
剛才介紹了 OpenPitrix 的功能以及技術(shù)架構，接下來(lái)一同看下 OpenPitrix 的主要應用場(chǎng)景。
由于 OpenPitrix 的 Runtime 既可以是公有云，也可以是私有云的，所以最普遍的一種場(chǎng)景就是為采用多云或者混合云系統的企業(yè)，提供一站式的應用管理平臺，讓企業(yè)的員工可以不關(guān)心 IaaS 層，直接使用應用，且只用一套管理界面。
再一個(gè)就是一些云管理平臺，只有多云 IaaS 資源的管理， 那可以將 OpenPitrix 整合進(jìn)去，從而增加多云應用管理的功能。
第三個(gè)是 OpenPitrix 可以作為 Kubernetes 的一個(gè)應用管理系統。
OpenPitrix 和 Helm 有著(zhù)本質(zhì)上的不同，雖然 OpenPitrix 底層用了 Helm 來(lái)部署 Kubernetes 應用，但 OpenPitrix 著(zhù)眼于應用的全生命周期管理，比如在企業(yè)中，通常會(huì )按照應用的狀態(tài)來(lái)分類(lèi)，如開(kāi)發(fā)、測試、預覽、生產(chǎn)等，同時(shí)還有應用市場(chǎng)的管理功能，這些是 Helm 所沒(méi)有的。
OpenPitrix 未來(lái)發(fā)展
OpenPitrix 這個(gè)項目在去年 8 月份啟動(dòng)，到今年 2 月 24 日完成各個(gè)模塊的設計和討論工作并開(kāi)始開(kāi)發(fā)，目前已經(jīng)完成了第一版大部分功能的開(kāi)發(fā)，我們目前已經(jīng)上線(xiàn)了官網(wǎng)：
openpitrix.io
希望感興趣的朋友們加入我們，共同構建這個(gè)多云應用管理平臺的生態(tài)。未來(lái)，OpenPitrix 希望逐步發(fā)展為多云環(huán)境下應用程序管理系統的全方位的解決方案。
