開源PaaS Rainbond的架構與實現

回顧雲計算產業技術的發展，IaaS層虛擬化的逐步成熟，解決了過去使用物理計算集群所面對的資源提供者和使用者之間的耦合問題，一定程度上降低了交付應用和創造業務價值的門檻，但在開發和運維的技術難度方面表現一般。

隨後，以Docker、Kubernetes為代表的容器技術日益盛行，對應用的虛擬化為創造和交付大規模業務系統鋪平了道路。然而單純的容器管理還不足以實現我們對於企業IT的願景——只需關注業務，無需在底層技術和基礎設施上花費大量時間和精力。

因此我們提出了「應用管理「的概念，圍繞以應用為中心，呈現為無伺服器PaaS和雲原生SaaS兩個產品服務。

image

應用管理的價值

對於大多數企業IT來說，業務價值來源於創造應用和使用應用兩個場景。傳統的業務系統運行方式，要求企業IT搭建運行環境，考慮網路、存儲、配置、負載均衡、安全等一些列基礎設置管理問題……這些工作在每一次系統搭建時重複進行，佔據了大量的企業IT成本。

通過在應用與計算資源之間增加應用管理層（無伺服器PaaS/雲原生SaaS）實現解耦，開發者和使用者僅關注業務邏輯設計、編碼、測試、上線等業務直接相關工作，源代碼與雲端運行之間的複雜工作交給應用管理層自動化完成。

換個角度來說，開發者和使用者將無需面對底層計算資源的管理複雜性，解除了開發對於運維的依賴，而運維人員僅需在平台自動化資源管理的基礎上維護資源池穩定即可。當開發與運維之間責任清晰、邊界明確，DevOps工作流也隨之得到天然的落地。

應用管理的服務模式

應用管理是Rainbond的核心設計思路，包括北向的應用抽象管理和南向的計算資源管理。

image

兩層應用抽象模型適用絕大多數企業IT系統和基礎應用，包括互聯網應用、行業應用、物理網應用和大數據技術應用等等。

在此基礎之上對於微服務架構的支持，包括開箱即用的Service Mesh、插件式治理功能擴展、兼容spring cloud、api gateway、dubbo等主流微服務架構，可實現多類型單體應用、新老應用的規模化整合，並配套標準、完整的功能特性。

當然，不同應用可能會有不同的高級需求，如Mysql熱備份、外網訪問應用需求防火牆等。Rainbond相應設計了應用插件體系，對應用功能進行差異化、無侵入式的拓展。

在計算資源管理方面，Rainbond對不同的計算資源進行統一池化，通過軟體定義基礎設置提供標準的計算服務，公有雲計算資源、IDC廠商、企業私有x86-64架構計算資源均作為Rainbond數據中心接入。

總結里說，Rainbond的服務模式可以描述為，用戶將任何應用運行於任何計算資源之上，按需靈活組合，並以SaaS化服務的形式提供給終端用戶。

以應用為中心的產品設計

Rainbond以應用為中心（app-centric）的產品設計理念體現在：

• 應用生產階段，Rainbond從設計上支持從各類型軟體源構建生產應用，包括各類型編程語言源碼、容器鏡像、DockerCompose文件等，以生產線的形式定義應用個層面元素——輸入代碼，輸出應用；
• 應用運行階段，Rainbond以軟體定義的方式管理存儲、網路、計算等各種資源，並在此基礎上運行App-Runtime，為應用提供統一的、豐富的服務，構建高性能架構；
• 應用傳播階段，Rainbond作為交付橋樑實現應用的一處構建、處處使用，即使是包含數百個獨立應用的微服務架構服務，企業也可以通過Rainbond交付給最終用戶一鍵部署使用；

Rainbond希望以產品為紐帶，構建由所有使用者組成的相輔相成的整體——在互聯互通的應用管理生態體系中，有人創造應用、有人發揮應用的最大價值、有人為應用提供超大資源保障。

Rainbond的技術架構

Rainbond是一套完整的PaaS平台解決方案，包括由應用控制、應用運行時、集群控制等三大魔魁結合而成的數據中心技術架構，以及跨數據中心的上策應用控制台和資源控制台。

重點組建包括：

• Chaos（應用構建/CI）
• Worker（應用部署/CD）
• Entrance（負載均衡/LB）
• Eventlog（日誌處理）
• Webcli（容器控制）
• Monitor（集群監控）
• Node（集群節點管理與Service Mesh）
• MQ（消息）
• App-UI
• Resource-UI
• grctl（命令行工具）

Chaos（應用構建/CI）

Rainbond應用構建(CI)組件——Chaos主要用於完成處理輸入介質（源代碼、Docker鏡像）並生成Rainbond應用抽象介質的過程。

傳統意義上完整的CI過程包括：設計、編碼、打包、測試、Release。而隨著Docker逐步成為眾多應用代碼打包的新形式，以及Jenkins、Gitlab等已有的CI產品在源碼測試和Pipline方面的成熟，Rainbond實現了對源碼或Docker鏡像的前置處理，可直接對接第三方服務，由第三方服務完成源碼或鏡像處理，再對接到Rainbond-Chaos模塊進行應用抽象。

Chaos支持Git協議代碼倉庫、Docker鏡像倉庫。對於源代碼，Chaos智能判斷源碼類型，如Java、PHP、Python、Dockerfile等，並根據不同源碼類型選擇對應BuildingPack進行源碼編譯，同時識別源碼中定義的埠、環境變數等參數，形成應用抽象的配置雛形。Dockerfile以外的源碼類型將被編譯成應用代碼環境包（SLUG）存儲於分散式存儲中，其他源碼則生成Docker本地鏡像存儲於數據中心的鏡像倉庫中，結合應用的各類屬性信息形成應用抽象包。

• 源碼編譯的BuildingPack請參考各語言支持文檔
• Chaos組件支持多點高可用部署，多點部署從MQ獲取應用構建任務

Worker（應用部署/CD）

應用部署（CD）組件——Worker將Chaos構建完成的應用抽象進行實例化，配置應用運行需要的各類資源，並完成應用生命周期中的運行態部分工作（啟停、升級、回滾等）。

不同的應用類型需要不同的控制策略，例如無狀態應用能夠進行無序的滾動升級，而有狀態應用的升級控制策略將更複雜一些。

應用運行需要各種外部環境支持，例如網路資源（租戶IP、埠等）分配、應用配屬持久化存儲資源設置，再如分配存儲目錄和塊存儲等依託各類插件的存儲資源分配、根據應用依賴屬性建立服務發現和負載均衡策略供給mesh插件等。

根據應用屬性生成的調度策略通過調用Kubernetes集群調度應用運行。目前Rainbond涉及ReplicationController、Deployment、Statefulset、Service、Pod等Kubernetes資源類型。不過對於Rainbond用戶來說，不需要理解這些概念，這些概念在Rainbond產品只做為應用運行的載體，中沒有使用上的複雜體現。

• Worker組件功能分為有狀態部分和無狀態部分，為了實現worker組件的集群部署，worker進行了主節點選舉，當選主節點的服務將額外啟動一個gRPC服務，提供應用狀態等數據服務。

Entrance（負載均衡/LB）

負載均衡（LB）組件——Entrance是已運行應用的關鍵組件。

Rainbond應用運行時為每個租戶分配子網，租戶之間網路隔離，因此集群內運行的應用不能直接通過外網訪問，而應用每次啟動IP地址隨之變化，租戶內應用與應用之間也無法直接訪問。

因此，Rainbond設計了應用埠級的服務控制，具備對內服務和對外服務兩個服務級別。打開相應的服務級別，應用運行時會生成對應的服務發現策略和負載均衡策略。

應用與應用直接的內部訪問由ServiceMesh完成，而應用外部訪問的負載均衡，由於不同應用提供不同協議的服務（http、mysql、mongo、websocket等）、現有負載均衡器（nginx、haproxy等）對於不同協議支持效果不同，Rainbond設計在4層協議支持之外，實現應用級別的負載均衡器選擇。

Entrance模塊需要對接不同的負載均衡器，針對於此抽象了池、節點、路由器規則等資源，實現不同的adapter適配不同的負載均衡器，並根據應用運行時和集群中應用的狀態變化、上線策略，實時操作負載均衡器以實現應用級別的LB。

• Entrance集群部署通過etcd實現全局資源一致性，防止了對同一個資源的重複操作

Eventlog（日誌處理）

Rainbond需要處理用戶非同步操作日誌、應用構建日誌、應用運行日誌等日誌和消息信息。

對於操作日誌，需要分散式跟蹤每一次操作的最終狀態，由Eventlog組件根據每一次操作的日誌匯聚判斷。其他組件在處理非同步任務過程中，會將過程日誌記錄通過gRPC消息流發送到eventlog集群。

Rainbond推薦區分應用日誌為兩類：由標準輸出和錯誤輸出的系統日誌和輸出到持久化文件的業務日誌（訪問日誌）。

對於標準輸出的日誌，Rainbond定製了docker日誌處理驅動插件，基於TCP數據流通信實現將所有計算節點的容器日誌，實時送往Eventlog組件按照應用級別的匯聚，從而進行存儲和實時推送到UI。

隨著集群規模越大，運行應用越多，日誌處理量非常大，因此我們實現了Eventlog的集群，每一個應用的日誌在傳輸之前會選擇送往的eventlog服務節點，類似於數據分區。選擇過程中做了均衡分配處理，例如當前有10000個應用，3個eventlog服務節點，將做到每個eventlog節點分別處理3000左右應用日誌。

對於輸出到持久化目錄的業務日誌，一般需要對其進行自動分析（例如對接ELK系統），因此在插件體系中安裝日誌處理插件，收集持久化目錄的日誌文件並輸送到第三方日誌分析服務上。

• 由於各種實時推送的需要，eventlog組件實現了websockt服務

Webcli（容器控制）

為方便用戶進入容器空間進行命令行操作，Rainbond提供Webcli組件，通過與UI進行websocket通信，用戶可以模擬Web終端發送各類shell命令。

Webcli通過kubernets提供的exec方式在容器中執行命令並返回結果到Web終端。

• Webcli屬於無狀態組件，天然支持多點高可用部署

Monitor（集群監控）

Rainbond包含應用業務性能級、應用容器資源級、集群節點級、管理服務級等多維度監控。

而集群監控組件Monitor是在監控報警項目Prometheus基礎之上包裝而成，能夠自動發現以上描述的各類監控對象並完成配置，將以上所述所有監控目標納入Prometheus監控範圍。Rainbond各組件也都實現了Prometheus的exporter端暴露監控指標。

Prometheus本身有單點性能障礙，當單節點服務監控目標數量很多時，內存使用量和磁碟使用量會變得非常大。為解決這一問題，Monitor組件在prometheus之上建立集群查詢機制，實現了Prometheus的多點數據分區運行。

在報警方面，Monitor能夠自動配置一些默認的報警規則（自定義的報警規則支持在資源管理後台體現），未來還將支持支持命令行控制。

實際運行中，Prometheus將發出報警信息到Monitor，在完成去重、忽略等操作後根據級別向用戶發送郵件、微信、站內報警信。

Node（集群節點管理與Service Mesh）

Node是Rainbond集群的基礎組件，運行於所有節點之上。當Node運行於管理節點，將具備master角色，維護所有節點的狀態與健康檢查。

在監控方面，Node暴露出節點的操作系統級別各類指標（集成promethes node-exporter），同時定時檢查不同屬性的節點上運行的各類服務狀態、網路狀態等。Node會嘗試自動解決監控到的問題，這是集群自動化運維能力的來源之一。

所有計算節點運行的Node服務共同組建起租戶網路內運行應用的運行環境支持，特別是ServiceMesh支持。

Node提供了envoy的全局化配置發現支持，與應用綁定的envoy插件通過宿主機網路跳出租戶網路，訪問Node服務獲取全局的服務網路治理配置信息。其他應用插件通過同樣的機制，可以從node服務中動態獲取配置、應用運行信息等。

MQ（消息）

考慮到能夠提供分散式消息一致性的消息中間件設計都很重，Rainbond沒有選擇使用已有的消息中間件服務，基於etcd實現輕量級分散式、消息持久化和一致性消息中間件MQ，用於維護非同步任務消息、提供多種主題的發布和訂閱能力，提供gRPC和http兩種介面實現pub/sub。

• 對於非同步消息任務的保證執行是MQ組件的下一步迭代方向

App-UI

應用控制台UI組件是Rainbond以應用為中心抽象的關鍵模塊，基於Django+Ant design前後端分離架構設計，為應用抽象、應用組抽象、數據中心抽象、應用市場抽象提供交互體驗。目前App-UI組件實現了完整的應用創建、管理流程，應用交付分享流程。

Resource-UI

Resource-UI（資源控制台UI）組件面向運維人員設計，提供Rainbond集群資源管理，關注節點物理資源、集群資源、管理服務資源、應用實際使用資源、租戶資源等管理，是Rainbond自動化運維能力的關鍵展示平台。Resource-UI目前屬於Rainbond企業版功能模塊，未來計劃支持對接IaaS的資源管理能力，

grctl（命令行工具）

grctl命令行工具提供一些有趣實用的應用管理功能和集群運維功能，方便開源使用用戶來說在沒有ResourceUI的情況下進行集群管理和運維，目前正在並逐步豐富中。

關於Rainbond

Rainbond是一款以應用為中心的開源PaaS，由好雨基於Docker、Kubernetes等容器技術自主研發，可作為公有雲或私有雲環境下的應用交付平台、DevOps平台、自動化運維平台和行業雲平台，或作為企業級的混合雲多雲管理工具、Kubernetes容器管理工具或Service Mesh微服務架構治理工具。

• Rainbond項目網站
• 試用Rainbond公有雲
• 註冊或使用Demo賬號/密碼登錄：rainbond-demo/rainbond-demo
• Github
• 碼雲
• 文檔
• 微信群: 添加微信「zqg5258423」並接受邀請入群

推薦閱讀：