在Owin Startup中訂閱使用OnMessage的Azure服務總線

我正在處理將從Azure Service Bus處理郵件的解決方案，我的同事建議使用我們現有的Asp.Net WebApi應用程序之一併訂閱OWIN啓動如在Owin Startup中訂閱使用OnMessage的Azure服務總線

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，hovewer我想不出任何參數來他說服我的想法。

所以問題是：

誰是誰非，我或我的同事，也許這兩種解決方案都還好嗎？
如果我的同事不對，他的解決方案有什麼爭議？

來源

2016-11-06 Krzysiek

你改變了主意嗎？現在在您的項目中實施這個權利是什麼？ –

如果該Web API項目並不僅僅是聽此隊列考慮使用Web作業或輔助角色的方法的這些優勢：

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

如果您使用Azure函數（https://azure.microsoft.com/en-us/services/functions/），則甚至可以應用無服務器計算。您只支付使用費用（不是用於託管您的功能），並且可以單獨更新，也可以獨立更新。

技術上這兩種方法都可行。如果消息的處理直接與Web應用程序進行交互（您沒有告訴您如何處理消息），根據工作情況在Web應用程序中運行它可能更有意義。

網站在處理請求時更好，而不是運行連續的過程。網絡工作/員工角色感覺像是這種情況下更好的環境，但也真的看看Azure函數。

來源

2016-11-06 21:34:19

服務總線存在的原因之一是孤立地處理這個消息/隊列，因爲這個特定的進程被確定爲大型企業系統的子系統或子域。因此，應用/服務（以web worker角色/ web jobs/azure功能的形式）可以由具有該子系統關注領域知識的相同或不同團隊開發。由於它是一個獨立的過程，如果需要它可以獨立調整。

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

來源

2016-11-07 18:13:56 alltej

在Owin Startup中訂閱使用OnMessage的Azure服務總線

回答

相關問題