任务场景下直接发消息到SQS与先经SNS再投递到SQS的优势对比

这个架构调整是有明确收益的，尤其适合业务处于迭代期、后续有扩展需求的场景，核心优势如下：

• 下游消费扩展零侵入
  现有直连SQS的架构下，如果你后续需要新增独立的消费逻辑（比如全量任务日志归档、独立的合规审计、异构业务系统同步消费任务），必须修改任务生成器代码，额外新增往其他队列发消息的逻辑，和下游系统耦合度极高。
  引入SNS做中转后，新增消费方只需要给对应SNS主题新增SQS订阅即可，任务生成器完全不需要做任何改造，甚至感知不到下游消费链路的变化，解耦效果非常好。
• 跨部署场景适配成本更低
  如果你的业务需要跨AWS账号、跨区域部署不同的任务处理集群，SNS原生支持跨账号、跨区域的SQS订阅，你不需要做复杂的权限配置让任务生成器访问多个不同账号/区域的SQS，只需要给SNS配置对应订阅权限即可，架构复杂度大幅降低。
• 开箱即用的服务端消息过滤
  SNS原生支持服务端消息过滤规则，你可以给不同的SQS订阅配置不同的过滤规则，只有符合规则的消息才会投递到对应队列。比如你可以将不同优先级、不同类型的任务自动分发到对应的处理队列，不需要任务生成器做路由判断，也不需要额外部署消息路由服务，简化了上游逻辑。
• 更好的故障隔离与可靠性保障
  SNS默认自带消息重试策略，投递到SQS失败的消息可以配置进入死信队列，避免消息丢失。如果某一条订阅链路的SQS出现积压或者故障，也不会影响其他订阅链路的消息投递，故障影响范围更小。

如果你的业务非常稳定，完全没有新增消费逻辑、跨部署的需求，那直连SQS的架构已经可以满足需求，额外引入SNS只会增加少量的成本和链路复杂度，没有必要做调整。

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