咱們真的須要Service Mesh嗎？

George Miranda

業務對於Service Mesh微服務架構的討論熱度居高不下，不少人認爲Service Mesh將是雲原生應用基礎設施解決方案的MUST，它在構建健壯微服務架構應用時的能量使人印象深入。不過在人氣飆升的同時，人們對於落地Service Mesh的確切價值仍有困惑，所以有必要深刻了解什麼是Service Mesh以及它解決了哪些問題，以便咱們肯定是否真的須要Service Mesh。

Service Mesh

Service Mesh是一個用於處理服務之間通訊的基礎結構層，其體系結構的具體細節在不一樣實現中略有差別。通常來講，每一個Service Mesh都是做爲一個系列(或「mesh」)實現的，這些相互鏈接的網絡代理設計容許咱們更優雅地管理服務流量（service traffic）。

該解決方案隨着微服務架構的普遍接受而興起，它引入了一種全新的通訊流量（communication traffic）概念。但不幸的是，採用者每每沒有作太多的考慮。這有時被歸由於南北流量模式與東西流量模式的區別。簡單來講，南北流量是server-to-client流量，而東西流量則是server-to-server流量。以上命名來源於「映射」網絡流量的關係圖，圖中一般用垂直線表示server-client流量，水平線表示server-to-server流量。在Server-to-server流量世界裏，除了對網絡和傳輸層(L3/L4)考量，在會話層（session layer）中還有一個重要的差別要考慮。

在這個新的世界中，service-to-service通訊成爲了應用在應用時行爲的基本決定因素。應用函數在本地做爲相同運行時的一部分出現，而不是以在不可靠的網絡上傳輸的遠程過程調用出現。這意味着，反映業務需求的複雜決策樹（decision tree）的成功或失敗，如今須要您考慮分佈式系統編程的現實。對於大多數人來講，這是一個新的專業領域，須要建立並在代碼中編寫大量定製的工具。而Service Mesh，減輕了應用開發人員的負擔，將工具與應用分離開來，並將這種「責任」推到了基礎架構層。

使用Service Mesh，每一個應用的endpoint(不管是容器、pod仍是主機，不管如何在部署中設置這些endpoint)都被配置爲「將通訊路由到本地代理」(例如以sidecar容器形式安裝)。本地代理公開了能夠用於管理諸如重試邏輯、加密機制、自定義路由規則、服務發現等內容的原語。這些代理的集合構成了一個「網格」服務，共享公共網絡流量的管理屬性。這些代理能夠從一個集中的控制平面進行控制，操做人員能夠在該控制平面中對影響整個網格行爲的策略加以組合。

因爲service-to-service的通訊是基於微服務的應用運行時行爲的基本決定因素，可以從Sercice Mesh中獲取價值的最明顯的地方是管理用於遠程過程調用(或API調用)的消息。對比Service Mesh和其餘消息管理解決方案，如面向消息的中間件、企業服務總線(ESB)、企業應用程序集成模式(EAI)或API網關，Service Mesh可能與其中的一些功能有輕微重疊，可是做爲一個總體，它面對的是一個更大的問題集。

Service Mesh是做爲基礎設施實現的，位於應用以外，所以應用不須要修改任何代碼就可使用Service Mesh。Service Mesh的價值起初是在檢查rpc(或消息)管理時實現的，隨後擴展到了全部入站和出站流量的管理。與直接將遠程通訊管理編碼到應用中不一樣，Service Mesh容許您更容易地跨整個分佈式基礎設施管理該邏輯。

The problem space

Service Mesh的核心是解決管理分佈式系統帶來的固有挑戰。這並非一格新的問題，但在微服務數量激增的狀況下，愈來愈多用戶開始面對這些問題。而關於分佈式系統，存在着一下謬誤——

網絡是可靠的（The Network is Reliable） 延遲爲零（Latency is Zero） 帶寬是無限的（Bandwidth is Infinite） 網絡是安全的（The Network is Secure） 拓撲不會改變（Topology does not Change） 有一名管理員（There is one Administrator） 傳輸成本爲零（Transport Cost is Zero） 網絡是同質的（The Network is Homogenous）

瞭解更多：Service Mesh微服務架構的崛起

這些錯誤每每會在大規模運行時出現，每每在發現時已經太晚了，不過好在，通過這麼多年的實踐，已經有了很多通過驗證的解決方案。

過去，應用開發人員經過在應用中直接建立自定義工具來解決這些問題：打開一個socket、傳輸數據、在某個特定的時間段內從新嘗試，當事務不可避免地須要終止時關閉socket，等等。分佈式應用的編程負擔直接落在了每一個開發人員的肩上，所以這樣作的邏輯與每一個分佈式應用緊密耦合。

做爲實現可重用解決方案的漸進步驟，出現了網絡彈性庫(如Netflix的Hystrix或Twitter的Finagle)。在咱們的應用代碼中包含這些庫，如今您已經準備好了一組預先開發的工具。雖然這些解決方案取得了使人難以置信的飛躍，但它們對多語言應用的價值有限。不一樣的編程語言須要不一樣的庫，而後咱們會遇到管理二者之間集成的挑戰。在這一模型中，不一樣應用endpoint之間的一致管理是一個固有的挑戰。

對於Service Mesh，它旨在解決分佈式系統編程的挑戰，這意味着咱們須要首先搞明白一個問題：咱們應用基礎結構中，是否有許多服務彼此通訊？

固然，若是咱們主要管理的是一體化架構應用，咱們也能夠從Service Mesh中得到些許價值。

若是咱們管理的是較小的服務，那麼處理分佈式計算錯誤的工做不可避免。隨着微服務架構應用的發展，新特性一般做爲附加的外部服務引入，咱們對於Service Mesh的需求也將不斷增加。

Service Mesh的存在解決了可靠性(重試、超時、減輕級聯故障)、故障診斷(可觀察性、監視、跟蹤、診斷)、性能(吞吐量、延遲、負載平衡)、安全性(管理機密、確保加密)、動態拓撲(服務發現、自定義路由)以及在生產中管理微服務時常見的問題。

若是咱們目前正在面臨這些問題，或者已經次啊用了雲原生和微服務架構，那麼咱們應該研究一下Service Mesh工具，並肯定它是否適用於咱們的環境。想要避免被各類炒做迷亂了雙眼，咱們應該量化Service Mesh的價值，而辦法就像咱們剛纔討論的那樣，關注這類工具的存在並探索它是否能夠解決特定的問題。

• END -

關於Rainbond

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

• Rainbond項目網站
• 試用Rainbond公有云
  • 註冊或使用Demo帳號/密碼登陸：rainbond-demo/rainbond-demo
• Github
• 碼雲
• 文檔
• 微信羣: 添加微信「zqg5258423」並接受邀請入羣

閱讀更多

• 技術 Service Mesh真的是雲原生應用的絕配嗎？
• 技術 Service Mesh微服務架構的崛起 2018/0706
• 技術 Service Mesh：什麼是Sidecar模式 2018/06/21
• 技術 開源PaaS Rainbond v3.6.0正式發佈，Service Mesh開箱即用 2018/06/20
• 技術 解讀Rainbond ServiceMesh微服務架構_開源PaaS Rainbond 2018/05/15
• 技術 Pinpoint-java性能分析最佳實踐_開源PaaS Rainbond 2018/05/08
• 技術 經過Minio搭建私有化對象存儲服務_開源PaaS Rainbond 2018/04/26
• 技術 揭祕高可用負載均衡組件Rainbond-Entrance_開源PaaS Rainbond 2018/04/25
• 技術 Rainbond插件體系設計簡介_開源PaaS Rainbond 2018/02/24
• 技術 Rainbond如何對接外部Maven倉庫_開源PaaS Rainbond 2018/01/18
• 技術 Spring Boot框架配置MySQL_開源PaaS Rainbond 2018/01/10
• 技術 基於Midonet的多租戶網絡設計_開源PaaS Rainbond 2018/01/09