共計 5850 個字符，預計需要花費 15 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關開源 PaaS Rainbond 架構與實現的示例分析，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

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

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

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

應用管理的價值

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

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

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

應用管理的服務模式

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

兩層應用抽象模型適用絕大多數企業 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 微服務架構治理工具。

關于開源 PaaS Rainbond 架構與實現的示例分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。