提到微服務，spring cloud等經典框架被使用的最為廣泛，但是在2016年才被提起的Service Mesh，已經被Paypal、Lyft、Ticketmaster和Credit Karma等等一些大流量平臺所使用，在生產應用中添加了Service mesh。今年隨著Linkerd傳入國內，Service mesh才在國內的技術社區里出現，而與此同時，2017年1月份Service mesh成為CNFC的官方項目。

那么，什么是Service mesh

Service mesh被用來處理服務間通訊的專用基礎設施層，通過復雜的拓撲結構讓請求傳遞的過程變得更可靠，這些服務成為新一代云原生應用程序。

在實際應用中，Service mesh通常作為一組輕量級高性能網絡代理，這些代理和程序代碼部署在一起，但是應用程序不需要對代理有任何動作。

Service mesh作為單獨層的概念與云原生應用程序的大規模普及有關。 在云原生模型中，單個應用程序可能包含數百個服務; 每個服務可能又包含數千個實例;并且這些實例中的每一個都可能處于不斷變化的狀態，因為它們是由像Kubernetes這樣的服務協調程序動態調度的。世界上的服務通訊不僅極其復雜，而且是運行時行為（runtime behavior）的一個普遍和基本的組成部分。管理好它對于確保端到端性能和可靠性是至關重要的。

Service mesh是網絡模型

Service mesh是一個網絡模型，它是位于TCP/IP之上的抽象層。它假定底層的L3/L4網絡是真實存在的，并且能夠點對點地傳遞字節。(它還假定了這個網絡像運行環境的其他方面一樣，是不可靠的； 因此，Service mesh必須能夠處理網絡故障。)

Service mesh在某些方面其實是類似于TCP/IP。就像TCP棧抽象出了網絡端點之間可靠傳遞字節的機制一樣，Service mesh在服務之間可靠地傳遞請求的機制也是抽象的。與TCP相同的是，Service mesh并不關心實際的有效負載，也不關心它的編碼問題。應用程序有一個高級目標(“從A到B發送一些數據”)， Service mesh的職責，和TCP一樣，是在這個數據的發送過程中解決故障并圓滿完成數據發送。

但與TCP不同的是，Service mesh具有更高的性能，它的使命超越了“僅僅讓它可以工作”， 并且有一個更重要的目標: 它提供了統一的、應用廣泛的觀點，應用程序在運行操作時具有可視性和可控性。Service mesh的明確目標是將服務通訊從不可見的、隱含的基礎設施中抽離出來，在云原生系統中扮演重要的一級成員的角色,從而可對系統進行監控，管理和控制。

Service mesh能做什么

在云原生應用中可靠地傳遞請求可能非常復雜。 像Linkerd這樣的Service mesh，通過一系列強大技術來管理這種復雜性: 鏈路熔斷、延遲感知、負載均衡，eventually consistent (“advisory”) 服務發現，服務續約及下線與剔除。這些功能必須協同工作，而這些功能與它們所操作的復雜環境之間的交互作用是非常微妙的。

為什么要使Service mesh

Service mesh最終并不是引入一項新功能，而是功能定位的轉變。Web應用程序總是必須管理服務間通信的復雜性。要想了解Service mesh模型的起源， 我們可以追溯過去15年以來的這些應用程序的發展歷程。

你可以思考下2000年的中型web應用程序的典型架構: 三層應用程序。 在這個模型中，應用程序邏輯、web服務邏輯和存儲邏輯都是單獨的一層。 層之間的通信雖然復雜，但這種復雜性是限定在一定范圍內，因為畢竟只有兩個跳轉。這里沒有“網格”，但是在每個層的代碼中處理的跳轉之間有通信邏輯。

當這種架構方式在面對應用程序內部邏輯越來越復雜化的情形時，它就開始崩潰了。 像Google、Netflix和Twitter這樣的公司無時無刻都面臨著巨大的流量需求，它們實現了云原生方案的前身: 應用層被分解成許多服務(有時稱為“微服務”)，層級間則形成了一個拓撲結構。 在這些系統中，廣義的通訊層突然變得相關起來， 但通常以“胖客戶端”的庫集（library）形式出現， 比如twitter的Finagle，Netflix的Hystrix，以及Google的Stubby就是這樣的例子。

從很多方面上來講，像Finagle, Stubby和Hystrix這些庫集其實是Service mesh的雛形。雖然它們受其周圍環境的細節影響，并且需要使用特定的語言和框架，但是它們是用于管理服務到服務間通信的專用基礎設施，并且(在開源Finagle和 Hystrix庫集的情形下)可以在其公司之外使用。

到了云原生應用時期， 云原生模型本身結合了許多小型服務的微服務方法和兩個額外的因素:容器(例如Docker)，它提供了資源隔離和依賴關系管理，以及一個編排層(例如Kubernetes)，它將底層硬件抽象出了一個同質池。

這三個組件支持應用程序在負載下可彈性伸縮的自然機制， 并能夠處理云平臺環境中存在的部分故障。

但面對數百個服務或數千個實例，和隨時在重新安排實例的編排層，單個請求經由服務拓撲的路徑可能非常復雜， 而由于容器使每個服務用不同的語言寫入處理變得更容易了，庫集方法也就不再可行了。

這種復雜性和關鍵性的結合，激發了對服務到服務間通信的專用基礎層的需求，這個專用層與應用程序代碼分離出來，并能夠捕捉底層環境的高度動態特性。就是這一專用層我們稱之為Service mesh。

學習Service mesh有哪些資料？

1.入門級資料

什么是Service Mesh（服務網格）

https://jimmysong.io/posts/what-is-a-service-mesh/

Pattern: Service Mesh

//philcalcado.com/2017/08/03/pattern_service_mesh.html

中文翻譯：

//www.infoq.com/cn/articles/pattern-service-mesh

What is Istio? It’s a service mesh. Great. What’s a service mesh?

https://www.mirantis.com/blog/what-is-istio-its-a-service-mesh-whats-a-service-mesh

https://www.slideshare.net/dbryant_uk/oreilly-2017-introduction-to-service-meshes

Google、IBM和Lyft開源的微服務管理框架Istio簡介

//dockone.io/article/2397

2.Service mesh熱點文章

萬字解讀:Service Mesh服務網格新生代--Istio https://zhuanlan.zhihu.com/p/29586032

再談 Kubernetes，微服務以及 Service Mesh

//baijiahao.baidu.com/s?id=1579758778464216551

系列文章：A SERVICE MESH FOR KUBERNETES

1.Top-line service metrics https://buoyant.io/a-service-mesh-for-kubernetes-part-i-top-line-service-metrics/

2.Pods are great, until they’re not https://buoyant.io/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/

3.Encrypting all the things https://buoyant.io/a-service-mesh-for-kubernetes-part-iii-encrypting-all-the-things/

4.Continuous deployment via traffic shifting

5.Dogfood environments, ingress, and edge routing

6.Staging microservices without the tears

7.Distributed tracing made easy

8.Linkerd as an ingress controller

9.gRPC for fun and profit

10.The Service Mesh API

11.Egress (this article) https://buoyant.io/2017/06/20/a-service-mesh-for-kubernetes-part-xi-egress/

12.Retry budgets, deadline propagation, and failing gracefully

13.Autoscaling by top-line metrics

部分中文翻譯：

Kubernetes的service mesh——第一部分：Service的重要指標

//blog.csdn.net/hty46565/article/details/78179005

Kubernetes的service mesh——第二部分：以DaemonSet方式運行linkerd

//blog.csdn.net/hty46565/article/details/78188434

Kubernetes的service mesh——第三部分：將一切加密

//blog.csdn.net/hty46565/article/details/78210626

Kubernetes與云原生應用概覽

//www.infoq.com/cn/articles/kubernetes-and-cloud-native-app-overview

NGINX 發布微服務平臺、OpenShift Ingress Controller 和Service Mesh預覽版

//www.infoq.com/cn/news/2017/09/nginx-platform-service-mesh

3.Service mesh可以參考的項目

Istio

https://istio.io/

IBM、Google、Lyft支持的一個開源的微服務連接、管理平臺，并給微服務提供安全管理，支持Kubernetes、Mesos等容器管理工具，其底層依賴于Envoy。

Linkerd

https://linkerd.io/

Buoyant開發，基于Twitter的Fingle，經過長期的實際產線運行經驗及驗證，支持Kubernetes、DC/OS容器管理平臺，也是CNCF官方支持的項目之一。據說其CEO就是service mesh概念的提出者，官方博客有很多高質量的文章，幾篇網絡熱文均出自他們。

Envoy

https://www.envoyproxy.io/

Lyft開發，7層代理及通信總線，支持7層HTTP路由、TLS、gRPC、服務發現以及健康監測等。

原文：http://dy.163.com/v2/article/detail/D2AKGNHU0518NIIT.html

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的如果不懂Service mesh，就不要谈微服务了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。