在Owin Startup类中使用OnMessage订阅Azure服务总线

本文关键字：订阅 OnMessage Azure 服务 总线 Owin Startup | 更新日期: 2023-09-27 18:16:46

我正在研究一个解决方案，它将处理来自Azure服务总线的消息，我的同事建议使用我们现有的Asp。. Net WebApi应用程序并订阅ASB OWINStartup例如

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. 如果我的同事不正确，反对他的解决方案的论据是什么?

在Owin Startup类中使用OnMessage订阅Azure服务总线

如果这个web api项目做的不仅仅是监听这个队列，那么考虑使用web job或worker角色方法的这些优点:

  • Worker角色可以独立于web应用扩展
  • web job/worker角色可以独立于web应用程序进行更新
  • 进程隔离:如果一个失败，另一个可能仍在运行。

如果你使用Azure Functions (https://azure.microsoft.com/en-us/services/functions/)，你甚至可以应用无服务器计算。您只需为使用付费(而不是为功能的托管付费)，并且可以扩展，也可以独立更新。

从技术上讲，这两种方法都有效。如果消息的处理直接与web应用程序交互(您没有告诉您对消息做什么)，则根据工作在web应用程序中运行它可能更有意义。

一个网站在处理请求方面比运行一个连续的过程要好。对于这种情况，web job/worker角色感觉是一个更好的环境，但也要看看Azure Functions。

存在服务总线的原因之一是隔离地处理此消息/队列，因为此特定流程被标识为较大企业系统的子系统或子域。因此，应用程序/服务(以web工作者角色/web作业/azure功能的形式)可以由具有子系统重点领域知识的相同或不同团队开发。由于它是一个独立的进程，如果需要的话，它可以独立扩展。

如果消息的处理依赖于web应用程序的业务逻辑/服务，这可能是一个危险信号，说明为什么它需要在web API进程中。

相关文章：