溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章將為大家詳細講解有關開源PaaS Rainbond架構與實現的示例分析，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
回顧云計算產業技術的發展，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是一套完整的PaaS平臺解決方案，包括由應用控制、應用運行時、集群控制等三大魔魁結合而成的數據中心技術架構，以及跨數據中心的上策應用控制臺和資源控制臺。
重點組建包括：
Chaos（應用構建/CI）
Worker（應用部署/CD）
Entrance（負載均衡/LB）
Eventlog（日志處理）
Webcli（容器控制）
Monitor（集群監控）
Node（集群節點管理與Service Mesh）
MQ（消息）
App-UI
Resource-UI
grctl（命令行工具）
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獲取應用構建任務
應用部署（CD）組件——Worker將Chaos構建完成的應用抽象進行實例化，配置應用運行需要的各類資源，并完成應用生命周期中的運行態部分工作（啟停、升級、回滾等）。
不同的應用類型需要不同的控制策略，例如無狀態應用能夠進行無序的滾動升級，而有狀態應用的升級控制策略將更復雜一些。
應用運行需要各種外部環境支持，例如網絡資源（租戶IP、端口等）分配、應用配屬持久化存儲資源設置，再如分配存儲目錄和塊存儲等依托各類插件的存儲資源分配、根據應用依賴屬性建立服務發現和負載均衡策略供給mesh插件等。
根據應用屬性生成的調度策略通過調用Kubernetes集群調度應用運行。目前Rainbond涉及ReplicationController、Deployment、Statefulset、Service、Pod等Kubernetes資源類型。不過對于Rainbond用戶來說，不需要理解這些概念，這些概念在Rainbond產品只做為應用運行的載體，中沒有使用上的復雜體現。
Worker組件功能分為有狀態部分和無狀態部分，為了實現worker組件的集群部署，worker進行了主節點選舉，當選主節點的服務將額外啟動一個gRPC服務，提供應用狀態等數據服務。
負載均衡（LB）組件——Entrance是已運行應用的關鍵組件。
Rainbond應用運行時為每個租戶分配子網，租戶之間網絡隔離，因此集群內運行的應用不能直接通過外網訪問，而應用每次啟動IP地址隨之變化，租戶內應用與應用之間也無法直接訪問。
因此，Rainbond設計了應用端口級的服務控制，具備對內服務和對外服務兩個服務級別。打開相應的服務級別，應用運行時會生成對應的服務發現策略和負載均衡策略。
應用與應用直接的內部訪問由ServiceMesh完成，而應用外部訪問的負載均衡，由于不同應用提供不同協議的服務（http、mysql、mongo、websocket等）、現有負載均衡器（nginx、haproxy等）對于不同協議支持效果不同，Rainbond設計在4層協議支持之外，實現應用級別的負載均衡器選擇。
Entrance模塊需要對接不同的負載均衡器，針對于此抽象了池、節點、路由器規則等資源，實現不同的adapter適配不同的負載均衡器，并根據應用運行時和集群中應用的狀態變化、上線策略，實時操作負載均衡器以實現應用級別的LB。
Entrance集群部署通過etcd實現全局資源一致性，防止了對同一個資源的重復操作
Rainbond需要處理用戶異步操作日志、應用構建日志、應用運行日志等日志和消息信息。
對于操作日志，需要分布式跟蹤每一次操作的最終狀態，由Eventlog組件根據每一次操作的日志匯聚判斷。其他組件在處理異步任務過程中，會將過程日志記錄通過gRPC消息流發送到eventlog集群。
Rainbond推薦區分應用日志為兩類：由標準輸出和錯誤輸出的系統日志和輸出到持久化文件的業務日志（訪問日志）。
對于標準輸出的日志，Rainbond定制了docker日志處理驅動插件，基于TCP數據流通信實現將所有計算節點的容器日志，實時送往Eventlog組件按照應用級別的匯聚，從而進行存儲和實時推送到UI。
隨著集群規模越大，運行應用越多，日志處理量非常大，因此我們實現了Eventlog的集群，每一個應用的日志在傳輸之前會選擇送往的eventlog服務節點，類似于數據分區。選擇過程中做了均衡分配處理，例如當前有10000個應用，3個eventlog服務節點，將做到每個eventlog節點分別處理3000左右應用日志。
對于輸出到持久化目錄的業務日志，一般需要對其進行自動分析（例如對接ELK系統），因此在插件體系中安裝日志處理插件，收集持久化目錄的日志文件并輸送到第三方日志分析服務上。
由于各種實時推送的需要，eventlog組件實現了websockt服務
為方便用戶進入容器空間進行命令行操作，Rainbond提供Webcli組件，通過與UI進行websocket通信，用戶可以模擬Web終端發送各類shell命令。
Webcli通過kubernets提供的exec方式在容器中執行命令并返回結果到Web終端。
Webcli屬于無狀態組件，天然支持多點高可用部署
Rainbond包含應用業務性能級、應用容器資源級、集群節點級、管理服務級等多維度監控。
而集群監控組件Monitor是在監控報警項目Prometheus基礎之上包裝而成，能夠自動發現以上描述的各類監控對象并完成配置，將以上所述所有監控目標納入Prometheus監控范圍。Rainbond各組件也都實現了Prometheus的exporter端暴露監控指標。
Prometheus本身有單點性能障礙，當單節點服務監控目標數量很多時，內存使用量和磁盤使用量會變得非常大。為解決這一問題，Monitor組件在prometheus之上建立集群查詢機制，實現了Prometheus的多點數據分區運行。
在報警方面，Monitor能夠自動配置一些默認的報警規則（自定義的報警規則支持在資源管理后臺體現），未來還將支持支持命令行控制。
實際運行中，Prometheus將發出報警信息到Monitor，在完成去重、忽略等操作后根據級別向用戶發送郵件、微信、站內報警信。
Node是Rainbond集群的基礎組件，運行于所有節點之上。當Node運行于管理節點，將具備master角色，維護所有節點的狀態與健康檢查。
在監控方面，Node暴露出節點的操作系統級別各類指標（集成promethes node-exporter），同時定時檢查不同屬性的節點上運行的各類服務狀態、網絡狀態等。Node會嘗試自動解決監控到的問題，這是集群自動化運維能力的來源之一。
所有計算節點運行的Node服務共同組建起租戶網絡內運行應用的運行環境支持，特別是ServiceMesh支持。
Node提供了envoy的全局化配置發現支持，與應用綁定的envoy插件通過宿主機網絡跳出租戶網絡，訪問Node服務獲取全局的服務網絡治理配置信息。其他應用插件通過同樣的機制，可以從node服務中動態獲取配置、應用運行信息等。
考慮到能夠提供分布式消息一致性的消息中間件設計都很重，Rainbond沒有選擇使用已有的消息中間件服務，基于etcd實現輕量級分布式、消息持久化和一致性消息中間件MQ，用于維護異步任務消息、提供多種主題的發布和訂閱能力，提供gRPC和http兩種接口實現pub/sub。
對于異步消息任務的保證執行是MQ組件的下一步迭代方向
應用控制臺UI組件是Rainbond以應用為中心抽象的關鍵模塊，基于Django+Ant design前后端分離架構設計，為應用抽象、應用組抽象、數據中心抽象、應用市場抽象提供交互體驗。目前App-UI組件實現了完整的應用創建、管理流程，應用交付分享流程。
Resource-UI（資源控制臺UI）組件面向運維人員設計，提供Rainbond集群資源管理，關注節點物理資源、集群資源、管理服務資源、應用實際使用資源、租戶資源等管理，是Rainbond自動化運維能力的關鍵展示平臺。Resource-UI目前屬于Rainbond企業版功能模塊，未來計劃支持對接IaaS的資源管理能力，
grctl命令行工具提供一些有趣實用的應用管理功能和集群運維功能，方便開源使用用戶來說在沒有ResourceUI的情況下進行集群管理和運維，目前正在并逐步豐富中。
Rainbond是一款以應用為中心的開源PaaS，由好雨基于Docker、Kubernetes等容器技術自主研發，可作為公有云或私有云環境下的應用交付平臺、DevOps平臺、自動化運維平臺和行業云平臺，或作為企業級的混合云多云管理工具、Kubernetes容器管理工具或Service Mesh微服務架構治理工具。
關于開源PaaS Rainbond架構與實現的示例分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
