MSK vs SQS + SNS

Question

我正在决定是否应该使用 AWS 的 MSK（托管 Kafka）或 SQS + SNS 的组合来实现发布订阅模型？

背景

目前，我们拥有微服务架构，但不使用任何消息服务，而只使用 REST API（不要问为什么-与一些设计架构的第三方供应商有关）。现在，我想重新设计它，并开始使用消息传递来进行微服务之间的通信。

起初，计划是开始发布实体事件以供其他微服务消费-这些事件也将存储在数据湖中，在 S3 中也会成为启动数据团队的基础。

随后，我想将某些功能从 REST 移动到异步通信。

无论如何，我主要的问题是-我应该决定使用 MSK 还是应该使用 SQS + SNS 来实现同样的功能？ （我已经了解了基本概念，但希望从社区中了解是否还有其他利弊）？

提前感谢！

- Rachit

---

恭喜你的问题没有因为“基于观点”的原因而被立即关闭。我从这个问题和答案中受益匪浅，谢谢！ - Tobias Feil

Answer 1

MSK VS SQS+SNS并不是真正的1:1比较。选择取决于各种用例。请找出两者之间的一些具体差异。

1. 可伸缩性 -> 由于分区的固有设计允许消息的并行和排序，因此MSK具有更好的可伸缩性选项。 SNS每秒限制为300次发布，为了实现与MSK相同的性能，需要有更多的SNS主题来实现相同的目的。

例如：主题：订单服务 在MSK中->一个主题+ 10个分区 SNS->10个主题

如果客户端/消息生产者使用10个SNS主题来实现相同的目的，则客户端需要了解所有10个SNS主题的信息和消息分发。 在MSK中，这是相当简单的，只需将密钥发送到消息中，kafka将根据密钥值分配分区。

2. 管理/操作-> SNS+SQS设置比MSK要简单得多。 即使这是托管服务，MSK的运营挑战也更加复杂。 MSK需要更深入的技能才能实现最佳效果。

3. SNS + SQS VS SQS -> 我认为您对同一消息有多个订阅（扇出），因此您已经参考了SNS + SQS。 如果一个消息只有一个订阅，那么仅使用SQS就足够了。

4. 重播消息 -> MSK可用于重播已处理的消息。 对于SQS来说，这可能有些棘手，尽管可以通过拥有重复队列来实现，以便可以用于重播。

- kus