Azure Service Fabric和消息隊列

Question

現在有了Azure Service Fabric，是否會有用例來使用單獨的隊列解決方案，例如Windows Service Bus？ 不利之處可能是新的單點故障，但是有不利之處嗎？ 隊列可以添加一些緩沖，但是另一方面，Service Fabric應該能夠真正很好地擴展並提供有狀態功能，因此不需要隊列緩沖區嗎？

Answer 1

可以肯定的是，Azure Service Bus和Azure Storage Queues之類的服務提供的功能並未包含在Service Fabric中。 因此，要問自己的問題是：是否添加外部服務依賴項以獲得該功能，還是通過在Service Fabric上自行構建來保持獨立性？ 在Service Fabric上自包含的應用程序是好的，但是重新發明現有的功能是不好的，因此您必須確定對您來說最大的價值並朝那個方向傾斜。

例如，考慮一下。

• 可移植性。 Service Fabric自身包含的應用程序可以在Service Fabric可以運行的任何地方托管，幾乎可以在任何地方（Azure，其他公共雲，您自己的機器或數據中心等）運行。
• 沒有外部依賴關系意味着更少的故障點，單個工具集以及統一的開發，部署，升級和維護過程。

另一方面..

• 諸如服務總線之類的服務提供了豐富的功能集 。 花時間在Service Fabric上構建和維護自己需要的功能是否值得？

Answer 2

好問題！ 我也在這周圍打no。 就我而言，我使用RabbitMQ集群進行排隊。 我想避免這種情況，並希望使用可靠隊列來提供有狀態服務。 我公開了一種將消息添加到服務的方法，並使用RunAsync方法在消息到達時使消息出隊。 與連接到RabbitMQ的無狀態服務相比，使用這種方法的性能沒有讓我印象深刻。 但是在放棄之前，我打算將Stateful服務划分為5個節點，並使用Stateful服務隊列消耗型工人，看看是否有任何性能改進。