基于Azure Service Bus的事件驱动微服务架构主题设计最佳实践咨询

针对你提出的Azure Service Bus事件驱动微服务场景，行业主流最佳实践是优先采用「按业务域/事件聚合维度拆分主题」的方案，也就是介于你提到的方案一和方案二之间的颗粒度，其次才是纯按事件类型拆分的方案二，方案一和方案三属于极端不推荐的选型。

方案一：单一主题承载所有类型事件 #

• 优势：仅需维护1个主题资源，初期配置成本极低，事件发布侧无需做路由判断
• 劣势：
  • 订阅侧过滤成本极高，所有微服务都需要在订阅规则中过滤大量无关事件，不仅额外占用Service Bus计算资源，还会增加事件传输、过滤的链路延迟
  • 权限管控粒度极粗，无法针对特定事件类型设置单独的发布/订阅权限
  • 故障影响范围全局，单主题流量过载、出现故障时所有事件链路都会中断
  • 可扩展性极差，后续事件类型持续扩容后，过滤规则会越来越复杂，极易出现配置错误导致的事件漏消费、错消费问题

方案三：为每个微服务单独创建主题 #

• 优势：微服务订阅逻辑非常简单，不需要做任何事件过滤
• 劣势：
  • 发布侧逻辑极度复杂，每发布一个事件需要先感知所有订阅该事件的微服务对应的主题，向多个主题重复推送同一份事件，严重浪费存储、带宽资源，还会大幅提升事件发布不一致的风险
  • 资源数量随微服务数量线性增长，运维成本极高，后续新增微服务订阅事件时，还要修改所有对应事件发布侧的路由逻辑，完全违背事件驱动架构的发布订阅解耦原则
  • 事件溯源、审计难度极大，同一份事件散落在多个不同主题中，无法统一追踪全链路流转情况

方案二：为每类事件单独创建主题 #

• 优势：
  • 订阅侧不需要配置复杂过滤规则，直接订阅对应事件类型的主题即可，资源利用率高，事件投递延迟低
  • 权限管控、流量监控、故障隔离都可以做到单事件类型粒度，运维风险可控
  • 发布侧和订阅侧完全解耦，发布方只需要知道事件对应的主题，不需要关心下游有哪些订阅方
• 劣势：
  • 如果事件类型数量极多（比如超过上百种），会导致主题数量爆炸，整体运维成本上升
  • 同一业务域的关联事件分散在不同主题，无法实现跨事件类型的批量订阅、统一权限管控

优先按照业务域/事件聚合粒度拆分主题，而非极端的单主题、单微服务主题或者纯单事件类型主题：

1. 首先对所有事件做领域划分，比如归为「订单域事件」「用户域事件」「支付域事件」等，每个业务域对应一个主题，同一个域下的多个关联事件类型放在同一个主题中
2. 订阅侧如果只需要消费域内某一类事件，用Service Bus订阅规则做轻量过滤即可，同一个域的过滤规则复杂度很低，不会带来明显性能损耗
3. 如果某类事件的流量特别大、或者有独立的权限、SLA要求，可以单独拆分为独立主题，不用强行归到某个业务域下

这种拆分方式既避免了单主题的性能和稳定性风险，也避免了主题数量过多导致的运维成本过高问题，同时完全符合事件驱动架构的解耦设计要求。

内容的提问来源于stack exchange，提问作者user11081980