[[376673]]

本文轉(zhuǎn)載自微信公眾號(hào)「石杉的架構(gòu)筆記」，作者崔皓 。轉(zhuǎn)載本文請(qǐng)聯(lián)系石杉的架構(gòu)筆記公眾號(hào)。 

開篇

在云環(huán)境下，技術(shù)?？芍^是多種多樣，通過不同的技術(shù)生成不同的應(yīng)用。如何能將這些異構(gòu)的服務(wù)或者應(yīng)用有機(jī)地串聯(lián)起來，成為了服務(wù)治理的重大課題，在這樣的大背景下Istio架構(gòu)為這樣應(yīng)用場景提供了服務(wù)治理的功能，Istio提供的流量治理、策略、遙測、訪問安全等功能至今都被人津津樂道。

今天就圍繞Istio架構(gòu)的實(shí)現(xiàn)原理為大家介紹如下內(nèi)容：

• 為什么選擇Istio
• 什么是Istio
• Istio架構(gòu)原理
• Istio服務(wù)治理功能介紹

為什么選擇Istio

隨著業(yè)務(wù)的復(fù)雜度提高，為了應(yīng)對(duì)高并發(fā)、大流量，系統(tǒng)架構(gòu)對(duì)服務(wù)/應(yīng)用進(jìn)行拆分。拆分以后的服務(wù)/應(yīng)用可以進(jìn)行分布式部署，來應(yīng)對(duì)高并發(fā)帶來的系統(tǒng)壓力以及處理復(fù)雜的業(yè)務(wù)邏輯。

這樣的做法會(huì)造成系統(tǒng)中存在大量獨(dú)立的服務(wù)或者應(yīng)用，它們分布在不同的進(jìn)程、主機(jī)上面，在它們之間互相調(diào)用的時(shí)候就存在服務(wù)治理的問題。微服務(wù)就是一個(gè)典型的例子，微服務(wù)的開發(fā)和運(yùn)維對(duì)程序員來說是一個(gè)挑戰(zhàn)。

分而治之的思想使得業(yè)務(wù)本身的規(guī)模和復(fù)雜度不降反增。

在分布式系統(tǒng)中，網(wǎng)絡(luò)可靠性、通信安全、網(wǎng)絡(luò)時(shí)延、網(wǎng)絡(luò)拓?fù)渥兓榷汲闪岁P(guān)注的焦點(diǎn)，同時(shí)服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、服務(wù)間通訊、分布式調(diào)用鏈追蹤都是要解決的問題。

為了解決這個(gè)問題，把服務(wù)治理部分抽象成公共庫，讓所有微服務(wù)都使用這個(gè)公共庫。如圖1所示，在Node 1 和 Node 2 上分別用Service 1 和Service 2兩個(gè)服務(wù)，它們分別針對(duì)自己的業(yè)務(wù)邏輯都有對(duì)應(yīng)的服務(wù)治理的SDK，通過這個(gè)SDK完成服務(wù)治理的服務(wù)發(fā)現(xiàn)、服務(wù)注冊(cè)等功能。

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

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

圖2.Sidecar解耦業(yè)務(wù)邏輯和服務(wù)治理

Sidecar的模式使兩者代碼和運(yùn)行無耦合。如圖3所示，業(yè)務(wù)邏輯就好像綠色的方塊，再其右邊的藍(lán)色方塊就是Istio提供的Sidecar(邊車)，也就是通過這個(gè)Sidecar與網(wǎng)絡(luò)中其他服務(wù)的Sidecar進(jìn)行鏈接，從而實(shí)現(xiàn)服務(wù)之間的通信。

這樣業(yè)務(wù)邏輯可以使用不同的語言進(jìn)行開發(fā)，升級(jí)也相互獨(dú)立，而其他的服務(wù)治理的工作，例如：服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、通訊等都由Sidecar來完成。

圖3.Istio的Sidecar模式

這里通過業(yè)務(wù)邏輯與服務(wù)治理的角度，將使用Istio之前和之后的微服務(wù)做區(qū)分，從以下三個(gè)維度進(jìn)行對(duì)比。

因此在使用Istio架構(gòu)以后，會(huì)將業(yè)務(wù)邏輯與服務(wù)治理在運(yùn)行進(jìn)程、技術(shù)棧和服務(wù)升級(jí)三個(gè)方面進(jìn)行完全解耦，通過Sidecar模式打造分布式系統(tǒng)的最佳實(shí)踐，接下來就來看看Istio包括哪些內(nèi)容。

什么是Istio

眾所周知Istio是一個(gè)Service Mesh形態(tài)的，用于服務(wù)治理的開放平臺(tái)。這里的服務(wù)“治理”不僅限于“微服務(wù)”，可以推廣到任何服務(wù)。只要存在服務(wù)或者應(yīng)用，在它們之間存在訪問，也存在對(duì)服務(wù)與應(yīng)用的管理，都可以使用到 Istio。

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

圖4.Istio 官方功能介紹

將上面四項(xiàng)功能總結(jié)如下：

• 連接：通過流量規(guī)則控制服務(wù)間的流量和調(diào)用，實(shí)現(xiàn)負(fù)載均衡、熔斷、故障注入、重試、重定向等功能。
• 安全：提供認(rèn)證機(jī)制、通道加密、服務(wù)訪問授權(quán)等安全能力，增強(qiáng)訪問的安全性。
• 控制：通過可動(dòng)態(tài)插拔、可擴(kuò)展的策略實(shí)現(xiàn)訪問控制、速率限制、配額管理、服務(wù)計(jì)費(fèi)等能力。
• 觀察：獲取服務(wù)運(yùn)行數(shù)據(jù)和輸出，提供調(diào)用鏈監(jiān)控和日志收集能力。

在微服務(wù)時(shí)代，Kubernetes提供了服務(wù)的部署、升級(jí)、擴(kuò)容等運(yùn)行管理能力，但在服務(wù)治理方面，如服務(wù)的熔斷、限流、動(dòng)態(tài)路由、調(diào)用鏈追蹤顯得能力不足。

Istio作為服務(wù)治理的架構(gòu)剛好在這一點(diǎn)上彌補(bǔ)了Kubernetes的不足，成為了Kubernetes的好搭檔。

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

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

圖5.Istio 針對(duì)服務(wù)治理的功能

Istio架構(gòu)原理

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

圖6.Istio的控制面和數(shù)據(jù)面

1.自動(dòng)注入

由于Istio使用了Sidecar代理的模式，將業(yè)務(wù)邏輯和服務(wù)治理進(jìn)行了解耦。因此在 Kubernetes場景下創(chuàng)建 Pod時(shí)，同時(shí)創(chuàng)建Sidecar容器。實(shí)際上是注入并創(chuàng)建了istio-proxy和istio-init兩個(gè)容器。其中istio-proxy包含了Pilot-agent和Envoy兩個(gè)進(jìn)程。Envoy作為處理服務(wù)之間請(qǐng)求流量的進(jìn)程在服務(wù)調(diào)用中起到重要的作用，因此在圖4中特別標(biāo)注出來。

2.服務(wù)發(fā)現(xiàn)

在注入Envoy以后，假設(shè)服務(wù)A調(diào)用服務(wù)B，因此需要通過Envoy向服務(wù)B發(fā)起請(qǐng)求。服務(wù)A如何得知服務(wù)B的訪問地址能，就需要通過服務(wù)發(fā)現(xiàn)的方式完成。此時(shí)，Envoy 需要調(diào)用管理面組件 Pilot 的服務(wù)發(fā)現(xiàn)接口，獲取服務(wù)B的實(shí)例列表。Pilot 直接從運(yùn)行平臺(tái)提取數(shù)據(jù)并將其轉(zhuǎn)換成 Istio 的服務(wù)發(fā)現(xiàn)模型，這種服務(wù)發(fā)現(xiàn)的方式還支持Kubernetes、Consul等平臺(tái)。

3.流量攔截

當(dāng)服務(wù)A得知服務(wù)B的地址以后，就會(huì)通過服務(wù)A向Envoy發(fā)送請(qǐng)求流量。發(fā)出的流量成為Outbound，在服務(wù)B端會(huì)接收到這個(gè)流量成為Inbound。圖4中從服務(wù)A流出的流量(Outbound)會(huì)被服務(wù)A側(cè)的 Envoy攔截，而當(dāng)流量作為流入的流量(Inbound)到達(dá)服務(wù)B時(shí)，會(huì)被服務(wù)B側(cè)的Envoy攔截。這里攔截的目的是對(duì)流量進(jìn)行控制，特別是在高并發(fā)的情況下會(huì)對(duì)某些服務(wù)進(jìn)行流量的限制。

4.負(fù)載均衡

服務(wù)A作為請(qǐng)求的發(fā)起方，Envoy根據(jù)配置的負(fù)載均衡策略選擇服務(wù)實(shí)例，并連接對(duì)應(yīng)的實(shí)例地址。這些負(fù)載均衡的策略是通過Pilot以配置文件的形式下發(fā)到Envoy上實(shí)現(xiàn)的，具體策略如RANDOM和ROUND_ROBIN。圖4中訪問服務(wù)B，V2版本的時(shí)候，發(fā)現(xiàn)該版本有多個(gè)服務(wù)B，此時(shí)就需要使用負(fù)載均衡策略訪問其中某個(gè)服務(wù)B了。

5. 流量治理

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

6. 訪問安全

在服務(wù)A和服務(wù)B之間建立雙向認(rèn)證和通道加密，并基于服務(wù)的身份進(jìn)行授權(quán)管理。同樣由Pilot下發(fā)安全配置，在服務(wù)A和服務(wù)B對(duì)應(yīng)的Envoy上加載證書和密鑰來實(shí)現(xiàn)雙向認(rèn)證，證書和密鑰由管理面的Citadel組件維護(hù)。

7. 服務(wù)遙測

在服務(wù)間通信時(shí)，通信雙方的Envoy會(huì)連接管理面的Mixer組件上報(bào)訪問數(shù)據(jù)。例如：監(jiān)控指標(biāo)、日志和調(diào)用鏈都可以通過這種方式進(jìn)行收集。

8. 外部訪問

在左下角有個(gè)“外部請(qǐng)求訪問”，其作為這個(gè)網(wǎng)格之外的請(qǐng)求訪問網(wǎng)格內(nèi)的服務(wù)A。因此在入口處有一個(gè)Envoy扮演入口網(wǎng)關(guān)的角色。外部服務(wù)通過Gateway訪問服務(wù)A。如果需要負(fù)載均衡以及流量治理的策略，都在這個(gè)Gateway的Envoy進(jìn)行設(shè)置。

9. 管理配置

最后是管理面的galley組件。它不面向數(shù)據(jù)面提供服務(wù)，而是在控制面上向其他組件提供支持。主要負(fù)責(zé)驗(yàn)證控制面的配置信息格式和內(nèi)容的正確性，并將配置信息提供給 Pilot和 Mixer組件使用。

Istoio服務(wù)治理功能介紹

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

服務(wù)路由

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

圖7.服務(wù)路由

正如在“Istio架構(gòu)原理”章節(jié)中提到的，Istio配置規(guī)則從Pilot發(fā)起傳送到Envoy上執(zhí)行。其配置文件格式基本與Kubernetes相似。具體到圖5的配置文件會(huì)使用到VirtualService類型的配置。

VirtualService定義了對(duì)特定目標(biāo)服務(wù)的流量規(guī)則。它在表示一個(gè)虛擬服務(wù)，功能是將滿足條件的流量轉(zhuǎn)發(fā)到對(duì)應(yīng)的服務(wù)(一個(gè)或者多個(gè))。

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

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

代碼段1

流量切分

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

圖8.流量切分

照舊看看配置文件的每個(gè)配置項(xiàng)的內(nèi)容，按照紅色數(shù)字描述如下：

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

代碼段2

負(fù)載均衡

負(fù)載均衡是服務(wù)治理中經(jīng)常遇到的功能，來看看在Istio中是如何實(shí)現(xiàn)的。如圖7 所示，Service A會(huì)訪問Service B V2版本的集群以及Service B V1版本的集群。針對(duì)同一個(gè)服務(wù)的兩個(gè)不同版本的集群，需要使用兩種不同的負(fù)載均衡策略，分別是ROUND_ROBIN和RANDOM。

圖9.負(fù)載均衡

在看完負(fù)載均衡的需求之后再來看看如何通過配置文件實(shí)現(xiàn)它，在介紹配置文件之前先來介紹一下DestinationRule 的規(guī)則描述。

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

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

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

代碼段3 上面Istio服務(wù)治理的功能介紹，主要圍繞服務(wù)之間的關(guān)系展開的，通過配置文件中節(jié)點(diǎn)數(shù)據(jù)的調(diào)整定義服務(wù)之間的關(guān)系，獲取這種方式對(duì)于開發(fā)者理解其工作原理有些抽象，為了方便理清服務(wù)之間的關(guān)系并且對(duì)其進(jìn)行有效管理，Istio提供了可視化的服務(wù)網(wǎng)格工具-Kiali，針對(duì)服務(wù)拓?fù)鋱D、全鏈路跟蹤、指標(biāo)遙測、配置校驗(yàn)、健康檢查等功能提供可視化的界面。

這里著重介紹服務(wù)拓?fù)鋱D的功能，由于篇幅的關(guān)系這里不介紹Kiali的安裝，有興趣的同學(xué)可以去Istio的官網(wǎng)查看。如圖8 所示，登陸Kiali以后可以看到其Overview界面，其中包括網(wǎng)格里面所有命名空間的服務(wù)。

圖10.Kiali overview 界面

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

圖11.Bookinfo命名空間下的服務(wù)關(guān)系圖

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

圖12.App 類型調(diào)用

Versioned App 類型會(huì)在App類型的基礎(chǔ)上，將每個(gè)服務(wù)的版本顯示出來。如圖11 所示，可以看出productpage服務(wù)只有一個(gè)版本v1，但是reviews服務(wù)有v1、v2、v3三個(gè)版本，ratings有兩個(gè)版本。這種方式的現(xiàn)實(shí)讓服務(wù)調(diào)用的版本更加清晰。

圖13.Versioned App 類型

Workload 類型又在Versioned App 類型的基礎(chǔ)上，針對(duì)每個(gè)服務(wù)的workload進(jìn)行了顯示上的轉(zhuǎn)換。如圖12 所示，將每個(gè)服務(wù)的版本作為一個(gè)workload，通過圓形的方式顯示，實(shí)際上每個(gè)圓形的workload在實(shí)際調(diào)用中也是一個(gè)實(shí)體。

圖14.Workload 類型

最后是Service 類型，如圖13所示，它為網(wǎng)格中的每個(gè)服務(wù)生成一個(gè)節(jié)點(diǎn)，但是會(huì)排除所有的應(yīng)用和工作負(fù)載。

圖15.Service 類型

總結(jié)

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