使用服務總線與WCF進行計算角色通信

Question

給定一個簡單的高級體系結構，例如具有Web角色的雲服務和計算角色，在什麼情況下我們會選擇使用WCF作爲web角色和計算角色，而不是服務總線。

有很多文檔和有關服務總線的示例，但我想了解是否有使用服務總線的任何平臺好處，而不是WCF。

鑑於呼叫是同步的，並且很短，例如一個典型的API數據訪問網站的API調用，您會選擇WCF隊列消息並回復隊列嗎？

從邏輯上看，對於同步調用，WCF會提供最少的開銷和延遲？

我並不完全瞭解平臺是否提供了任何「巧妙」的技巧，以保持服務總線的運行速度與通過WCF的TCP連接一樣快（考慮到排隊開銷？），並且希望進一步瞭解這一點。

目前，如果我要爲這種類型的呼叫選擇一個實現，我會選擇WCF，這可能有點天真。

只是爲了清楚，這些調用總是返回數據，它們不會長時間運行，或者發生並忘記。

謝謝！

Answer 1

我認爲這取決於你想要做什麼。

服務總線通常更多地用於我稱之爲常量聯繫類型的交互。它應該更高性能，但設置起來更復雜。它還具有雙向通信功能。所以你會獲得很多額外的靈活性。

我會交換WCF的更現代的Web API。兩者都解決了同樣的核心問題，主要是在提供內容。我認爲它只是一個API，不一定是消息傳遞和處理的平臺。他們解決2個不同的核心問題。

我實際上會以不同方式解決可能的問題，並使用Azure網站+ WebJobs。它是同樣的東西。您可以將WebJob綁定到Azure隊列，表或blob，並將消息放置在該存儲機制上，這些作業將採用並執行某些操作。我不相信網絡角色應該依賴從工作中回來的內容。這項工作可能會在AzureWeb站點完成後觸發一個SignalR Hub，這會將狀態推回給受影響的各方。

參考資料： WebJobs：https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-web-jobs/

SignalR：http://signalr.net/

Azure的Web應用程序：https://azure.microsoft.com/en-us/services/app-service/web/