在Owin Startup類中使用OnMessage訂閱Azure Service Bus

Question

我正在開發一個解決方案來處理來自Azure Service Bus的消息，我的同事建議使用我們現有的Asp.Net WebApi應用程序並在OWIN Startup中訂閱ASB，例如

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        // ... registering WebApi etc

        var queueClient = SubscriptionClient.CreateFromConnectionString("connection string", "sometopic", "somesubscription");

        queueClient.OnMessage(m =>
        {
            //do something with message

            m.Complete();
        }, new OnMessageOptions
        {
            AutoComplete = false,
            AutoRenewTimeout = TimeSpan.FromSeconds(30),
            MaxConcurrentCalls = 30
        });
    }
}

我個人認為這不是正確的方法，而是我們應該使用WebJobs或WorkerRoles ，我想不出任何讓他說服我的想法的論據。

所以問題是：

1. 誰是對的，我或我的同事，或者兩種解決方案都可以嗎？
2. 如果我的同事不對，反對他的解決方案的理由是什么？

Answer 1

如果該web api項目不只是監聽此隊列，請考慮使用Web作業或輔助角色方法的這些優點：

• 工作者角色可以獨立於Web應用程序進行擴展
• 可以獨立於Web應用程序更新Web作業/輔助角色
• 進程隔離：如果一個失敗，另一個可能仍然運行。

如果您使用Azure功能（ https://azure.microsoft.com/en-us/services/functions/ ），您甚至可以應用無服務器計算。 您只需支付使用費用（不用於托管您的功能）和比例，也可以單獨更新。

從技術上講，兩種方法都可行。 如果消息的處理直接與Web應用程序交互（您沒有告訴您對消息做了什么），那么根據工作在Web應用程序中運行它可能更有意義。

網站更好地處理請求而不是運行連續過程。 Web作業/工作者角色對於這種情況來說感覺就像是一個更好的環境，但也真正看看Azure功能。

Answer 2

服務總線存在的原因之一是單獨處理此消息/隊列，因為此特定進程被識別為較大企業系統的子系統或子域。 因此，app / service（以web worker角色/ web作業/ azure函數的形式）可以由具有子系統的焦點領域知識的相同或不同團隊開發。 由於它是一個獨立的過程，因此可以根據需要獨立擴展。

如果消息的處理依賴於Web應用程序業務邏輯/服務，則可能是一個紅旗，表明它為什么需要在Web API過程中。