从API到事件驱动：现代Java后端架构演进实践
这次故障发生在我们年度最大的促销活动期间。我们的订单处理系统陷入了停滞：客户可以将商品加入购物车，但结算过程却屡屡失败。工程团队紧急排查日志，发现是一连串同步 REST API 调用在高负载下发生了崩溃。服务 A 调用服务 B，服务 B 又调用服务 C。当服务 C 因数据库锁导致响应变慢时，延迟会沿着调用链向上蔓延。服务 A 超时，服务 B 超时，整个订单处理流程随之瘫痪。我们每分钟都在蒙受损失。这次事件迫使我们重新思考架构，意识到同步 API 并不适用于所有交互场景。我们需要解耦服务，构建一个事件驱动的系统。
在本文中，我将分享我们如何利用 Java 和 Kafka 从紧耦合的 API 架构迁移到事件驱动设计，并详细说明转型过程中面临的挑战以及处理异步通信所需的代码变更。这不仅是关于微服务的理论探讨，更是我们稳定平台所采取的实际步骤。构建弹性后端系统不仅仅是选择正确的工具，更需要理解一致性与可用性之间的权衡。
同步陷阱
我们最初的设计遵循标准的 REST 原则。每个微服务都对外暴露端点供其他服务调用。这对于简单的读取操作效果良好，但对于涉及多个领域（Domain）的复杂工作流却行不通。订单创建流程涉及库存管理、支付处理和通知服务，每一步都依赖前一步的成功完成。
问题在于延迟累积。如果每个服务增加 50 毫秒的延迟，总请求时间会迅速增长。在高负载下，网络开销增加，数据库连接变得稀缺，线程因等待响应而阻塞，线程池迅速耗尽。系统进入了“死亡螺旋”，重试机制反而加剧了拥塞。我们需要打破这些依赖关系。
事件驱动的转型
我们决定引入 Apache Kafka 作为我们的事件主干。服务不再直接相互调用，而是在状态发生变化时发布事件。其他服务通过订阅这些事件并独立做出响应，从而实现了生产者与消费者的解耦。
订单服务可以发布 OrderCreated 事件并立即返回成功。库存服务异步消费该事件并预留库存；支付服务则独立消费事件并处理扣款。这种变更显著提高了韧性：如果库存服务宕机，订单服务仍能继续接收订单，事件会暂存在 Kafka 中，直到库存服务恢复。我们消除了级联故障场景，系统能够在不崩溃的情况下吸收流量峰值。
Java 实现细节
我们使用 Spring Boot 和 Spring Cloud Stream 进行集成，这抽象掉了大部分 Kafka 的样板代码。我们为每个服务定义了输入和输出通道，代码变得声明式而非命令式。
（此处为原文图片：订单服务中事件生产者的结构）
（此处为原文图片：库存服务中的消费者逻辑）
这种简单的模式取代了复杂的 REST 客户端代码。我们从应用层移除了重试逻辑，因为 Kafka 负责重试；移除了服务间的熔断器，因为服务不再直接耦合。尽管增加了基础设施，但架构反而变得更加简洁。
处理重复事件
事件驱动系统带来了新的挑战。Kafka 默认提供“至少一次（At-least-once）”交付保证，这意味着消费者可能会多次收到同一个事件。我们最初的实现非幂等，导致处理重复事件时重复预留了库存，造成数据不一致，库存计数甚至出现了负数。
我们通过实现幂等性检查解决了这个问题。每个事件都携带一个唯一的关联 ID（Correlation ID），消费者将已处理的 ID 存储在数据库表中。在处理事件前，消费者先检查该表，如果 ID 已存在，则跳过处理。
（此处为原文图片：处理重复事件）
从业务逻辑的角度来看，这确保了每个订单只被处理一次。与数据损坏的风险相比，数据库检查的开销微乎其微。我们认识到，最终一致性需要对状态进行精细化管理。
模式演进与兼容性
另一个挑战是管理事件模式（Schema）。服务是独立演进的，订单服务可能会添加新字段，而库存服务可能无法识别。我们使用带有 Schema Registry 的 Apache Avro 来管理，强制执行兼容性规则。我们将注册表配置为允许向后兼容的变更——添加可选字段是安全的，而删除字段则需要弃用周期。这防止了破坏性变更进入生产环境。我们将事件契约视为公共 API，变更需要团队间的协调，从而避免了消费者忽略新数据导致的静默失败。
分布式流程中的可观测性
调试事件驱动系统比调试 REST API 更难，因为请求不再遵循单一路径，而是分支到多个消费者。追踪单一订单需要关联跨服务的事件。我们使用 OpenTelemetry 实现了分布式追踪，在事件头中传播 Trace ID，每个消费者延续追踪跨度（Trace Span）。这使我们能够在 Grafana Tempo 中可视化完整流程，观察每个服务处理事件的时间，并识别滞后的慢消费者。
我们还监控了消费者滞后（Consumer Lag）指标。Kafka 暴露了最新偏移量与已提交偏移量之间的差值，高滞后预示着消费者处理缓慢。我们为此设置了告警，如果滞后超过阈值，值班团队会收到通知，从而在用户察觉到延迟之前对消费者进行扩容。
何时不应使用事件
事件驱动架构并非万能药。我们曾尝试将事件用于用户登录认证，但失败了，因为登录需要即时反馈。事件本质上是异步的，会引入延迟。我们最终将事件保留用于后台处理和数据传播，如订单履约和通知发送；而用户认证和实时余额查询则保持同步，使用 REST API 进行请求-响应交互。理解这种区别是我们成功的关键。
经验教训与最佳实践
我们的迁移总结了以下几点经验：
- 为失败而设计：假设消费者会失败，确保事件可以重放，并将事件存储在持久化日志中。
- 监控滞后：消费者滞后是最重要的指标，它比 CPU 使用率更能反映系统健康状况。
- 事件版本化：从第一天起就规划模式变更，使用注册表来强制兼容性。
- 测试集成：单元测试是不够的，必须在测试环境中验证完整事件流，并核实消费者处理重复数据的能力。
- 保持事件精简：大型事件会拖慢处理速度，仅包含必要数据，必要时通过 ID 引用大负载。
- 保护主题：限制对 Kafka 主题的访问，使用 ACL 防止未经授权的发布或消费。
- 文档化流程：事件流是不可见的，请记录每个事件类型由哪个服务生产和消费。
结论
从 API 转向事件驱动系统是一项重大工程，它要求代码和思维方式的双重转变。我们不再以请求和响应的角度思考，而是转向状态变更和反应。结果是一个更具韧性和可扩展性的平台。我们的订单处理系统现在可以在没有停机的情况下处理峰值负载，单个服务的故障也不会拖垮整个系统。Java 为构建此类系统提供了强大的工具，Spring Cloud Stream 和 Kafka 的集成非常无缝。虽然解耦增加了复杂性，但对于大规模应用而言，其收益远大于成本。我们仍在不断优化架构，并正在探索关键领域的事件溯源（Event Sourcing）。从同步到异步的旅程仍在继续。祝大家构建愉快，保持系统解耦！