詳解Rainbond內建ServiceMesh微服務架構

2022-04-20 22:00:02

ServiceMesh

一般的字面解釋是“服務網格”，作為時下最流行的分散式系統架構微服務的動態連結器，處於服務到服務的通訊的專用基礎設施層，該層獨立於應用程式為服務之間的通訊提供輕量級的可靠傳遞。

如果簡單的描述的話，可以將它比作是應用程式或者說微服務間的 TCP/IP，負責服務之間的網路呼叫、限流、熔斷和監控，同樣使用 ServiceMesh 也就無須關係服務之間的那些原來是通過應用程式或者其他框架實現的事情，比如 Spring Cloud架構，現在只要交給 ServiceMesh 就可以了。

ServiceMesh的出現主要是由於應用虛擬化技術的發展，例如Kubernetes, Rainbond等專案，大大降低了應用的部署和運維複雜度。

微服務架構對比

為何使用ServiceMesh

ServiceMesh 並沒有給我們帶來新功能，它是用於解決其他工具已經解決過的問題，只不過這是在 Cloud Native 的雲原生環境下將過去複雜的人工運維工作有機的自動化管理。

在傳統的 MVC 三層 Web 應用程式架構下，服務之間的通訊並不複雜，在應用程式內部自己管理即可，但是在現今的複雜的大型網站情況下，單體應用被分解為眾多的微服務，服務之間的依賴和通訊十分複雜，出現了 twitter 開發的 Finagle、Netflix 開發的 Hystrix 和 Google 的 Stubby 這樣的 “胖使用者端” 庫，這些就是早期的 ServiceMesh，但是它們都近適用於特定的環境和特定的開發語言，並不能作為平臺級的 ServiceMesh 支援。

在 Cloud Native 架構下，容器的使用給予了異構應用程式的更多可行性，kubernetes 增強的應用的橫向擴容能力，使用者可以快速的編排出複雜環境、複雜依賴關係的應用程式，同時開發者又無須過分關心應用程式的監控、擴充套件性、服務發現、負載均衡和分散式追蹤這些繁瑣的事情而專注於程式開發，賦予開發者更多的創造性。如果你是符合以下場景，推薦選擇ServiceMesh架構：

1.遺留龐大系統逐步過渡到微服務架構

2.業務系統由多種開發語言開發

ServiceMesh相對其他微服務架構優勢

最大層度透明

ServiceMesh通過全域性控制層控制服務與服務之間的呼叫關係，服務的治理策略。對於服務本身來說，只需要站在單機的維度考慮上游服務的依賴通訊，採用簡單的通訊協定例如HTTP，gRPC等。Mesh層透明的發現上游目標，進行重試/超時、監控、追蹤。為單機服務賦予分散式系統能力。

學習成本低

過去我們要設計搭建一個完整的微服務架構，比如SpringCloud,Dubbo等，免不了需要改變我們傳統的程式設計思想，學習複雜的架構框架，例如SpringCloud,其包含各類元件10餘個，基本與服務業務本身沒有直接關係。對於大多數業務開發者來說是一個高高的門檻。但是使用ServiceMesh架構，由於其最大化的透明，開發者幾乎不需要額外學習與業務無關的框架技術。大大降低了學習成本。

架構靈活

對於不同的團隊組成，可能擁有具有掌握不同開發語言的成員，或者具有成熟的已實現業務系統。如果轉變到微服務架構支援更大量級使用者，如果使用SpringCloud架構，免不了對系統進行重構甚至重寫。面對現實與未來，我們需要逐步落地微服務架構，使用合適的開發語言開發合適的服務，甚至融合多種輕量級架構模式，比如Dubbo,SpringBoot和LNMP架構。

ServiceMesh架構效能

有人提出，在服務與服務之間增加兩層代理對效能會產生較大影響，對於效能問題，我們應該放眼全域性，從以下幾個方面分析：

對於增加代理響應效能問題在所有的微服務架構中都存在。

ServiceMesh的網路代理層一般採用輕量級的高效率的代理實現，其本身效能通常較為優越。

ServiceMesh為了提供更好的治理功能支援，通訊模型一般處在應用層，比如處理（http,grpc,mongo,mysql）等協定。如果對效能要求比較高，也可以直接使用4層網路模型。

ServiceMesh一般面向中大型分散式系統，分散式系統直接本身就會有通訊消耗，Mesh層相反可以使用更高效的通訊協定比如http/2 來優化通過http/1.1協定通訊的服務通訊過程。

ServiceMesh只對網路進行治理麼？

ServiceMesh架構框架是工作在網路通訊層面提供一系列服務治理功能，包括：

服務發現和負載均衡
高階路由
通訊監控和分析
通訊安全

對於Rainbond的架構設計來說還通過外掛擴充套件的方式增加以下方面功能：

紀錄檔處理
資料備份和恢復
服務運維和監控
服務執行環境保障

Rainbond與ServiceMesh

Rainbond原生提供全量的ServiceMesh治理功能方案，同時提供了外掛化得擴充套件策略，使用者除了使用預設方案以外也可以自定義外掛實現。Rainbond與Istio的實現有共同點，也有天然的不同。

相同點是都實現了基於XDS規範實現全域性控制層，支援envoy和istio-proxy。

不同點是Istio需要依賴Kubernetes等平臺工作，微服務架構的支援需要從底層儲存與通訊到上層的應用層設定全盤考慮，大型的微服務架構是離開不了自動化管理應用的PaaS平臺的。Rainbond從硬體層，通訊層，平臺層實現不同的控制邏輯，既相容已有的微服務架構，同時提供了完整的ServiceMesh微服務架構實踐。包容的架構形式讓已有的應用服務化變得可落地。

Rainbond提供給使用者的體驗是最大化的透明，即使用者將服務執行於Rainbond即已經構成了微服務架構，而無需先學習微服務架構知識，再考慮自己的服務如何改造，最後再落地。