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即已經構成了微服務架構，而無需先學習微服務架構知識，再考慮自己的服務如何改造，最后再落地。

如下圖可知，Rainbond的網絡治理插件通過Sidecar的方式在應用的同一個網絡命名空間，同一個存儲空間，同一個環境變量空間內動態啟動第三方插件服務，例如envoy服務，通過與Rainbond應用運行時通信完成從應用空間到平臺空間的數據交換，實現平臺對應用通信的控制。