如何实现SNS根据条件向不同订阅者推送消息

AWS SNS完全可以实现按条件向指定订阅者投递消息，不需要额外搭建中转服务，针对你描述的业务服务故障时才投递SQS的场景，有两种成熟的生产级实现方式：

• 方案1：SNS原生订阅过滤策略（成本最低，配置最简单）
  SNS默认全量投递是因为所有订阅默认没有配置过滤规则，你可以给每个订阅单独配置Subscription Filter Policy，只有消息属性匹配规则的前提下，SNS才会向该订阅投递消息。
  针对你的场景配置逻辑如下：

  1. 业务服务的订阅配置宽松过滤规则，保证所有正常发布的消息都能优先投递到业务服务，不做拦截
  2. SQS队列的订阅配置严格过滤规则：仅当消息携带biz_service_status: down的属性时，才接收对应消息
  3. 部署一个轻量的独立健康检查探针，按固定频率探测业务服务的存活状态：
     • 服务正常运行时，所有发布到SNS的消息不携带biz_service_status: down属性，此时SQS订阅不满足过滤规则，不会收到任何消息
     • 探针探测到服务宕机时，通知SNS发布端给所有待发消息加上biz_service_status: down属性，此时消息会同时投递到业务服务（此时服务不可达，投递失败会走SNS内置的重试策略，不影响流程）和SQS队列，实现故障时消息入队暂存
       这个方案的过滤逻辑完全在SNS侧执行，不需要改动核心业务逻辑，只需要在健康状态变化时调整消息附带的属性即可，没有额外的性能损耗。

• 方案2：SNS对接EventBridge做灵活路由（适合多条件复杂判断场景）
  如果你的路由判断逻辑比较复杂，比如需要结合消息正文内容、多个依赖服务的状态做综合判断，可以把SNS的消息统一投递到EventBridge事件总线，在总线层配置路由规则：

  1. 配置第一条规则：当健康检查返回业务服务状态正常时，仅将消息转发到业务服务的接入端点，不向SQS转发
  2. 配置第二条规则：当健康检查返回业务服务状态异常时，将消息同时转发给业务服务做重试、转发到SQS队列做持久化暂存
     这个方案的优势是规则匹配能力更强，支持直接对消息正文做字段匹配，健康检查的状态可以作为EventBridge的自定义上下文参数直接参与规则判断，不需要在消息发布端手动打属性标记。

注意：不建议在业务代码里硬写路由判断逻辑，这种方式会把消息路由逻辑和业务逻辑强耦合，后续新增订阅者或者调整路由规则时改造成本极高。上面两种方案都是云厂商原生提供的能力，稳定性和SNS默认全量投递能力一致，生产环境已经有大量落地案例。

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