[[376673]]

本文轉載自微信公眾號「石杉的架構筆記」，作者崔皓 。轉載本文請聯系石杉的架構筆記公眾號。 

開篇

在云環境下，技術棧可謂是多種多樣，通過不同的技術生成不同的應用。如何能將這些異構的服務或者應用有機地串聯起來，成為了服務治理的重大課題，在這樣的大背景下Istio架構為這樣應用場景提供了服務治理的功能，Istio提供的流量治理、策略、遙測、訪問安全等功能至今都被人津津樂道。

今天就圍繞Istio架構的實現原理為大家介紹如下內容：

• 為什么選擇Istio
• 什么是Istio
• Istio架構原理
• Istio服務治理功能介紹

為什么選擇Istio

隨著業務的復雜度提高，為了應對高并發、大流量，系統架構對服務/應用進行拆分。拆分以后的服務/應用可以進行分布式部署，來應對高并發帶來的系統壓力以及處理復雜的業務邏輯。

這樣的做法會造成系統中存在大量獨立的服務或者應用，它們分布在不同的進程、主機上面，在它們之間互相調用的時候就存在服務治理的問題。微服務就是一個典型的例子，微服務的開發和運維對程序員來說是一個挑戰。

分而治之的思想使得業務本身的規模和復雜度不降反增。

在分布式系統中，網絡可靠性、通信安全、網絡時延、網絡拓撲變化等都成了關注的焦點，同時服務注冊、服務發現、負載均衡、服務間通訊、分布式調用鏈追蹤都是要解決的問題。

為了解決這個問題，把服務治理部分抽象成公共庫，讓所有微服務都使用這個公共庫。如圖1所示，在Node 1 和 Node 2 上分別用Service 1 和Service 2兩個服務，它們分別針對自己的業務邏輯都有對應的服務治理的SDK，通過這個SDK完成服務治理的服務發現、服務注冊等功能。

 圖1.將服務治理的邏輯抽象成公共庫

如果將圖1中的SDK包含到開發框架中(例如：Spring Cloud)，當運用這種開發框架后就擁有服務治理的能力了。SDK的模式雖然解耦了業務邏輯和服務治理，由于在一個開發框架中，因此業務邏輯需要和 服務治理的SDK一起編譯，發布以后業務邏輯和服務治理的代碼在一個進程中運行。這會導致業務代碼和 SDK 基于同一種語言，無法兼容其他語言開發的服務。同時，在服務治理升級時，需要升級整個服務，即使業務邏輯沒有改變。如果說圖1的模式，SDK和業務代碼在同一進程，因此需要對其進行解耦，把服務治理從業務代碼中剝離出來。如圖2所示，紅色的部分代替了原來的SDK，其使用了Sidecar模式。在這種形態下，業務邏輯和服務治理在獨立的進程下運行。

圖2.Sidecar解耦業務邏輯和服務治理

Sidecar的模式使兩者代碼和運行無耦合。如圖3所示，業務邏輯就好像綠色的方塊，再其右邊的藍色方塊就是Istio提供的Sidecar(邊車)，也就是通過這個Sidecar與網絡中其他服務的Sidecar進行鏈接，從而實現服務之間的通信。

這樣業務邏輯可以使用不同的語言進行開發，升級也相互獨立，而其他的服務治理的工作，例如：服務注冊、服務發現、負載均衡、通訊等都由Sidecar來完成。

圖3.Istio的Sidecar模式

這里通過業務邏輯與服務治理的角度，將使用Istio之前和之后的微服務做區分，從以下三個維度進行對比。

因此在使用Istio架構以后，會將業務邏輯與服務治理在運行進程、技術棧和服務升級三個方面進行完全解耦，通過Sidecar模式打造分布式系統的最佳實踐，接下來就來看看Istio包括哪些內容。

什么是Istio

眾所周知Istio是一個Service Mesh形態的，用于服務治理的開放平臺。這里的服務“治理”不僅限于“微服務”，可以推廣到任何服務。只要存在服務或者應用，在它們之間存在訪問，也存在對服務與應用的管理，都可以使用到 Istio。

如圖4所示，在 Istio 官方介紹中，其功能包括：連接(Connect)、安全(Secure)、控制(Control)和觀察(Observe)

圖4.Istio 官方功能介紹

將上面四項功能總結如下：

• 連接：通過流量規則控制服務間的流量和調用，實現負載均衡、熔斷、故障注入、重試、重定向等功能。
• 安全：提供認證機制、通道加密、服務訪問授權等安全能力，增強訪問的安全性。
• 控制：通過可動態插拔、可擴展的策略實現訪問控制、速率限制、配額管理、服務計費等能力。
• 觀察：獲取服務運行數據和輸出，提供調用鏈監控和日志收集能力。

在微服務時代，Kubernetes提供了服務的部署、升級、擴容等運行管理能力，但在服務治理方面，如服務的熔斷、限流、動態路由、調用鏈追蹤顯得能力不足。

Istio作為服務治理的架構剛好在這一點上彌補了Kubernetes的不足，成為了Kubernetes的好搭檔。

既然把Istio吹上了天，就來看看Istio 在服務訪問的過程中有哪些建樹吧。如圖5所示，有兩個Pod容器，分別存放兩個不同的服務，Service A和Service B。其中Service A由Java進行開發，而Service B由Python進行開發。

• Service A通過服務發現獲取Service B服務實例列表，如果Service B存在多個水平擴展(Service B集群)，還需要根據負載均衡策略選擇一個具體的Service B實例。
• 為了保證安全性，服務之間的請求和響應需要啟用雙向認證和通道加密。
• 在一段時間內，Service A在訪問Service B不斷出現錯誤，需要進行熔斷處理，停止對Service B的請求動作。
• 針對Service B的處理能力，設置最大連接的請求數、訪問超時等參數，從而對其進行服務保護。
• 如果有需要可以將Service A對Service B發起的請求重定向到其他服務上。
• 如果Service B 有新、老兩個版本，在執行灰度發布的時候，將Service A請求的部分流量(20%)導入到Service B的新版本中，其他的流量(80%)導入到Service B的老版本上。隨著Service B 新版本的逐步穩定，再將剩下的80% 流量導入到新版本上。
• 對Service A調用 Service B 的調用鏈進行追蹤，為提升服務之間的調用效率提供數據依據。

圖5.Istio 針對服務治理的功能

Istio架構原理

在上一節中介紹了什么是Istio，是針對其功能進行的描述，看上去比較抽象，這里從Istio的工作機制和架構進一步進行描述。如圖4所示，Istio整個架構可以分為控制面和數據面兩部分，控制面主要包括Pilot、Mixer、Galley、Citadel等組件;數據面由伴隨服務部署的代理Envoy組成，Envoy針對服務完成服務治理的邏輯。這里我們按照Istio的運行機制將每個步驟標上序號，逐個介紹。序號并不表示執行的順序，只是為了方便標注，為的是講解功能。在數據面中的交互通過帶箭頭的實線表示，數據面和控制面的交互通過虛線標注。其資源是通過Kubernetes進行部署的，在Node 1 和Node 2 通過Pod容器部署了服務A和服務B，其中服務B有兩個版本V1 和V2，分別部署在Node 2 的兩個Pod中。通過描述服務A調用服務B不同的版本，以及外部請求訪問服務A的過程給大家講述Istio各個組件的工作流程。

圖6.Istio的控制面和數據面

1.自動注入

由于Istio使用了Sidecar代理的模式，將業務邏輯和服務治理進行了解耦。因此在 Kubernetes場景下創建 Pod時，同時創建Sidecar容器。實際上是注入并創建了istio-proxy和istio-init兩個容器。其中istio-proxy包含了Pilot-agent和Envoy兩個進程。Envoy作為處理服務之間請求流量的進程在服務調用中起到重要的作用，因此在圖4中特別標注出來。

2.服務發現

在注入Envoy以后，假設服務A調用服務B，因此需要通過Envoy向服務B發起請求。服務A如何得知服務B的訪問地址能，就需要通過服務發現的方式完成。此時，Envoy 需要調用管理面組件 Pilot 的服務發現接口，獲取服務B的實例列表。Pilot 直接從運行平臺提取數據并將其轉換成 Istio 的服務發現模型，這種服務發現的方式還支持Kubernetes、Consul等平臺。

3.流量攔截

當服務A得知服務B的地址以后，就會通過服務A向Envoy發送請求流量。發出的流量成為Outbound，在服務B端會接收到這個流量成為Inbound。圖4中從服務A流出的流量(Outbound)會被服務A側的 Envoy攔截，而當流量作為流入的流量(Inbound)到達服務B時，會被服務B側的Envoy攔截。這里攔截的目的是對流量進行控制，特別是在高并發的情況下會對某些服務進行流量的限制。

4.負載均衡

服務A作為請求的發起方，Envoy根據配置的負載均衡策略選擇服務實例，并連接對應的實例地址。這些負載均衡的策略是通過Pilot以配置文件的形式下發到Envoy上實現的，具體策略如RANDOM和ROUND_ROBIN。圖4中訪問服務B，V2版本的時候，發現該版本有多個服務B，此時就需要使用負載均衡策略訪問其中某個服務B了。

5. 流量治理

Envoy 從 Pilot 中獲取配置的流量規則，在攔截到 Inbound 流量和Outbound 流量時執行治理邏輯。和流量攔截不同的是，其目的是為了訪問同一服務的不同版本。服務A通過Envoy獲取規則，通過規則判斷將流量分發到服務B的V1或V2版本。

6. 訪問安全

在服務A和服務B之間建立雙向認證和通道加密，并基于服務的身份進行授權管理。同樣由Pilot下發安全配置，在服務A和服務B對應的Envoy上加載證書和密鑰來實現雙向認證，證書和密鑰由管理面的Citadel組件維護。

7. 服務遙測

在服務間通信時，通信雙方的Envoy會連接管理面的Mixer組件上報訪問數據。例如：監控指標、日志和調用鏈都可以通過這種方式進行收集。

8. 外部訪問

在左下角有個“外部請求訪問”，其作為這個網格之外的請求訪問網格內的服務A。因此在入口處有一個Envoy扮演入口網關的角色。外部服務通過Gateway訪問服務A。如果需要負載均衡以及流量治理的策略，都在這個Gateway的Envoy進行設置。

9. 管理配置

最后是管理面的galley組件。它不面向數據面提供服務，而是在控制面上向其他組件提供支持。主要負責驗證控制面的配置信息格式和內容的正確性，并將配置信息提供給 Pilot和 Mixer組件使用。

Istoio服務治理功能介紹

通過上面Istio架構原理的介紹，把控制面和數據面的組件給大家過了一遍。由于篇幅問題不能在這里逐個展開介紹，由于Istio的主要功能是服務治理，這里選取幾個服務治理中經常使用的功能給大家介紹，也算是窺豹一斑吧。

服務路由

服務路由在實際場景中比較常見，如圖5所示Service A根據不同的路由:Test.com/ServiceB, Test.com/ServiceC, Test.com/ServiceD，分別訪問Service B、C和D。

圖7.服務路由

正如在“Istio架構原理”章節中提到的，Istio配置規則從Pilot發起傳送到Envoy上執行。其配置文件格式基本與Kubernetes相似。具體到圖5的配置文件會使用到VirtualService類型的配置。

VirtualService定義了對特定目標服務的流量規則。它在表示一個虛擬服務，功能是將滿足條件的流量轉發到對應的服務(一個或者多個)。

如代碼段1所示，在Istio的配置文件中，按照紅色數字描述如下：

1. 在kind中定義VirtualService的類型
2. 定義要訪問的入口服務的名稱，這里ServiceA作為入口服務，通過它訪問后面的三個服務。
3. 在hosts中定義主機的url地址作為路由的一部分，因為這里的地址訪問按照“Test.com/ServiceB”的方式進行訪問，因此定義為“Test.com”。
4. 這里針對http請求進行路由，因此在http下面的match(匹配)中的uri中定義prefix，顯然如果要訪問“Test.com/ServiceB”，這里的prefix需要定義為“/ServiceB”。實際上就是具體服務路由的地址。
5. 最后，針對uri地址制定對應的route，在destination(目標)的host中定義服務的名稱：“ServiceB”。ServiceC、D的定義和B的基本一致，不再贅述。

代碼段1

流量切分

上面描述了簡單路由的規則設置，如果遇到需要更具訪問內容進行流量切分的情況，或者需要按照比例切分流量的情況配置文件的內容就需要修改了。如圖6 所示，Service A要訪問Service B的三個不同版本 V1、V2、V3。當URI為”Test.com/status”和”Test.com/data”的時候會請求Service B的V2 和V3版本，導入的流量分別是20%和80%(紅線標注的部分)。其他URI路由到Service B的V1 版本(綠線標注的部分)。

圖8.流量切分

照舊看看配置文件的每個配置項的內容，按照紅色數字描述如下：

1. 在http-match的部分用來匹配URI，這里有兩個prefix 分別是：“data”和“status”，當請求URI滿足這個兩個條件中的一個時進入下面的路由選擇。
2. 在路由選擇route的destination中對應了ServiceB服務的，subset：V2 也就是V2版本。Weight設置是20，意思是20%的流量，流入ServiceB的V2版本。
3. 在路由選擇route的destination中對應了ServiceB服務的，subset：V3 也就是V3版本。Weight設置是80，意思是80%的流量，流入ServiceB的V3版本。
4. 最后，如果在沒有命中上述兩個prefix的情況下，流量會流入ServiceB的V1版本。

代碼段2

負載均衡

負載均衡是服務治理中經常遇到的功能，來看看在Istio中是如何實現的。如圖7 所示，Service A會訪問Service B V2版本的集群以及Service B V1版本的集群。針對同一個服務的兩個不同版本的集群，需要使用兩種不同的負載均衡策略，分別是ROUND_ROBIN和RANDOM。

圖9.負載均衡

在看完負載均衡的需求之后再來看看如何通過配置文件實現它，在介紹配置文件之前先來介紹一下DestinationRule 的規則描述。

如果說VirtualService是一個虛擬Service，其描述的內容是“從服務流出的請求被哪個服務處理”，那么 DestinationRule 描述的是“流入的請求到達服務之后如何處理”，從字面意思理解就是目標規則，如果落到負載均衡的這個例子上來說，也就是流量到達Service B的兩個版本(V1、V2)以后如何進行訪問。

如代碼段3所示，按照紅色數字的順序如下：

1. 規則配置定義為DestinationRule，表示處理服務流入的請求。
2. 這里請求流入的服務是Service B，其從在兩個版本，每個版本都是以集群的方式存在的。
3. 針對Service B 版本V2 的情況，在trafficPolicy(流量規則)的loadBalancer(負載均衡)中使用了ROUND_ROBIN 的策略。
4. 同樣，針對Service B 版本V1 的情況，在trafficPolicy(流量規則)的loadBalancer(負載均衡)中使用了RANDOM 的策略。

代碼段3 上面Istio服務治理的功能介紹，主要圍繞服務之間的關系展開的，通過配置文件中節點數據的調整定義服務之間的關系，獲取這種方式對于開發者理解其工作原理有些抽象，為了方便理清服務之間的關系并且對其進行有效管理，Istio提供了可視化的服務網格工具-Kiali，針對服務拓撲圖、全鏈路跟蹤、指標遙測、配置校驗、健康檢查等功能提供可視化的界面。

這里著重介紹服務拓撲圖的功能，由于篇幅的關系這里不介紹Kiali的安裝，有興趣的同學可以去Istio的官網查看。如圖8 所示，登陸Kiali以后可以看到其Overview界面，其中包括網格里面所有命名空間的服務。

圖10.Kiali overview 界面

如果要查看對應的服務，例如：Bookinfo，可以點擊 Bookinfo 命名空間卡片，顯示如圖9所示的內容。這里展示了該命名空間下服務的調用情況。注意看上方紅色框出的部分：Graph Type，這里可以選擇服務顯示的類型，也就是說通過不同形式展示服務之間的關系。目前有四種可以選擇：App、Versioned App、Workload 以及 Service。

圖11.Bookinfo命名空間下的服務關系圖

選擇 App 類型會將同一應用的所有版本聚合到單點上，如圖10所示，網格外部的請求通過istio-ingressgateway調用productpage服務，productpage分別會調用details服務和reviews服務。其中reviews會依次調用ratings服務和mongedb。App類型的服務關系展示，通過簡潔的方式描述了服務之間的依賴(調用)關系，沒有涉及到服務的具體版本。

圖12.App 類型調用

Versioned App 類型會在App類型的基礎上，將每個服務的版本顯示出來。如圖11 所示，可以看出productpage服務只有一個版本v1，但是reviews服務有v1、v2、v3三個版本，ratings有兩個版本。這種方式的現實讓服務調用的版本更加清晰。

圖13.Versioned App 類型

Workload 類型又在Versioned App 類型的基礎上，針對每個服務的workload進行了顯示上的轉換。如圖12 所示，將每個服務的版本作為一個workload，通過圓形的方式顯示，實際上每個圓形的workload在實際調用中也是一個實體。

圖14.Workload 類型

最后是Service 類型，如圖13所示，它為網格中的每個服務生成一個節點，但是會排除所有的應用和工作負載。

圖15.Service 類型

總結

本文從服務治理作為切入點，描述了在分布式、微服務的環境下為什么需要Istio提供服務治理的功能。Istio能夠將業務邏輯與服務治理的SDK進行解耦，能夠支持不同技術開發的分布式服務/應用的服務治理。同時指出Istio是包含的連接(Connect)、安全(Secure)、控制(Control)和觀察(Observe)等功能。以及在這些功能的支撐下，Istio的基本架構是如何工作的。在架構原理中通過九個步驟，將控制面的Pilot、Mixer、Galley和Citadel，以及數據面的Envoy的工作流程給大家梳理了一遍。最后針對使用頻度較高的服務治理功能：服務路由、流量切分、負載均衡進行了展開描述。