[[413394]]

現(xiàn)在最火的后端架構(gòu)無(wú)疑是微服務(wù)了，微服務(wù)將之前的單體應(yīng)用拆分成了許多獨(dú)立的服務(wù)應(yīng)用，每個(gè)微服務(wù)都是獨(dú)立的，好處自然很多，但是隨著應(yīng)用的越來(lái)越大，微服務(wù)暴露出來(lái)的問(wèn)題也就隨之而來(lái)了，微服務(wù)越來(lái)越多，管理越來(lái)越麻煩，特別是要你部署一套新環(huán)境的時(shí)候，你就能體會(huì)到這種痛苦了，隨之而來(lái)的服務(wù)發(fā)現(xiàn)、負(fù)載均衡、Trace跟蹤、流量管理、安全認(rèn)證等等問(wèn)題。如果從頭到尾完成過(guò)一套微服務(wù)框架的話，你就會(huì)知道這里面涉及到的東西真的非常多。當(dāng)然隨著微服務(wù)的不斷發(fā)展，微服務(wù)的生態(tài)也不斷完善，最近新一代的微服務(wù)開(kāi)發(fā)就悄然興起了，那就是服務(wù)網(wǎng)格/Service Mesh。

什么是Service Mesh?

Service Mesh 是一個(gè)非常新的名詞，最早是2016年由開(kāi)發(fā) Linkerd 的 Buoyant 公司提出的，伴隨著 Linkerd 的傳入， Service Mesh 的概念也慢慢進(jìn)入國(guó)內(nèi)技術(shù)社區(qū)，現(xiàn)在主流的叫法都叫：服務(wù)網(wǎng)格。

• 服務(wù)網(wǎng)格是一個(gè)用于處理服務(wù)間通信的基礎(chǔ)設(shè)施層，它負(fù)責(zé)為構(gòu)建復(fù)雜的云原生應(yīng)用傳遞可靠的網(wǎng)絡(luò)請(qǐng)求。在實(shí)踐中，服務(wù)網(wǎng)格通常實(shí)現(xiàn)為一組和應(yīng)用程序部署在一起的輕量級(jí)的網(wǎng)絡(luò)代理，但對(duì)應(yīng)用程序來(lái)說(shuō)是透明的。

要理解網(wǎng)格的概念，就得從服務(wù)的部署模型說(shuō)起：

單個(gè)服務(wù)調(diào)用，表現(xiàn)為sidecar

單個(gè)服務(wù)調(diào)用

Service Mesh 的部署模型，先看單個(gè)的，對(duì)于一個(gè)簡(jiǎn)單請(qǐng)求，作為請(qǐng)求發(fā)起者的客戶端應(yīng)用實(shí)例，會(huì)首先用簡(jiǎn)單方式將請(qǐng)求發(fā)送到本地的 Service Mesh 實(shí)例。這是兩個(gè)獨(dú)立進(jìn)程，他們之間是遠(yuǎn)程調(diào)用。

Service Mesh 會(huì)完成完整的服務(wù)間調(diào)用流程，如服務(wù)發(fā)現(xiàn)負(fù)載均衡，最后將請(qǐng)求發(fā)送給目標(biāo)服務(wù)，這表現(xiàn)為 Sidecar 方式。

部署多個(gè)服務(wù)，表現(xiàn)為通訊層

多個(gè)服務(wù)調(diào)用

多個(gè)服務(wù)調(diào)用的情況，在這個(gè)圖上我們可以看到 Service Mesh 在所有的服務(wù)的下面，這一層被稱之為服務(wù)間通訊專用基礎(chǔ)設(shè)施層。Service Mesh 會(huì)接管整個(gè)網(wǎng)絡(luò)，把所有的請(qǐng)求在服務(wù)之間做轉(zhuǎn)發(fā)。在這種情況下，我們會(huì)看到上面的服務(wù)不再負(fù)責(zé)傳遞請(qǐng)求的具體邏輯，只負(fù)責(zé)完成業(yè)務(wù)處理。服務(wù)間通訊的環(huán)節(jié)就從應(yīng)用里面剝離出來(lái)，呈現(xiàn)出一個(gè)抽象層。

有大量服務(wù)，表現(xiàn)為網(wǎng)絡(luò)

大量服務(wù)調(diào)用

如果有大量的服務(wù)，就會(huì)表現(xiàn)出來(lái)網(wǎng)格，圖中左邊綠色方格是應(yīng)用，右邊藍(lán)色的方框是 Service Mesh，藍(lán)色之間的線條是表示服務(wù)之間的調(diào)用關(guān)系。Sidecar 之間的連接就會(huì)形成一個(gè)網(wǎng)絡(luò)，這個(gè)就是服務(wù)網(wǎng)格名字的由來(lái)，這個(gè)時(shí)候代理體現(xiàn)出來(lái)的就和前面的 Sidecar 不一樣了，形成網(wǎng)狀。

首先第一個(gè)，服務(wù)網(wǎng)格是抽象的，實(shí)際上是抽象出了一個(gè)基礎(chǔ)設(shè)施層，在應(yīng)用之外。其次，功能是實(shí)現(xiàn)請(qǐng)求的可靠傳遞。部署上體現(xiàn)為輕量級(jí)的網(wǎng)絡(luò)代理。最后一個(gè)關(guān)鍵詞是，對(duì)應(yīng)用程序透明。

Service mesh

大家注意看，上面的圖中，網(wǎng)絡(luò)在這種情況下，可能不是特別明顯。但是如果把左邊的應(yīng)用程序去掉，現(xiàn)在只呈現(xiàn)出來(lái) Service Mesh 和他們之間的調(diào)用，這個(gè)時(shí)候關(guān)系就會(huì)特別清晰，就是一個(gè)完整的網(wǎng)絡(luò)。這是 Service Mesh 定義當(dāng)中一個(gè)非常重要的關(guān)鍵點(diǎn)，和 Sidecar 不相同的地方：不再將代理視為單獨(dú)的組件，而是強(qiáng)調(diào)由這些代理連接而形成的網(wǎng)絡(luò)。在 Service Mesh 里面非常強(qiáng)調(diào)代理連接組成的網(wǎng)絡(luò)，而不像 Sidecar 那樣看待個(gè)體。

現(xiàn)在我們基本上把 Service Mesh 的定義介紹清楚了，大家應(yīng)該可以大概了解什么是 Service Mesh 了?，F(xiàn)在實(shí)現(xiàn) Service Mesh 的開(kāi)源方案有很多，比如 Linkerd、Istio 等，當(dāng)然目前最流行最火熱的還是要數(shù) Istio 了，記下來(lái)我們就來(lái)開(kāi)始講解 Istio 的使用。

什么是Istio?

Istio 解決了開(kāi)發(fā)人員和運(yùn)維在分布式或微服務(wù)架構(gòu)方面面臨的挑戰(zhàn)，無(wú)論是從頭開(kāi)始構(gòu)建還是將現(xiàn)有應(yīng)用程序遷移到云原生環(huán)境下，Istio 都可以提供幫助。

通過(guò)在部署的每個(gè)應(yīng)用程序中添加代理 sidecar，Istio 允許您將應(yīng)用程序感知流量管理、令人難以置信的可觀察性和強(qiáng)大的安全功能編程到您的網(wǎng)絡(luò)中。

Istio

Istio 是一個(gè)開(kāi)源服務(wù)網(wǎng)格，它透明地分層到現(xiàn)有的分布式應(yīng)用程序上。Istio 強(qiáng)大的特性提供了一種統(tǒng)一和更有效的方式來(lái)保護(hù)、連接和監(jiān)視服務(wù)。Istio 是實(shí)現(xiàn)負(fù)載平衡、服務(wù)到服務(wù)身份驗(yàn)證和監(jiān)視的路徑——只需要很少或不需要更改服務(wù)代碼。它強(qiáng)大的控制平面帶來(lái)了重要的特點(diǎn)，包括：

• 使用 TLS 加密、強(qiáng)身份認(rèn)證和授權(quán)的集群內(nèi)服務(wù)到服務(wù)的安全通信
• 自動(dòng)負(fù)載均衡的 HTTP, gRPC, WebSocket，和 TCP 流量
• 通過(guò)豐富的路由規(guī)則、重試、故障轉(zhuǎn)移和故障注入對(duì)流量行為進(jìn)行細(xì)粒度控制
• 一個(gè)可插入的策略層和配置 API，支持訪問(wèn)控制、速率限制和配額
• 對(duì)集群內(nèi)的所有流量(包括集群入口和出口)進(jìn)行自動(dòng)度量、日志和跟蹤

Istio 是為可擴(kuò)展性而設(shè)計(jì)的，可以處理不同范圍的部署需求。Istio 的控制平面運(yùn)行在 Kubernetes 上，您可以將部署在該集群中的應(yīng)用程序添加到您的網(wǎng)格中，將網(wǎng)格擴(kuò)展到其他集群，甚至連接 VM 或運(yùn)行在 Kubernetes 之外的其他端點(diǎn)。

架構(gòu)

Istio 有兩個(gè)組成部分：數(shù)據(jù)平面和控制平面。

數(shù)據(jù)平面由一組智能代理(Envoy)組成，被部署為 Sidecar。這些代理負(fù)責(zé)協(xié)調(diào)和控制微服務(wù)之間的所有網(wǎng)絡(luò)通信。它們還收集和報(bào)告所有網(wǎng)格流量的遙測(cè)數(shù)據(jù)。

服務(wù)網(wǎng)格使用代理攔截所有的網(wǎng)絡(luò)流量，允許根據(jù)您設(shè)置的配置提供廣泛的應(yīng)用程序感知功能。代理與您在集群中啟動(dòng)的每個(gè)服務(wù)一起部署，或者與運(yùn)行在虛擬機(jī)上的服務(wù)一起運(yùn)行。

控制平面管理并配置代理來(lái)進(jìn)行流量路由。

在使用 Istio 之前服務(wù)與服務(wù)之間通信如下圖所示：

使用 Istio 之前

使用 Istio 之后服務(wù)與服務(wù)之間通信則通過(guò) Envoy 代理進(jìn)行：

使用 Istio 之后

下圖則是 Istio 每個(gè)平面的不同組件的架構(gòu)：

Istio 架構(gòu)

Envoy

Istio 默認(rèn)使用 Envoy 代理的擴(kuò)展版本，Envoy 是用 C++ 開(kāi)發(fā)的高性能代理，用于協(xié)調(diào)服務(wù)網(wǎng)格中所有服務(wù)的入站和出站流量。Envoy 代理是唯一與數(shù)據(jù)平面流量交互的 Istio 組件。

Envoy 代理被部署為服務(wù)的 Sidecar，在邏輯上為服務(wù)增加了 Envoy 的許多內(nèi)置特性，例如：

• 動(dòng)態(tài)服務(wù)發(fā)現(xiàn)
• 負(fù)載均衡
• TLS 校驗(yàn)
• HTTP/2 與 gRPC 代理
• 熔斷器
• 健康檢查
• 基于百分比流量分割的分階段發(fā)布
• 故障注入
• 豐富的指標(biāo)

這種 Sidecar 部署允許 Istio 可以執(zhí)行策略決策，并提取豐富的遙測(cè)數(shù)據(jù)，接著將這些數(shù)據(jù)發(fā)送到監(jiān)視系統(tǒng)以提供有關(guān)整個(gè)網(wǎng)格行為的信息。

Sidecar 代理模型還允許你向現(xiàn)有的應(yīng)用添加 Istio 功能，而不需要重新設(shè)計(jì)架構(gòu)或重寫(xiě)代碼。

由 Envoy 代理啟用的一些 Istio 的功能和任務(wù)包括：

• 流量控制功能：通過(guò)豐富的 HTTP、gRPC、WebSocket 和 TCP 流量路由規(guī)則來(lái)執(zhí)行細(xì)粒度的流量控制。
• 網(wǎng)絡(luò)彈性特性：重試設(shè)置、故障轉(zhuǎn)移、熔斷器和故障注入。
• 安全性和身份認(rèn)證特性：執(zhí)行安全性策略，并強(qiáng)制實(shí)行通過(guò)配置 API 定義的訪問(wèn)控制和速率限制。
• 基于 WebAssembly 的可插拔擴(kuò)展模型，允許通過(guò)自定義策略執(zhí)行和生成網(wǎng)格流量的遙測(cè)。

Istiod

組件 Istiod 提供服務(wù)發(fā)現(xiàn)、配置和證書(shū)管理。

Istiod 將控制流量行為的高級(jí)路由規(guī)則轉(zhuǎn)換為 Envoy 特定的配置，并在運(yùn)行時(shí)將其傳播給 Sidecar。Pilot 提取了特定平臺(tái)的服務(wù)發(fā)現(xiàn)機(jī)制，并將其配置為一種標(biāo)準(zhǔn)格式，任何符合 Envoy API 的 Sidecar 都可以使用。

Istio 可以支持發(fā)現(xiàn)多種環(huán)境，如 Kubernetes 或 VM。

你可以使用 Istio 流量管理 API 讓 Istiod 重新構(gòu)造 Envoy 的配置，以便對(duì)服務(wù)網(wǎng)格中的流量進(jìn)行更精細(xì)的控制。

Istiod 通過(guò)內(nèi)置的身份和憑證管理進(jìn)行安全管理，你可以使用 Istio 來(lái)升級(jí)服務(wù)網(wǎng)格中未加密的流量，可以使用 Istio 的授權(quán)功能控制誰(shuí)可以訪問(wèn)你的服務(wù)。

Istiod 充當(dāng)證書(shū)授權(quán)(CA)，并生成證書(shū)以允許在數(shù)據(jù)平面中進(jìn)行安全的 mTLS 通信。

安裝

接下來(lái)我們將介紹如何在 Kubernetes 集群中安裝 Istio，這里我們使用的是最新的 1.10.3 版本。

下面的命令可以下載指定的 1.10.3 版本的 Istio：

➜  ~ curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.10.3 sh - 

如果安裝失敗，可以用手動(dòng)方式進(jìn)行安裝，在 GitHub Release 頁(yè)面獲取對(duì)應(yīng)系統(tǒng)的下載地址：

# 注意選擇和自己操作系統(tǒng)匹配的文件 
➜  ~ wget https://github.com/istio/istio/releases/download/1.10.3/istio-1.10.3-linux-amd64.tar.gz 
➜  ~ tar -xzf istioctl-1.10.3-linux-amd64.tar.gz 
# 進(jìn)入到 istio 解壓的目錄 
➜  ~ cd istio-1.10.3 && ls -la 
total 48 
drwxr-x---@   9 ych  staff    288 Jul 15 13:32 . 
drwx---r-x@ 482 ych  staff  15424 Jul 20 14:17 .. 
-rw-r--r--@   1 ych  staff  11348 Jul 15 13:32 LICENSE 
-rw-r--r--@   1 ych  staff   5866 Jul 15 13:32 README.md 
drwxr-x---@   3 ych  staff     96 Jul 15 13:32 bin 
-rw-r-----@   1 ych  staff    854 Jul 15 13:32 manifest.yaml 
drwxr-xr-x@   5 ych  staff    160 Jul 15 13:32 manifests 
drwxr-xr-x@  21 ych  staff    672 Jul 15 13:32 samples 
drwxr-xr-x@   5 ych  staff    160 Jul 15 13:32 tools 

其中 samples/ 目錄下面是一些示例應(yīng)用程序，bin/ 目錄下面的 istioctl 是 Istio 的 CLI 工具，可以將該 bin/ 目錄加入到 PATH 路徑之下，也可以直接拷貝到某個(gè) PATH 目錄下去：

➜  ~ cp bin/istioctl /usr/local/bin/istioctl 
➜  ~ istioctl version 
no running Istio pods in "istio-system" 
1.10.3 

安裝 istio 的工具和文件準(zhǔn)備好過(guò)后，直接執(zhí)行如下所示的安裝命令即可，這里我們采用的是 demo 配置組合的形式，這是因?yàn)樗艘唤M專為測(cè)試準(zhǔn)備的功能集合，另外還有用于生產(chǎn)或性能測(cè)試的配置組合。

➜  ~ istioctl install --set profile=demo -y 
Detected that your cluster does not support third party JWT authentication. Falling back to less secure first party JWT. See https://istio.io/v1.10/docs/ops/best-practices/security/#configure-third-party-service-account-tokens for details. 
! values.global.jwtPolicy is deprecated; use Values.global.jwtPolicy=third-party-jwt. See http://istio.io/latest/docs/ops/best-practices/security/#configure-third-party-service-account-tokens for more information instead 
✔ Istio core installed 
✔ Istiod installed 
✔ Ingress gateways installed 
✔ Egress gateways installed 
✔ Installation complete 

安裝完成后我們可以查看 istio-system 命名空間下面的 Pod 運(yùn)行狀態(tài)：

➜  ~ kubectl get pods -n istio-system 
NAME                                    READY   STATUS    RESTARTS   AGE 
istio-egressgateway-5c8d96c9b5-6d5g9    1/1     Running   0          4m6s 
istio-ingressgateway-6bcfd457f9-wpj7w   1/1     Running   0          4m6s 
istiod-775bcf58f7-v6jl2                 1/1     Running   0          5m4s 

如果都是 Running 狀態(tài)證明 istio 就已經(jīng)安裝成功了。然后我們還可以給 namespace 添加一個(gè) isito-injection=enabled 的 label 標(biāo)簽，指示 Istio 在部署應(yīng)用的時(shí)候，可以自動(dòng)注入 Envoy Sidecar 代理，比如這里我們給 default 命名空間注入自動(dòng)標(biāo)簽：

➜  ~ kubectl label namespace default istio-injection=enabled 
namespace/default labeled 

部署示例應(yīng)用

然后我們可以來(lái)安裝官方提供的一個(gè)非常經(jīng)典的 Bookinfo 應(yīng)用示例，這個(gè)示例部署了一個(gè)用于演示多種 Istio 特性的應(yīng)用，該應(yīng)用由四個(gè)單獨(dú)的微服務(wù)構(gòu)成，這個(gè)應(yīng)用模仿在線書(shū)店的一個(gè)分類，顯示一本書(shū)的信息。頁(yè)面上會(huì)顯示一本書(shū)的描述、書(shū)籍的 ISBN、頁(yè)數(shù)等信息，以及關(guān)于這本書(shū)的一些評(píng)論。

Bookinfo 應(yīng)用分為四個(gè)單獨(dú)的微服務(wù)：

• productpage：這個(gè)微服務(wù)會(huì)調(diào)用 details 和 reviews 兩個(gè)微服務(wù)，用來(lái)生成頁(yè)面。
• details：這個(gè)微服務(wù)中包含了書(shū)籍的信息。
• reviews：這個(gè)微服務(wù)中包含了書(shū)籍相關(guān)的評(píng)論，它還會(huì)調(diào)用 ratings 微服務(wù)。
• ratings：這個(gè)微服務(wù)中包含了由書(shū)籍評(píng)價(jià)組成的評(píng)級(jí)信息。

reviews 微服務(wù)有 3 個(gè)版本：

• v1 版本不會(huì)調(diào)用 ratings 服務(wù)。
• v2 版本會(huì)調(diào)用 ratings 服務(wù)，并使用 1 到 5 個(gè)黑色星形圖標(biāo)來(lái)顯示評(píng)分信息。
• v3 版本會(huì)調(diào)用 ratings 服務(wù)，并使用 1 到 5 個(gè)紅色星形圖標(biāo)來(lái)顯示評(píng)分信息。

下圖可以用來(lái)說(shuō)明我們這個(gè)示例應(yīng)用的整體架構(gòu):

沒(méi)有使用 Istio 之前的架構(gòu)

Bookinfo 應(yīng)用中的幾個(gè)微服務(wù)是由不同的語(yǔ)言編寫(xiě)而成的，這些服務(wù)對(duì) Istio 并無(wú)依賴，但是構(gòu)成了一個(gè)有代表性的服務(wù)網(wǎng)格的例子：它由多個(gè)服務(wù)、多個(gè)語(yǔ)言構(gòu)成，并且 reviews 服務(wù)具有多個(gè)版本。

我們要在 Istio 中運(yùn)行這個(gè)應(yīng)用，不需要對(duì)應(yīng)用本身做任何改變，只要簡(jiǎn)單的在 Istio 環(huán)境中對(duì)服務(wù)進(jìn)行配置和運(yùn)行，也就是把 Envoy sidecar 注入到每個(gè)服務(wù)之中。最終的部署結(jié)果將如下圖所示：

istio bookinfo

所有的微服務(wù)都和 Envoy sidecar 集成在一起，被集成服務(wù)所有的出入流量都被 sidecar 所劫持，這樣就為外部控制準(zhǔn)備了所需的 Hook，然后就可以利用 Istio 控制平面為應(yīng)用提供服務(wù)路由、遙測(cè)數(shù)據(jù)收集以及策略實(shí)施等功能。

進(jìn)入上面的 Istio 安裝目錄，執(zhí)行如下命令：

➜  ~ kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml 
service/details created 
serviceaccount/bookinfo-details created 
deployment.apps/details-v1 created 
service/ratings created 
serviceaccount/bookinfo-ratings created 
deployment.apps/ratings-v1 created 
service/reviews created 
serviceaccount/bookinfo-reviews created 
deployment.apps/reviews-v1 created 
deployment.apps/reviews-v2 created 
deployment.apps/reviews-v3 created 
service/productpage created 
serviceaccount/bookinfo-productpage created 
deployment.apps/productpage-v1 created 

如果在安裝過(guò)程中禁用了 Sidecar 自動(dòng)注入功能而選擇手動(dòng)注入 Sidecar，請(qǐng)?jiān)诓渴饝?yīng)用之前可以使用 istioctl kube-inject 命令來(lái)注入 sidecar 容器。

➜  ~ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo.yaml) 

這里我們部署的 bookinfo.yaml 資源清單文件就是普通的 Kubernetes 的 Deployment 和 Service 的 yaml 文件，使用 istioctl kube-inject 或者配置自動(dòng)注入后會(huì)在這個(gè)文件的基礎(chǔ)上向其中的 Deployment 追加一個(gè)鏡像為 docker.io/istio/proxyv2:1.10.3 的 sidecar 容器，上面的命令會(huì)啟動(dòng)全部的四個(gè)服務(wù)，其中也包括了 reviews 服務(wù)的三個(gè)版本(v1、v2 以及 v3)。

過(guò)一會(huì)兒就可以看到如下 service 和 pod 啟動(dòng):

➜  ~ kubectl get pods 
NAME                                      READY   STATUS        RESTARTS   AGE 
details-v1-79f774bdb9-mqpzm               2/2     Running       0          25m 
productpage-v1-6b746f74dc-xjzgh           2/2     Running       0          25m 
ratings-v1-b6994bb9-9j9dq                 2/2     Running       0          25m 
reviews-v1-545db77b95-wwhkq               2/2     Running       0          25m 
reviews-v2-7bf8c9648f-rh6b9               2/2     Running       0          25m 
reviews-v3-84779c7bbc-bsld9               2/2     Running       0          25m 
➜  ~ kubectl get svc 
NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE 
details              ClusterIP   10.99.137.40    <none>        9080/TCP   26m 
kubernetes           ClusterIP   10.96.0.1       <none>        443/TCP    57d 
productpage          ClusterIP   10.111.10.219   <none>        9080/TCP   26m 
ratings              ClusterIP   10.105.20.158   <none>        9080/TCP   26m 
reviews              ClusterIP   10.105.81.29    <none>        9080/TCP   26m 

現(xiàn)在應(yīng)用的服務(wù)都部署成功并啟動(dòng)了，如果我們需要在集群外部訪問(wèn)，就需要添加一個(gè) istio gateway，gateway 相當(dāng)于 k8s 的 ingress controller 和 ingress，它為 HTTP/TCP 流量配置負(fù)載均衡，通常在服務(wù)網(wǎng)格邊緣作為應(yīng)用的 ingress 流量管理。

創(chuàng)建一個(gè) Ingress gateway:

➜  ~ kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml 
gateway.networking.istio.io/bookinfo-gateway created 
virtualservice.networking.istio.io/bookinfo created 

驗(yàn)證 gateway 是否創(chuàng)建成功:

➜  ~ kubectl get gateway 
NAME               AGE 
bookinfo-gateway   15s 

要想訪問(wèn)這個(gè)應(yīng)用，這里我們需要更改下 istio 提供的 istio-ingressgateway 這個(gè) Service 對(duì)象，默認(rèn)是 LoadBalancer 類型的服務(wù)：

➜  ~ kubectl get svc -n istio-system 
NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                                      AGE 
istio-egressgateway    ClusterIP      10.103.199.67    <none>        80/TCP,443/TCP                                                               47m 
istio-ingressgateway   LoadBalancer   10.100.241.242   <pending>     15021:31548/TCP,80:31529/TCP,443:30433/TCP,31400:31175/TCP,15443:32533/TCP   47m 
istiod                 ClusterIP      10.107.77.147    <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP 

LoadBalancer 類型的服務(wù)，實(shí)際上是用來(lái)對(duì)接云服務(wù)廠商的，如果我們沒(méi)有對(duì)接云服務(wù)廠商的話，可以將這里類型改成 NodePort，但是這樣當(dāng)訪問(wèn)我們的服務(wù)的時(shí)候就需要加上 nodePort 端口了：

➜  ~ kubectl edit svc istio-ingressgateway -n istio-system 
...... 
type: NodePort  # 修改成 NodePort 類型 
status: 
  loadBalancer: {} 

這樣我們就可以通過(guò) http://:/productpage 從集群外部訪問(wèn) Bookinfo 應(yīng)用了：

bookinfo demo

刷新頁(yè)面可以看到 Book Reviews 發(fā)生了改變(紅色、黑色的星形或者沒(méi)有顯示)，因?yàn)槊看握?qǐng)求會(huì)被路由到到了不同的 Reviews 服務(wù)版本去。

儀表盤(pán)

上面我們是安裝的 Istio 的核心組件，此外 Istio 還和一些遙測(cè)應(yīng)用做了集成，遙測(cè)能幫助我們了解服務(wù)網(wǎng)格的結(jié)構(gòu)、展示網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)、分析網(wǎng)格的健康狀態(tài)等，對(duì)于分布式微服務(wù)應(yīng)用也是非常重要的。

我們可以使用下面的命令來(lái)部署 Kiali、Prometheus、Grafana 以及 Jaeger：

➜  ~ kubectl apply -f samples/addons 
# 如果出現(xiàn)了錯(cuò)誤，則可以重新執(zhí)行上面的命令 
➜  ~ kubectl get pods -n istio-system 
NAME                                    READY   STATUS    RESTARTS   AGE 
grafana-f766d6c97-4888w                 1/1     Running   0          3m57s 
istio-egressgateway-5c8d96c9b5-6d5g9    1/1     Running   0          60m 
istio-ingressgateway-6bcfd457f9-wpj7w   1/1     Running   0          60m 
istiod-775bcf58f7-v6jl2                 1/1     Running   0          61m 
jaeger-7f78b6fb65-bj8pm                 1/1     Running   0          3m56s 
kiali-85c8cdd5b5-b5zv4                  1/1     Running   0          3m55s 
prometheus-54b5dcf6bf-wjkpl             3/3     Running   0          3m48s 

上面幾個(gè)組件部署完成后我們就可以查看前面 Bookinfo 示例應(yīng)用的遙測(cè)信息了，比如可以使用下面的命令訪問(wèn) Kiali：

➜  ~ istioctl dashboard kiali 

在左側(cè)的導(dǎo)航菜單，選擇 Graph ，然后在 Namespace 下拉列表中，選擇 default 。Kiali 儀表板展示了網(wǎng)格的概覽、以及 Bookinfo 示例應(yīng)用的各個(gè)服務(wù)之間的關(guān)系。它還提供過(guò)濾器來(lái)可視化流量的流動(dòng)。

kiali dashboard

至此，整個(gè) Istio 和 Bookinfo 示例應(yīng)用就安裝并驗(yàn)證成功了，現(xiàn)在就可以使用這一應(yīng)用來(lái)體驗(yàn) Istio 的特性了，其中包括了流量的路由、錯(cuò)誤注入、速率限制等特性。

目前搭建 Bookinfo 應(yīng)用我們只用到了下面兩個(gè)資源文件：

samples/bookinfo/platform/kube/bookinfo.yaml 
samples/bookinfo/networking/bookinfo-gateway.yaml 

前者就是通常的 Kubernetes 定義的 Deployment 和 Service 的資源清單文件，只是在部署時(shí)使用 istioctl kube-inject(或者通過(guò)對(duì)命名空間打上自動(dòng)注入的標(biāo)簽)對(duì)這個(gè)文件定義的 Pod 注入了 sidecar 代理，后者定義了這個(gè)應(yīng)用的外部訪問(wèn)入口 gateway，以及應(yīng)用內(nèi)部 productpage 服務(wù)的 VirtualService 規(guī)則，而其他內(nèi)部服務(wù)的訪問(wèn)規(guī)則還沒(méi)有被定義。

現(xiàn)在訪問(wèn)應(yīng)用界面并刷新，會(huì)看到 Reviews 有時(shí)不會(huì)顯示評(píng)分，有時(shí)候會(huì)顯示不同樣式的評(píng)分，這是因?yàn)楹竺嬗?個(gè)不同的 Reviews 服務(wù)版本，而沒(méi)有配置該服務(wù)的路由規(guī)則的情況下，該服務(wù)的幾個(gè)實(shí)例會(huì)被隨機(jī)訪問(wèn)到，有的版本服務(wù)會(huì)進(jìn)一步調(diào)用 Ratings 服務(wù)，有的不會(huì)。

這里我們會(huì)了解 Istio 中兩個(gè)非常重要的流量管理的資源對(duì)象：

• VirtualService(虛擬服務(wù))：用來(lái)在 Istio 中定義路由規(guī)則，控制流量路由到服務(wù)上的各種行為。
• DestinationRule(目標(biāo)規(guī)則)：虛擬服務(wù)視定義將流量如何路由到指定目標(biāo)地址，然后使用目標(biāo)規(guī)則來(lái)配置該目標(biāo)的流量，在評(píng)估虛擬服務(wù)路由規(guī)則之后，目標(biāo)規(guī)則將應(yīng)用于流量的真實(shí)目標(biāo)地址。

VirtualService

虛擬服務(wù)(VirtualService)和目標(biāo)規(guī)則(Destination Rule)是 Istio 流量路由功能的關(guān)鍵對(duì)象，虛擬服務(wù)配置如何在 Istio 內(nèi)將請(qǐng)求路由到服務(wù)，每個(gè)虛擬服務(wù)包含一組路由規(guī)則，Istio 會(huì)按定義的順序來(lái)評(píng)估它們，Istio 將每個(gè)指定的請(qǐng)求匹配到虛擬服務(wù)指定的實(shí)際目標(biāo)地址。在網(wǎng)格中可以有多個(gè)虛擬服務(wù)，也可以沒(méi)有。

使用虛擬服務(wù)，你可以為一個(gè)或多個(gè)主機(jī)名指定流量行為，在虛擬服務(wù)中使用路由規(guī)則，告訴 Envoy 如何發(fā)送虛擬服務(wù)的流量到合適的目標(biāo)，路由目標(biāo)地址可以是同一服務(wù)的不同版本，也可以是完全不同的服務(wù)。

一個(gè)典型的使用場(chǎng)景是將流量發(fā)送到指定服務(wù)的不同版本?？蛻舳藭?huì)將虛擬服務(wù)視為一個(gè)單一實(shí)體，將請(qǐng)求發(fā)送至虛擬服務(wù)主機(jī)，然后 Envoy 根據(jù)虛擬服務(wù)規(guī)則把流量路由到不同的版本。比如把 20% 的流量路由到新版本 或 將這些用戶的請(qǐng)求路由到版本 2，可以創(chuàng)建一個(gè)金絲雀發(fā)布，然后逐步增加發(fā)送到新版本服務(wù)的流量百分比。流量路由完全獨(dú)立于實(shí)例部署，所以實(shí)現(xiàn)新版本服務(wù)的實(shí)例可以根據(jù)流量的負(fù)載來(lái)伸縮，完全不影響流量路由。相比之下，Kubernetes 則只支持基于實(shí)例縮放的流量分發(fā)，這會(huì)更復(fù)雜。

如下所示我們定義一個(gè)虛擬服務(wù)，根據(jù)請(qǐng)求是否來(lái)自某個(gè)特定用戶，把它們路由到服務(wù)的不同版本去。

apiVersion: networking.istio.io/v1alpha3 
kind: VirtualService 
metadata: 
  name: reviews 
spec: 
  hosts: # 列出VirtualService的hosts，可以是IP、DNS名稱、FQDN或* 
  - reviews 
  http: # 在下面配置VirtualService的路由規(guī)則，指定符合哪些規(guī)則的流量打到哪些Destination，支持HTTP/1.1，HTTP2，及gRPC等協(xié)議 
  - match: # 指定具體的匹配規(guī)則 
    - headers: 
        end-user: 
          exact: jason 
    route: 
    - destination: # 指定滿足規(guī)則后將流量打到哪個(gè)具體的Destination 
        host: reviews 
        subset: v2 
  - route:  # 流量規(guī)則按從上到下的優(yōu)先級(jí)去匹配，若不滿足上述規(guī)則時(shí)，進(jìn)入該默認(rèn)規(guī)則 
    - destination: 
        host: reviews 
        subset: v3 

我們使用 hosts 字段列舉虛擬服務(wù)的主機(jī)——即用戶指定的目標(biāo)或是路由規(guī)則設(shè)定的目標(biāo)，這是客戶端向服務(wù)發(fā)送請(qǐng)求時(shí)使用的一個(gè)或多個(gè)地址。

hosts: 
- reviews 

虛擬服務(wù)主機(jī)名可以是 IP 地址、DNS 名稱，比如 Kubernetes Service 的短名稱，隱式或顯式地指向一個(gè)完全限定域名(FQDN)。也可以使用通配符(“*”)前綴，創(chuàng)建一組匹配所有服務(wù)的路由規(guī)則。虛擬服務(wù)的 hosts 字段實(shí)際上不必是 Istio 服務(wù)注冊(cè)的一部分，它只是虛擬的目標(biāo)地址，這樣可以為沒(méi)有路由到網(wǎng)格內(nèi)部的虛擬主機(jī)建模。

然后接著就是路由規(guī)則的定義，這里通過(guò) http 字段來(lái)定義虛擬服務(wù)的路由規(guī)則，用來(lái)描述匹配條件和路由行為，它們把 HTTP/1.1、HTTP2 和 gRPC 等流量發(fā)送到 hosts 字段指定的目標(biāo)，一條路由規(guī)則包含了指定的請(qǐng)求要流向哪個(gè)目標(biāo)地址，可以有0個(gè)或多個(gè)匹配條件。

比如上面示例中的第一個(gè)路由規(guī)則有一個(gè)條件，所以使用 match 字段開(kāi)始定義，我們希望該路由應(yīng)用于來(lái)自 jason 用戶的所有請(qǐng)求，所以使用 headers、end-user 和 exact 字段來(lái)匹配合適的請(qǐng)求。

- match: 
  - headers: 
    end-user: 
      exact: jason 

然后后面的 route 部分的 destination 字段指定了符合該條件的流量的實(shí)際目標(biāo)地址，與虛擬服務(wù)的 hosts 不同，destination 的 host 必須是存在于 Istio 服務(wù)注冊(cè)中心的實(shí)際目標(biāo)地址，否則 Envoy 不知道該將請(qǐng)求發(fā)送到哪里?？梢允且粋€(gè)有代理的服務(wù)網(wǎng)格，或者是一個(gè)通過(guò)服務(wù)入口被添加進(jìn)來(lái)的非網(wǎng)格服務(wù)。本示例運(yùn)行在 Kubernetes 環(huán)境中，host 名為一個(gè) Kubernetes 服務(wù)名：

route: 
- destination: 
    host: reviews  # Kubernetes Service 短名稱 
    subset: v2 

此外 destination 下面還指定了 Kubernetes 服務(wù)的子集，將符合此規(guī)則條件的請(qǐng)求轉(zhuǎn)入其中，比如這里我們使用的子集名稱是 v2，我們會(huì)在目標(biāo)規(guī)則中看到如何定義服務(wù)子集。

路由規(guī)則是按從上到下的順序選擇的，虛擬服務(wù)中定義的第一條規(guī)則有最高優(yōu)先級(jí)。比如上面我們定義的虛擬服務(wù)中，不滿足第一個(gè)路由規(guī)則的流量均會(huì)流向一個(gè)默認(rèn)的目標(biāo)，第二條規(guī)則沒(méi)有配置 match 條件，直接將流量導(dǎo)向 v3 子集。

- route: 
  - destination: 
      host: reviews 
      subset: v3 

一般建議提供一個(gè)默認(rèn)的無(wú)條件或基于權(quán)重的規(guī)則作為每一個(gè)虛擬服務(wù)的最后一條規(guī)則，從而確保流經(jīng)虛擬服務(wù)的流量至少能夠匹配到一條路由規(guī)則。

DestinationRule

與虛擬服務(wù)一樣，DestinationRule(目標(biāo)規(guī)則)也是 Istio 流量路由功能的關(guān)鍵部分，我們可以將虛擬服務(wù)看成將流量如何路由到指定目標(biāo)地址，然后使用目標(biāo)規(guī)則來(lái)配置該目標(biāo)的流量。在評(píng)估虛擬服務(wù)路由規(guī)則之后，目標(biāo)規(guī)則將應(yīng)用于流量的“真實(shí)”目標(biāo)地址。

可以使用目標(biāo)規(guī)則來(lái)指定命名的服務(wù)子集，例如按版本為所有指定服務(wù)的實(shí)例分組，然后可以在虛擬服務(wù)的路由規(guī)則中使用這些服務(wù)子集來(lái)控制到服務(wù)不同實(shí)例的流量。目標(biāo)規(guī)則還允許你在調(diào)用整個(gè)目的服務(wù)或特定服務(wù)子集時(shí)定制 Envoy 的流量策略，比如負(fù)載均衡模型、TLS 安全模式或熔斷器設(shè)置。

默認(rèn)情況下，Istio 使用輪詢的負(fù)載均衡策略，實(shí)例池中的每個(gè)實(shí)例依次獲取請(qǐng)求。Istio 同時(shí)支持如下的負(fù)載均衡模型，可以在 DestinationRule 中為流向某個(gè)特定服務(wù)或服務(wù)子集的流量指定這些模型。

• 隨機(jī)：請(qǐng)求以隨機(jī)的方式轉(zhuǎn)到池中的實(shí)例。
• 權(quán)重：請(qǐng)求根據(jù)指定的百分比轉(zhuǎn)到實(shí)例。
• 最少請(qǐng)求：請(qǐng)求被轉(zhuǎn)到最少被訪問(wèn)的實(shí)例。

比如在下面的示例中，目標(biāo)規(guī)則為 my-svc 目標(biāo)服務(wù)配置了 3 個(gè)具有不同負(fù)載均衡策略的子集：

apiVersion: networking.istio.io/v1alpha3 
kind: DestinationRule 
metadata: 
  name: my-destination-rule 
spec: 
  host: my-svc 
  trafficPolicy: 
    loadBalancer: 
      simple: RANDOM  # 隨機(jī)的策略 
  subsets: 
  - name: v1 
    labels: 
      version: v1 
  - name: v2 
    labels: 
      version: v2 
    trafficPolicy: 
      loadBalancer: 
        simple: ROUND_ROBIN  # 輪詢 
  - name: v3 
    labels: 
      version: v3 

每個(gè)子集都是基于一個(gè)或多個(gè) labels 定義的，在 Kubernetes 中它是附加到 Pod 這種對(duì)象上的鍵/值對(duì)。除了定義子集之外，目標(biāo)規(guī)則對(duì)于所有子集都有默認(rèn)的流量策略，而對(duì)于具體的子集，則可以使用特定于子集的策略來(lái)覆蓋它。上面的示例定義在 subsets 上的默認(rèn)策略，為 v1 和 v3 子集設(shè)置了一個(gè)簡(jiǎn)單的隨機(jī)負(fù)載均衡器，在 v2 策略中，指定了一個(gè)輪詢負(fù)載均衡器。

在對(duì)虛擬服務(wù)和目標(biāo)規(guī)則有了初步了解后，接下來(lái)我們就來(lái)對(duì) Bookinfo 服務(wù)的訪問(wèn)規(guī)則進(jìn)行修改。

不同服務(wù)版本訪問(wèn)規(guī)則

對(duì) Reviews 服務(wù)添加一條路由規(guī)則，啟用 samples/bookinfo/networking/virtual-service-reviews-v3.yaml 定義的 VirtualService 規(guī)則，內(nèi)容如下：

apiVersion: networking.istio.io/v1alpha3 
kind: VirtualService 
metadata: 
  name: reviews 
spec: 
  hosts: 
  - reviews 
  http: 
  - route: 
    - destination: 
        host: reviews 
        subset: v3 

這樣，所有訪問(wèn) reviews 服務(wù)的流量就會(huì)被引導(dǎo)到 reviews 服務(wù)對(duì)應(yīng)的 subset 為 v3 的 Pod 中。啟用這條規(guī)則：

➜  ~ kubectl apply -f  samples/bookinfo/networking/virtual-service-reviews-v3.yaml 
virtualservice.networking.istio.io/reviews created 

然后查看所有的路由規(guī)則：

➜  ~ kubectl get virtualservices 
NAME       GATEWAYS             HOSTS       AGE 
bookinfo   [bookinfo-gateway]   [*]         158d 
reviews                         [reviews]   20s 

我們可以看到 reviews 的 VirtualService 已經(jīng)創(chuàng)建成功了，此時(shí)我們?nèi)ニ⑿聭?yīng)用的頁(yè)面，發(fā)現(xiàn)訪問(wèn) Reviews 失敗了：

bookinfo reviews v3 failed

這是因?yàn)槲覀冞€沒(méi)有創(chuàng)建 DestinationRule 對(duì)象，DestinationRule 對(duì)象是 VirtualService 路由生效后，配置應(yīng)用與請(qǐng)求的策略集，用來(lái)將 VirtualService 中指定的 subset 與對(duì)應(yīng)的 Pod 關(guān)聯(lián)起來(lái)。

在 samples/bookinfo/networking/destination-rule-all.yaml 文件中有定義所有該應(yīng)用中要用到的所有 DestinationRule 資源對(duì)象，其中有一段就是對(duì) Reviews 相關(guān)的 DestinationRule 的定義:

--- 
apiVersion: networking.istio.io/v1alpha3 
kind: DestinationRule 
metadata: 
  name: reviews 
spec: 
  host: reviews 
  subsets: 
  - name: v1 
    labels: 
      version: v1 
  - name: v2 
    labels: 
      version: v2 
  - name: v3 
    labels: 
      version: v3  # 匹配version=v3標(biāo)簽的Pod 

我們可以看到 DestinationRule 中定義了 subsets 集合，其中 labels 就和我們之前 Service 的 labelselector 一樣是去匹配 Pod 的 labels 標(biāo)簽的，比如我們這里 subsets 中就包含一個(gè)名為 v3 的 subset，而這個(gè) subset 匹配的就是具有 version=v3 這個(gè) label 標(biāo)簽的 Pod 集合，前面我們創(chuàng)建的 Bookinfo 中也有這個(gè)標(biāo)簽的 Pod:

➜  ~ kubectl get pods -l version=v3 
NAME                          READY   STATUS    RESTARTS   AGE 
reviews-v3-84779c7bbc-bsld9   2/2     Running   2          47h 

這樣我們就通過(guò) DestinationRule 將 VirtualService 與 Service 不同的版本關(guān)聯(lián)起來(lái)了?，F(xiàn)在我們直接創(chuàng)建 DestinationRule 資源：

➜  ~ kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml 
destinationrule.networking.istio.io/productpage created 
destinationrule.networking.istio.io/reviews created 
destinationrule.networking.istio.io/ratings created 
destinationrule.networking.istio.io/details created 

創(chuàng)建完成后，我們就可以查看目前我們網(wǎng)格中的 DestinationRules:

➜  ~ kubectl get destinationrule 
NAME          HOST          AGE 
details       details       30s 
productpage   productpage   30s 
ratings       ratings       30s 
reviews       reviews       30s 

此時(shí)再訪問(wèn)應(yīng)用就成功了，多次刷新頁(yè)面發(fā)現(xiàn) Reviews 始終都展示的是 v3 版本(帶紅色星的)的 Ratings 了，說(shuō)明我們VirtualService 的配置成功了。

reviews v3

基于權(quán)重的服務(wù)訪問(wèn)規(guī)則

剛剛我們演示的基于不同服務(wù)版本的服務(wù)網(wǎng)格的控制，接下來(lái)我們來(lái)演示下基于權(quán)重的服務(wù)訪問(wèn)規(guī)則的使用。

首先移除剛剛創(chuàng)建的 VirtualService 對(duì)象，排除對(duì)環(huán)境的影響：

➜  ~ kubectl delete virtualservice reviews 
virtualservice.networking.istio.io "reviews" deleted 
➜  ~ kubectl get virtualservice 
NAME       GATEWAYS               HOSTS   AGE 
bookinfo   ["bookinfo-gateway"]   ["*"]   2d 

現(xiàn)在我們?cè)偃ピL問(wèn) Bookinfo 應(yīng)用又回到最初隨機(jī)訪問(wèn) Reviews 的情況了。現(xiàn)在我們查看文件 samples/bookinfo/networking/virtual-service-reviews-80-20.yaml 的定義：

apiVersion: networking.istio.io/v1alpha3 
kind: VirtualService 
metadata: 
  name: reviews 
spec: 
  hosts: 
    - reviews 
  http: 
  - route: 
    - destination: 
        host: reviews 
        subset: v1 
      weight: 80 
    - destination: 
        host: reviews 
        subset: v2 
      weight: 20 

這個(gè)規(guī)則定義了 80% 的對(duì) Reviews 的流量會(huì)落入到 v1(沒(méi)有 Ratings)這個(gè) subset，20% 會(huì)落入 v2(帶黑色 Ratings)子集，然后我們創(chuàng)建這個(gè)資源對(duì)象：

➜  ~ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-80-20.yaml 
virtualservice.networking.istio.io/reviews created 
➜  ~ kubectl get virtualservice 
NAME       GATEWAYS               HOSTS         AGE 
bookinfo   ["bookinfo-gateway"]   ["*"]         2d 
reviews                           ["reviews"]   8s 

我們查看當(dāng)前網(wǎng)格中的 VirtualService 對(duì)象，可以看到已經(jīng)有 reviews 了，證明已經(jīng)創(chuàng)建成功了，由于上面我們已經(jīng)將應(yīng)用中所有的 DestinationRules 都已經(jīng)創(chuàng)建過(guò)了，所以現(xiàn)在我們直接訪問(wèn)應(yīng)用就可以了，我們多次刷新，可以發(fā)現(xiàn)沒(méi)有出現(xiàn) Ratings 的次數(shù)與出現(xiàn)黑色星 Ratings 的比例大概在4:1左右，并且沒(méi)有紅色星的 Ratings 的情況出現(xiàn)，說(shuō)明我們配置的基于權(quán)重的 VirtualService 訪問(wèn)規(guī)則配置生效了。

基于請(qǐng)求內(nèi)容的服務(wù)訪問(wèn)規(guī)則

除了上面基于服務(wù)版本和服務(wù)權(quán)重的方式控制服務(wù)訪問(wèn)之外，我們還可以基于請(qǐng)求內(nèi)容來(lái)進(jìn)行訪問(wèn)控制。

同樣，將上面創(chuàng)建的 VirtualService 對(duì)象刪除：

➜  ~ kubectl delete virtualservice reviews 
virtualservice.networking.istio.io "reviews" deleted 
➜  ~ kubectl get virtualservice 
NAME       GATEWAYS               HOSTS         AGE 
bookinfo   ["bookinfo-gateway"]   ["*"]         2d 

查看文件 samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml 的定義：

apiVersion: networking.istio.io/v1alpha3 
kind: VirtualService 
metadata: 
  name: reviews 
spec: 
  hosts: 
  - reviews 
  http: 
  - match: 
    - headers: 
        end-user: 
          exact: jason 
    route: 
    - destination: 
        host: reviews 
        subset: v2 
  - route: 
    - destination: 
        host: reviews 
        subset: v3 

這個(gè) VirtualService 對(duì)象定義了對(duì) reviews 服務(wù)訪問(wèn)的 match 規(guī)則，意思是如果當(dāng)前請(qǐng)求的 header 中包含 jason 這個(gè)用戶信息，則只會(huì)訪問(wèn)到 v2 的 reviews 這個(gè)服務(wù)版本，即都帶黑星的樣式，如果不包含該用戶信息，則都直接將流量轉(zhuǎn)發(fā)給 v3 這個(gè) reviews 的服務(wù)。

我們先不啟用這個(gè) VirtualService，先去訪問(wèn)下 Bookinfo 這個(gè)應(yīng)用。

bookinfo login

右上角有登錄按鈕，在沒(méi)有登錄的情況下刷新頁(yè)面，reviews 服務(wù)是被隨機(jī)訪問(wèn)的，可以看到有帶星不帶星的樣式，點(diǎn)擊登錄，在彈窗中 User Name 輸入 jason，Password 為空，登錄：

bookinfo logined

再刷新頁(yè)面，可以看到跟未登錄前的訪問(wèn)規(guī)則一樣，也是隨機(jī)的?，F(xiàn)在我們來(lái)創(chuàng)建上面的 VirtualService 這個(gè)對(duì)象:

➜  ~ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml 
virtualservice.networking.istio.io/reviews created 
➜  ~ kubectl get virtualservice 
NAME       GATEWAYS               HOSTS         AGE 
bookinfo   ["bookinfo-gateway"]   ["*"]         2d 
reviews                           ["reviews"]   8s 

此時(shí)再回去刷新頁(yè)面，發(fā)現(xiàn)一直都是黑星的 Reviews 版本(v2)被訪問(wèn)到了，注銷退出后再訪問(wèn)，此時(shí)又一直是紅星的版本(v3)被訪問(wèn)了。

說(shuō)明我們基于 headers->end-user->exact:jason 的控制規(guī)則生效了。在 productpage 服務(wù)調(diào)用 reviews 服務(wù)時(shí)，登錄的情況下會(huì)在 header 中帶上用戶信息，通過(guò) exact 規(guī)則匹配到相關(guān)信息后，流量被引向了上面配置的 v2 版本中。

這里要說(shuō)明一下 match 的匹配規(guī)則：

All conditions inside a single match block have AND semantics, while the list of match blocks have OR semantics. The rule is matched if any one of the match blocks succeed. 

意思是一個(gè) match 塊里的條件是需要同時(shí)滿足才算匹配成功的，如下面是 url 前綴和端口都必須都滿足才算成功：

- match: 
    - uri: 
        prefix: "/wpcatalog" 
      port: 443 

多個(gè) match 塊之間是只要有一個(gè) match 匹配成功了，就會(huì)被路由到它指定的服務(wù)版本去，而忽略其他的。我們的示例中在登錄的條件下，滿足第一個(gè) match，所以服務(wù)一直會(huì)訪問(wèn)到 v2 版本。退出登錄后，沒(méi)有 match 規(guī)則滿足匹配，所以就走最后一個(gè) route 規(guī)則，即 v3 版本。

到這里，我們就和大家一起學(xué)習(xí)了基于不同服務(wù)版本、權(quán)重以及請(qǐng)求內(nèi)容來(lái)控制服務(wù)流量的配置。