MSK 与 SQS + SNS

Question

我正在决定是否应该使用 MSK（来自 AWS 的托管 kafka）还是 SQS + SNS 的组合来实现 pub sub 模型？

背景

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

最初，计划是开始发布实体事件以供任何其他微服务使用 - 这些事件也将存储在 S3 的数据湖中，S3 也将作为启动数据团队的基础。

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

无论如何，我的主要问题是 - 我应该决定选择 MSK 还是应该使用 SQS + SNS？（我已经了解基本概念，但想从其他社区了解是否还有其他优点和缺点）？

提前致谢

Answer 1

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

1. 可扩展性 -> 由于允许并行性和消息排序的分区的固有设计，MSK 具有更好的可扩展性选项。SNS 的发布次数限制为 300 个/秒，要达到与 MSK 相同的性能，需要有更多数量的 SNS 主题用于相同目的。

示例：主题：MSK 中的订​​单服务 -> 1 个主题+ 10 个分区 SNS -> 10 个主题

如果客户端/消息生产者出于同一目的使用10个SNS主题，则客户端需要拥有所有10个SNS主题和消息分发的信息。在MSK中，非常简单，key需要在消息中发送，kafka将根据Key值分配分区。

2. 与 MSK 相比，管理/操作 -> SNS+SQS 设置要简单得多。MSK 的运营挑战要大得多（即使这是托管服务）。MSK 斯隆需要更深入的技能才能发挥最佳效果。

3. SNS +SQS VS SQS -> 我相信您对同一条消息有多个订阅（扇出），这就是您参考 SNS +SQS 的原因。如果您对一条消息有一个订阅，那么仅 SQS 也足够了。

4. 消息重放 -> MSK 可用于重放已经处理过的消息。这对于 SQS 来说会很棘手，尽管可以通过重复队列来实现，以便可以用于重放。