Service Mesh 是什么，我们为什么需要它？
Service Mesh 是一個專門使服務與服務之間的通信變得安全、快速和可靠的的基礎設施。如果你正在在構建一個云原生（ Cloud Native ）應用，那么你一定需要 Service Mesh 。
在過去的一年中， Service Mesh 成為了云原生技術棧的關鍵組件。像 PayPal , Ticketmaster 和 Credit Karma 這樣的大廠，已經將 Service Mesh 加入到他們的應用中。并且在 2017 年 1 月，開源的 Service Mesh 軟件 Linkerd 加入云原生基金會（ CNCF ），成為云原生基金會（CNCF）的官方項目。但是什么是真正的 Service Mesh？它又為何突然變的如此重要？
在這篇文章，我會講解 Service Mesh 的定義，并通過應用服務架構過去十年的發展追溯其起源。并將 Service Mesh 與其他相似的概念，包括 API 網關，邊緣代理以及 ESB （enterprise service bus）進行區分。最終，將會描述 Service Mesh 的發展方向，以及隨著云原生概念的普及，Service Mesh 發生的變化。
什么是 Service Mesh
Service Mesh 這個服務網絡專注于處理服務和服務間的通訊。其主要負責構造一個穩定可靠的服務通訊的基礎設施，并讓整個架構更為先進和 Cloud Native。在實踐中，Service Mesh 基本來說是一組輕量級的服務代理和應用邏輯的服務在一起，并且對于應用服務是透明的。
Service Mesh 作為獨立層的概念與云原生應用的興起有關。在云原生模式，單個應用可能有數百個服務組成，每個服務又可能有上千個實例，而每個實例都有可能被像 Kubernetes 這樣的服務調度器不斷調度從而不斷變化狀態。而這些復雜的通信又普遍是服務運行時行為的一部分，這時確保端到端的通信的性能和可靠性就變的至關重要。
Service Mesh 就是一個網絡模型嗎？
Service Mesh 是一個位于 TCP/IP 上的抽象層的網絡模型。它假定底層 L3/L4 網絡存在并且能夠從一點向另一點傳輸數據。（它還假定這個網絡和環境的其他方面一樣不可靠，所以 Service Mesh 也必須能夠處理網絡故障。）
在某些方面，Service Mesh 就像是網絡七層模型中的第四層 TCP 協議。其把底層的那些非常難控制的網絡通訊方面的控制面的東西都管了（比如：丟包重傳、擁塞控制、流量控制），而更為上面的應用層的協議，只需要關心自己業務應用層上的事了。
與 TCP 不同的是， Service Mesh 想要達成的目的不僅僅是正常的網絡通訊。它為應用提供了統一的，可視化的以及可控制的控制平面。Service Mesh 是要將服務間的通信從無法發現和控制的基礎設施中分離出來，并對其進行監控、管理和控制。
Service Mesh 實際上做了什么？
在云原生應用中傳遞可靠的請求是十分復雜的。而?Linkerd?提供了服務熔斷、重試、負載均衡、熔斷降級等功能，通過其強大的功能來管理那些必須運行在復雜環境中的服務。
這里列舉一個通過 Linkerd 向服務發出請求的簡單流程：
通過 Linkerd 的動態路由規則來確定打算連接哪個服務。這個請求是要路由到生產環境還是演示環境？是請求本地數據中心的服務還是云上的服務？是請求正在測試的最新版的服務還是已經在生產中經過驗證的老版本？所有的這些路由規則都是動態配置的，可以全局應用也可以部分應用。
找到正確的目的服務后，Linkerd 從一個或幾個相關的服務發現端點檢索實例池。如果這些信息與 Linkerd 的服務發現信息不同， Linkerd 會決定信任哪些信息來源。
Linkerd 會根據觀察到的最近的響應延遲來選擇速度最快的實例。
Linkerd 發送請求給這個實例，記錄延遲和響應類型。
如果這個實例掛了、無響應或者無法處理請求， Linkerd 會再另一個實例上重試這個請求（但只有在請求是冪等的時候）。
如果一個實例一直請求失敗， Linkerd 會將其移出定時重試的負載均衡池。
如果請求超時， Linkerd 會主動將請求失效，而不是進一步重試從而增加負載。
Linkerd 會記錄指標和分布式的追蹤上述行為的各個方面，將他們保存在集中的指標系統中。
以上只是簡化版的介紹， Linkerd 還可以啟動和重試 TLS ，執行協議升級，動態切換流量，甚至在故障之后數據中心的切換。
值得注意的是，這些功能旨在為每個實例和應用程序提供彈性伸縮。而大規模的分布式系統（無論是如何構建的）都有一個共同特點：都會因為許多小的故障，而升級為全系統災難性的故障。Service Mesh 則被設計為通過快速的失效和減少負載來保護整個系統免受這樣災難性的故障。
為什么 Service Mesh 是必要的？
Service Mesh 本質上并不是什么新技術，而是功能所在位置的轉變。Web 應用需要管理復雜的服務通信，Service Mesh 模式的起源和演變過程可以追溯到15年前。
參考2000年左右中型 Web 應用的典型三層架構，在這個架構中，應用被分為三層：應用邏輯、Web 服務邏輯、存儲邏輯。層之間的通信雖然復雜，但是畢竟范圍有限，最多只有 2 跳。這里并不是 “Mesh” 的，但在每層中處理跳轉的代碼是存在通信邏輯的。
當這種架構向更大規模發展的時候，這種通信方式就無以為繼了。像 Google、Netflix 和 Twitte ，在面臨巨大的請求流量的時候，他們實現了云原生應用的前身：應用被分割成了許多服務（現在稱作“微服務”），這些服務組成了一種網格結構。在這些系統中，通用通信層突然興起，表現為“胖客戶端”的形式——Twitter 的 Finagle，Netflix 的 Hystrix 和 Google 的 Stubby 都是很典型的例子。
現在看來，像 Finagle 、Stubby 和 Hystrix 這樣的庫就是最早的 Service Mesh。雖然它們是為特定環境、語言和框架定制了，但都是作為基礎設施專門用于管理服務間的通信，并（在 Finagle 和 Hystrix 開源的情況下）在其他公司的應用中被使用。
這三個組件都有應用自適應機制，以便在負載中進行拓展，并處理在云環境中的部分故障。但是對于數百個服務或數千個實例，以及不時需要重新調度的業務層實例，單個請求通過的調用鏈可能變的非常復雜，而且服務可能由不同的語言編寫，這時基于庫的解決方案可能就不再適用了。
服務通信的復雜性和重要性導致我們急需一個專門的基礎設施層來處理服務間的通信，該層需要與業務代碼解耦，并且具有捕獲底層環境的動態機制。這就是 Service Mesh。
Service Mesh 的未來
Service Mesh 在云生態下迅速的成長，并且有著令人激動的未來等待探索。對無服務器計算（Serverless， 例如 Amazon 的?Lambda）適用的 Service Mesh 網絡模型，在云生態系統中角色的自然拓展。Service Mesh 可能成為服務身份和訪問策略這些在云原生領域還是比較新的技術的基礎。最后，Service Mesh，如之前的TCP / IP，將推進加入到底層的基礎架構中。就像 Linkerd 是由像 Finagle 這樣的系統發展而來，Service Mesh 將作為單獨的用戶空間代理添加到云原生技術棧中繼續發展。
結語
Service Mesh 是云原生技術棧的關鍵技術。Linkerd 成立僅 1 年就成為了云原生基金會（CNCF）的一部分，擁有蓬勃發展的社區和貢獻者。使用者從像 Monzo 這樣顛覆英國銀行業的創業公司，到像 PayPal、 Ticketmaster 和 Credit Karma 這樣的互聯網大廠，再到像 Houghton Mifflin Harcourt 這樣經營了數百年的公司。
使用者和貢獻者每天都在 Linkerd 社區展示 Service Mesh 創造的價值。我們將致力于打造這一令人驚嘆的產品，并繼續發展壯大我們的社區。
原文鏈接：https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/
總結
以上是生活随笔為你收集整理的Service Mesh 是什么，我们为什么需要它？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 行业观察丨激荡二十年——货代软件1999
- 下一篇： 未来我们对微服务和 Serverless