開源PaaS Rainbond架構(gòu)與實(shí)現(xiàn)的示例分析

這篇文章將為大家詳細(xì)講解有關(guān)開源PaaS Rainbond架構(gòu)與實(shí)現(xiàn)的示例分析，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

回顧云計(jì)算產(chǎn)業(yè)技術(shù)的發(fā)展，IaaS層虛擬化的逐步成熟，解決了過去使用物理計(jì)算集群所面對的資源提供者和使用者之間的耦合問題，一定程度上降低了交付應(yīng)用和創(chuàng)造業(yè)務(wù)價(jià)值的門檻，但在開發(fā)和運(yùn)維的技術(shù)難度方面表現(xiàn)一般。

隨后，以Docker、Kubernetes為代表的容器技術(shù)日益盛行，對應(yīng)用的虛擬化為創(chuàng)造和交付大規(guī)模業(yè)務(wù)系統(tǒng)鋪平了道路。然而單純的容器管理還不足以實(shí)現(xiàn)我們對于企業(yè)IT的愿景——只需關(guān)注業(yè)務(wù)，無需在底層技術(shù)和基礎(chǔ)設(shè)施上花費(fèi)大量時(shí)間和精力。

因此我們提出了“應(yīng)用管理“的概念，圍繞以應(yīng)用為中心，呈現(xiàn)為無服務(wù)器PaaS和云原生SaaS兩個(gè)產(chǎn)品服務(wù)。

應(yīng)用管理的價(jià)值

對于大多數(shù)企業(yè)IT來說，業(yè)務(wù)價(jià)值來源于創(chuàng)造應(yīng)用和使用應(yīng)用兩個(gè)場景。傳統(tǒng)的業(yè)務(wù)系統(tǒng)運(yùn)行方式，要求企業(yè)IT搭建運(yùn)行環(huán)境，考慮網(wǎng)絡(luò)、存儲、配置、負(fù)載均衡、安全等一些列基礎(chǔ)設(shè)置管理問題……這些工作在每一次系統(tǒng)搭建時(shí)重復(fù)進(jìn)行，占據(jù)了大量的企業(yè)IT成本。

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

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

應(yīng)用管理的服務(wù)模式

應(yīng)用管理是Rainbond的核心設(shè)計(jì)思路，包括北向的應(yīng)用抽象管理和南向的計(jì)算資源管理。

兩層應(yīng)用抽象模型適用絕大多數(shù)企業(yè)IT系統(tǒng)和基礎(chǔ)應(yīng)用，包括互聯(lián)網(wǎng)應(yīng)用、行業(yè)應(yīng)用、物理網(wǎng)應(yīng)用和大數(shù)據(jù)技術(shù)應(yīng)用等等。

在此基礎(chǔ)之上對于微服務(wù)架構(gòu)的支持，包括開箱即用的Service Mesh、插件式治理功能擴(kuò)展、兼容spring cloud、api gateway、dubbo等主流微服務(wù)架構(gòu)，可實(shí)現(xiàn)多類型單體應(yīng)用、新老應(yīng)用的規(guī)?；?，并配套標(biāo)準(zhǔn)、完整的功能特性。

當(dāng)然，不同應(yīng)用可能會有不同的高級需求，如Mysql熱備份、外網(wǎng)訪問應(yīng)用需求防火墻等。Rainbond相應(yīng)設(shè)計(jì)了應(yīng)用插件體系，對應(yīng)用功能進(jìn)行差異化、無侵入式的拓展。

在計(jì)算資源管理方面，Rainbond對不同的計(jì)算資源進(jìn)行統(tǒng)一池化，通過軟件定義基礎(chǔ)設(shè)置提供標(biāo)準(zhǔn)的計(jì)算服務(wù)，公有云計(jì)算資源、IDC廠商、企業(yè)私有x86-64架構(gòu)計(jì)算資源均作為Rainbond數(shù)據(jù)中心接入。

總結(jié)里說，Rainbond的服務(wù)模式可以描述為，用戶將任何應(yīng)用運(yùn)行于任何計(jì)算資源之上，按需靈活組合，并以SaaS化服務(wù)的形式提供給終端用戶。

以應(yīng)用為中心的產(chǎn)品設(shè)計(jì)

Rainbond以應(yīng)用為中心（app-centric）的產(chǎn)品設(shè)計(jì)理念體現(xiàn)在：

• 應(yīng)用生產(chǎn)階段，Rainbond從設(shè)計(jì)上支持從各類型軟件源構(gòu)建生產(chǎn)應(yīng)用，包括各類型編程語言源碼、容器鏡像、DockerCompose文件等，以生產(chǎn)線的形式定義應(yīng)用個(gè)層面元素——輸入代碼，輸出應(yīng)用；

• 應(yīng)用運(yùn)行階段，Rainbond以軟件定義的方式管理存儲、網(wǎng)絡(luò)、計(jì)算等各種資源，并在此基礎(chǔ)上運(yùn)行App-Runtime，為應(yīng)用提供統(tǒng)一的、豐富的服務(wù)，構(gòu)建高性能架構(gòu)；

• 應(yīng)用傳播階段，Rainbond作為交付橋梁實(shí)現(xiàn)應(yīng)用的一處構(gòu)建、處處使用，即使是包含數(shù)百個(gè)獨(dú)立應(yīng)用的微服務(wù)架構(gòu)服務(wù)，企業(yè)也可以通過Rainbond交付給最終用戶一鍵部署使用；

Rainbond希望以產(chǎn)品為紐帶，構(gòu)建由所有使用者組成的相輔相成的整體——在互聯(lián)互通的應(yīng)用管理生態(tài)體系中，有人創(chuàng)造應(yīng)用、有人發(fā)揮應(yīng)用的最大價(jià)值、有人為應(yīng)用提供超大資源保障。

Rainbond的技術(shù)架構(gòu)

Rainbond是一套完整的PaaS平臺解決方案，包括由應(yīng)用控制、應(yīng)用運(yùn)行時(shí)、集群控制等三大魔魁結(jié)合而成的數(shù)據(jù)中心技術(shù)架構(gòu)，以及跨數(shù)據(jù)中心的上策應(yīng)用控制臺和資源控制臺。

重點(diǎn)組建包括：

• Chaos（應(yīng)用構(gòu)建/CI）

• Worker（應(yīng)用部署/CD）

• Entrance（負(fù)載均衡/LB）

• Eventlog（日志處理）

• Webcli（容器控制）

• Monitor（集群監(jiān)控）

• Node（集群節(jié)點(diǎn)管理與Service Mesh）

• MQ（消息）

• App-UI

• Resource-UI

• grctl（命令行工具）

Chaos（應(yīng)用構(gòu)建/CI）

Rainbond應(yīng)用構(gòu)建(CI)組件——Chaos主要用于完成處理輸入介質(zhì)（源代碼、Docker鏡像）并生成Rainbond應(yīng)用抽象介質(zhì)的過程。

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

Chaos支持Git協(xié)議代碼倉庫、Docker鏡像倉庫。對于源代碼，Chaos智能判斷源碼類型，如Java、PHP、Python、Dockerfile等，并根據(jù)不同源碼類型選擇對應(yīng)BuildingPack進(jìn)行源碼編譯，同時(shí)識別源碼中定義的端口、環(huán)境變量等參數(shù)，形成應(yīng)用抽象的配置雛形。Dockerfile以外的源碼類型將被編譯成應(yīng)用代碼環(huán)境包（SLUG）存儲于分布式存儲中，其他源碼則生成Docker本地鏡像存儲于數(shù)據(jù)中心的鏡像倉庫中，結(jié)合應(yīng)用的各類屬性信息形成應(yīng)用抽象包。

• 源碼編譯的BuildingPack請參考各語言支持文檔

• Chaos組件支持多點(diǎn)高可用部署，多點(diǎn)部署從MQ獲取應(yīng)用構(gòu)建任務(wù)

Worker（應(yīng)用部署/CD）

應(yīng)用部署（CD）組件——Worker將Chaos構(gòu)建完成的應(yīng)用抽象進(jìn)行實(shí)例化，配置應(yīng)用運(yùn)行需要的各類資源，并完成應(yīng)用生命周期中的運(yùn)行態(tài)部分工作（啟停、升級、回滾等）。

不同的應(yīng)用類型需要不同的控制策略，例如無狀態(tài)應(yīng)用能夠進(jìn)行無序的滾動升級，而有狀態(tài)應(yīng)用的升級控制策略將更復(fù)雜一些。

應(yīng)用運(yùn)行需要各種外部環(huán)境支持，例如網(wǎng)絡(luò)資源（租戶IP、端口等）分配、應(yīng)用配屬持久化存儲資源設(shè)置，再如分配存儲目錄和塊存儲等依托各類插件的存儲資源分配、根據(jù)應(yīng)用依賴屬性建立服務(wù)發(fā)現(xiàn)和負(fù)載均衡策略供給mesh插件等。

根據(jù)應(yīng)用屬性生成的調(diào)度策略通過調(diào)用Kubernetes集群調(diào)度應(yīng)用運(yùn)行。目前Rainbond涉及ReplicationController、Deployment、Statefulset、Service、Pod等Kubernetes資源類型。不過對于Rainbond用戶來說，不需要理解這些概念，這些概念在Rainbond產(chǎn)品只做為應(yīng)用運(yùn)行的載體，中沒有使用上的復(fù)雜體現(xiàn)。

• Worker組件功能分為有狀態(tài)部分和無狀態(tài)部分，為了實(shí)現(xiàn)worker組件的集群部署，worker進(jìn)行了主節(jié)點(diǎn)選舉，當(dāng)選主節(jié)點(diǎn)的服務(wù)將額外啟動一個(gè)gRPC服務(wù)，提供應(yīng)用狀態(tài)等數(shù)據(jù)服務(wù)。

Entrance（負(fù)載均衡/LB）

負(fù)載均衡（LB）組件——Entrance是已運(yùn)行應(yīng)用的關(guān)鍵組件。

Rainbond應(yīng)用運(yùn)行時(shí)為每個(gè)租戶分配子網(wǎng)，租戶之間網(wǎng)絡(luò)隔離，因此集群內(nèi)運(yùn)行的應(yīng)用不能直接通過外網(wǎng)訪問，而應(yīng)用每次啟動IP地址隨之變化，租戶內(nèi)應(yīng)用與應(yīng)用之間也無法直接訪問。

因此，Rainbond設(shè)計(jì)了應(yīng)用端口級的服務(wù)控制，具備對內(nèi)服務(wù)和對外服務(wù)兩個(gè)服務(wù)級別。打開相應(yīng)的服務(wù)級別，應(yīng)用運(yùn)行時(shí)會生成對應(yīng)的服務(wù)發(fā)現(xiàn)策略和負(fù)載均衡策略。

應(yīng)用與應(yīng)用直接的內(nèi)部訪問由ServiceMesh完成，而應(yīng)用外部訪問的負(fù)載均衡，由于不同應(yīng)用提供不同協(xié)議的服務(wù)（http、mysql、mongo、websocket等）、現(xiàn)有負(fù)載均衡器（nginx、haproxy等）對于不同協(xié)議支持效果不同，Rainbond設(shè)計(jì)在4層協(xié)議支持之外，實(shí)現(xiàn)應(yīng)用級別的負(fù)載均衡器選擇。

Entrance模塊需要對接不同的負(fù)載均衡器，針對于此抽象了池、節(jié)點(diǎn)、路由器規(guī)則等資源，實(shí)現(xiàn)不同的adapter適配不同的負(fù)載均衡器，并根據(jù)應(yīng)用運(yùn)行時(shí)和集群中應(yīng)用的狀態(tài)變化、上線策略，實(shí)時(shí)操作負(fù)載均衡器以實(shí)現(xiàn)應(yīng)用級別的LB。

• Entrance集群部署通過etcd實(shí)現(xiàn)全局資源一致性，防止了對同一個(gè)資源的重復(fù)操作

Eventlog（日志處理）

Rainbond需要處理用戶異步操作日志、應(yīng)用構(gòu)建日志、應(yīng)用運(yùn)行日志等日志和消息信息。

對于操作日志，需要分布式跟蹤每一次操作的最終狀態(tài)，由Eventlog組件根據(jù)每一次操作的日志匯聚判斷。其他組件在處理異步任務(wù)過程中，會將過程日志記錄通過gRPC消息流發(fā)送到eventlog集群。

Rainbond推薦區(qū)分應(yīng)用日志為兩類：由標(biāo)準(zhǔn)輸出和錯誤輸出的系統(tǒng)日志和輸出到持久化文件的業(yè)務(wù)日志（訪問日志）。

對于標(biāo)準(zhǔn)輸出的日志，Rainbond定制了docker日志處理驅(qū)動插件，基于TCP數(shù)據(jù)流通信實(shí)現(xiàn)將所有計(jì)算節(jié)點(diǎn)的容器日志，實(shí)時(shí)送往Eventlog組件按照應(yīng)用級別的匯聚，從而進(jìn)行存儲和實(shí)時(shí)推送到UI。

隨著集群規(guī)模越大，運(yùn)行應(yīng)用越多，日志處理量非常大，因此我們實(shí)現(xiàn)了Eventlog的集群，每一個(gè)應(yīng)用的日志在傳輸之前會選擇送往的eventlog服務(wù)節(jié)點(diǎn)，類似于數(shù)據(jù)分區(qū)。選擇過程中做了均衡分配處理，例如當(dāng)前有10000個(gè)應(yīng)用，3個(gè)eventlog服務(wù)節(jié)點(diǎn)，將做到每個(gè)eventlog節(jié)點(diǎn)分別處理3000左右應(yīng)用日志。

對于輸出到持久化目錄的業(yè)務(wù)日志，一般需要對其進(jìn)行自動分析（例如對接ELK系統(tǒng)），因此在插件體系中安裝日志處理插件，收集持久化目錄的日志文件并輸送到第三方日志分析服務(wù)上。

• 由于各種實(shí)時(shí)推送的需要，eventlog組件實(shí)現(xiàn)了websockt服務(wù)

Webcli（容器控制）

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

Webcli通過kubernets提供的exec方式在容器中執(zhí)行命令并返回結(jié)果到Web終端。

• Webcli屬于無狀態(tài)組件，天然支持多點(diǎn)高可用部署

Monitor（集群監(jiān)控）

Rainbond包含應(yīng)用業(yè)務(wù)性能級、應(yīng)用容器資源級、集群節(jié)點(diǎn)級、管理服務(wù)級等多維度監(jiān)控。

而集群監(jiān)控組件Monitor是在監(jiān)控報(bào)警項(xiàng)目Prometheus基礎(chǔ)之上包裝而成，能夠自動發(fā)現(xiàn)以上描述的各類監(jiān)控對象并完成配置，將以上所述所有監(jiān)控目標(biāo)納入Prometheus監(jiān)控范圍。Rainbond各組件也都實(shí)現(xiàn)了Prometheus的exporter端暴露監(jiān)控指標(biāo)。

Prometheus本身有單點(diǎn)性能障礙，當(dāng)單節(jié)點(diǎn)服務(wù)監(jiān)控目標(biāo)數(shù)量很多時(shí)，內(nèi)存使用量和磁盤使用量會變得非常大。為解決這一問題，Monitor組件在prometheus之上建立集群查詢機(jī)制，實(shí)現(xiàn)了Prometheus的多點(diǎn)數(shù)據(jù)分區(qū)運(yùn)行。

在報(bào)警方面，Monitor能夠自動配置一些默認(rèn)的報(bào)警規(guī)則（自定義的報(bào)警規(guī)則支持在資源管理后臺體現(xiàn)），未來還將支持支持命令行控制。

實(shí)際運(yùn)行中，Prometheus將發(fā)出報(bào)警信息到Monitor，在完成去重、忽略等操作后根據(jù)級別向用戶發(fā)送郵件、微信、站內(nèi)報(bào)警信。

Node（集群節(jié)點(diǎn)管理與Service Mesh）

Node是Rainbond集群的基礎(chǔ)組件，運(yùn)行于所有節(jié)點(diǎn)之上。當(dāng)Node運(yùn)行于管理節(jié)點(diǎn)，將具備master角色，維護(hù)所有節(jié)點(diǎn)的狀態(tài)與健康檢查。

在監(jiān)控方面，Node暴露出節(jié)點(diǎn)的操作系統(tǒng)級別各類指標(biāo)（集成promethes node-exporter），同時(shí)定時(shí)檢查不同屬性的節(jié)點(diǎn)上運(yùn)行的各類服務(wù)狀態(tài)、網(wǎng)絡(luò)狀態(tài)等。Node會嘗試自動解決監(jiān)控到的問題，這是集群自動化運(yùn)維能力的來源之一。

所有計(jì)算節(jié)點(diǎn)運(yùn)行的Node服務(wù)共同組建起租戶網(wǎng)絡(luò)內(nèi)運(yùn)行應(yīng)用的運(yùn)行環(huán)境支持，特別是ServiceMesh支持。

Node提供了envoy的全局化配置發(fā)現(xiàn)支持，與應(yīng)用綁定的envoy插件通過宿主機(jī)網(wǎng)絡(luò)跳出租戶網(wǎng)絡(luò)，訪問Node服務(wù)獲取全局的服務(wù)網(wǎng)絡(luò)治理配置信息。其他應(yīng)用插件通過同樣的機(jī)制，可以從node服務(wù)中動態(tài)獲取配置、應(yīng)用運(yùn)行信息等。

MQ（消息）

考慮到能夠提供分布式消息一致性的消息中間件設(shè)計(jì)都很重，Rainbond沒有選擇使用已有的消息中間件服務(wù)，基于etcd實(shí)現(xiàn)輕量級分布式、消息持久化和一致性消息中間件MQ，用于維護(hù)異步任務(wù)消息、提供多種主題的發(fā)布和訂閱能力，提供gRPC和http兩種接口實(shí)現(xiàn)pub/sub。

• 對于異步消息任務(wù)的保證執(zhí)行是MQ組件的下一步迭代方向

App-UI

應(yīng)用控制臺UI組件是Rainbond以應(yīng)用為中心抽象的關(guān)鍵模塊，基于Django+Ant design前后端分離架構(gòu)設(shè)計(jì)，為應(yīng)用抽象、應(yīng)用組抽象、數(shù)據(jù)中心抽象、應(yīng)用市場抽象提供交互體驗(yàn)。目前App-UI組件實(shí)現(xiàn)了完整的應(yīng)用創(chuàng)建、管理流程，應(yīng)用交付分享流程。

Resource-UI

Resource-UI（資源控制臺UI）組件面向運(yùn)維人員設(shè)計(jì)，提供Rainbond集群資源管理，關(guān)注節(jié)點(diǎn)物理資源、集群資源、管理服務(wù)資源、應(yīng)用實(shí)際使用資源、租戶資源等管理，是Rainbond自動化運(yùn)維能力的關(guān)鍵展示平臺。Resource-UI目前屬于Rainbond企業(yè)版功能模塊，未來計(jì)劃支持對接IaaS的資源管理能力，

grctl（命令行工具）

grctl命令行工具提供一些有趣實(shí)用的應(yīng)用管理功能和集群運(yùn)維功能，方便開源使用用戶來說在沒有ResourceUI的情況下進(jìn)行集群管理和運(yùn)維，目前正在并逐步豐富中。

關(guān)于Rainbond

Rainbond是一款以應(yīng)用為中心的開源PaaS，由好雨基于Docker、Kubernetes等容器技術(shù)自主研發(fā)，可作為公有云或私有云環(huán)境下的應(yīng)用交付平臺、DevOps平臺、自動化運(yùn)維平臺和行業(yè)云平臺，或作為企業(yè)級的混合云多云管理工具、Kubernetes容器管理工具或Service Mesh微服務(wù)架構(gòu)治理工具。

關(guān)于開源PaaS Rainbond架構(gòu)與實(shí)現(xiàn)的示例分析就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。