![4.7頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/dfc925c8fc7e4fa8946e7ce116ac90ca.png)

作者 | 王夕寧  阿里巴巴高階技術專家

**關注“阿里巴巴雲原生”公眾號，參與文末留言互動，即有機會獲得贈書福利！**

> 本文摘自於由阿里雲高階技術專家王夕寧撰寫的《Istio 服務網格技術解析與實踐》一書，文章從基礎概念入手，介紹了什麼是服務網格及 Istio，針對 2020 服務網格的 3 個發展趨勢，體系化、全方位地介紹了 Istio 服務網格的相關知識。**你只需開心參與公眾號文末互動，我們負責買單！技術人必備書籍《Istio 服務網格技術解析與實踐》免費領~**

有[外文](https://link.zhihu.com/?target=https%3A//thenewstack.io/the-top-3-service-mesh-developments-in-2020/)指出，2020 年 Service Mesh 技術將有以下 3 個發展趨勢：

- 快速增長的服務網格需求；
- Istio
很難被打敗，很可能成為服務網格技術的事實標準；
- 出現更多的服務網格用例，WebAssembly 將帶來新的可能。

# 什麼是服務網格

Gartner 2018 關於服務網格技術趨勢分析報告，展示了一系列的服務網格技術，劃分服務網格技術的依據是基於應用服務程式碼是否必須對其服務網格感知及其是否鎖定，或鎖定的程度。

基於程式設計框架的網格技術可以幫助開發人員構建一個架構體系良好的服務，但這會導致應用程式碼與框架和執行時環境的緊密耦合。而基於 Sidecar 代理的服務網格技術不會為開發人員設定這些障礙，並且使其管理和維護更加輕鬆，能夠提供更靈活的方法來配置執行時策略。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/94f95a896e7041639496d7e1ec97cc09.png)

在微服務環境中，可將單一應用程式分解為獨立的多個元件，並作為分散式服務進行部署，這些服務通常是無狀態的、短暫的、動態可擴充套件的，執行在容器編排系統（如 Kubernetes）中。

服務網格一般由控制平面和資料平面組成。具體來說，控制平面是一組在一個專用的名稱空間中執行的服務。這些服務完成一些控制管理的功能，包括聚合遙測資料、提供面向使用者的 API、向資料平面代理提供控制資料等。而資料平面則是由一系列執行在每個服務例項旁邊的透明代理構成。這些代理自動處理進出服務的所有流量，因為它們是透明的，所以這些代理充當了一個程式外網路堆疊，向控制平面傳送遙測資料並從控制平面接收控制訊號。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/675f57f5a58b4b0ea8e87577be6a34e9.png)

服務例項可以根據需要進行啟動、停止、銷燬、重建或替換。因此，這些服務需要一個通訊中介軟體來支援服務的動態發現和自我修復連線能力，從而使得這些服務之間能夠以安全、動態和可靠的方式相互通訊，這就是服務網格所支援的功能。

服務網格是一個專用的基礎設施層，使服務到服務之間的通訊更加安全、快速、可靠。如果你正在構建雲原生應用程式，則需要服務網格。在過去的一年中，服務網格已成為雲原生程式的關鍵元件，它透過包含現代雲原生應用程式的複雜服務拓撲來可靠地傳遞請求。實際上，服務網格通常實現為輕量級網路代理的組合，這些代理與應用程式程式碼一起部署，不需要知道應用程式是什麼。

服務網格作為單獨層的概念與雲原生應用程式的興起有關。在雲原生模型中，單個應用程式可能包含數百個服務，每個服務可能有數千個例項，並且每個例項可能處於不斷變化的狀態。這也是為什麼像 Kubernetes 這樣的協調器日益流行和必要的原因所在。這些服務之間的通訊不僅變得越來越複雜，而且也是執行時環境中最為常見的一部分，因此管理這些服務之間的通訊對於確保端到端的效能和可靠性至關重要。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/422baf41de5d4a7e9046633125c9b6b5.png)

服務網格是一種網路模型，位於 TCP/IP 之上的抽象層。它假定底層的三四層網路存在並且能夠從一點到另一點傳送位元組。它還假設該網路與環境的其他方面一樣不可靠，因此服務網路也必須能夠處理網路故障。在某些方面，服務網格類似於 TCP/IP。正如 TCP 協議棧抽象了在網路端點之間可靠地傳遞位元組的機制一樣，服務網格抽象了在服務之間可靠地傳遞請求的機制。與 TCP 一樣，服務網格不關心實際有效負載或其編碼方式，只負責完成從服務 A 傳送到服務B，並且在處理任何故障的同時實現這一目標。但是，與 TCP 不同的是，服務網格不僅僅具備“使其工作”的能力，還提供了一個統一的應用程式控制點，用於將可見性和控制引入應用程式執行時。服務網格的明確目標是將服務通訊從不可見的基礎設施領域移出，並轉變為生態系統的一部分，可以對其進行監控、管理和控制。

在雲原生應用程式中，保證請求具備完整的可靠性並非易事。服務網路透過各種強大的技術來管理這種複雜性，支援熔斷、延遲感知的負載均衡、最終一致性的服務發現、重試與超時等機制來儘可能保證可靠性。這些功能必須全部協同工作，並且與其執行的複雜環境之間的相互作用也非常重要。

例如，當透過一個服務網格向服務發出請求時，其互動過程可以大致簡化為如下步驟：

- 服務網格元件透過應用動態路由規則來確定請求者想要的服務。請求應該路由到生產還是預釋出的服務？是路由到本地資料中心還是雲中的服務？是需要灰度到正在測試的服務的最新版本，還是仍然路由到在生產中經過驗證的舊版本？所有這些路由規則都是動態可配置的，並且可以全域性應用，也可以應用於任意流量片段；

- 找到正確的目的地後，服務網格元件從相關的服務發現端點檢索相應的例項池，可能有多個例項。如果這些資訊與服務網格元件在實踐中觀察到的資訊不同，那麼它會決定要信任哪些資訊來源；

- 服務網格元件根據各種因素選擇最有可能返回快速響應的例項，包括觀察到的最近請求的延遲資料；

- 服務網格元件嘗試將請求傳送到選擇的例項，記錄響應結果的延遲和響應型別；

- 如果例項已經由於各種原因當機，或者請求根本沒有響應，或者由於其他任何原因而無法處理請求，服務網格元件則會根據需要在另一個例項上重試該請求，前提是它知道請求是冪等的；

- 如果例項始終返回錯誤，服務網格元件會將其從負載均衡池中逐出，以便稍後定期重試。這種情況在網際網路分散式應用中非常常見，公共網路中的例項非常有可能由於某些原因導致瞬間故障；

- 如果請求的超時點已過，服務網格元件則會主動使請求失敗，而不是透過進一步重試來新增負載，以防雪崩發生。這一點對於網際網路分散式應用至關重要，否則一個小故障極有可能會引起雪崩式災難；

- 與此同時，服務網格元件以度量指標和分散式跟蹤的形式捕獲上述行為的各個方面，並將這些資料傳送到集中式的度量系統或者鏈路跟蹤系統。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/ec03ffd632614222bd938b37aed6b8b2.png)

值得注意的是，這些功能都是在為分散式應用提供逐點彈性和應用程式範圍的彈效能力。大規模分散式系統（無論如何構建）都有一個明確的特徵：任何小型本地化故障都有可能升級為系統範圍的災難性故障。服務網格必須設計成在基礎系統接近其極限時透過減少負載和快速失敗來防止這些故障升級。

# 為什麼服務網格是必要的

服務網格本身並不是一個新功能，更像是功能所在位置的轉變。Web 應用程式始終必須管理服務通訊的複雜性。在過去的十五年中，服務網格模型的起源可以追溯到這些應用程式的演變過程。

在本世紀初，中型 Web 應用程式的典型架構常見的是三層應用程式架構，分為應用程式邏輯層、Web 服務邏輯層和儲存邏輯層，都是單獨的層。層之間的通訊雖然複雜，但範圍有限。這個時候的應用架構並沒有網格，但是在每個層的程式碼處理邏輯之間存在通訊邏輯。

當網路發展到非常高規模時，這種架構方法開始變得捉襟見肘。特別是一些大型網際網路公司，都面臨著巨大的流量需求，實現了有效的雲原生方法的前身：應用層被分成許多服務，也就是現在通常所知的“微服務”，層之間形成拓撲的通訊方式。在這些系統中，通常採用“胖客戶端”庫的形式，也就是前面講述過的類似於 Netflix 的 OSS 庫，Hystrix 的熔斷能力就是很好的例證。這些程式碼庫雖然與特定的環境相關，並且需要使用特定的語言和框架，但它們是用於管理服務之間通訊的形式與能力，在當時的情況下是不錯的選擇，而且也在眾多公司裡被使用。

進入雲原生時代之後，雲原生模型有兩個重要因素：

- 容器（例如 Docker）提供資源隔離和依賴管理；
- 編排層（例如 Kubernetes）將底層硬體抽象為同質的資源池。

儘管這些程式碼庫元件在一定程度上允許應用程式具備一定的負載擴充套件能力，並處理雲環境中始終存在的部分故障，但是，隨著數百個服務或數千個例項的增加，以及存在不時重新排程例項的業務流程層，單個請求透過服務拓撲所遵循的路徑可能非常複雜。同時隨著容器技術的普及，且容器使每個服務都易於用另一種語言編寫執行，程式庫式方法在此時此刻就變得捉襟見肘了。

這種複雜性和關鍵性的訴求，使得應用越來越需要一個服務間通訊的專用層，該專用層與應用程式程式碼分離並且能夠捕獲底層環境的高度動態彈效能力。該層就是我們需要的服務網格。

服務代理可以幫助我們在雲環境服務架構中新增重要功能。每個應用程式都可以擁有自己的要求或配置，以瞭解代理在給定其工作負載目標時的行為方式。隨著應用程式和服務越來越多，配置和管理大量代理可能非常困難。此外，在每個應用程式例項中使用這些代理可以為構建豐富的高階功能提供機會，否則我們將不得不在應用程式本身執行這些功能。

服務代理形成一個網狀的資料平面，透過該資料平面處理和觀察所有服務間的流量。資料平面負責建立、保護和控制透過網格的流量。負責資料平面如何執行的管理元件稱為控制平面。控制平面是網格的大腦，併為網格使用人員提供公開 API，以便操縱網路行為。

# Istio 服務網格

Istio 是一個用於連線/管理以及安全化微服務的開放平臺，提供了一種簡單的方式用於建立微服務網格，並提供負載均衡、服務間認證以及監控等能力，關鍵的一點是並不需要修改太多服務就可以實現上述功能。Istio 本身是一個開源專案，它提供了一致的方式用於連線、加固、管理和監控微服務，最初是由 Google、IBM 和 Lyft 建立的服務網路的開源實現。Istio 可以幫助你以透明的方式為服務架構新增彈性和可觀察效能力。使用 Istio，應用程式不必知道它們是服務網格的一部分。每當應用程式與外界互動時，Istio 將代表應用程式處理網路流量。這意味著如果你正在做微服務，Istio 可以帶來很多好處。

Istio 主要提供以下功能：

- 流量管理，控制服務之間呼叫的流量和API呼叫，使得呼叫更可靠，並使網路在惡劣情況下更加健壯；
- 可觀測性，獲取服務之間的依賴，以及服務呼叫的流量走向，從而提供快速識別問題的能力；
- 策略執行，控制服務的訪問策略，不需要改動服務本身。

服務身份和安全，為網格中的服務提供可驗證身份，並提供保護服務流量的能力，使其可以在不同可信度的網路上流轉。

Istio 第一個生產可用版本 1.0 於 2018 年 7 月 31 日正式釋出，並於 2019 年 3 月釋出版本 1.1。之後，社群按照快速迭代的方式，在三個月內接連發布了 10 個小版本。截至本書完稿之際，社群已經發布了 1.4 版本。

Istio 的資料平面預設使用 Envoy 代理，開箱即用，可幫助你配置應用程式以在其旁邊部署服務代理的例項。Istio 的控制平面由一些元件組成，這些元件為終端使用者和運維人員提供運維 API、代理的配置 API、安全設定、策略宣告以及其他更多功能。我們將在本書的後續部分介紹這些控制平面元件。

Istio 最初是為在 Kubernetes 上執行而構建的，但卻是從部署平臺中立的角度實現程式碼的。這意味著你可以在 Kubernetes、OpenShift、Mesos 和 Cloud Foundry 等部署平臺上利用基於 Istio 的服務網格，甚至可以在虛擬機器、物理裸機上部署 Istio 環境。在後面的章節中，我們將展示 Istio 對於包括私有資料中心在內的雲組合的混合部署來說有多強大。在本書中，我們將優先考慮在 Kubernetes 上進行部署，在後面更高階的章節中會引入虛擬機器等環節。

Istio 在希臘語中的意思是“啟航”，而 Kubernetes 在希臘語中可以翻譯為“舵手”或“駕駛員”。所以從一開始 Istio 就期望與 Kubernetes 很好地配合，高效地執行分散式微服務架構，並提供安全、連線和監控微服務的統一方法。

透過每個應用程式例項旁邊的服務代理，應用程式不再需要具有特定於語言的彈性庫來實現熔斷、超時、重試、服務發現、負載均衡等功能。此外，服務代理還處理度量標準收集、分散式跟蹤和日誌收集等。

由於服務網格中的流量流經 Istio 服務代理，因此 Istio 在每個應用程式中都有控制點來影響和指導其網路行為。這允許服務運維人員可以控制路由流量，並透過金絲雀部署、暗啟動（Dark Launch）、分級滾動和 A/B 測試來實現細粒度部署。我們將在後面的章節中探討這些功能。

# 核心功能

Istio 在服務網路中統一提供了許多關鍵功能，主要包括流量管理、安全、可觀測性、平臺支援、整合和定製五個部分。

## 1.流量管理

透過簡單的規則配置和流量路由，Istio 可以控制服務之間的流量和 API 呼叫。Istio 簡化了熔斷器、超時和重試等服務級別屬性的配置，並且可以輕鬆設定 A/B 測試、金絲雀部署和基於百分比的流量分割的分階段部署等重要任務。

Istio 有開箱即用的故障恢復功能，你可以在問題出現之前先發現問題，透過最佳化使服務之間的呼叫更加可靠。

## 2.安全

Istio 具備強大的安全功能，使開發人員可以專注於應用程式級別的安全性。Istio 提供底層安全通訊通道，並大規模管理服務通訊的認證、授權和加密。使用 Istio，服務通訊在預設情況下是安全的，允許跨多種協議和執行時一致地實施策略，而關鍵的是所有這些都很少或根本不需要應用程式更改。

雖然 Istio 與平臺無關，但將其與 Kubernetes 網路策略一起使用時，其優勢更大，包括在網路和應用層保護 pod-to-pod 或服務到服務通訊的能力。後續章節中會講述如何在 Kubernetes 中結合網路策略與 Istio 來共同保護服務。

## 3.可觀測性

Istio 具備強大的追蹤、監控和日誌記錄能力，可讓你深入瞭解服務網格部署。透過 Istio 的監控功能，可以真正瞭解服務效能如何影響上游和下游的功能，而其自定義的儀表板可以提供對所有服務效能的可視性，並讓你瞭解該效能如何影響其他程式。

Istio 的 Mixer 元件負責策略控制和遙測收集，提供後端抽象和中介，將 Istio 的其餘部分與各個後端基礎設施的實現細節隔離開來，併為運維人員提供對網格和後端基礎設施之間所有互動的細粒度控制。

所有這些功能可以讓你更有效地設定、監控和實施服務上的服務等級目標 SLO。當然，最重要的是可以快速有效地檢測和修復問題。

## 4.平臺支援

Istio 是獨立於平臺的，目標是可以在各種環境中執行，包括跨雲、內部部署、Kubernetes、Mesos 等。你可以在 Kubernetes 上部署 Istio 或在具有 Consul 的 Nomad 上部署。Istio 目前支援：

- 在 Kubernetes 上部署的服務；
- 使用 Consul 註冊的服務；
- 在各個虛擬機器上執行的服務。

## 5.整合和定製

可以擴充套件和自定義 Istio 的策略實施元件，以與現有的 ACL、日誌記錄、監控、配額、審計等解決方案整合。

此外，從版本 1.0 開始，Istio 支援基於 MCP（Mesh Conf?iguration Protocol，網格配置協議）進行配置分發。透過使用 MCP，可以很容易地整合外部系統，例如可以自己實現 MCP 伺服器，然後將其整合到 Istio 中。MCP 伺服器可以提供以下兩個主要功能：

- 連線並監控外部服務註冊系統，以獲取最新的服務資訊（例如 Eureka、ZooKeeper 等系統）；
- 將外部服務資訊轉換為 Istio
ServiceEntry 並透過 MCP 資源釋出。

# 為什麼要使用 Istio

在從單體應用程式向分散式微服務架構的轉型過程中，開發人員和運維人員面臨諸多挑戰，使用 Istio 可以解決這些問題。隨著規模和複雜性的增長，服務網格越來越難以理解和管理，各種需求包括服務發現、負載均衡、故障恢復、指標收集和監控以及更加複雜的運維，例如 A/B 測試、金絲雀釋出、限流、訪問控制和端到端認證等。Istio 提供了一個完整的解決方案，透過為整個服務網格提供行為洞察和操作控制來滿足微服務應用程式的多樣化需求。

Istio 提供一種簡單的方式來為已部署的服務建立網路，該網路具有負載均衡、服務間認證、監控等功能，只需要對服務的程式碼進行一點改動或不需要做任何改動。想要讓服務支援 Istio，只需要在你的環境中部署一個特殊的 Sidecar 代理，使用 Istio 控制平面來配置和管理代理，攔截微服務之間的所有網路通訊。

此外，面向服務的架構（SOA）的企業服務匯流排（ESB）與服務網格有一些相似之處，在 SOA 體系架構中 ESB 對於應用程式服務來說是透明的，這意味著應用程式對它無感知。服務網格可以得到類似的行為，服務網格應該對應用程式透明，就像 ESB 那樣，簡化服務間的呼叫。當然，ESB 還包括互動協議的中轉、訊息轉換，或者基於內容的路由之類的事情，而服務網格不負責 ESB 所做的所有功能。服務網格確實透過重試、超時、熔斷提供服務請求的彈效能力，同時也提供服務發現和負載均衡等服務。複雜的業務轉換、業務流程編排、業務流程異常，以及服務編排能力等並不屬於服務網格的解決範疇。相對於 ESB 的集中式系統，服務網格中的資料平面高度分佈，其代理與應用程式並存，這消除了 ESB 架構中經常出現的單點故障瓶頸問題。

當然，也需要清楚服務網格沒有解決哪些問題，像 Istio 這樣的服務網格技術通常都提供了強大的基礎架構功能，可以觸及分散式架構的許多領域，但肯定不能解決你可能遇到的每個問題。理想的雲架構能從實現的每個層中分離出不同的關注點。

在基礎架構的低層，更加關注基礎設施，如何提供自動化部署的基礎架構能力。這有助於將程式碼部署到各種平臺上，無論是容器、Kubernetes，還是虛擬機器等。Istio 不會限定你應該使用哪種自動化部署工具。

在更高的業務應用級別，應用程式業務邏輯是企業保持核心競爭力的差異化資產。這些程式碼資產涉及了包括業務功能單一以及需要呼叫的服務，以何種順序執行，如何執行這些服務的互動，如何將它們聚合在一起，以及在發生故障時要執行的操作等。Istio 不實現或替換任何業務邏輯，它本身不執行服務編排，也不會提供業務負載的內容轉換或者增強，不會針對負載進行拆分或者聚合。這些功能最好留給應用程式中的庫和框架來實現。

下圖是關於雲原生應用程式中的關注點分離，其中 Istio 對應用程式層起支援作用並位於較低階別的部署層之上。<br>Istio 扮演著部署平臺和應用程式程式碼之間的連線角色。它的作用是促進從應用程式中取出複雜的網路邏輯，可以基於作為請求的一部分的外部後設資料（例如 HTTP 標頭等）來執行基於內容的路由。也可以根據服務和請求的後設資料匹配進行細粒度的流量控制和路由。還可以保護傳輸和解除安裝安全令牌驗證，或者可以實施服務運維人員定義的配額和使用策略等。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/4a79e06f220b43feb5d05a65f6cb0863.png)

瞭解 Istio 的能力，與其他系統的相似之處以及它在架構中的位置，可幫助我們像我們過去可能遇到的有前途的技術那樣犯同樣的錯誤至關重要。

**成熟度和支援級別**

Istio 社群針對每個元件功能的相對成熟度和支援級別，提出了不同的功能階段定義，分別用 Alpha、Beta 和 Stable 來描述各自的狀態，如表 1-1 所示。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/91adf101598f46a2a863b8a25fc9d9b8.png)

表 1-2 是我們摘錄的 Istio 1.4 版本現有功能中已經達到 Beta 及 Stable 功能階段的列表。此資訊將在每次釋出後更新，可參照官方網站獲取更新狀態。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/3961015b6cc449eebc39056cecff1660.png)
![8.png](https://ucc.alicdn.com/pic/developer-ecology/3e3e9832dff04de6845b79134c74acfc.png)

當然，Istio 仍然有一些功能還處於 Alpha 狀態，如 Istio CNI 外掛，它能夠代替 istio-init 容器完成同樣的網路功能，而且無需 Istio 使用者額外申請 Kubernetes RBAC 授權；以及在 Envoy 中使用自定義過濾器的能力等等。相信在後續不斷完善中，這些功能將逐漸變得越來越穩定且生產可用。

# 總結

Istio 作為當前業界服務網格領域中最流行的實現，其功能允許你在混合環境中簡化雲原生服務架構應用的執行和操作。Istio 使開發者專注於使用自己喜歡的程式語言構建服務功能，這有效地提升了開發者的生產力，同時開發者免於將解決分散式系統問題的程式碼糅合到業務程式碼中。

Istio 是一個完全開放的開發專案，擁有一個充滿活力、開放和多元化的社群，它的目標是賦能開發者和運維人員，使他們在所有環境中都能敏捷地釋出和維護微服務，擁有底層網路的完全的可見性，且獲得一致的控制和安全能力。在本書的後續部分，我們將展示如何利用 Istio 的功能在雲原生世界中執行微服務。

本文摘自於《Istio 服務網格解析與實戰》，經出版方授權釋出。本書由阿里雲高階技術專家王夕寧撰寫，詳細介紹 Istio 的基本原理與開發實戰，包含大量精選案例和參考程式碼可以下載，可快速入門 Istio 開發。Gartner 認為，2020 年服務網格將成為所有領先的容器管理系統的標配技術。本書適合所有對微服務和雲原生感興趣的讀者，推薦大家對本書進行深入的閱讀。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/04190b70351846b99de5d9e5e47b5bb3.png)

**推薦閱讀：**

【1】阿里雲服務網格ASM公測來襲系列之一：快速瞭解什麼是ASM

文章連結：https://yq.aliyun.com/articles/748761

【2】阿里雲服務網格ASM之擴充套件能力(1)：在ASM中透過EnvoyFilter新增HTTP請求頭

文章連結：https://yq.aliyun.com/articles/748807

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/I4UwyEMJ7TnQKg7bDokEzg)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

阿里雲專家詳解 2020 服務網格發展趨勢

相關文章