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

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

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

有外文指出，2020 年 Service Mesh 技術將有以下三大發展：

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

什么是服務網格

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

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

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

服務網格一般由控制平面和數據平面組成。具體來說，控制平面是一組在一個專用的命名空間中運行的服務。這些服務完成一些控制管理的功能，包括聚合遙測數據、提供面向用戶的 API、向數據平面代理提供控制數據等。而數據平面則是由一系列運行在每個服務實例旁邊的透明代理構成。這些代理自動處理進出服務的所有流量，因為它們是透明的，所以這些代理充當了一個進程外網絡堆棧，向控制平面發送遙測數據并從控制平面接收控制信號。

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

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

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

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

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

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

• 服務網格組件通過應用動態路由規則來確定請求者想要的服務。請求應該路由到生產還是預發布的服務？是路由到本地數據中心還是云中的服務？是需要灰度到正在測試的服務的最新版本，還是仍然路由到在生產中經過驗證的舊版本？所有這些路由規則都是動態可配置的，并且可以全局應用，也可以應用于任意流量片段；

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

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

• 服務網格組件嘗試將請求發送到選擇的實例，記錄響應結果的延遲和響應類型；

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

• 如果實例始終返回錯誤，服務網格組件會將其從負載均衡池中逐出，以便稍后定期重試。這種情況在互聯網分布式應用中非常常見，公共網絡中的實例非常有可能由于某些原因導致瞬間故障；

• 如果請求的超時點已過，服務網格組件則會主動使請求失敗，而不是通過進一步重試來添加負載，以防雪崩發生。這一點對于互聯網分布式應用至關重要，否則一個小故障極有可能會引起雪崩式災難；

• 與此同時，服務網格組件以度量指標和分布式跟蹤的形式捕獲上述行為的各個方面，并將這些數據發送到集中式的度量系統或者鏈路跟蹤系統。

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

為什么服務網格是必要的

服務網格本身并不是一個新功能，更像是功能所在位置的轉變。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 對應用程序層起支持作用并位于較低級別的部署層之上。
Istio 扮演著部署平臺和應用程序代碼之間的連接角色。它的作用是促進從應用程序中取出復雜的網絡邏輯，可以基于作為請求的一部分的外部元數據（例如 HTTP 標頭等）來執行基于內容的路由。也可以根據服務和請求的元數據匹配進行細粒度的流量控制和路由。還可以保護傳輸和卸載安全令牌驗證，或者可以實施服務運維人員定義的配額和使用策略等。

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

成熟度和支持級別

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

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

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

總結

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

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

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

推薦閱讀：
【1】阿里云服務網格ASM公測來襲系列之一：快速了解什么是ASM
文章鏈接：https://yq.aliyun.com/articles/748761
【2】阿里云服務網格ASM之擴展能力(1)：在ASM中通過EnvoyFilter添加HTTP請求頭
文章鏈接：https://yq.aliyun.com/articles/748807

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的公眾號。”

總結

以上是生活随笔為你收集整理的阿里云专家详解 2020 服务网格发展趋势的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。