https://blog.csdn.net/persistencegoing/article/details/84376427

Service Mesh 是什麼？為什麼我們需要它？

Service Mesh（服務網格）是一個基礎設施層，讓服務之間的通訊更安全、快速和可靠。如果你在構建雲原生應用，那麼就需要 Service Mesh。

在過去的一年中，Service Mesh 已經成為雲原生技術棧裡的一個關鍵元件。很多擁有高負載流量業務的公司都在他們的生產應用里加入了 Service Mesh，如 PayPal、Lyft、Ticketmaster 和 Credit Karma 等。並且在今年一月份， Linkerd 作為雲原生應用程式的開源 Service Mesh，已經成為 CNCF（Cloud Native Computing Foundation）的官方專案。但是 Service Mesh 到底是什麼？為什麼它突然間變得如此重要？

在這篇文章裡，將給出 Service Mesh 的定義，並追溯過去十年間 Service Mesh 在應用架構中的演變過程。解釋 Service Mesh 與 API 閘道器、邊緣代理（Edge Proxy）和企業服務匯流排之間的區別。最後描述 Service Mesh 將如何發展以及我們可以作何期待。

什麼是 Service Mesh？

Service Mesh 是用於處理服務間通訊的基礎設施層。它負責通過構成現代雲原生應用程式的複雜拓撲結構來可靠地傳遞請求。

在實踐中，Service Mesh 通常被實現為與應用程式程式碼一起部署的輕量級網路代理的陣列，而不需要應用程式需要知道。

Service Mesh 作為一個單獨的層的概念與雲原生應用程式的興起息息相關。在雲原生模型裡，單個應用程式可能由數百個服務組成; 每個服務可能有數千個例項; 而且這些例項中的每一個都可能處於不斷變化的狀態，因為它們是動態排程一個像 Kubernetes 一樣的編排器。服務間通訊不僅異常複雜，而且也是執行時行為的基礎。管理好服務間通訊對於保證端到端的效能和可靠性來說是非常重要的。

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 不同的是，Service Mesh 有著超越“只是能工作”的更高的目標：為應用執行時提供統一的、應用層面的可見性和可控性。Service Mesh 的明確目標是將服務通訊從隱形的，隱含的基礎設施的領域轉移到生態系統的一流成員的角色中，在那裡它可以被監控，管理和控制。

Service Mesh 可以做什麼？

在雲本地應用程式中可靠地傳送請求可能非常複雜。像 Linkerd 這樣的 Service Mesh 通過一系列強大的技術來管理這種複雜性：電路中斷，延遲感知、負載平衡，最終一致性服務發現，重試和超時。 這些功能必須全部配合使用，這些功能與其執行的複雜環境之間的互動可能非常微妙。

例如，當通過 Linkerd 向服務請求時，會發生如下的一系列事件：

1、Linkerd 根據動態路由規則確定請求是發給哪個服務的，比如是發給生產環境裡的服務還是發給 staging 環境裡的服務？是發給本地資料中心的服務還是發給雲端的服務？是發給最新版本的服務還是發給舊版本的服務？這些路由規則可以動態配置，可以應用在全域性的流量上，也可以應用在部分流量上。

2、在確定了請求的目標服務後，Linkerd 從服務發現端點獲取相應的服務例項。如果服務例項的資訊出現了偏差，Linkerd 需要決定哪個資訊來源更值得信任。

3、Linkerd 基於某些因素（比如最近處理請求的延遲情況）選擇更有可能快速返回響應的例項。

4、Linkerd 向選中的例項傳送請求，並把延遲情況和響應型別記錄下來。

5、如果選中的例項發生宕機、沒有響應或無法處理請求，Linkerd 就把請求發給另一個例項（前提是請求必須是冪等的）。

6、如果一個例項持續返回錯誤，Linkerd 就會將其從負載均衡池中移除，並在稍後定時重試（例如這個例項有可能只是臨時發生故障）。

7、如果請求超時，Linkerd 會主動放棄請求，不會進行額外的重試。

8、Linkerd 以度量和分散式跟蹤的形式捕捉上述行為的每一個方面，並將其傳送到集中的度量系統。

除此之外，這只是簡化的版本，Linkerd 還能啟動和終止 TLS、執行協議升級、動態調整流量、在資料中心之間進行故障切換。

Linkerd 的這些特性可以保證區域性的彈性和應用層面的彈性。大規模分散式系統有一個共性：區域性故障累積到一定程度就會造成系統層面的災難。Service Mesh 的作用就是在底層系統的負載達到上限之前通過分散流量和快速失效來防止這些故障破壞到整個系統。

為什麼我們需要 Service Mesh？

Service Mesh 並非新出現的功能。Web 應用程式一直需要自己管理複雜的服務間通訊， Service Mesh 的起源可以追溯到過去十五年來這些應用的發展。

2000 年左右的中型 Web 應用一般使用了三層模型：應用邏輯層、Web 服務邏輯層和儲存邏輯層。層與層之間的互動雖然複雜，但範圍有限，畢竟一個請求最多隻需要兩個跳轉。雖然這裡不存在“網格”，但仍然存在跳轉通訊邏輯。

隨著規模的增長，這種架構就顯得力不從心了。像 Google、Netflix、Twitter 這樣的公司面臨著大規模流量的需求，他們實現了雲原生應用的前身：應用層被拆分為多個服務（也叫作微服務），層級成了一種拓撲結構。這樣的系統需要一個通用的通訊層，以一個“富客戶端”包的形式存在，如 Twitter 的 Finagle、Netflix 的 Hystrix 和 Google 的 Stubby。

在許多方面，像 Finagle、Stubby 和 Hystrix 這樣的包就是最初的 Service Mesh。

雖然他們特定於周圍環境的細節，並要求使用特定的語言和框架，但它們是用於管理服務對服務通訊的專用基礎架構的形式，（對於開源的 Finagle 和 Hysterix 庫 ）在其原籍公司之外使用。

快速轉到現代雲原生應用程式。 雲原生模式將許多小型服務的微服務方法與另外兩個因素相結合：容器（例如，提供資源隔離和依賴管理的 Docker），以及將底層硬體抽象為同質池的編排層（例如 Kubernetes）。

這三個元件允許具有自然機制的應用程式在負載下進行縮放，並處理雲環境的永久存在的區域性故障。 但是，數百個服務或數千個服務，以及一個不時重新排程例項的編排層，單個請求通過服務拓撲所遵循的路徑可能非常複雜，並且由於容器使得每個服務都可以很容易地寫入 用不同的語言，之前的方法已經不再可行了。

這種複雜性和重要性的結合激發了對與應用程式程式碼分離的服務到服務通訊的專用層的需求，並且能夠捕獲底層環境的高度動態性質。 這一層是 Service Mesh。

Service Mesh 的未來

雖然雲原生生態系統中 Service Mesh 的採用正在迅速增長，但是還有一個廣泛而令人興奮的發展路線值得探索。 對無伺服器計算（例如 Amazon 的 Lambda）的要求直接適用於 Service Mesh 的命名和連結模型，並形成其在雲原生生態系統中的角色的自然延伸。 服務標識和訪問策略在雲原生環境中的作用仍然很新穎，Service Mesh 在這裡扮演著重要角色。 最後，像之前的 TCP / IP 這樣的服務 Service Mesh 繼續被推進到底層基礎架構中。 就像 Linkerd 從 Finagle 這樣的系統發展而來，作為單獨的使用者空間代理的服務的當前版本必須明確地新增到雲原生堆疊中，這個代理也將繼續發展。

結論

Service Mesh 是雲原生技術棧中一個非常關鍵的元件。Linkerd 專案在啟動一年多之後正式成為 CNCF 的官方專案，並擁有了眾多的貢獻者和使用者。Linkerd 的使用者橫跨初創公司（如 Monzo）到大規模的網際網路公司（如 PayPal、Ticketmaster、Credit Karma），再到擁有數百年曆史的老牌公司（如 Houghton Mifflin Harcourt）。

原文地址：https://www.tuicool.com/articles/uQFbYzB

譯文地址 : https://blog.csdn.net/wangqingjiewa/article/details/78677912;

希望大家關注我一波,防止以後迷路,有需要的可以加群討論互相學習java ,學習路線探討,經驗分享與java求職      群號:721515304