MSK 與 SQS + SNS

Question

我在決定是否應該使用 MSK（來自 AWS 的托管 kafka）或 SQS + SNS 的組合來實現 pub sub model？

背景

目前，我們有一個微服務架構，但我們不使用任何消息服務，只使用 REST api（不要問為什么 - 與設計該架構的一些 3rd 方供應商有關）。 現在，我想改造它並開始使用消息傳遞來進行微服務之間的通信。

最初，計划是開始發布實體事件供任何其他微服務使用——這些事件也將存儲在 S3 的數據湖中，這也將作為啟動數據團隊的基礎。

稍后，我想將某些功能從 REST 移動到異步通信。

無論如何，我的主要問題是 - 我應該決定使用 MSK 的 go 還是應該使用 SQS + SNS？ （我已經了解了基本概念，但想從其他社區了解是否還有其他優點和缺點）？

提前致謝

Answer 1

MSK VS SQS+SNS 並不是真正的 1:1 比較。 選擇取決於各種用例。 請找出兩者之間的一些具體區別

1. 可擴展性 -> MSK 具有更好的可擴展性選項，因為分區的固有設計允許消息的並行性和排序。 SNS 有 300 發布/秒的限制，要達到與 MSK 相同的性能，需要有更多的 SNS 主題用於相同的目的。

示例：主題：MSK 中的訂單服務 -> 一個主題+ 10 個分區 SNS -> 10 個主題

如果客戶端/消息生產者出於同一目的使用 10 個 SNS 主題，則客戶端需要擁有所有 10 個 SNS 主題和消息分發的信息。 在MSK中，很簡單，key需要在消息中發送，kafka會根據Key值分配partition。

2. 與 MSK 相比，管理/操作 -> SNS+SQS 設置要簡單得多。 MSK 面臨更多的運營挑戰（即使這是托管服務）。 MSK 需要更深入的技能才能以最佳方式使用。

3. SNS +SQS VS SQS -> 我相信您對同一消息有多個訂閱（扇出），這就是您引用 SNS +SQS 的原因。 如果您對一條消息有一個訂閱，那么僅 SQS 也足夠了。

4. 消息重播 -> MSK 可用於重播已處理的消息。 對於 SQS 來說這將是棘手的，盡管可以通過復制隊列來實現，以便可以用於重播。