為什麼我們需要服務網格Service mesh？

什麼是服務網格？
服務網格是用於處理服務與服務通訊的專用基礎架構層。它負責透過建構基於現代雲應用的複雜拓撲結構來可靠地傳遞請求。實際上，服務網格通常作為輕量級網路代理的陣列實現，這些代理與應用程式程式碼一起部署，而不需要應用程式需要事先知道。（Sprin cloud需要在程式碼中配置，但是我們會看到，這個想法有些不同。）

服務網格的概念作為一個單獨的層與雲應用的興起息息相關。在雲模式中，單個應用程式可能由數百個服務組成; 每項服務可能有數千個例項; 並且這些例項中的每一個例項都可能處於不斷變化的狀態，因為它們是由諸如Kubernetes之類的協調器動態排程的。這個世界中的服務通訊不僅非常複雜，而且是這是運維的最基礎部分。管理它對於確保端到端的效能和可靠性至關重要。

服務網路是一個網路模型嗎？
服務網格是位於TCP / IP之上的抽象層的網路模型。它假設底層的L3 / L4網路存在並且能夠從點到點傳送位元組。（它也假定這個網路和環境的其他方面一樣不可靠;因此服務網格也必須能夠處理網路故障。）

在某些方面，服務網格類似於TCP / IP。正如TCP堆疊抽象了網路端點之間可靠地傳遞位元組的機制一樣，服務網格也抽象了在服務之間傳遞可靠地請求的機制。與TCP一樣，服務網格不關心實際有效負載或其編碼方式。應用程式有一個最高目標（“從A傳送到B的某樣東西”），而服務網格的工作就像TCP一樣，是為了在處理任何故障的同時完成這個目標。

與TCP不同，服務網格已經超越了“僅僅能執行即可”的目標：它提供了一個統一的、應用程式級別的切入角度，將可見性和控制引入執行時的應用程式。服務網格的明確目標是將服務通訊從無形的、隱含的基礎設施的領域中移出，並轉化為生態系統中第一等公民的角色 - 在這個位置可以對其進行監控，管理和控制。

服務網格實際上做了什麼？
在雲應用程式中要實現可靠地傳送請求可能非常複雜。像Linkerd 這樣的開源服務網路產品是透過各種強大的技術來管理這種複雜性：斷路器、負載平衡延遲感知、服務發現的最終一致性，重試和死期等。這些功能都必須協同工作，並且這些功能與其執行的複雜環境之間的互動可能非常微妙。

例如，當透過Linkerd向服務發出請求時，一個非常簡化的事件時間表如下：

1. Linkerd應用動態路由規則來確定請求者想要的服務。應該將請求路由到生產服務還是測試服務？是針對本地資料中心或雲中的服務？對於正在測試的服務的最新版本還是在生產中已經過審查的較舊版本的服務？所有這些路由規則都是可動態配置的，並且可以在全域性和任意切片中應用。

2. 找到正確的目的地後，Linkerd從相關服務發現端點檢索相應的例項池，其中可能有幾個例項。如果這些資訊與Linkerd在實踐中觀察到的不同，Linkerd會決定要信任哪些資訊來源。

3. Linkerd根據各種因素選擇最有可能返回快速響應的例項，包括觀察到的最近請求的延遲。

4. Linkerd會嘗試將請求傳送到例項，記錄結果的延遲和響應型別。

5.如果例項關閉，無響應或無法處理請求，則Linkerd會在另一個例項上重試請求（但只有當它知道請求是冪等的時）。

6.如果一個例項始終返回錯誤，則Linkerd會將其從負載平衡池中剔除，以便以後定期重試（例如，某個例項可能正在經歷一個瞬時故障）。

7.如果請求的死期已到，則Linkerd主動發出失敗請求，而不是在進一步重試，給系統新增額外負載。

8.Linkerd以度量和分散式跟蹤的形式捕獲上述行為的各個方面，並將這些資料傳送到集中式度量系統。

這只是簡化的版本 - Linkerd還可以啟動和終止TLS，執行協議升級，動態切換流量，並在資料中心之間進行故障切換！


需要注意的是，這些功能目標是提供逐點的恢復能力和應用程式範圍的恢復能力。大型的分散式系統，不管它們是如何架構的，都有一個明確的特徵：存在各種小型區域性的故障，從而可能升級為全系統的災難性故障(banq注：比如雲當機)。服務網格必須設計成透過在底層系統接近極限時減少負載和快速失敗來防範故障升級或擴大化。

為什麼需要服務網格？
服務網格不是引入新功能，而是功能定位的轉變。Web應用程式一直必須管理服務通訊的複雜性。服務網格模型的起源可以追溯到過去十五年來這些應用的發展。

想想2000年代中型Web應用程式的典型架構：三層應用程式。在這個模型中，應用程式邏輯，Web服務邏輯和儲存邏輯都是獨立的層。層之間的通訊雖然複雜，但範圍有限 - 畢竟只有兩次層層呼叫。雖然沒有“網格”，但是這種層之間有通訊邏輯，在每層的程式碼中處理。

當這種架構方法被推到非常大的規模時，它開始出現問題。像谷歌，Netflix和Twitter這樣的公司面臨著巨大的流量需求， - 應用層被分成許多服務（有時稱為“微服務”），層級成為拓撲結構。在這些系統中，廣義的通訊層變得瞬間相關，但通常採用“胖客戶”庫的形式，例如Twitter的Finagle，Netflix的 Hystrix和Google的Stubby就是這樣的例子。

在許多方面，像Finagle，Stubby和Hystrix這樣的庫包是第一種服務網格。雖然它們服務於特定的周圍環境，並且需要使用特定的語言和框架，但它們是用於管理服務到服務通訊的專用基礎架構的形式，以及（對於開源Finagle和Hystrix庫）在其原公司之外還有使用。

快速轉向現代雲應用程式，雲模式將許多小型服務的微服務方法與兩個附加因素結合在一起：容器（例如 Docker）（提供資源隔離和依賴性管理）以及編排層（例如 Kubernetes），將底層硬體抽象為均勻池。

這三個元件啟用了應用程式自適應的自然機制，這樣能在負載下進行動態擴充套件並處理雲環境中不斷出現的部分故障。但是，數百個服務或數千個例項以及編排層不時重新調整例項，單個請求透過服務拓撲結構遵循的路徑可能非常複雜，並且由於容器使得每個服務都可以輕鬆用另一種語言編寫，庫包的方法已不再可行。

這種複雜性和重要性一旦結合，激發了對與應用程式程式碼分離，需要將服務到服務通訊專門從應用程式碼中分離一個專用層，並能夠捕獲底層環境的高度動態性。該層就是服務網格。

服務網路的未來
雖然雲生態系統中服務網格的使用量正在迅速增長，但還有一個廣泛而令人興奮的路線圖仍有待探索。無伺服器計算Serverless的要求（例如亞馬遜的 Lambda）可直接使用服務網格的命名和連結模型，並在雲生態系統中形成其角色的自然延伸。服務身份和訪問策略的作用在雲環境中仍然非常新穎，服務網格很好地扮演著這個故事的基本組成部分。最後，像它之前的TCP / IP一樣，服務網格將繼續推進到底層基礎架構中。就像Linkerd從Finagle這樣的系統演變而來，目前作為單獨的使用者空間代理的服務網格化體系必須明確新增到雲堆疊中，這個代理也將繼續發展。

結論
服務網格是雲堆疊的關鍵元件。從推出起僅一年多的時間裡，Linkerd就是雲端計算本地計算基金會的成員，並且擁有一個蓬勃發展的貢獻者和使用者社群。從像Monzo這樣正在顛覆英國銀行業的初創公司到像Paypal，Ticketmaster和Credit Karma這樣的高規模網際網路公司，也還有像Houghton Mifflin Harcourt這樣經營了幾百年的公司。

What’s a service mesh? And why do I need one?