1. 背景：从请求驱动到事件驱动
传统后端架构大多是 请求驱动：
- 前端发起请求 → API 网关 → 服务 → 数据库 → 返回结果。
问题是：
- 对实时性支持不足（无法应对秒级决策）。
- 服务之间强耦合（调用链复杂，容易级联故障）。
- 无法自然处理流式数据（日志、传感器、交易流）。
事件驱动架构 (Event-Driven Architecture, EDA) 提供了解法：
系统以 事件 为核心，每个事件都能触发异步处理，从而实现 松耦合、可扩展、实时性强 的后端系统。
2. EDA 的核心思想
EDA = 事件生产者 → 事件通道 → 事件消费者
- 事件生产者：业务系统、传感器、用户操作。
- 事件通道：Kafka / Pulsar / RabbitMQ 等消息流平台。
- 事件消费者：服务 / 函数 / 流处理框架。
示意架构：
[Producer] → [Kafka/Pulsar] → [Flink/Consumer] → [Database/API]
3. 主流技术栈
(1) Kafka
- 行业事实标准，生态完善。
- 适合日志收集、实时 ETL、微服务解耦。
- 缺点：存储层依赖文件系统，长时间存储成本高。
(2) Pulsar
- 原生多租户、分层存储。
- 支持消息队列 + 流式处理，功能比 Kafka 丰富。
- 云原生友好（支持 Kubernetes Operator）。
(3) Flink
- 实时流处理引擎。
- 支持事件时间 (Event Time)，保证窗口计算准确性。
- 场景：实时风控、推荐系统、日志监控。
4. 工程落地示例：实时风控系统
架构流程
- 交易系统产生支付事件 → 推送到 Kafka。
- Flink 消费事件流，实时计算风控特征。
- 风控服务根据特征打分 → 触发拦截或放行。
- 结果事件再写回 Kafka，供下游系统消费。
样例代码（Flink 流处理）
DataStream<String> stream = env
.addSource(new FlinkKafkaConsumer<>("payment", new SimpleStringSchema(), props));
stream
.map(json -> parseTransaction(json))
.filter(tx -> tx.amount > 10000)
.map(tx -> "High risk transaction: " + tx.id)
.addSink(new FlinkKafkaProducer<>("alert", new SimpleStringSchema(), props));
5. 优势
- 松耦合：事件通道解耦了生产者和消费者。
- 实时性强：支持毫秒级处理。
- 扩展性高：消费者可水平扩展，独立部署。
- 天然审计：事件日志可追溯、可重放。
6. 挑战
- 一致性保证：如何保证事件 Exactly-once 处理。
- 顺序问题：跨分区事件可能乱序，需要事件时间语义。
- 运维复杂度：Kafka/Pulsar 集群管理门槛高。
- 开发思维转变：需要习惯“最终一致性”，而非强一致事务。
7. 前沿趋势
- EDA + Serverless：事件直接触发函数执行（如 AWS Lambda、阿里云函数计算）。
- EDA + AI：事件流实时进入 LLM/RAG，支持智能风控/推荐。
- EDA + 数据湖：事件流沉淀到 Iceberg/Hudi，结合批处理做实时 + 离线统一。
- EDA + eBPF：在内核级别捕获系统事件，直接推送到流平台。
8. 总结
事件驱动架构正在成为 后端实时化的基石：
- 让系统从 被动响应请求 → 主动响应事件。
- 特别适合 高并发、高实时性、强解耦 的场景（支付、风控、物联网、日志监控）。
未来，随着 AI 实时推理 的兴起，EDA 可能会成为 AI 原生后端的必备架构模式。
