開源PaaS Rainbond v3.6.0：提供service mesh微服務架構開箱即用

Service Mesh 自 2018 年以來，受到了前所未有的關注，這種微服務架構允許我們在開發應用時，只關注業務代碼，而不需要關心技術底層邏輯，被認為是企業擴展、保護和監控微服務的最佳方式。

好雨同樣對 Sevice Mesh 微服務架構寄予厚望。經過過去三年對微服務架構不斷的思考和實踐，我們在開源 PaaS Rainbond v3.6.0 中，正式釋出了對 Service Mesh 微服務架構開箱即用的支持，其主要特點如下——

業務代碼無侵入

以透明代理的形式提供服務間通信，不會與業務代碼耦合

跨語言 & 跨協議

不限制服務開發語言，使用 HTTP、gPRC 等輕量級通信協議

支持主流微服務架構

spring cloud 、api gateway、dubbo

通過插件式擴展來實現治理功能

服務發現和註冊、彈性伸縮與負載均衡、容錯處理（斷路器與限流）、監控與報警、數據存儲與共享、日誌分析等

1

Rainbond Service Mesh 的實現

Rainbond 利用容器的 sidecar 模式，抽象出應用插件層，根據不同的插件類型提供不同的控制策略，例如可根據應用容器的啟動順序、運行環境等，並在全局應用運行時提供標準的服務發現介面、配置發現介面，相當於 Rainbond 通過插件的方式提供了 envoy 的運行環境。

ServiceMesh 功能在 Rainbond 中通過服務網路治理插件來實現，在「我的插件」中安裝該插件，並在需要使用的應用中啟用該插件，即在該應用上啟用了 Service Mesh，示例如下：

安裝服務網路治理插件

在應用中啟用插件

配置插件

2

Rainbond 如何通過插件式擴展來實現治理功能

服務發現和註冊

服務註冊是任何一個 SOA/ 服務化 / 微服務框架必不可少的關鍵部分，與之密切相關的是一些強一致性分散式存儲：Zookeeper、Etcd、Consul，其中 Consul 和 Etcd 基於 Raft 協議實現，Zookeeper 基於 PAXOS 協議實現。

幾乎所有的服務註冊和發現都需要基於以上強一致性分散式存儲實現，例如 SpringCloud 的兩個重要的子項目 Spring_Cloud_Consul/Spring_Cloud_Zookeeper。

對於 Rainbond 來說，通過應用 / 服務統一管理實現了所有部署應用 / 服務的自動註冊。其原理在於 Rainbond 內部基於 Kubernetes 實現應用調度，註冊於 Kubernetes 集群中的應用 / 服務信息，實際也是註冊到了 Etcd 之中。應用實例每次重啟，Rianbond 都會為其分配不同的 IP 地址，服務註冊信息將動態地改變。

我們知道，應用與應用直接通信之前必須首先發現對方，在這方面，Rainbond 採用了聲明式的發現機制，即當 A 服務需要與 B 服務通信，那麼首先需要在 A 服務聲明依賴 B 服務，而 Rainbond 應用運行時模塊會基於用戶聲明發現對方服務地址，注入到 A 服務內部, 賦予 A 服務一個本地訪問地址（127.0.0.1）訪問 B 服務。

平台服務間的依賴關係

彈性伸縮與負載均衡

說到服務發現和註冊，彈性伸縮與負載均衡也就不得不談。

上文中 A 服務連接 B 服務，B 服務可以是有狀態的資料庫服務，例如 Mysql、MongoDB 等，也可以是無狀態的 restfulAPI 服務。

對於可以水平伸縮的應用（無狀態應用或者分散式有狀態應用），服務發現注入多個端點地址，必然需要負載均衡，因此 A 服務內部需要支持 4 層網路代理或者 7 層網路代理，通過應用運行時模塊發現的後端地址注入到代理插件內部。

Rainbond 默認的代理插件支持 4 層負載均衡，藉助 Service Mesh 便於擴展得特性，我們可以再針對各種應用層協議匹配不同的網路治理插件，實現 7 層負載均衡，例如 HTTP、gRPC、Redis 等協議。

為什麼需要 7 層負載均衡這樣的高級功能？原因在於對於一些在線環境，我們希望可以對服務間調用實現熱更改或者更好的容錯，比方說 A/B 測試、灰度發布等等，必須要在 7 層負載均衡上完成。

Rainbond 目前提供「基於 envoy 的 7 層網路治理插件」（envoy 本身可以與安生運行於 Rainbond 插件體系之中），用戶也可以選擇和實現其他插件，Rainbond 運行時將提供完善的基礎服務。

配置 7 層高級負載均衡的方式

容錯處理（斷路器與限流）

能夠容忍其中某些服務異常情況的微服務架構，才稱得上是健壯的生產級微服務架構。比方說某購物網站，訂單頁面會推薦其他相關商品，在大流量異常情況下，為了保證訂單功能可用，將推薦功能（計算耗時，性能不好）限制可用，需要優雅的服務降級，將有限的資源用於關鍵服務的同時，保證整個系統穩定。

這裡有兩種方案：，將某個服務設置其最大的請求量或者連接數，硬性保護下游服務；，當下游服務錯誤率到達一個閥值，將上游請求快速失敗返回，保護上游服務穩定，同時又不給下游服務增加壓力，做到快速失敗、快速返回。

以上功能的實現對於業務系統來說相對複雜，而在上文提到的 Rainbond 高級負載均衡支持下，僅需為每個調用線路配置簡單的限流參數或者熔斷參數，即可實現斷路器和限流機制開箱即用。

監控與報警

傳統運維關注監控物理資源，例如內存、CPU、負載等指標數據。Rainbond 在監控和警報方面，重點沒有放在這些側面體現運行狀況的方式，除了基礎的資源監控之外，Rainbond 核心選擇了能夠直接體現服務運行情況的和作為關鍵指標，如吞吐率異常降低，響應時間增大證明當前服務壓力過大，就表示需要擴容了。

Rainbond 的業務級監控分析如下圖：

對於不同的服務協議，Rainbond 使用不同的指標實時表現、，例如 HTTP 協議，使用 Path 的請求量和相應時間表達，Mysql 協議使用 SQL 執行量和響應時間表達。

後續 Rainbond 將支持除上述兩種協議之外的更多的應用協議，包括 gRPC、Redis、postgreSQL 等。用戶可以自動或手動在這些指標之上配置規則或自動學習規則，實現提供業務報警和自動伸縮。

數據存儲與共享

分散式是微服務架構中不可缺少的部分，在運行多種不同類型應用、需求不同存儲，並且不同數據中心和不同基礎設施提供不同存儲類型的情況下，實現和處理起來並不容易。

Rainbond 的實現方式是將存儲和應用進行解耦和，插件式支持不同的存儲類型，例如基於 NFS 的分散式文件存儲、塊設備存儲、內存虛擬存儲等，

當然不同的存儲具有不同的屬性，Rainbond 分散式無狀態應用最常用的是共享文件存儲，為每個應用分配的存儲區域將掛載到所有實例之上，實時同步數據。用戶可以自定義需要掛載的路徑，應用到哪裡，數據就跟到哪裡。

日誌分析

微服務架構中服務產生的日誌處理也是一個難點，日誌需要統一收集，同一個應用的多個實例產生的日誌需要匯聚，然後需要分析和報警。

服務的日誌一般會分為兩部分：系統日誌和訪問日誌，Rainbond 推薦將兩類日誌區別處理。

對於系統日誌，其主要作用是調試系統、記錄異常，Rainbond 提供基於應用級別的應用日誌匯聚和實時展示，因此只需要將系統日誌輸出到標準輸出 (stdout)，系統將自動收集和匯聚，以應用的維度存儲。

對於訪問日誌，我們一般需要對其進行分析和監控，日誌分析常用的方案是 ELK 系統，Rainbond 建議的方式是將訪問日誌輸出到指定文件，並安裝 Elasticsearch 插件，以便將收集文件日誌發送到指定 Elasticsearch 服務端（平台一鍵部署 ELK 完整服務）。如果使用其他分析系統，同樣使用插件的形式將應用日誌輸送到指定服務端即可。

3

關於 Rainbond

Rainbond 是一款以應用為中心的開源 PaaS，由好雨基於 Docker、Kubernetes 等容器技術自主研發，可作為公有雲或私有雲環境下的應用交付平台、DevOps 平台、自動化運維平台和行業雲平台，或作為企業級的混合雲多雲管理工具、Kubernetes 容器管理工具或 Service Mesh 微服務架構治理工具。

Rainbond 項目網站

https://www.rainbond.com/

試用 Rainbond 公有雲

https://www.goodrain.com/

Github

https://github.com/goodrain/rainbond

碼雲

https://gitee.com/rainbond/Rainbond

文檔

https://www.goodrain.com/docs/stable/

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！