电商微服务场景下发布消息到SNS而非直接推SQS的优势是什么？

两种方案的核心区别 #

• 消息路由模式不同
  直接向SQS发消息是点对点单播模式，一条消息只能投递到1个指定SQS队列，仅该队列的消费者可获取消息。SNS+SQS的组合是发布订阅多播模式，消息仅需发布1次到SNS主题，所有订阅该主题的终端（包括SQS队列、Lambda函数、HTTP端点、短信服务等）都可以收到对应消息。
• 架构耦合度不同
  直接发SQS的方案中，上游交易服务需要感知所有下游SQS队列的配置信息，后续新增消费端、修改队列属性、切换队列地域等操作都需要修改上游服务的发信逻辑，耦合度极高。SNS+SQS的方案中上游仅需对接SNS主题，所有下游变更都在SNS层配置完成，上游服务完全无感知，耦合度极低。
• 消息处理能力不同
  直接发SQS没有原生的消息过滤能力，所有消息都会全量进入队列，需要消费者自行过滤不需要的消息。SNS原生支持订阅级消息过滤，可以基于消息属性、消息内容设置过滤规则，仅将符合要求的消息推送到对应SQS队列，减少无效消息占用SQS存储与消费者计算资源。

为什么AWS推荐SNS+SQS方案（即便产生额外SNS费用） #

• 适配微服务架构的扩展需求
  电商业务的下游消费场景会随着业务发展不断新增，比如后续可能需要交易数据同步到订单履约队列、财务对账队列、数据分析队列、实时风控系统等，用SNS仅需新增对应订阅即可完成配置，不需要修改上游交易服务代码，避免高频修改核心交易链路的代码带来的生产事故风险，节省的研发、运维成本远高于SNS的小额支出。
• 降低消息投递的开发复杂度
  如果需要实现多消费端投递，直接发SQS的方案需要自行开发多目标发送、失败重试、死信处理、投递一致性保障等逻辑，开发和维护成本极高。SNS原生已经实现了以上所有能力，仅需通过控制台或接口配置即可使用，不需要额外开发。
• 多消费端场景下成本更低
  当消费端数量≥2时，直接发SQS需要为每个队列单独发起一次发送请求，SQS调用费用随消费端数量线性增长。使用SNS仅需发起1次发布请求，SNS自动完成多端投递，总费用为1次SNS调用费+N次SQS投递费，相比直接发多队列的成本更低。

如果你的交易数据当前及可预见的未来都确定只有1个SQS队列消费，没有新增其他消费端的需求，直接发SQS是更简单、成本更低的选择。AWS的推荐针对的是通用微服务场景，默认考虑了业务后续的扩展性需求。

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