可扩展的微服务演示 Kubernetes Istio Kafka


【编者的话】本文将演示使用 Kafka 的异步通信的高度可扩展微服务应用。

系列内容

本系列使用不同的技术创建相同的可伸缩微服务应用程序:
  1. 本文
  2. 使用 AWS Lambda Kinesis 的可扩展的无服务器微服务演示
  3. 使用 Knative 和 Kafka 的可扩展的无服务器微服务演示(计划中)


本文关于什么?

本文描述了使用 Kubernetes,Istio 和 Kafka 的高度可扩展的微服务演示应用程序。通过同步的 REST API 调用,可以创建用户。在内部,所有通信都是通过 Kafka 异步完成。
1.png

Image 1:Architecture overview

Kafka 消费者/生产者 “用户审批服务” 会根据 Kafka 主题中有多少未处理的消息自动缩放(HPA)。还有一个节点/集群缩放器。

我们将扩展到每秒23000个 Kafka 事件,11个 Kubernetes 节点和280个 Pod。
2.png

Image 2:Results overview

该应用程序完全使用 Terraform 编写,并且可以使用一条命令来运行。

技术栈

  • Terraform
  • (Azure)Kubernetes、MongoDB、Container Registry
  • (ConfluentCloud)Kafka
  • Istio
  • Grafana、Prometheus、Kafka Exporter、Kiali
  • Python、Go


资料库

https://github.com/wuestkamp/s ... -demo

查看自述文件以获取有关如何运行程序的说明。

架构图

3.png

Image 3:Architecture

我们有三个微服务:
  • 操作服务(Python):接收同步的 REST 请求,并将其转换为异步事件。将请求作为“操作”进行跟踪,并将其存储在自己的数据库中。
  • 用户服务(Python):处理用户创建并将其存储于自己的数据库中。
  • 用户审批服务(Go):可以批准/拒绝用户,无状态服务。


Kafka 集群由 ConfluentCloud 管理,Mongo 数据库和 Kubernetes 集群由 Azure 管理。

每个服务的数据库

我们不会使用多个服务共享一个大型数据库,每个服务都有自己的数据库(如果是有状态的)。我们仍然只有一台 MongoDB 数据库服务器,但是在一台服务器上可以存在多个数据库。如果微服务使用相同的类型/版本,则它们可以共享相同的数据库服务器。详细内容请阅读这里

异步通信

这三个微服务彼此异步通信,没有直接的同步连接。异步通信的优点之一是松耦合。如果用户审批服务停止服务了一段时间,请求不会失败,只是需要更长的时间,直到用户获得审批完成。因此,在使用异步通信时,无需执行重试或断路器。

消息的流程图

4.png

Image 4:Message workflow

图四显示了消息是如何生成和消费的。用户服务使用用户创建的消息,创建待审批的用户并存储于MongoDB,然后生成用户审批的消息。

一旦收到来自用户审批服务的用户批准响应消息,它将更新用户为“批准”或“未批准”,并生成用户创建响应消息,操作服务将接收该消息,该消息将更新操作状态为“完成”。

SAGA 模式

当使用一个大型(MySQL)关系数据库时,你只需将操作包装在数据库事务中即可。SAGA模式可用于实现类似于ACID的事物,可用来跨多个微服务进行操作。

在图4中,可以将用户服务视为SAGA用户创建的协调器。因为它通过生产和消费各种消息来协调用户的创建。在此示例中,仅涉及一项服务(用户审批服务),但是如果有更多服务,可能会变得更加复杂。

可以将SAGA与状态机进行比较并实现为状态机。了解更多关于SAGA模式以及编排和编排之间的区别,请阅读这里:https://microservices.io/patterns/data/saga.html

同步 <-> 异步转换

5.png

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完美结合,并立即为我们提供了概要图:
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

13.png

Image 13: 23000 !

回顾

该应用程序自动扩展到约280个用户审批服务Pod,11个Node节点,每秒处理约23000个事件!这是一个不错的开始:)

这仅受 Azure 账户的计算限制,无法再创建更多Node节点。

原文链接:Scalable Microservice Demo K8s Istio Kafka (翻译:xiebo)

0 个评论

要回复文章请先登录注册