雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
本文将示範使用 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與狀态機進行比較并實作為狀态機。
同步 <-> 異步轉換
Image 5：Sync to Async conversion
1.圖5顯示，首先對操作服務進行同步REST調用以建立一個新操作，這種情況為“使用者建立”。操作服務發出異步消息，然後立即以挂起狀态傳回新操作。
2.傳回的操作包含一個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完美結合，并立即為我們提供了概要圖：
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個新事件。
Image 7：topic user-approve lag is rising
從左到右，我們看到：
- Kafka事件/秒
- 尚未處理（滞後）使用者審批事件
- 使用者審批服務Pod數量
- Node節點數量
使用者審批服務在處理消息後會休眠200毫秒。這意味着如果隻有單個執行個體并且新事件不斷出現，使用者審批服務将落後，如圖7所示。
開啟縮放
現在啟用了HPA，并且不斷增加REST請求以建立新使用者。
Image 8：no load, but we start with 9 Nodes for faster scaling
Image 9: Requests hitting, we see HPA scaling up the Kafka consumer UserApprovalService
Image 10：2045 Events per second
Image 11：First node scaling
Image 12：Close to 20000 Events per second
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-06-22
本文作者：jackbb
本文來自：“
dockone”，了解相關資訊可以關注“dockone”