雲棲號資訊：【點擊查看更多行業資訊】
在這裏您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
本文將演示使用 Kafka 的異步通信的高度可擴展微服務應用。
系列內容
本系列使用不同的技術創建相同的可伸縮微服務應用程序：
1.本文
2.使用 AWS Lambda Kinesis 的可擴展的無服務器微服務演示
3.使用 Knative 和 Kafka 的可擴展的無服務器微服務演示（計劃中）
本文關於什麼？
本文描述了使用 Kubernetes，Istio 和 Kafka 的高度可擴展的微服務演示應用程序。通過同步的 REST API 調用，可以創建用戶。在內部，所有通信都是通過 Kafka 異步完成。
Image 1：Architecture overview
Kafka 消費者/生產者 “用戶審批服務” 會根據 Kafka 主題中有多少未處理的消息自動縮放（HPA）。還有一個節點/集羣縮放器。
我們將擴展到每秒23000個 Kafka 事件，11個 Kubernetes 節點和280個 Pod。
Image 2：Results overview
該應用程序完全使用 Terraform 編寫，並且可以使用一條命令來運行。
技術棧
- Terraform
- （Azure）Kubernetes、MongoDB、Container Registry
- （ConfluentCloud）Kafka
- Istio
- Grafana、Prometheus、Kafka Exporter、Kiali
- Python、Go
架構圖
Image 3：Architecture
我們有三個微服務：
- 操作服務（Python）：接收同步的 REST 請求，並將其轉換爲異步事件。將請求作爲“操作”進行跟蹤，並將其存儲在自己的數據庫中。
- 用戶服務（Python）：處理用戶創建並將其存儲於自己的數據庫中。
- 用戶審批服務（Go）：可以批准/拒絕用戶，無狀態服務。
Kafka 集羣由 ConfluentCloud 管理，Mongo 數據庫和 Kubernetes 集羣由 Azure 管理。
每個服務的數據庫
我們不會使用多個服務共享一個大型數據庫，每個服務都有自己的數據庫（如果是有狀態的）。我們仍然只有一臺 MongoDB 數據庫服務器，但是在一臺服務器上可以存在多個數據庫。如果微服務使用相同的類型/版本，則它們可以共享相同的數據庫服務器。詳細內容請閱讀這裏。
異步通信
這三個微服務彼此異步通信，沒有直接的同步連接。異步通信的優點之一是松耦合。如果用戶審批服務停止服務了一段時間，請求不會失敗，只是需要更長的時間，直到用戶獲得審批完成。因此，在使用異步通信時，無需執行重試或斷路器。
消息的流程圖
Image 4：Message workflow
圖四顯示了消息是如何生成和消費的。用戶服務使用用戶創建的消息，創建待審批的用戶並存儲於MongoDB，然後生成用戶審批的消息。
一旦收到來自用戶審批服務的用戶批准響應消息，它將更新用戶爲“批准”或“未批准”，並生成用戶創建響應消息，操作服務將接收該消息，該消息將更新操作狀態爲“完成”。
SAGA 模式
當使用一個大型（MySQL）關係數據庫時，你只需將操作包裝在數據庫事務中即可。SAGA模式可用於實現類似於ACID的事物，可用來跨多個微服務進行操作。
在圖4中，可以將用戶服務視爲SAGA用戶創建的協調器。因爲它通過生產和消費各種消息來協調用戶的創建。在此示例中，僅涉及一項服務（用戶審批服務），但是如果有更多服務，可能會變得更加複雜。
可以將SAGA與狀態機進行比較並實現爲狀態機。
同步 <-> 異步轉換
5.png
Image 5：Sync to Async conversion
圖5顯示，首先對操作服務進行同步REST調用以創建一個新操作，這種情況爲“用戶創建”。操作服務發出異步消息，然後立即以掛起狀態返回新操作。
返回的操作包含一個UUID，可以使用該UUID定期獲取該操作的當前狀態。該操作將根據其他服務提出的異步請求進行更新。
基於 Kafka 消息計數的擴展
Kubernetes 集羣擴展在 Azure 上使用 Terraform 配置。在用戶審批服務的部署上，我們還有一個HPA（水平Pod自動縮放器）。
HPA會監聽一個自定義指標，該指標提供有關用戶審批的Kafka主題中尚未處理的消息數量。如果有消息排隊，我們會增加更多的Pod。
用戶審批服務在處理消息後會休眠200毫秒。這意味着如果它是唯一實例，並且不斷收到新消息，它將會落後。
監控與指標
我們使用 Prometheus 和 Grafana 實現可視化。
Kafka 指標
我們使用 kafka_exporter 從Kafka獲取指標，它可以爲Prometheus和Grafana提供這些指標。我們在用戶審批服務的每個Pod中將kafka_exporter作爲sidecar，以便可以從每個Pod中或者爲每個Pod使用指標。
爲了使這些Kafka Prometheus指標可用作 Kubernetes 的自定義指標（HPA 必需），我們使用 k8s-prometheus-adapter。
confirm install
kubectl api-versions | grep "custom.metrics"
list Kafka topic metrics
kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1 | jq
list Kafka topic metrics for every pod
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pod/*/kafka_consumergroup_lag" | jq
更多詳細信息請訪問該項目的prometheus-adapter.yaml。現在我們可以將這些Kafka指標用於Kubernetes HPA 。
Istio指標/ Kiali
Kiali與Istio完美結合，並立即爲我們提供了概要圖：
6.png
Image 6：Kiali network
6中，我們看到REST請求命中Istio Gateway，然後是操作服務。其餘的通信都通過“PassthroughCluster”進行，這是外部託管的Kafka。我們還可以看到kafka-exporter正在與Kafka進行通信以收集指標。
到目前爲止，Istio無法更加詳細地管理Kafka流量，而是將其作爲TCP進行處理。Envoy似乎已經能夠做到這一點，這意味着Istio將效仿。我們可能還會看到Kiali的進步，例如在邊緣顯示每秒的消息數。
在Joel Takvorian的Twitter線程中瞭解更多信息，他在其中設法將Kafka節點包含在Kiali服務圖譜中。
行動
現在，樂趣開始了。
用戶審批服務落後了
在未啓用HPA的情況下，我們每秒創建約60個新事件。
7.png
Image 7：topic user-approve lag is rising
從左到右，我們看到：
Kafka事件/秒
尚未處理（滯後）用戶審批事件
用戶審批服務Pod數量
Node節點數量
用戶審批服務在處理消息後會休眠200毫秒。這意味着如果只有單個實例並且新事件不斷出現，用戶審批服務將落後，如圖7所示。
開啓縮放
現在啓用了HPA，並且不斷增加REST請求以創建新用戶。
8.png
Image 8：no load, but we start with 9 Nodes for faster scaling
9.png
Image 9: Requests hitting, we see HPA scaling up the Kafka consumer UserApprovalService
10.png
Image 10：2045 Events per second
11.png
Image 11：First node scaling
12.png
Image 12：Close to 20000 Events per second
【雲棲號在線課堂】每天都有產品技術專家分享！
課程地址：https://yqh.aliyun.com/live立即加入社羣，與專家面對面，及時瞭解課程最新動態！
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK
原文發佈時間：2020-06-23
本文作者：XXXX
本文來自：“XXXX公衆號”，瞭解相關信息可以關注“XXXX”