使用 Istio 實現基於 Kubernetes 的微服務應用
【編者的話】近兩年，隨著容器、Kubernetes 等技術的興起，微服務被廣泛提及並被大量使用。本文旨在讓讀者瞭解 Istio，通過它與 Kubernetes 相結合，大幅降低微服務的複雜度，以便讓開發人員更關注於程式碼本身。
Istio 的架構分析
Istio 介紹
Istio 被稱為 Service Mesh 架構，該開源專案由 Google 和 IBM 主導，根據 http://stackalytics.com 網站的統計，該社群程式碼 Commits 廠商排名如下：
圖 1. Istio 各廠商程式碼貢獻量圖示
圖 2. Istio 各廠商程式碼貢獻量排名
在 GitHub 上，Istio 專案受關注的程度非常高，您可進一步瞭解。接下來，我們詳細介紹 Istio 的技術架構。
Istio 的架構
Istio 分為兩個平面：資料平面和控制平面。
資料平面：
資料平面由一組 Sidecar 的代理（Envoy）組成。這些代理調解和控制微服務之間的所有網路通訊，並且與控制平面的 Mixer 通訊，接受排程策略。
控制平面：
控制平面通過管理和配置 Envoy 來管理流量。此外，控制平面配置 Mixers 來實施路由策略並收集檢測到的監控資料。
圖 3. Istio 的架構圖
在介紹了 Istio 的兩個平面以後，我們詳細介紹 Istio 的各個元件。
Envoy 是一個用 C ++開發的高效能代理，用於管理 Service Mesh 中所有服務的所有入站和出站流量。 Istio 利用 Envoy 的許多內建功能，例如：
- 動態服務發現
- 負載均衡
- TLS 終止
- HTTP / 2 和 gRPC 代理
- 斷路器
- 健康檢查
- 流量分割
- 故障注入
- 監控指標
我們知道，在 Kubernetes 中叢集中，Pod 是最小的計算資源排程單位。一個 pod 可以包含一個或者多個容器，但通常是一個。而使用 Istio 的時候，需要在 Pod 中主容器旁註入一個 Sidecar，也就是上面提到的代理（Envoy）。
舉一個例子，我們檢視一個被注入了 Envoy 的 Pod，從下圖結果可以看到，這個 Pod 包含兩個容器：
圖 4. 檢視 Pod 中的 Container
在 Istio 中，每一個 Pod 中都必須要部署一個 Sidecar。
Mixer 是一個獨立於平臺的元件，負責在整個 Service Mesh 中執行訪問控制和使用策略，並從 Envoy 代理和其他服務收集監控到的資料。
Pilot 為 Envoy 提供服務發現；為高階路由（例如，A / B 測試，金絲雀部署等）提供流量管理功能；以及異常控制，如：超時，重試，斷路器等。
Citadel 通過內建身份和憑證管理，提供強大的服務到服務和終端使用者身份驗證。我們可以使用 Citadel 升級 Service Mesh 中的未加密流量。我們可以使用 Istio 的授權功能來控制誰可以訪問服務。
Istio 路由規則的實現
在 Istio 中，和路由相關的有四個概念：Virtual Services 、Destination Rules、ServiceEntry、Gateways。
Virtual Services 的作用是：定義了針對 Istio 中的一個微服務的請求的路由規則。Virtual Services 既可以將請求路由到一個應用的不同版本，也可以將請求路由到完全不同的應用。
在如下的示例配置中，發給微服務的請求，將會被路由到 Productpage，埠號為 9080。
route: - destination: host: productpage port: number: 9080
清單 1. Virtual Services 規則
在下面的示例配置中，定義了熔斷策略。
spec: host: productpage subsets: - labels: version: v1 name: v1 trafficPolicy: connectionPool: http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 tcp: maxConnections: 1 tls:
清單 2. Destination 規則
ServiceEntry 用於將 Istio 外部的服務註冊到 Istio 的內部服務登錄檔，以便 Istio 內部的服務可以訪問這些外部的服務，如 Istio 外部的 Web API。
在如下的示例配置中，定義了 Istio 外部的 Mongo Cluster 與 Istio 內部的訪問規則。
apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: external-svc-mongocluster spec: hosts: - mymongodb.somedomain # not used addresses: - 192.192.192.192/24 # VIPs ports: - number: 27018 name: mongodb protocol: MONGO location: MESH_INTERNAL resolution: STATIC endpoints: - address: 2.2.2.2 - address: 3.3.3.3
清單 3. ServiceEntry 規則
Gateway：定義了 Istio 邊緣的負載均衡器。所謂邊緣，就是 Istio 的入口和出口。這個負載均衡器用於接收傳入或傳出 Istio 的 HTTP / TCP 連線。在 Istio 中會有 Ingress Gateway 和 Egress Gateway，前者負責入口流量，後者負責出口流量。
在如下的示例配置中，定義了 Istio 的入口流量。
spec: selector: istio: ingressgateway servers: - hosts: - '*' port: name: http number: 80 protocol: HTTP
清單 4. Gateway 規則
Istio 的技術實現
基於 Kubernetes 部署的 Istio
在本文中，我們基於 Kubernetes 1.11 部署 Istio 1.04。由於篇幅有限，具體的部署步驟可以參考 Quick Start with Kubernetes 。
檢視 Kubernetes 版本：
圖 5. 檢視 Kubernetes 叢集的版本
檢視 Kubernetes 叢集：
圖 6. 檢視 Kubernetes 叢集的節點
檢視部署好的 Istio。
Istio 以一個專案的形式部署到 Kubernetes 叢集中。我們可以看到，部署好的 Pod 中，除了有 istio-citadel、istio-egressgateway、istio-ingressgateway、istio-pilot 等 Istio 本身的功能元件，還集成了微服務相關的監控工具，如：Grafana、jaeger-agent、Kiali、Prometheus。正是這些功能豐富且強大的監控工具，幫助 Istio 實現了微服務的視覺化管理。
圖 7. 檢視 Kubernetes 中的 Istio
檢視 istio 版本：1.0.4：
圖 8. 檢視 Istio 版本
接下來，我們將會對 Isito 整合的工具進行介紹。本文最後的實驗展現環節，我們將會使用這些工具進行微服務的監控和管理。
Istio 的工具集：Grafana
Grafana 是一個非常著名的開源專案。它是一個 Web 應用，可以提供豐富的監控儀表盤。它的後端支援 Graphite、 InfluxDB 或 OpenTSDB。
通過瀏覽器訪問 Istio 中部署好的 Grafana。
登入 Grafana 後，首頁面如下：
圖 9. Grafana 首頁面
檢視已有的 Dashboard：
圖 10. Grafana 上的 Istio Dashboard
我們檢視 Pilot Dashboard，可以看到豐富的資源統計。
圖 11. Grafana 上的 Istio Dashboard 檢視
Istio 的工具集：Prometheus
Prometheus 是一個開源監控系統。它具有維度資料模型；具備靈活的查詢語言、高效的時間序列資料庫，並提供靈活的警報方法。
在 Istio 中，Prometheus 收到的資料，會被彙總到 Grafana 進行統一展現。
訪問 Istio 中部署好的 Prometheus：
圖 12. Prometheus 的 UI
我們可以看到有多達上百個監測點：
圖 13. Prometheus 的監測點
例如我們選擇 Container_memory_cache，點選 Execute。
圖 14. 執行監測點
然後可以生成圖形化介面展示，並且我們也可以調整時間間隔（圖中是 60 分鐘）。
圖 15. 監控圖
Istio 的工具集：Kiali
Kiali 作為一個開源專案，可以為 Istio 提供視覺化服務網格拓撲、斷路器或請求率等功能。此外 Kiali 還包括 Jaeger Tracing，可以提供開箱即用的分散式跟蹤功能。
我們看一下 Istio 中部署的 Kiali：
圖 16. Kiali 的 UI 首頁
它可以檢視在 Istio 上部署的微服務的拓撲結構：
圖 17. Kiali 檢視微服務的拓撲
Istio 的工具集：Jaeger
Jaeger 是一個開源專案，用於微服務的分散式跟蹤。它實現的功能有：
- 分散式事務監控
- 服務呼叫問題根因分析
- 服務依賴性分析
- 效能/延遲優化
Jaeger 工具已經整合到 Istio 中，部署以後可以通過瀏覽器訪問。
下圖是 Jeager 追蹤 Productpage 這個服務在過去三個小時的所有呼叫：
圖 18. Jaeger 檢視 API 呼叫
我們可以展開看詳細的呼叫層級：
圖 19. Jaeger 檢視 API 詳細呼叫
Istio 管理微服務的實驗展現
在本小節中，我們將在 Istio 上部署一個名為 bookinfo 的微服務應用。為了方便讀者理解，我們先分析這個應用的原始碼。然後展示 Istio 如何管理這套微服務。
bookinfo 微服務原始碼分析
bookinfo 應用程式顯示的有關書籍的資訊，類似於線上書店的單個商品。應用頁面上顯示的是書籍的描述、書籍詳細資訊（ISBN，頁數等）以及書評。
bookinfo 應用一共包含四個微服務：Productpage、Details、Reviews、Ratings。
- Productpage 使用 Python 開發，負責展示書籍的名稱和書籍的簡介。
- Details 使用 Ruby 開發，負責展示書籍的詳細資訊。
- Reviews 使用 Java 開發，負責顯示書評。
- Ratings 使用 Node.js 開發,負責顯示書籍的評星。
其拓撲關係見下圖。
圖 20. bookinfo 應用拓撲架構
我們看一下 bookinfo 微服務部署完畢的展示效果：
圖 21. bookinfo 應用頁面展示效果
Productpage 微服務包含兩部分內容：
- 書籍的名稱："The Comedy of Errors"，翻譯成中文是《錯誤的喜劇》。
- 書籍的簡介：Summary。翻譯成中文是：《錯誤的喜劇》是威廉·莎士比亞早期劇作之一。這是他最短的、也是他最喜歡的喜劇之一，除了雙關語和文字遊戲之外，幽默的主要部分來自於打鬧和錯誤的身份。
Details 微服務包含的內容是書籍的詳細資訊，內容如下。
Type: paperback Pages: 200 Publisher: PublisherA Language: English ISBN-10: 1234567890 ISBN-13: 123-1234567890
清單 5. Details 微服務顯示內容
Reviews 微服務包含的資訊是書評內容：
An extremely entertaining play by Shakespeare. The slapstick humour is refreshing! Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare.
清單 6. 書評內容
Ratings 微服務包含的內容將展示為評星部分（下圖黑框中的部分）。
圖 22. 評星圖
接下來，我們訪問 GitHub 上檢視 bookinfo 原始碼，通過原始碼分析，理解業務的實現邏輯。
首先檢視 Productpage 的原始碼（部分內容）：
def getProducts():
return [
{
'id': 0,
'title': 'The Comedy of Errors',
'descriptionHtml': '<a href="https://en.wikipedia.org/wiki/The_Comedy_of_Errors">Wikipedia Summary</a>: The Comedy of Errors is one of < b>William Shakespeare\'s< /b> early plays. It is his shortest and one of his most farcical comedies, with a major part of the humour coming from slapstick and mistaken identity, in addition to puns and word play.'
}
清單 7. Productpage 原始碼
我們可以很明顯看出，以上程式碼就是 bookinfo 頁面顯示的書籍的名稱和簡介。
檢視 Productpage 的另外一部分原始碼。
details = {
"name" : "http://details{0}:9080".format(servicesDomain),
"endpoint" : "details",
"children" : []
}
ratings = {
"name" : "http://ratings{0}:9080".format(servicesDomain),
"endpoint" : "ratings",
"children" : []
}
reviews = {
"name" : "http://reviews{0}:9080".format(servicesDomain),
"endpoint" : "reviews",
"children" : [ratings]
}
productpage = {
"name" : "http://details{0}:9080".format(servicesDomain),
"endpoint" : "details",
"children" : [details, reviews]
}
service_dict = {
"productpage" : productpage,
"details" : details,
"reviews" : reviews,
}
清單 8. Productpage 原始碼
上面程式碼定義了四個微服務的 name、endpoint、children。endpoint 代表這個微服務後端的 Kubernetes 叢集中 service 名稱、children 代表本微服務呼叫的 Kubernetes 叢集中的微服務 service 名稱。
以 Productpage 舉例，它的 endpoint 是 details、children 是 details 和 reviews。所以，被髮送到 Productpage 請求，將會呼叫 details、reviews 這兩個服務。
接下來，檢視 reviews 微服務的原始碼，程式碼使用 Java 編寫的。
private String getJsonResponse (String productId, int starsReviewer1, int starsReviewer2) {
String result = "{";
result += "\"id\": \"" + productId + "\",";
result += "\"reviews\": [";
// reviewer 1:
result += "{";
result += "\"reviewer\": \"Reviewer1\",";
result += "\"text\": \"An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!\"";
if (ratings_enabled) {
if (starsReviewer1 != -1) {
result += ", \"rating\": {\"stars\": " + starsReviewer1 + ", \"color\": \"" + star_color + "\"}";
}
else {
result += ", \"rating\": {\"error\": \"Ratings service is currently unavailable\"}";
}
}
result += "},";
// reviewer 2:
result += "{";
result += "\"reviewer\": \"Reviewer2\",";
result += "\"text\": \"Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare.\"";
if (ratings_enabled) {
if (starsReviewer2 != -1) {
result += ", \"rating\": {\"stars\": " + starsReviewer2 + ", \"color\": \"" + star_color + "\"}";
}
else {
result += ", \"rating\": {\"error\": \"Ratings service is currently unavailable\"}";
}
}
result += "}";
result += "]";
result += "}";
return result;
}
清單 9. reviews 服務原始碼
上面的這段程式碼，定義的是兩個 Reviewer，以及書評的內容。書評的內容正是 bookinfo 頁面展示的內容。
在上面的程式碼中，我們注意到有兩個重要的變數 star_color 和 ratings_enabled。
- star_color 表示評星的顏色（黑色和紅色）。
- ratings_enabled 表示是否啟用評星。
檢視 reviews 微服務的原始碼的另外一部分內容：
private final static String star_color = System.getenv("STAR_COLOR") == null ? "black" : System.getenv("STAR_COLOR");
清單 10. reviews 服務原始碼
上面程式碼顯示：在應用構建時：
- 如果不指定 STAR_COLOR 變數且 ratings_enabled 為 true，那麼評星預設為黑色。
- 如果指定 STAR_COLOR 變數且 ratings_enabled 為 true，那麼評星顏色為傳入的顏色。
- 如果不指定 ratings_enabled 為 true，那麼將不會顯示評星。
那麼，STAR_COLOR 這個變數，在應用構建時，有沒有傳入呢？我們檢視：build-services.sh
#java build the app.
docker run --rm -v "$(pwd)":/home/gradle/project -w /home/gradle/project gradle:4.8.1 gradle clean build
pushd reviews-wlpcfg
#plain build -- no ratings
docker build -t "istio/examples-bookinfo-reviews-v1:${VERSION}" -t istio/examples-bookinfo-reviews-v1:latest --build-arg service_version=v1 .
#with ratings black stars
docker build -t "istio/examples-bookinfo-reviews-v2:${VERSION}" -t istio/examples-bookinfo-reviews-v2:latest --build-arg service_version=v2 \
--build-arg enable_ratings=true .
#with ratings red stars
docker build -t "istio/examples-bookinfo-reviews-v3:${VERSION}" -t istio/examples-bookinfo-reviews-v3:latest --build-arg service_version=v3 \
--build-arg enable_ratings=true --build-arg star_color=red .
清單 11. build-services.sh 內容
上面程式碼顯示，執行該指令碼是，將會構建三個版本 Reviews 的 docker image：
- V1：沒有評星（未指定 enable_ratings=true）。
- V2：評星為黑色（指定 enable_ratings=true；未指定 star_color 的變數，程式碼中預設的顏色為黑色）。
- V3：評星為紅色（指定 enable_ratings=true；指定 star_color 的變數為 red）。
在 bookinfo 的原始碼中，還有兩個資料庫的定義 Mongodb 和 MySQL。
接下來，我們看這個應用中兩個資料庫的內容。
先看 MongoDB 的 script.sh，內容如下：
#!/bin/sh set -e mongoimport --host localhost --db test --collection ratings --drop --file /app/data/ratings_data.json
清單 12. MongoDB 的 script.sh
也就是說，MongoDB 資料庫在初始化時，會將 ratings_data.json 檔案中的資訊匯入到資料庫中。
再看 ratings_data.json：
{rating: 5}
{rating: 4}
清單 13. ratings_data.json 檔案
也就是說，當應用部署完畢後，MongoDB 將包含五星和四星。
檢視 MySQL 的初始化檔案：mysqldb-init.sql。
# Initialize a mysql db with a 'test' db and be able test productpage with it. # mysql -h 127.0.0.1 -ppassword < mysqldb-init.sql CREATE DATABASE test; USE test; CREATE TABLE `ratings` ( `ReviewID` INT NOT NULL, `Rating` INT, PRIMARY KEY (`ReviewID`) ); INSERT INTO ratings (ReviewID, Rating) VALUES (1, 5); INSERT INTO ratings (ReviewID, Rating) VALUES (2, 4);
清單 14. mysqldb-init.sql 內容
我們可以看出，上面的初始化指令碼是建立一個名為 Ratings 的資料庫表，插入的資料效果如下：
表 1. 資料庫表示意
檢視 Ratings 的原始碼，該程式碼使用 Node.JS 書寫。
* We default to using mongodb, if DB_TYPE is not set to mysql.
*/
if (process.env.SERVICE_VERSION === 'v2') {
if (process.env.DB_TYPE === 'mysql') {
var mysql = require('mysql')
var hostName = process.env.MYSQL_DB_HOST
var portNumber = process.env.MYSQL_DB_PORT
var username = process.env.MYSQL_DB_USER
var password = process.env.MYSQL_DB_PASSWORD
} else {
var MongoClient = require('mongodb').MongoClient
var url = process.env.MONGO_DB_URL
}
}
dispatcher.onGet(/^\/ratings\/[0-9]*/, function (req, res) {
var productIdStr = req.url.split('/').pop()
var productId = parseInt(productIdStr)
if (Number.isNaN(productId)) {
res.writeHead(400, {'Content-type': 'application/json'})
res.end(JSON.stringify({error: 'please provide numeric product ID'}))
} else if (process.env.SERVICE_VERSION === 'v2') {
var firstRating = 0
var secondRating = 0
if (process.env.DB_TYPE === 'mysql') {
var connection = mysql.createConnection({
host: hostName,
port: portNumber,
user: username,
password: password,
database: 'test'
})
connection.connect()
connection.query('SELECT Rating FROM ratings', function (err, results, fields) {
if (err) {
res.writeHead(500, {'Content-type': 'application/json'})
res.end(JSON.stringify({error: 'could not connect to ratings database'}))
} else {
if (results[0]) {
firstRating = results[0].Rating
}
if (results[1]) {
secondRating = results[1].Rating
}
var result = {
id: productId,
ratings: {
Reviewer1: firstRating,
Reviewer2: secondRating
}
}
res.writeHead(200, {'Content-type': 'application/json'})
res.end(JSON.stringify(result))
}
})
清單 15. Ratings 的原始碼
以上程式碼主要實現：如果不指定 DB_TYPE 的變數，將預設使用 MongoDB 資料庫。
當微服務 Reviews 的版本是 V2 時，將連線資料庫 MySQL 或 MongoDB（根據環境變數傳入的 DB_TYPE）。當 Reviews 的版本是 V3 時，訪問 MongoDB 資料庫。
但從上面的資料庫分析我們可以知道，無論 Reviews 連線哪個資料庫，得到的資料都是第一個評論者五星、第二個評論者四星。也就是說，只要是 Reviews 的 V2 和 V3 版本，訪問資料庫得到的評星結果是一樣的；只不過 Reviews 為 V2 時評星為黑色、Reviews 為 V3 時評星為紅色。
微服務的部署
我們在 Kubernetes 叢集中部署 bookinfo 應用。
圖 23. 在 Kubernetes 叢集部署 bookinfo
Pod 建立成功：
圖 24. 檢視 bookinfo 的 Pod
接下來，通過瀏覽器對 bookinfo 發起多次訪問，頁面呈現三種顯示。
- 第一種：訪問 bookinfo 時（Productpage 呼叫的 Review V1），頁面沒有評星；
- 第二種：訪問 bookinfo 時（Productpage 呼叫的 Review V2），頁面是黑色的評星；
- 第三種：訪問 bookinfo 時（Productpage 呼叫的 Review V3），頁面是紅色的評星。
圖 25. bookinfo 第一種展現
圖 26. bookinfo 第二種展現
圖 27. bookinfo 第三種展現
過了幾秒後：Kiali 收集到之前幾次對 bookinfo 的訪問流量，並進行動態展示。我們可以看到，Productpage 隨機訪問 Reviews V1、V2、V3。
圖 28. Kiali 展示微服務流量
Productpage 輪詢訪問 Review V1 和 V2 的原因是：我們沒有設定針對 Reviews 的特定策略，而 Productpage 的原始碼中，指定了 Product 服務呼叫 Reviews 服務的業務邏輯，但並未指定版本。因此，Product 服務會隨機訪問 Reviews 的三個版本。
圖 29. 檢視 virtualservice
接下來，我們檢視 Virtualservice 的配置檔案。
30. 檢視 Virtualservice 配置檔案列表
檢視 virtual-service-reviews-v3.yaml 內容。該檔案定義發向 Reviews 的請求，全部到 V3 版本。
[root@master networking]# cat virtual-service-reviews-v3.yaml apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v3version: v3
清單 16. 檢視 virtual-service-reviews-v3.yaml 內容
接下來，應用 Virtualservice 配置。
圖 31. 應用配置
檢視生效的 Virtualservice，reviews 的配置生效。
圖 32. 檢視生效的 Virtualservice
接下來，我們再次對 bookinfo 發起多次訪問，可以看到，頁面的評星均為紅色。
圖 33. 訪問 bookinfo 應用
通過 Kiali 檢視流量，可以看到，Productpage 的流量全部訪問 Review V3。
圖 34. Kiali 檢視 bookinfo 應用訪問流量
接下來，我們繼續調整策略，讓 Productpage 對 Reviews 的訪問，以 V1 和 V2 按照 8:2 比率進行：
[root@master networking]# cat 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
清單 17. 檢視 virtual-service-reviews-80-20.yaml 內容
圖 35. 替換之前的 Virtual Services 策略
圖 36. Kiali 檢視 bookinfo 應用訪問流量
Istio 的限速
在瞭解了 Istio 微服務的路由策略後，接下來我們對微服務元件進行限速的設定。
在預設情況下，Productpage 隨機訪問 reviews 三個版本，沒有流量限制。我們編寫兩個配置檔案，限制 Productpage 到 reviews v3 的訪問速度。
speedrule.yaml 限制了從 Productpage 到 reviews v3 的訪問速度，最多每秒一個請求。
[root@master ~]# cat speedrule.yaml apiVersion: "config.istio.io/v1alpha2" kind: memquota metadata: name: handler namespace: myproject spec: quotas: - name: requestcount.quota.myproject # default rate limit is 5000qps maxAmount: 5000 validDuration: 1s # The first matching override is applied. # A requestcount instance is checked against override dimensions. overrides: - dimensions: destination: reviews source: productpage destinationVersion: v3 maxAmount: 1 validDuration: 1s recommendation_rate_limit_handler.yml 檔案聲明瞭 requestcount quota。
清單 18. 檢視 speedrule.yaml
[root@master ~]# cat recommendation_rate_limit_handler.yml apiVersion: "config.istio.io/v1alpha2" kind: quota metadata: name: requestcount namespace: myproject spec: dimensions: source: source.labels["app"] | source.service | "unknown" sourceVersion: source.labels["version"] | "unknown" destination: destination.labels["app"] | destination.service | "unknown" destinationVersion: destination.labels["version"] | "unknown" --- apiVersion: "config.istio.io/v1alpha2" kind: rule metadata: name: quota namespace: myproject spec: actions: - handler: handler.memquota instances: - requestcount.quota --- apiVersion: config.istio.io/v1alpha2 kind: QuotaSpec metadata: creationTimestamp: null name: request-count namespace: myproject spec: rules: - quotas: - charge: 1 quota: RequestCount --- apiVersion: config.istio.io/v1alpha2 kind: QuotaSpecBinding metadata: creationTimestamp: null name: request-count namespace: myproject spec: quotaSpecs: - name: request-count namespace: myproject services: - name: productpage namespace: myproject - name: details namespace: myproject - name: reviews namespace: myproject
清單 19. 檢視 recommendation_rate_limit_handler.yml
應用兩個配置：
圖 37. 應用配置
圖 38. 應用配置
然後，對 bookinfo 發起高頻度請求，訪問請求頻率為 10 次/秒。
while true; do curl http://istio-ingressgateway-istio-system.apps.example.com/productpage; sleep .1; done
清單 20. 發起高頻度訪問請求
通過 Kiali，可以看到：
圖 39. Kiali 顯示微服務流量
我們檢視 Grafana，可以看到這段時間內，reviews v3 的流量，遠低於同期 reviews v1 和 v2 的流量。
圖 40. Grafana 顯示微服務流量統計
Istio 的熔斷
熔斷技術，是為了避免"雪崩效應"的產生而出現的。我們都知道"雪球越滾越大"的現象。應用中的雪崩指的由於應用第一個元件的出現問題，造成呼叫這個元件的第二個元件有無無法呼叫第一個元件，無法實現業務邏輯，也出現問題；而呼叫第二個元件第三個元件因此也出現問題，問題迅速傳播，從而造成整個應用的癱瘓，我們稱之為應用的雪崩效應。
在單體應用中，多個業務的功能模組放在一個應用中，且由於各個功能模組之前是緊耦合，因此不容易出現雪崩情況。但由於微服務鬆耦合、各個元件呼叫關係複雜的特點，雪崩現象就較為容易出現。為了避免雪崩情況的發生，就需要有熔斷機制，採用斷路模式。熔斷機制相當於為每個微服務前面加一個"保險絲"。當電流負載過大的時候（如服務訪出現故障問超時，並且超過設定的重試次數），保險絲燒斷，中斷客戶端對該應用的訪問，而不影響客戶端訪問其他正常執行的元件。
Spring Cloud 中熔斷的實現，需要呼叫 Hystrix。而 Istio 本身自帶熔斷的功能。下面，我們進行實現展現。
在初始情況下，未配置熔斷。
圖 41. 配置熔斷之前正常訪問應用流量
接下來，我們在 Productpage 的 destination rule 中配置熔斷策略（trafficPolicy）：每個連結最多的請求數量是一個；最多 pending 的 request 是一個、最多的連線數是一個。
spec: host: productpage subsets: - labels: version: v1 name: v1 trafficPolicy: connectionPool: http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 tcp: maxConnections: 1 tls: mode: ISTIO_MUTUAL
清單 21. 在 destination rule 中配置熔斷（open.yaml 配置檔案部分內容）
接下來，我們先刪除舊的配置，應用熔斷的配置。
圖 42. 應用新配置
圖 43. 發起大併發流量後的熔斷
過一會，當問題熔斷器開啟後，業務恢復正常：
圖 44. 熔斷後的應用訪問頁面
Istio 的訪問控制
Istio 中的訪問控制有白名單和黑名單。白名單是允許從哪個服務到哪個服務的訪問；黑名單是不允許從哪個服務到哪個服務之間的訪問。兩種實現的效果展現是一樣的，由於篇幅有限，本小節展示黑名單。
我們將在 details 服務上建立一個黑名單，從 Productpage 發往 details 請求將會返回 403 錯誤碼。
[root@master ~]# cat acl-blacklist.yml apiVersion: "config.istio.io/v1alpha2" kind: denier metadata: name: denycustomerhandler spec: status: code: 7 message: Not allowed --- apiVersion: "config.istio.io/v1alpha2" kind: checknothing metadata: name: denycustomerrequests spec: --- apiVersion: "config.istio.io/v1alpha2" kind: rule metadata: name: denycustomer spec: match: destination.labels["app"] == "details" && source.labels["app"]=="productpage" actions: - handler: denycustomerhandler.denier instances: [ denycustomerrequests.checknothing ]
清單 22. 黑名單配置檔案
圖 45. 應用黑名單
接下來，對 Producepage 發起流量訪問。從下圖可以看到，從 Productpage 到 details 之間的訪問是被拒絕的。
圖 46. Kali 顯示應用流量訪問
此時，通過瀏覽器訪問 bookinfo，介面無法顯示產品的詳細資訊，但其他微服務顯示正常。
圖 47. 訪問 bookinfo 應用
我們刪除黑名單，再訪問 bookinfo，對 details 微服務的訪問馬上正常。
圖 48. 刪除黑名單策略
圖 49. Kali 顯示應用流量訪問
圖 50. 訪問 bookinfo 應用
總結
通過本文，相信讀者對微服務的概念和 Istio 的架構有了一定程度的理解。在微服務領域，正是由於 Istio 強大的功能、豐富的介面、視覺化的監控，Istio 的使用將會越來越廣泛。