連結：https://jimmysong.io/blog/what-is-a-service-mesh/

Service Mesh 又譯作 “服務網格”，作為服務間通訊的基礎設施層。Buoyant 公司的 CEO Willian Morgan 在他的這篇文章 WHAT’S A Service Mesh? AND WHY DO I NEED ONE?（https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/） 中解釋了什麼是 Service Mesh，為什麼雲原生應用需要 Service Mesh。

下面是 Willian Morgan 對 Service Mesh 的解釋。

A Service Mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the Service Mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

翻譯成中文是：

服務網格（Service Mesh）是處理服務間通訊的基礎設施層。它負責構成現代雲原生應用程式的複雜服務拓撲來可靠地交付請求。在實踐中，Service Mesh 通常以輕量級網路代理陣列的形式實現，這些代理與應用程式程式碼部署在一起，對應用程式來說無需感知代理的存在。

Service Mesh的特點

Service Mesh 有如下幾個特點：

應用程式間通訊的中間層輕量級網路代理應用程式無感知解耦應用程式的重試/超時、監控、追蹤和服務發現

目前兩款流行的 Service Mesh 開源軟體 Istio（https://istio.io/） 和 Linkerd（https://linkerd.io/） 都可以直接在 Kubernetes 中整合，其中 Linkerd 已經成為 CNCF 成員。

理解 Service Mesh

如果用一句話來解釋什麼是 Service Mesh，可以將它比作是應用程式或者說微服務間的 TCP/IP，負責服務之間的網路呼叫、限流、熔斷和監控。對於編寫應用程式來說一般無須關心 TCP/IP 這一層（比如通過 HTTP 協議的 RESTful 應用），同樣使用 Service Mesh 也就無須關心服務之間的那些原本通過服務框架實現的事情，比如 Spring Cloud、Netflix OSS 和其他中介軟體，現在只要交給 Service Mesh 就可以了。

Phil Calçado 在他的這篇部落格 Pattern: Service Mesh （http://philcalcado.com/2017/08/03/pattern_service_mesh.html）中詳細解釋了 Service Mesh 的來龍去脈：

從最原始的主機之間直接使用網線相連網路層的出現整合到應用程式內部的控制流分解到應用程式外部的控制流應用程式的中整合服務發現和斷路器出現了專門用於服務發現和斷路器的軟體包/庫，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，這時候還是整合在應用程式內部出現了專門用於服務發現和斷路器的開源軟體，如 Netflix OSS、Airbnb 的 synapse 和 nerve最後作為微服務的中間層 Service Mesh 出現

Service Mesh 的架構如下圖所示：

Service Mesh 作為 sidecar 執行，對應用程式來說是透明，所有應用程式間的流量都會通過它，所以對應用程式流量的控制都可以在 serivce mesh 中實現。

Service Mesh如何工作？

下面以 Linkerd 為例講解 Service Mesh 如何工作，Istio 作為 Service Mesh 的另一種實現原理與 linkerd 基本類似，後續文章將會詳解 Istio 和 Linkerd 如何在 Kubernetes 中工作。

Linkerd 將服務請求路由到目的地址，根據中的引數判斷是到生產環境、測試環境還是 staging 環境中的服務（服務可能同時部署在這三個環境中），是路由到本地環境還是公有云環境？所有的這些路由資訊可以動態配置，可以是全域性配置也可以為某些服務單獨配置。當 Linkerd 確認了目的地址後，將流量傳送到相應服務發現端點，在 kubernetes 中是 service，然後 service 會將服務轉發給後端的例項。Linkerd 根據它觀測到最近請求的延遲時間，選擇出所有應用程式的例項中響應最快的例項。Linkerd 將請求傳送給該例項，同時記錄響應型別和延遲資料。如果該例項掛了、不響應了或者程序不工作了，Linkerd 將把請求傳送到其他例項上重試。如果該例項持續返回 error，Linkerd 會將該例項從負載均衡池中移除，稍後再週期性得重試。如果請求的截止時間已過，Linkerd 主動失敗該請求，而不是再次嘗試新增負載。Linkerd 以 metric 和分散式追蹤的形式捕獲上述行為的各個方面，這些追蹤資訊將傳送到集中 metric 系統。為何使用 Service Mesh？

Service Mesh 並沒有給我們帶來新功能，它是用於解決其他工具已經解決過的問題，只不過這次是在以 Kubernetes 為基礎的雲原生生態環境下的實現。

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

在 Cloud Native 架構下，容器的使用賦予了異構應用程式更多的可能性，Kubernetes 增強的應用的橫向擴容能力，使用者可以快速的編排出複雜環境、複雜依賴關係的應用程式，同時開發者又無須過分關心應用程式的監控、擴充套件性、服務發現和分散式追蹤這些繁瑣的事情，進而專注於程式開發，賦予開發者更多的創造性。

參考What's a Service Mesh? And why do I need one?（https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/）So what even is a Service Mesh? Hot take on Istio and Linkerd（http://redmonk.com/jgovernor/2017/05/31/so-what-even-is-a-service-mesh-hot-take-on-istio-and-linkerd）linkerd: A Service Mesh for AWS ECS（https://medium.com/attest-engineering/linkerd-a-service-mesh-for-aws-ecs-937f201f847a）Introducing Istio: A robust Service Mesh for microservices（https://istio.io/blog/istio-service-mesh-for-microservices.html）Application Network Functions With ESBs, API Management, and Now.. Service Mesh?（http://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/）Pattern: Service Mesh（http://philcalcado.com/2017/08/03/pattern_service_mesh.html）Envoy 官方文件中文版（http://www.servicemesher.com/envoy/）Istio 官方文件（https://istio.io/）Istio Handbook - Istio 服務網格進階實戰（https://www.servicemesher.com/istio-handbook/）

後記：本文為進一步學習Service Mesh提供了一定的索引指南。如果想進一步學習相關知識，可以進一步去“按圖索驥”。但建議還是先完全掌握好微服務後再進一步深入來學習服務網格相關內容。