云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！
本文将演示使用 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”