事件总线 EventBridge 实践：千里达票务系统业务事件的统一分发
接入 RocketMQ 之后，新问题：每加一个下游消费者，就要改订单服务代码，订单服务知道了太多不该知道的事（要给积分发消息、要给发票发消息、要给财务发消息）。接入阿里云事件总线 EventBridge 后，订单服务只负责发"订单已创建"这一个事件，下游谁订阅谁处理，订单服务完全解耦。
一、MQ vs EventBridge
- MQ：消息队列，强调"传消息"，生产者知道 Topic；
- EventBridge：事件总线，强调"事件订阅"，生产者只发事件，路由规则在云端配。
二、事件模型
业务事件: order.created
├─ 订阅规则1 → 发给积分服务
├─ 订阅规则2 → 发短信
├─ 订阅规则3 → 写数据仓库
└─ 订阅规则4 → 通知客服系统
三、关键实现
3.1 发事件（订单服务）
// 不关心谁订阅，只发事件
EventBridge.putEvent(
source: "ticket.order",
type: "order.created",
data: orderDTO
);
3.2 订阅规则配置
在 EventBridge 控制台配规则：
事件类型: order.created
转发目标:
1. MQ Topic (积分服务消费)
2. FC 函数 (发短信)
3. HTTP 接口 (客服系统 webhook)
3.3 Schema 演进
事件字段加了 channel，老的消费者不认识也不报错；新消费者按需读。
四、踩坑复盘
- 事件重复：下游接口超时，EventBridge 自动重试，用户收到两条通知。解决：消费端幂等；
- 事件格式不统一：不同业务团队发的事件字段名乱（orderId / order_id）。解决：团队内定事件规范，统一用小写下划线；
- 死信没人看：事件重试 3 次失败进死信，没人发现。解决：死信接告警；
- 事件太大：把整个订单对象塞事件里，10KB 一条。解决：事件只放关键 ID，下游收到再查库。
五、效果与总结
EventBridge 让千里达票务系统的业务事件真正"广播出去"，订单服务不再是所有下游的耦合点。事件驱动架构的核心不是用哪个 MQ，是让生产者和消费者通过"事件契约"解耦。
