開源PaaS Rainbond的架構與實現

時間 2019-11-16

原文原文鏈接

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

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

所以咱們提出了「應用管理「的概念，圍繞以應用爲中心，呈現爲無服務器PaaS和雲原生SaaS兩個產品服務。nginx

應用管理的價值

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

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

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

應用管理的服務模式

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

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

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

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

在計算資源管理方面，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微服務架構治理工具。