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

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

關注「阿里巴巴雲原生」公衆號，參與文末留言互動，即有機會得到贈書福利！

本文摘自於由阿里雲高級技術專家王夕寧撰寫的《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 對應用程序層起支持做用並位於較低級別的部署層之上。<br />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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」