云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！

---

本文将演示使用 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”