# Service Mesh技術對比 **注意：本書中的 Service Mesh 章節已不再維護，請轉到 [istio-handbook](https://jimmysong.io/istio-handbook) 中瀏覽。** 這一章主要講解Service Mesh技術之間的區別，Service Mesh與其他相關技術之間的區別，讀者可以直接瀏覽該網站來查看對比：http://layer5.io/service-meshes/ 為什么有了如Kubernetes這樣的容器編排我們還需要Service Mesh呢，下表是對容器編排調度器的核心功能和缺少的服務級別能力對比。 | 核心能力 | 缺少的服務級別能力 | | ---------------------------- | ----------------------------- | | 集群管理 | 熔斷 | | 調度 | L7細粒度的流量控制 | | 編排器和主機維護 | 混沌測試 | | 服務發現 | 金絲雀部署 | | 網絡和負載均衡 | 超時、重試、 budget和deadline | | 有狀態服務 | 按請求路由 | | 多租戶、多region | 策略 | | 簡單的應用監控檢查和性能監控 | 傳輸層安全（加密） | | 應用部署 | 身份和訪問控制 | | 配置和秘鑰管理 | 配額管理 | | / | 協議轉換（REST、gRPC） | 以上是容器編排中缺少的服務級別的能力，當讓類似Kubernetes這樣的容器編排系統中也有服務管理的能力，如Ingress Controller，但是它僅僅負責集群內的服務對外暴露的反向代理，每個Ingress Controller的能力受限于Kubernetes的編程模型。對服務進行管理還可以通過例如Kong、基于云的負載均衡器、API Gateway和API管理來實現，在沒有Service Mesh的時候還需要如[Finagle](https://finagle.github.io/blog/)、[Hystrix](https://github.com/Netflix/Hystrix)、[Ribbon](https://github.com/Netflix/ribbon)客戶端庫的加持。 下圖是一個使用**客戶端庫**將應用與服務治理緊耦合的示意圖。  從圖中我們可以看到，應用程序代碼與客戶端度庫緊耦合在一起，不同的服務團隊需要一起協調超時和重試機制等。容器編排更適用于分布式應用，API Gateway通常只需要部署在系統邊緣即可，不需要在每個應用中都部署，而Service Mesh卻需要在每個服務或者說節點中部署。