在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服务总线

回答

相关问题