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