無伺服器(ServerLess)PaaS—Rainbond宣佈開源

Rainbond：國內首個開源的無伺服器PaaS

Rainbond是好雨開源的生產級無伺服器PaaS，該專案基於Kubernetes、CI/CD、多資料中心管理等技術，為雲原生應用的建立組裝、執行生產、釋出傳播提供全生命週期解決方案，並構建應用與基礎設施、應用之間及基礎設施之間的互聯互通生態體系。

在設計層面，Rainbond遵循“以應用為中心，軟體定義一切”，它通過軟體定義系列對計算資源、執行環境、運維管理、複雜技術進行了應用化包裝，使資源、架構、應用充分解耦，對外呈現簡單的使用體驗，包括構建、配置以及監控、日誌、依賴、儲存、埠等所有資訊和操作均圍繞應用層面展開，應用可以一處構建、到處執行。

原始碼構建

有別於一般容器雲平臺，Rainbond不僅可以從映象或以docker-compose方式構建應用，還支援Java、PHP、Python、Ruby、Node.js、Golang、Scala等主流語言的原始碼構建。換句話說，使用者不需要理解Docker，也不需要編寫Dockerfile，Rainbond將自動識別語言，並將原始碼自動構建成應用。與此同時，Rainbond還提供了對於Jenkins等第三方CI/CD的對接支援。

在Rainbond上構建的應用，可搭配Mysql、Redis、Zookeeper等各類資料儲存應用，構成一個完整的服務，並可釋出到私有應用市場供企業內部共享，或分享到好雨雲市進行商業銷售。

微服務架構落地

微服務架構是Rainbond的核心功能之一，在它之上部署的任何應用，本身即是微服務，可按照微服務的方式進行操作。藉助好雨微服務架構強大的外掛體系，Rainbond無侵入原生提供服務治理、服務註冊與發現、服務升級、服務監控、服務伸縮等功能，同時支援各類第三方微服務框架。

同樣由好雨開源的最佳實踐專案雲框架中的Spring Cloud、api gateway等微服務架構主題，均可完美執行於Rainbond之上，開發者僅需替換例項中業務程式碼即可變成自己的微服務架構專案，並通過docker-compose的方式一鍵部署。

混合雲多雲管理

混合雲多雲管理是Rainbond的另一項優勢功能。在雲端計算飛速發展的今天，眾多廠商提供了豐富的各型別公有云資源，Rainbond通過對應用與資源的解耦，將各類資源（私有云伺服器、公有云伺服器、網路資源）統一整合成Rainbond資料中心，對各類資源進行自動管理，實現跨區域互聯與租戶化隔離，使用者無需關注伺服器即可將應用部署於混合雲多雲環境。

除了上文提到的特點，雲幫還具備以下特性：

CI/CD

• 支援Java、PHP、Python、Ruby、Node.js、Golang等語言直接構建
• 支援docker映象和Dockerfile構建應用
• 支援Docker Compose快速部署
• 可對接私有和公有Git倉庫
• 支援雲框架一鍵部署
• 遵循雲原生應用12要素原則
• 支援應用一鍵升級/回滾，當前業務不間斷
• 根據使用者使用場景可以靈活定製開發和釋出流程

高效運維

• 支援停止、啟動、刪除等應用控制
• 提供應用操作日誌
• 支援應用日誌實時輸出、檢視和打包下載
• 應用原生支援負載均衡
• 提供單點和多節點服務高可用機制
• 應用支援埠／域名／環境變數／對內對外服務的高階管理選項
• 支援應用手動伸縮（垂直、水平）
• 支援應用特性增強
• 提供實時的業務級監控
• 支援實時HTTP／MySQL協議效能分析

應用市場

• 支援釋出應用到應用市場
• 支援釋出一組分散式應用到應用市場
• 支援企業內部私有應用市場，IT部門和其他部門高效銜接
• 好雨應用市場提供大量開源和商業應用
• 支援從應用市場一鍵安裝
• 支援對已釋出應用進行管理

微服務架構

• 支援跨開發語言和跨協議的微服務架構
• 原生支援Service Mash
• 支援服務自動發現和服務動態編排
• 支援依賴關係與環境變數管理
• 支援微服務架構釋出到應用市場並支援一鍵安裝
• 支援非微服務按微服務管理和對接微服務架構
• 通過整體服務拓撲圖快速監控和管理微服務架構
• 支援Spring Cloud、Dubbo、api gateway等主流微服務架構

其他

• 支援平臺全功能的API介面
• 提供的團隊許可權管理
• 提供基於全路由的網路組建
• 提供基於Overlay的網路組建
• 支援NAS儲存方式，如NFS／GlusterFS
• 支援多資料中心管理
• 支援多租戶

目前，Rainbond原始碼已託管在Github上，採用GPLv3許可證。Github：https://github.com/goodrain/rainbond  文件：https://www.rainbond.com/docs/

什麼是無伺服器PaaS？

PaaS在雲端計算典型層級中介於應用和基礎設施之間，提供運算平臺和解決方案堆疊，像我們經常提到的Google App Engine、Cloud Foundry等平臺均屬於PaaS。這些早期的PaaS在一定程度上為開發者帶來了效率的提升和成本的降低，但也存在著支援語言有限、支援場景有限、學習成本太高的問題。

不過隨著近年來容器和軟體定義系列技術的成熟，以上阻礙PaaS發展的問題有機會得到解決，PaaS可以變得更靈活，形成支援各種語言和架構場景且簡單易用的平臺——無伺服器PaaS（Serverless PaaS），可以從應用角度支援各類複雜技術架構和業務交付流程，讓使用者專注業務開發和管理，而不需要關注底層伺服器相關的複雜技術。

Rainbond的設計思路

“無伺服器”是表現，背後的設計思路則是“以應用為中心，軟體定義一切”，具體來說有以下三點：

1.以應用粒度包裝底層複雜技術和基礎設施

直接面對基礎設施的開發和運維，不可避免地需要學習和管理很多技術，例如伺服器、網路、儲存、安全、負載均衡等，想要支援大使用者，還必須在此之上考慮分散式架構和效能優化的問題。

但如果將基礎設施通過軟體定義系列技術對接管理，梳理清楚技術點之間的內在聯絡，用開發和運維的最佳實踐，配合Kubernetes等技術，就可以將以上技術以應用的粒度簡化包裝，讓終端使用者通過簡單的使用方式專注在業務交付之上。同時應用粒度還能繼續相容現有技術架構，不影響架構靈活性。

2.解耦應用和基礎設施

通過滿足以下兩點解耦應用和基礎設施：

• 對接基礎設施時，不使用基礎設施提供的差異化能力
• 執行應用時，可以依賴平臺的特性

平臺實現解耦應用和基礎設施，應用和基礎設施將可以隨意組合，應用無需任何改動即可遷移至其他基礎設施，管理起來更方便且不被任何基礎設施繫結。

3.連線應用和基礎設施

核心模式：

• 連線應用和應用，實現分散式架構和微服務架構
• 連線應用和基礎設施，實現應用和基礎設施的靈活對接
• 連線基礎設施和基礎設施，實現混合雲、多雲和多資料中心

圖：Rainbond架構層次

Rainbond的技術優勢

從完整性上來說，Rainbond覆蓋了應用的建立組裝、執行生產、釋出傳播三個階段，是一個重量級的PaaS。除了“無伺服器”以外，Rainbond還在應用構建、微服務架構、混合雲多雲方面具備獨特的技術優勢。

圖：Rainbond交付流程

應用構建

一般容器化的PaaS平臺，往往會從映象開始應用的構建，這就意味著開發者需要花費額外的時間來把原始碼打包成映象。其次，容器映象的構建者進行的任何修改，對於映象使用者來說往往是不透明的，不利於團隊之間的協作。另外，當容器映象依賴的父映象發生變化時，必須重新構建，而如果不能從原始碼自動構建的話，需要手動修改容器的檔案系統。這些重複性的工作其實是沒有價值的。

Rainbond在應用構建方面面向多種介質來源，設計為持續整合／持續交付（CI/CD）的外掛式Pipeline。目前支援的來源有：

• 原始碼（Java、PHP、Python、Ruby、Node.js、Golang、Scala）
• 映象
• Dockerfile
• Docker-Compose

基於不同的來源，Rainbond構建出統一的應用完整執行介質，可以執行在各處Rainbond平臺之上。

在構建流程中，Rainbond從Dockerfile或映象檔案中智慧識別儲存、埠等配置資訊，近期還會定義rbdfile規範，方便開發者在原始碼中預先定義應用配置和執行環境配置。另外，Rainbond針對Jenkins等已有CI系統的對接也會在近期開放。

微服務架構

上文提到的“無伺服器”，側重於應用與資源、資源與資源之間的解耦，而應用與應用之間的解耦，需要依賴微服務架構實現。如果說容器技術對於應用和資源的解耦為我們帶來了可移植性和速度，那麼微服務架構對於應用之間的解耦則為我們帶來了敏捷性和適應性。

Rainbond的微服務架構設計基於ServiceMesh，初期以sidecar形式對應用所依賴的應用進行4層透明本地網路代理，遮蔽了應用的IP變化問題，而Rainbond本身並不處理通訊協議，完整的微服務功能由框架完成，因此Rainbond可以原生部署Spring Cloud、api gateway等第三方微服務框架。

目前Rainbond正在構建應用外掛體系，對sidecar模式進行進一步的封裝，為應用通訊和治理創造更大的擴充套件空間。其中計劃在近期增加的以envoy為基礎的7層網路治理外掛，將用來向原生的熔斷、限流、金絲雀部署等高階治理提供支援。

應用外掛體系結合已有Rainbond APP Runtime提供的服務伸縮、服務註冊和發現、自定義資源註冊和發現等功能，將可以原生提供可擴充套件的微服務執行環境，開發者也無需再學習第三方微服務框架複雜的技術實現。

圖：Rainbond部署Spring Cloud微服務框架拓撲圖

混合雲多雲

雲端計算髮展至今，湧現出了各種型別、不同廠商的計算資源，開發者面對的已經不再是單一的物理硬體、虛擬機器或公有云，因此如何管理混合雲多雲也是一個急需解決的問題。

面對各型別計算資源，Rainbond遮蔽了計算資源之間的不同，提供統一的應用執行環境，讓應用在無繫結的情況下快速進行多個資料中心之間的部署和遷移。具體實現如下：

1. 在各型別計算資源上建立獨立的資料中心，沒有特殊的基礎服務要求
2. 將所有節點統一抽象為rbd-node，並按功能分類（計算節點、基礎管理節點、儲存節點、負載均衡節點等）
3. 自動安裝節點自動化維護系統，對所有節點進行監控和管理

站在資源角度，無論公有或是私有，當我們通過以上方式連線物理機和IaaS便實現了混合雲的管理，連線不同IaaS便實現了多雲的管理。

Rainbond計劃在未來推出應用快照功能，對應用介質、環境配置、持久化資料進行快照備份，開發者可以通過此功能遷移執行態應用。

Rainbond與Heroku的對比

做為市場上最早的一批PaaS平臺，Heroku過去在海外開發者中備受推崇，它建立了很多沿用至今的平臺服務標準，其中就包括Cloud Native 12 Factors，雲原生應用的12要素。

Heroku提倡App-centric，使開發者可以專注於構建而不必關心基礎設施建設。在這一點上，Rainbond與Heroku是一致的。兩者也都支援主流開發語言、常用資料服務、應用伸縮、程式碼上線和回滾、對接Github，提供應用級監控和網路隔離的使用者空間。

不過Heroku對分散式架構、混合雲多雲，以及在安全控制、可見性和靈活性上對於滿足業務增長需求的架構略顯不足。

Rainbond與官方Kubernetes的對比

Kubernetes經過三年發展，儼然已經成為了容器編排和管理的社群標準，它提出的一系列概念抽象，非常符合理想的分散式排程系統。但大量高難度技術概念，同時也形成了一條陡峭的學習曲線，直接拉高了Kubernetes的使用門檻，而Rainbond將這些技術概念包裝成為“Production-Ready”的應用，開發者不需要特殊學習即可使用。

另一方面，Kubernetes本身是一個容器編排工具，並不提供管理流程，而Rainbond提供現成的管理流程，包括DevOps、自動化運維、微服務架構和應用市場等，可以開箱即用。

未來規劃

對於未來，Rainbond計劃搭建應用外掛擴充套件體系、支援跨資料中心的應用，並在未來構造互聯互通的生態。

搭建應用外掛擴充套件體系

應用往往需要一系列輔助功能來達到生產級別可用，例如MySQL需要定期資料備份或同步、api應用需要實時收集應用進行分析、應用升級需要處理資料 結構和資料持久化。

Rainbond計劃搭建一套通用性強的外掛支援體系，允許外掛和應用整合使用。開發者可以在體系內貢獻自研外掛，自研外掛的輸入、輸出、執行方式完全由外掛作者制定。

支援跨資料中心應用

在部分特殊場景下，同一個應用需要分割槽域部署，單個資料中心的高可用是不夠的。Rainbond計劃利用CRDTs資料模型的分散式架構，解決未來資料在大量邊緣資料中心同步的問題。

目前Rainbond已經通過應用抽象實現了無狀態應用的多資料中心部署，而對於資料庫類應用，Rainbond近期將通過對Geo-replication database類分散式資料庫的進一步支援，實現跨資料中心型資料應用的多資料中心多活部署。

構造互聯互通的生態

通過對接好雨雲市，讓應用在開發者之間流動起來，既可以快速使用，也可以分享或銷售。

通過引入更多的資料中心合作伙伴，讓公有資料中心擁有更大的覆蓋範圍，方便開發者自由選擇部署，並根據需要在私有和公有資料中心之間遷移。開發者甚至不需要專門構建自己的資料中心，僅通過簡單的控制檯即可將應用部署在距離世界上任何使用者最近的地方。