大多数基础设施故事都是在某个东西坏掉后写成的。这个故事不同。凌晨3点，没有人因为Kafka而通知Celestina Amadi的团队。虚拟机在正常工作，然而她还是决定重建，因为她能看到事情在发展成为问题之前的状态。Celestina Amadi领导着支持Moniepoint支付和储蓄产品的基础设施的云工程团队，每天为数百万客户可靠地传输交易和储蓄数据。她还是Grafana专家、HashiCorp大使，以及2026年IBM冠军。━━━━━━━━━━我们转向Strimzi的原因这不是危机，而是一个决定。我们转向Strimzi是因为我们诚实地审视了运行Kafka的方式，并做出了一个深思熟虑的决定：这种方式不可扩展，我们可以做得更好。这种决策实际上比在危机中反应要困难。事件是显而易见的——某件事情坏掉了，你去修复它。主动的架构改变需要你足够清晰地看到不适，并提前采取行动，避免它演变成灾难。它要求你说“这在工作，但还不够好”，并且要认真对待。这是我们看到的，我们构建的，以及它教会我们系统思维的故事。我们是如何运行Kafka的我们的Kafka设置开始于快速发展的工程团队中大多数事情的方式：务实。我们需要CDC数据管道。从数据库A到Kafka再到数据库B，从数据库C到Kafka再到数据库D。多个管道，每个管道服务于不同的业务流程。我们在虚拟机上启动了Kafka实例，根据需要使用Docker Compose进行管理。它们工作得不错。我们继续前进。随着时间的推移，问题开始显现。每次更改都需要SSH和端口转发。我们的Kafka实例没有URL。你通过localhost访问它们。要进行任何更改，无论是添加源连接器、添加汇、还是更新配置，你都必须SSH到服务器上，进行端口转发以获取本地访问权限，手动进行更改。每次都是如此。在每一个实例中。使用Docker Compose时，停机时间总是一个命令之遥。使用Docker Compose管理Kafka可以正常工作，直到有一天不能。任何需要重启堆栈的更新或修复都意味着运行`docker compose restart`并希望重启顺利进行。对于数据管道而言，这并不是一个舒适的状态。版本开始过时，而更新则是每个实例分别进行。Kafka在发展。新的版本发布了。但是因为每个实例都是独立管理的虚拟机，升级意味着要一个个进入每个实例。更糟的是，我们的实例甚至不一致。有些运行在ZooKeeper上，有些在Kafka发展时采用了Raft。不同的共识模型、不同的操作行为，触碰任何东西之前需要知道的东西都是不同的。配置一个新的管道意味着重新发明轮子。没有标准流程，没用共享配置。每个新的CDC管道都是一套新的决策：选择哪个版本，哪个共识模型，哪个配置。对每个集群工作方式的了解掌握在设置它的人的手中。监控是手动的。我们使用JMX Exporter来提取指标，最终将日志发送到Loki。这些工具提供了一些帮助。然而，它们是在一个仍然需要你SSH进入正确实例以诊断任何东西的操作模型之上的层。没有统一的视图来查看整个集群。以上所有都没有以一种触发警报的方式坏掉。只是慢，手动，并且随着集群的扩大而变得越来越不一致。我们耗费了很多开发时间在本应自动化的操作上。什么是Strimzi？在进入我们如何实现它之前，了解核心思想非常重要。Strimzi是在Kubernetes集群上运行的Kafka，由Kubernetes操作员管理。操作员是运行在你的集群内的一种软件，不断代表你管理另一个应用程序。它监视一组配置文件，并确保你的Kafka部署的实际状态始终与所声明的状态一致。如果有什么偏离，操作员将纠正它。如果某个代理宕机，操作员将使其恢复正常。关键的转变：你不再是操作员。软件成为了操作员。Strimzi是开源的，并且是CNCF的一部分——没有许可费用，没有供应商锁定。所有内容都通过Kubernetes自定义资源（CRDs）进行表达，这意味着你整个Kafka设置都是存在于Git中的代码。我们是如何实现的我们并不是简单地将Strimzi放到现有集群上就算完成。我们对结构进行了深思熟虑的决策。专用Kubernetes集群：我们在GCP/GKE上创建了一个专用集群用于我们的Kafka工作负载。将Kafka分离到自己的集群上使我们能够获得清晰的资源边界，并独立于我们的应用工作负载更容易地管理容量。每个管道的命名空间隔离：在该集群内，每个Kafka部署都有自己的命名空间。数据库A到数据库B的管道有其自己的命名空间。数据库C到数据库D的另一个命名空间。