Azure Service Bus Topic监听器方案选型：Azure Function vs 嵌入.NET Core微服务

核心需求梳理 #

• 监听Azure Service Bus的多个Topic（Create/Update/DeleteCustomer等），触发微服务的数据同步逻辑
• 兼顾扩展性、可维护性，适配未来新增Topic的需求

两种方案的优缺点拆解 #

方案1：微服务配套单Azure Function项目（多Trigger类） #

优点

• 完全解耦：消息监听逻辑与微服务主业务分离，Function仅负责触发，核心同步逻辑仍在微服务业务层，不会污染主应用代码
• 独立伸缩：每个Topic对应的Trigger可单独配置伸缩规则，比如CreateCustomer消息量高时单独扩容实例，避免资源浪费
• 运维独立：单个Trigger故障不影响微服务主应用，问题排查更聚焦
• Serverless托管：无需自行维护监听进程的生命周期，Azure自动管理运行状态

缺点

• 初期会新增少量Trigger类，但通过共享微服务业务层类库的方式，可完全避免代码重复，不会导致项目臃肿

方案2：监听器嵌入微服务业务层 #

优点

• 无需额外维护Function项目，代码集中在单个微服务内，部署流程简单

缺点

• 耦合性高：消息监听逻辑与业务代码绑定，新增Topic或修改监听规则时，需改动微服务主代码，增加回归测试成本
• 伸缩受限：监听进程与微服务主进程绑定，无法针对消息量单独伸缩，消息暴增时会被迫扩容整个微服务
• 运维风险高：监听逻辑故障会直接影响微服务主业务运行，排查时需区分业务问题与监听问题

多Topic场景的优化方案（解决Function臃肿顾虑） #

不用为每个Topic单独创建Function项目，在同一个Azure Function项目下编写多个Trigger类，每个类对应一个Topic的订阅，共享业务层依赖：

// CreateCustomer消息触发器
public class CreateCustomerTrigger
{
    private readonly ICustomerSyncService _syncService;

    public CreateCustomerTrigger(ICustomerSyncService syncService)
    {
        _syncService = syncService;
    }

    [FunctionName("CreateCustomerListener")]
    public async Task Run(
        [ServiceBusTrigger("CreateCustomer", "SyncSubscription", Connection = "ServiceBusConnection")] string msg,
        ILogger log)
    {
        log.LogInformation($"收到CreateCustomer消息: {msg}");
        await _syncService.SyncCreateCustomer(msg);
    }
}

// UpdateCustomer消息触发器（同一项目下）
public class UpdateCustomerTrigger
{
    private readonly ICustomerSyncService _syncService;

    public UpdateCustomerTrigger(ICustomerSyncService syncService)
    {
        _syncService = syncService;
    }

    [FunctionName("UpdateCustomerListener")]
    public async Task Run(
        [ServiceBusTrigger("UpdatedCustomer", "SyncSubscription", Connection = "ServiceBusConnection")] string msg,
        ILogger log)
    {
        log.LogInformation($"收到UpdatedCustomer消息: {msg}");
        await _syncService.SyncUpdateCustomer(msg);
    }
}

这种方式既保持了监听逻辑与主业务的分离，又通过统一的项目结构避免了臃肿问题。

最终选型建议 #

优先选择单Azure Function项目+多Trigger类的方案：

1. 解耦性与可维护性兼顾：新增Topic仅需在Function项目中添加对应Trigger类，无需改动微服务主代码
2. 扩展性强：每个Trigger可独立配置运行规则，适配不同Topic的消息量波动
3. 运维风险低：监听逻辑故障不会影响微服务主业务，Azure自动托管降低运维成本

若团队暂不熟悉Azure Function，可先采用嵌入监听器的过渡方案，但需将监听逻辑封装为独立的IHostedService后台服务，避免阻塞主业务线程：

public class CustomerTopicListener : BackgroundService
{
    private readonly ServiceBusClient _client;
    private readonly ICustomerSyncService _syncService;

    public CustomerTopicListener(IOptions<ServiceBusSettings> settings, ICustomerSyncService syncService)
    {
        _client = new ServiceBusClient(settings.Value.ConnectionString);
        _syncService = syncService;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        // 监听CreateCustomer Topic
        var processor = _client.CreateProcessor("CreateCustomer", "SyncSubscription", new ServiceBusProcessorOptions());
        processor.ProcessMessageAsync += async args =>
        {
            var msg = args.Message.Body.ToString();
            await _syncService.SyncCreateCustomer(msg);
            await args.CompleteMessageAsync(args.Message);
        };

        processor.ProcessErrorAsync += args =>
        {
            // 错误处理逻辑
            return Task.CompletedTask;
        };

        await processor.StartProcessingAsync(stoppingToken);

        // 可扩展添加其他Topic的监听逻辑
    }

    public override async Task StopAsync(CancellationToken stoppingToken)
    {
        await _client.DisposeAsync();
        await base.StopAsync(stoppingToken);
    }
}

在Startup中注册服务：

services.AddHostedService<CustomerTopicListener>();

此过渡方案可快速实现功能，但长期来看仍推荐Azure Function方案，尤其适合消息量增长或Topic数量增多的场景。

内容的提问来源于stack exchange，提问作者Laila Mohame