原文：https://dzone.com/articles/whats-a-service-mesh-and-why-do-i-need-one
## service mesh 有的翻譯成服務網格化，在這裏不作翻譯直接使用英文感覺可以正確的理解。
在過去的幾年中，service mesh 已經雲化（微服務）本地應用堆棧中重要組件。許多公司也開源的相應本地雲化Service mesh組件，並且成爲微服務化項目組織的和重要項目。但是什麼是Service Mesh？我們要做如何正確的理解？
下面，我們會探索service mesh 應用架構。認識service mesh 在應用中的關係。在認識之前我們要有API gateways, edge proxies, 和 the enterprise service bus 的概念。
什麼是Service Mesh?
Service Mesh處理服務到服務通信的專用基礎層。它負責雲本地應用複雜網絡可以的傳遞請求。在實踐中，service mesh 通常會實現一序列的輕量網絡代理，單獨應用代碼部署，並且不用關心應用代碼。
Service Mesh作爲獨立層的概念，和雲本地應用的興起有很大的關係。在本地雲模型中，一個應用會和其它的上百個服務有聯繫;每個服務有上百個實例,每個實例的狀態是動態變化的，它們類似使用Kubernetes進行編排器動態調度的。在實際中，服務之間的通信是異常複雜的，服務的運行時狀態和基礎層的管理，是確保端到端性能和可靠性的保證。
Service Mesh是一個網絡模型？
Service Mesh是一個工作矸TCP/IP之上的一個抽象網絡模型。它假設存在L3/L4網絡，並且能夠進行點到點的字節傳輸。
在某些方面，service mesh和TCP/IP是有些相似的。如：TCP是一個抽象模型用來確保網絡節點之間字節傳輸，service mesh是一個抽象模型用來確保各個服務之間的相互請求。如TCP 一樣，service mesh 不關心實際的負載或者它是如何編碼的。應用有一個高層的目標，和service mesh的工作，和TCP有些相似，處理任何失敗時實現該目標的一種方式。
和TCP不同的是：sevice mesh 除了“讓它工作”之外，還有一個重要的目標，爲應用的可見性和運行時應用的控制提供一種機制。service mesh的一個明確目標是：把服務通信從不可見，隱形的基礎層，轉移到生態系統的一級成員在這裏可以被監控，管理和控制。
service mesh 實際是做什麼的？
在雲本地應用可靠的交付請求蛺非常複雜的。servcie mesh 像 Linkerd 這樣的網絡廣泛的強大的技術來管理 管理這種複雜性。這些廣泛的強大技術如：circuit-breaking, latency-aware load balancing, eventually consistent (“advisory”) service discovery, retries, deadlines。這些功能必須協同工作，並且這些功能運行在複雜環境它們之間的交互是非常微妙的。
例如，通過Linkerd發送一個請求，它的簡單時間順序事件如下：
1，Linkerd 根據動態路由規則來確定請求需要的服務。確定請求是路由到一個服務還是中轉到轉換中的服務？請求的服務是本地的數據中心還是雲端服務？是最近發佈的服務還是已經過審覈的生產服務？這些所有的路由規則都是可以配置的，可以全局應用、也可以應用於流片段。
2，找到正確的目標，Linkerd 會從服務發現節點的實例池檢索，可能會有多個服務。如果這些信息和Linkerd檢索到的信息有不同，將由它決定那些信息是可靠的。
3，Linkerd 會根據各種因素選擇響應最快的一個實例，包括觀察到最近請求的延時。
4，Linkerd 會嘗試發送一個請求給這個實例，記錄延時和響應的結果類型。
5，如果該實例已經掛了，沒有響應，或者請求失敗，Linkerd 會嘗試請求其他實例。
6，如果一個實例總是返回錯誤，Linkerd 會把它從負載均衡池中移出，稍後在進行重試（如：一個實例出現短暫性的失敗。）
7，請求截止日期已過，Linkerd 會主動讓請求失敗，而不是添加到負載進一步重試。
8，Linkerd 可以捕獲上述行爲的各個方面，並將這些信息提交到一個集中的度量系統。
上面這些只是一個科化版的Linkerd 初始化到終止的TLS，執行協議的升級，動態轉流，以及數據中心間的故障轉移。
需要注意的是：這些特性旨在提供點的彈性和應用應用範圍的彈性。大型的分佈式系統，無論如何構建，都有一個共同的特徵：爲小的，局部的故障升級爲系統範圍的災難事故提供機。當底層系統接近極限時，service mesh必須設計通過減少負載和快速故障防止這些故障升級。
爲什麼需要Service Mesh
service mesh 最終不是新功能的引入，而是功能位置的轉變。web應用總是需要管理服務通信的複雜性。service mesh 的起源可以追溯到過去這些年的應用演變。
考慮下之前web應用程序的典型體系結構：三層應用程序。在這個模型中，應用程序邏輯、web服務邏輯和存儲邏輯都是一個單獨的層。層之間的通信雖然複雜，但範圍有限畢竟只有兩個跳。沒有“網格”，但是跳之間有通信邏輯，在每個層的代碼中處理。
當這種架構被推廣到非常大的規模，就會開始崩潰。Google, Netflix, and Twitter，面對巨大的流量需求，實現雲本地方法的前身：把應用層切分成多個服務（有時稱作“微服務”），這樣應用層就變成了一個拓撲結構。在這些系統中，一個通用的通信層突然變得相關起來，通常採用胖客戶端的形式設計比較洽當的例子如：Twitter 的 Finagle, Netflix 的 Hysterix, 和oogle的 Stubby 。
在許多方面，Finagle, Stubby, and Hysterix是第一個網格服務。雖然它們特定周圍環境的細節，並且需要使用特定的語言和框架，它們用於管理服務之間通信的基本形式，（如開源Finagle 和 Hysterix 庫）在源公司之外找到應用。
快速進行現在代雲主機應用，雲本地結構結合了許多小微服務方法和兩個額外的附加因素：容器（如：Docker,提供了資源隔離和依賴管理，以及編排層。 Kubernetes)把底層的硬件抽象成一個同質池。
這三個組件允許具有自然機制應用程序在負載下擴展，並且處理雲環境下的部分故障。但是，由於成千上萬的服務，以及在同一個時刻重新安排實例編排層，單個請求經過服務拓撲可能非常複雜，而且由於容器的服務很容易使用不同語言來實現，所以庫方法是不可行的。
這種複雜性和臨界性的結合促成需要一個專用來來處理服務間的通信和應用代碼分離的服務通信。這個一層就是service mesh。
Service Mesh的未來。
當雲原生系統中採用service mesh正在訊帶的增長，未來仍是一個廣泛而令人興奮的路線值得探索 。無服務器計算的需求（Amazon 的 Lambda），直接符合service mesh 命名和鏈接模型，並且自然的擴展到雲原生生態系統的作用。在雲原生環境中，服務要標識和訪問策略處於初始階段，並且service mesh 已經做好充分的準備可以在這裏扮演基礎角色。最後，sevice mesh 如之前的TCP/IP，它會繼續深入基礎應用層。就像Linkerd 從Finagle進化而來一樣，當前服務作爲一個單獨，必須顯式添加到雲主機空間堆棧中的用戶空間代理的化身也將繼續進化。
總結
service mesh 是雲主機堆棧的關鍵組件。Linkerd 經過一年多的成長，已經成爲Cloud Native Computing Foundation 組織的一部分。擁有繁榮的貢獻者和廣泛的用戶社區採用者包括正在擾亂英國銀行業的Monzo等初創公司、Paypal、Ticketmaster和Credit Karma等高規模互聯網公司，以及Houghton Mifflin Harcourt等已經營數百年的公司。