Kafka 不难,只是你用得不对
本文分享使用 Kafka 的一些经典模式。有时你感觉 Kafka 好难搞,可能是因为不了解这些模式。
让我们从基础开始:
1.每个事件类型一个主题
反模式:
orders-service-topic
shipping-service-topic
analytics-service-topic
每个服务都有自己的主题?不不不,你要这么搞,那就不是事件驱动设计了,这种设计只能看做是多了些步骤的远程过程调用(RPC)。
正模式:
order.created
order.shipped
order.cancelled
主题应该表示一个什么什么事件,多个服务可以对同一事件做出反应,这样你的架构才能保持松耦合。
2.消费者组 = 一个逻辑工作单元
消费者组很简单:一个组 = 一个合理的业务目的。
但很多团队都把这一点搞砸了。他们为每个实例创建一个消费者组,更糟糕的是,还会为不同的任务重复使用同一个组。
正模式:
- inventory-updater 仓库更新器
- email-sender 邮件发送器
- analytics-processor 分析处理器
这些中的每一个都是独立的组。它们都使用 order.created
并独立完成自己的工作。
这将所有内容解耦。它还具有出色的扩展性——Kafka 会在同一组内的消费者之间对分区进行负载均衡。
3.避免无状态的链式事件
假设你收到一个 order.created
的消息,然后你甚至没有检查任何内容就立即发布一个 order.verified
的消息。这很危险。不要把 Kafka 变成一个愚蠢的消息传递者。
正模式:事件 + 状态。
不要为了模拟工作流程而将五个事件串联在一起,而是让事件触发一个拥有逻辑和状态的服务,并且仅在必要时发出下一个事件。
这样可以避免意外的无限循环、幽灵事件和令人困惑的重放错误。
4.使用发件箱模式
有没有试过在插入数据库后向 Kafka 发送消息,结果 Kafka 调用失败?现在你的数据库已更新……但 Kafka 从未收到该消息。恭喜你——你刚刚制造了一个不一致性!
发件箱模式来解决这个问题
将事件作为同一事务的一部分存储在你的数据库中,如下所示:
BEGIN;
INSERT INTO orders (...) VALUES (...);
INSERT INTO outbox (event_type, payload) VALUES ('order.created', '{...}');
COMMIT;
然后运行一个后台任务,读取 outbox 表并将事件发送到 Kafka。
原子!可靠!可重放!
5.采用退避重试
人们认为“Kafka 让一切都可重放”,所以他们滥用它。他们只是不假思索地重新消费失败的事件。
但如果错误是由于下游系统宕机导致的呢?(比如A服务消费Kafka消息时要调用B服务做一些逻辑,此时B服务挂了,进而导致最终未能成功消费)
使用带有指数退避的重试队列,或者使用像Kafka Streams / Debezium这样内置错误处理功能的框架。
或者手动创建如下主题存放消费失败的消息,延迟重试:
- order.created.retry.1m
- order.created.retry.10m
- order.created.dlq
巴辉特提醒:这种 retry 队列的模式很有意思,之前我也未曾关注过。通常来讲,建议一个 topic + 一个 consumer group 作为颗粒度创建一套 retry 队列,因为事件可能有多个 consumer group 来消费。这个知识有点绕,大家可以通过 GPT 了解更多细节。
举例,比如 100 条事件里只有 1 条消费失败,如果持续重试这一条,持续失败,就会影响后面的事件消费。
当然,如果你们的业务逻辑就必须得严格要求顺序,那另当别论,case by case 来看哈。
6. Schema 要全局统一
如果您的事件看起来像这样:
{
"id": 123,
"user": "john",
"total": 100
}
这样没问题……直到有人添加了一个新字段:
{
"id": 123,
"user": "john",
"total": 100,
"vip": true
}
现在,你的使用者程序出现故障。或者更糟的是—— 悄无声息地出现异常行为。
巴辉特提醒:这个意思是说,consumer 不知道事件格式发生变化,可能会引起故障,需要一个机制,让所有人知道消息格式变了,而且消息格式需要兼容性。
使用 Avro/Protobuf + Schema Registry,你会得到:
- 向前/向后兼容性
- 严格类型标注
- 演进支持
当团队壮大时,你会感谢自己的这种做法。
简单的Kafka架构图
+------------------+
| Order Service |
|------------------|
| Emits: order.created |
+--------+---------+
|
v
+--------+---------+
| Kafka |
|-------------------|
| Topics: |
| - order.created |
| - order.retry |
| - order.dlq |
+--------+----------+
|
+-----------+------------+
| | |
v v v
+-----------+ +--------------+ +------------------+
|Inventory | |Email Service | |Analytics Service |
|Updater | |(Consumer) | |(Consumer) |
+-----------+ +--------------+ +------------------+
每个服务都是一个独立的消费者组,对相同的事件做出反应。发件箱模式(未显示)在生产者端实现。
最终想法
Kafka 并不难。你跳过了那些让事情变得易于处理的模式,结果反而把事情弄复杂了。
你越早遵循这些原则,Kafka就越早成为一个健壮、可扩展的事件驱动系统的支柱,而不是凌晨3点令人头疼的调试难题。
原文:https://codingplainenglish.medium.com/kafka-is-hard-because-you-keep-ignoring-these-patterns-588b2ebac3c0