在 Azure 服務總線中尋找事件中心與主題的清晰度

Question

我一直在了解事件中心，只是想確認或糾正我對事件中心的看法？ 我習慣於利用 Azure 服務總線隊列和主題為我提供的正常企業消息傳遞解決方案中的重試、有害消息、至少一次傳遞等。 似乎事件中心旨在為非常高的規模提供一種不同的工具，在這種情況下，您必須放棄一些更“企業”的功能以獲得更高的規模。

我是否正確地考慮了這一點？ 我還需要考慮其他細節嗎？ 我意識到事件中心和主題可能存在一些功能重疊，但我只是想弄清楚如何考慮使用事件中心。

Answer 1

如果您有選擇，那么基於完整的企業 pubsub 消息傳遞系統編寫一個系統幾乎總是更容易，您可以在其中將單個事件標記為已被使用、重試消息以及幾乎所有其他精彩功能。 如果您已經接受對消息通道進行分區（Azure 服務總線主題似乎支持），那么原則上您可以將功能更全面的消息系統擴展到您需要的程度。 問題是什么代價？

Azure 服務總線主題的大規模成本約為 每百萬條消息0.20 美元，Amazon SQS（有些類似）列出了 每百萬條消息0.50 美元。 如果您自己托管它，您可能需要在分區時設置許多 RabbitMQ 服務器甚至多個集群。

Azure 事件中心的成本為每百萬 0.028 美元加上每個吞吐量單位的金額，與Amazon Kinesis相同。 Apache Kafka 在 3 台機器上的基准測試為每秒 200 萬

以每秒 20,000 個事件為例，某些 Azure 主題和 Azure 事件中心之間的差異在全職開發人員的薪水范圍內。 每秒持續 200 萬（需要聯系 MS），差異接近 100 萬美元/月。

當您不需要完整消息傳遞系統的所有有用功能時，或者當您不需要它們來支付大約 10 倍的溢價時，基本上使用分區流|日志/偏移量跟蹤系統。 （或者不能使用它們，因為如果沒有英勇的努力，您就無法充分擴展適當的消息傳遞系統）。

Answer 2

不久前，我在服務總線團隊的 Dan 的支持下寫了一篇關於這個主題的帖子。 希望這應該為您澄清

http://microsoftintegration.guru/2015/03/03/azure-event-hubs-vs-azure-messaging/

服務總線（消息）

對於消息傳遞，它是關於一個應用程序告訴一個或多個應用程序做某事或給我某事。

事件中心（事件）

另一種方法是在事件中應用程序說發生了一些事情。

Answer 3

正確的！！

EventHubs 和 Topics 之間的根本區別是 - TOPICS 提供每消息語義- 而 EventHubs - 提供流語義- 意味着，不應期望 EventHubs 有任何per-message功能/語義。

任何提供per-message功能的中間層都會帶來processing overhead (the tax) ！！

例如：每條消息重復檢測，每條消息接收確認（主題有一個 Message.Complete 來確認收到的消息） - 都是主題功能。 EventHub 縮小了功能集的范圍，以提供更好的低延遲/高吞吐量解決方案。

將至少一次交付（每個 msg 在 EventHub 中不可用）等功能可視化是將其轉換為流語義 - 讀取直到給定 eventHub 分區和檢查點中的某個點，並讓使用這些事件的應用程序處理at-least-once交付。

更多關於事件中心...

Answer 4

根據這篇MS Learn 文章和“在 Azure 消息服務之間進行選擇”關於選擇什么：

“Azure 事件中心專為高流量分析類型的事件而設計。Azure 服務總線和存儲隊列用於消息，可用於綁定任何應用程序工作流的核心部分。”

了解事件和消息的用途之間的區別很重要，因為通信服務通常設計為處理它們各自的對象——事件中心處理事件，服務總線處理消息。

事件觸發通知，表明某事已發生。 它比消息“更輕”——它有關於發生了什么的信息，但沒有觸發事件本身的數據。 例如，事件可能會通知您文件上傳並包含有關文件的信息，但不包含文件本身。 事件通常用於廣播通信/扇出工作流，即當每個發布者都有大量訂閱者時。 發布者對消費者如何處理事件沒有期望。

消息包含觸發消息管道的數據。 與事件不同，發布者對消費者如何處理消息有期望。 例如，發布者發送一條包含由服務產生的原始數據的消息，並期望消費者存儲該數據並在完成后發回響應。

（還有事件網格，它也處理事件，但與事件中心不同。事件中心是為涉及分析的大數據管道而設計的，而事件網格是為事件驅動的反應式編程而設計的。）