【问题标题】：MSK vs SQS + SNSMSK 与 SQS + SNS
【发布时间】：2022-02-10 01:58:06
【问题描述】：
我正在决定是否应该使用 MSK（来自 AWS 的托管 kafka）或 SQS + SNS 的组合来实现 pub sub 模型？
背景
目前，我们有一个微服务架构，但我们不使用任何消息传递服务，只使用 REST API（不要问为什么 - 与一些设计该架构的第三方供应商有关）。现在，我想对其进行改造并开始使用消息传递在微服务之间进行通信。
最初，计划是开始发布实体事件以供任何其他微服务使用 - 这些事件也将存储在 S3 的数据湖中，这也将作为启动数据团队的基础。
稍后，我想将某些功能从 REST 移至异步通信。
无论如何，我的主要问题是 - 我应该决定使用 MSK 还是应该使用 SQS + SNS？ （我已经了解了基本概念，但如果还有其他利弊，我想从社区中了解）？
提前致谢
【问题讨论】：
标签：
amazon-web-services
architecture
microservices
messaging
aws-msk
【解决方案1】：
MSK VS SQS+SNS 并不是真正的 1:1 比较。选择取决于各种用例。请找出两者之间的一些具体区别
- 可扩展性->
由于允许并行性和消息排序的分区的固有设计，MSK 具有更好的可扩展性选项。
SNS 有 300 次发布/秒的限制，要达到与 MSK 相同的性能，需要有更多的 SNS 主题来实现相同的目的。
示例：主题：订单服务
在 MSK -> 一个主题+ 10 个分区
SNS -> 10 个主题
如果客户端/消息生产者出于相同目的使用 10 个 SNS 主题，则客户端需要拥有所有 10 个 SNS 主题和消息分发的信息。
在 MSK 中，很简单，key 需要在消息中发送，kafka 会根据 Key 的值分配分区。
-
管理/运营 ->
与 MSK 相比，SNS+SQS 设置要简单得多。
MSK 的运营挑战更大（即使这是托管服务）。 MSK 需要更深入的技能才能以最佳方式使用。
-
SNS +SQS VS SQS -> 我相信您对同一消息有多个订阅（扇出），这就是您引用 SNS +SQS 的原因。
如果您对一条消息有一个订阅，那么仅 SQS 也足够了。
-
消息重放 -> MSK 可用于重放已处理的消息。
这对 SQS 来说会很棘手，但可以通过重复队列来实现，以便用于重放。