# Service Mesh 服務網格 **注意：本書中的 Service Mesh 章節已不再維護，請轉到 [istio-handbook](https://jimmysong.io/istio-handbook) 中瀏覽。** 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。 > 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. 今年來以 [Istio](https://istio.io) 和 [Linkderd](https://linkerd.io) 為代表的 Service Mesh 蓬勃發展，大有成為下一代語言異構微服務架構的王者之范，今天又碰巧看到了 Red Hat 的 [Burr Sutter](https://twitter.com/burrsutter) 提出了**8 Steps to Becoming Awesome with Kubernetes**，整個PPT一共60多頁，很有建設性，[點此](https://github.com/rootsongjc/cloud-native-slides-share/blob/master/kubernetes/8-Steps-to-Becoming-Awesome-with-Kubernetes-readhat-burrsutter.pdf)跳轉到我的GitHub上下載，我將其歸檔到[cloud-native-slides-share](https://github.com/rootsongjc/cloud-native-slides-share)中了。  自我6月份初接觸Istio依賴就發覺service mesh很好的解決了異構語言中的很多問題，而且是kuberentes service 上層不可或缺的服務間代理。關于istio的更多內容請參考 [istio中文文檔](https://istio.io/zh/)。 ## 什么是 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、OSS，現在只要交給 Service Mesh 就可以了。 [Phil Cal?ado](http://philcalcado.com/) 在他的這篇博客 [Pattern: Service Mesh](http://philcalcado.com/2017/08/03/pattern_service_mesh.html) 中詳細解釋了 Service Mesh 的來龍去脈： 1. 從最原始的主機之間直接使用網線相連 2. 網絡層的出現 3. 集成到應用程序內部的控制流 4. 分解到應用程序外部的控制流 5. 應用程序的中集成服務發現和斷路器 6. 出現了專門用于服務發現和斷路器的軟件包/庫，如 [Twitter 的 Finagle](https://finagle.github.io/) 和 [Facebook 的 Proxygen](https://code.facebook.com/posts/1503205539947302)，這時候還是集成在應用程序內部 7. 出現了專門用于服務發現和斷路器的開源軟件，如 [Netflix OSS](http://netflix.github.io/)、Airbnb 的 [synapse](https://github.com/airbnb/synapse) 和 [nerve](https://github.com/airbnb/nerve) 8. 最后作為微服務的中間層 service mesh 出現 Service mesh 的架構如下圖所示：  圖片來自：[Pattern: Service Mesh](http://philcalcado.com/2017/08/03/pattern_service_mesh.html) Service mesh 作為 sidecar 運行，對應用程序來說是透明，所有應用程序間的流量都會通過它，所以對應用程序流量的控制都可以在 serivce mesh 中實現。 ## Service mesh如何工作？ 下面以 Linkerd 為例講解 service mesh 如何工作，Istio 作為 service mesh 的另一種實現原理與 linkerd 基本類似，后續文章將會詳解 Istio 和 Linkerd 如何在 kubernetes 中工作。 1. Linkerd 將服務請求路由到目的地址，根據中的參數判斷是到生產環境、測試環境還是 staging 環境中的服務（服務可能同時部署在這三個環境中），是路由到本地環境還是公有云環境？所有的這些路由信息可以動態配置，可以是全局配置也可以為某些服務單獨配置。 2. 當 Linkerd 確認了目的地址后，將流量發送到相應服務發現端點，在 kubernetes 中是 service，然后 service 會將服務轉發給后端的實例。 3. Linkerd 根據它觀測到最近請求的延遲時間，選擇出所有應用程序的實例中響應最快的實例。 4. Linkerd 將請求發送給該實例，同時記錄響應類型和延遲數據。 5. 如果該實例掛了、不響應了或者進程不工作了，Linkerd 將把請求發送到其他實例上重試。 6. 如果該實例持續返回 error，Linkerd 會將該實例從負載均衡池中移除，稍后再周期性得重試。 7. 如果請求的截止時間已過，Linkerd 主動失敗該請求，而不是再次嘗試添加負載。 8. Linkerd 以 metric 和分布式追蹤的形式捕獲上述行為的各個方面，這些追蹤信息將發送到集中 metric 系統。 ## 為何使用 service mesh？ Service mesh 并沒有給我們帶來新功能，它是用于解決其他工具已經解決過的問題，只不過這次是在 Cloud Native 的 kubernetes 環境下的實現。 在傳統的 MVC 三層 Web 應用程序架構下，服務之間的通訊并不復雜，在應用程序內部自己管理即可，但是在現今的復雜的大型網站情況下，單體應用被分解為眾多的微服務，服務之間的依賴和通訊十分復雜，出現了 twitter 開發的 [Finagle](https://twitter.github.io/finagle/)、Netflix 開發的 [Hystrix](https://github.com/Netflix/Hystrix) 和 Google 的 Stubby 這樣的 ”胖客戶端“ 庫，這些就是早期的 service mesh，但是它們都近適用于特定的環境和特定的開發語言，并不能作為平臺級的 service mesh 支持。 在 Cloud Native 架構下，容器的使用給予了異構應用程序的更多可行性，kubernetes 增強的應用的橫向擴容能力，用戶可以快速的編排出復雜環境、復雜依賴關系的應用程序，同時開發者又無須過分關心應用程序的監控、擴展性、服務發現和分布式追蹤這些繁瑣的事情而專注于程序開發，賦予開發者更多的創造性。 ## Istio VS Linkerd 當前的Service Mesh實現主要有兩大陣營，要給是Linkerd（也是最初提出該概念的），另一個是Istio，當然還有很多其他號稱也是Service Mesh，比如Nginx出品的[Nginmesh](https://github.com/nginmesh/nginmesh)。 | **Feature** | **Istio** | **Linkerd** | | ----------- | ------------- | ---------------------------- | | 部署架構 | Envoy/Sidecar | DaemonSets | | 易用性 | 復雜 | 簡單 | | 支持平臺 | kuberentes | kubernetes/mesos/Istio/local | | 當前版本 | 0.3.0 | 1.3.3 | | 是否已有生產部署 | 否 | 是 | 下圖是Istio和Linkerd架構的不同，Istio是使用Sidecar模式，將Envoy植入到Pod中，而Linkerd則是在每臺node上都以DaemonSet的方式運行。  關于Istio和Linkerd的詳細信息請參考 [安裝并試用Istio service mesh](istio-installation.md) 與 [Linkerd 使用指南](linkerd-user-guide.md)。 另外出品Linkerd的公司buoyant又推出了[conduit](https://conduit.io)，這是一種更輕量級的Service Mesh。 ## 參考 - [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) - [Istio官方中文文檔](https://istio.io/zh/)