如何快速上手 SlimMessageBus + Azure Service Bus:主题订阅与请求响应架构完整指南
【免费下载链接】SlimMessageBusLightweight message bus interface for .NET (pub/sub and request-response) with transport plugins for popular message brokers.项目地址: https://gitcode.com/gh_mirrors/sl/SlimMessageBus
SlimMessageBus是一款面向 .NET 的轻量级消息总线(Message Bus)框架,支持发布/订阅(pub/sub)与请求/响应(request-response)两种通信模式。搭配Azure Service Bus传输插件,你可以在云原生架构中快速搭建解耦的微服务通信:一条主题(Topic)承载多种消息,多个服务通过订阅(Subscription)各自消费,还能以await等待式调用完成跨服务的请求响应。本文带你用最短的路径掌握这两大核心架构。
30秒认识 SlimMessageBus 🚀
SlimMessageBus 的设计哲学是"小而美":
- 传输层可插拔:Kafka、Azure Service Bus、RabbitMQ、Redis、MQTT 等主流消息中间件均以 NuGet 插件形式接入;
- 两种通信范式:pub/sub 用于事件广播,request-response 用于异步等待结果;
- 统一 API:无论底层是哪种 Broker,业务代码只依赖
IMessageBus接口,切换 Broker 只需改配置。
SlimMessageBus 消息总线上一个主题承载多种消息,不同消费服务按类型独立消费
上图展示了 SlimMessageBus 的核心能力:Service A 把
CustomerEvent、OrderEvent等多种消息发布到同一个主题events,Service B 中的不同消费者按需各自消费。
核心接口定义在 src/SlimMessageBus/IMessageBus.cs,消费者通过实现IConsumer<T>接口处理消息。
一键接入:安装与配置 Azure Service Bus
在 .NET 项目中安装三个包即可完成接入:
dotnet add package SlimMessageBus dotnet add package SlimMessageBus.Host.AzureServiceBus dotnet add package SlimMessageBus.Host.Serialization.SystemTextJson然后一行AddSlimMessageBus完成总线配置,只需提供 Azure Service Bus 连接字符串:
services.AddSlimMessageBus(mbb => { mbb.WithProviderServiceBus(cfg => cfg.ConnectionString = connectionString); mbb.AddJsonSerializer(); });完整配置文档见 docs/provider_azure_servicebus.md,插件源码位于 src/SlimMessageBus.Host.AzureServiceBus/。
主题与订阅:pub/sub 架构的关键 📮
Azure Service Bus 同时支持队列(Queue)和主题(Topic),SlimMessageBus 通过简洁的构建器语法让你清晰声明"消息去哪、谁来消费"。
发布端:声明消息的目的地
// 订单事件发布到 orders-topic 主题 mbb.Produce<OrderPlacedEvent>(x => x.DefaultTopic("orders-topic"));之后业务代码里直接await bus.Publish(new OrderPlacedEvent(...))即可,无需关心 Broker 细节。
订阅端:每个服务拥有独立订阅
主题消费的关键概念是订阅名(Subscription)——不同服务用不同订阅名消费同一主题,互不干扰:
mbb.Consume<OrderPlacedEvent>(x => x .Topic("orders-topic") .SubscriptionName("inventory-service") .WithConsumer<OrderPlacedEventConsumer>() .Instances(1));几个实用技巧:
- 全局默认订阅名:所有主题消费者可统一通过
cfg.SubscriptionName("...")设置,避免重复配置; - 订阅过滤:支持 SQL 过滤(
SubscriptionSqlFilter)和关联 ID 过滤(SubscriptionCorrelationFilter),让每个订阅只收到符合条件的消息,实现"一主题多视图"; - 访问原生消息:消费者实现
IConsumerWithContext接口后,可读取 Azure 原生的ServiceBusReceivedMessage,拿到CorrelationId、ApplicationProperties等元数据。
异常处理与死信队列 💪
消费者抛异常时,SlimMessageBus 会将消息标记为废弃(abandon),由 Azure Service Bus 自动重试(默认 10 次),失败后进入死信队列(DLQ),并在消息上写入SMB.Exception属性方便排查。你还可以注册自定义错误处理器,实现应用级死信或失败时修改消息属性,详见 docs/provider_azure_servicebus.md 的异常处理章节。
请求响应架构:跨服务像本地调用一样 await ⚡
同步 HTTP 调用在微服务中会放大延迟和故障传播。SlimMessageBus 的request-response模式让你await一个请求消息并拿到响应,同时保持服务间的异步解耦。
工作原理
- 发送方把请求消息发到一个主题/队列;
- 消息头部自动携带
RequestId(关联 ID)、ReplyTo(回复地址)等元数据; - 处理方执行
IRequestHandler处理器,把响应发回ReplyTo指定的地址; - 发送方的
await bus.Send(request)拿到结果,继续执行。
上图展示了完整管线:
Send()请求会依次经过生产者拦截器 → 传输层(Azure Service Bus)→ 消费者拦截器 → 请求处理器,任何一环都可以插入横切逻辑(日志、校验、熔断等)。拦截器接口定义在 src/SlimMessageBus.Host.Interceptor/。
请求发送方配置
mbb.Produce<EchoRequest>(x => x.DefaultTopic("echo-request")); mbb.ExpectRequestResponses(x => { // 每个服务实例拥有专属回复队列,确保响应准确回到发起者 x.ReplyToQueue("my-service-reply"); x.DefaultTimeout(TimeSpan.FromSeconds(60)); });⚠️关键点:每个请求发送方实例都需要专属的回复队列(推荐用队列而非主题),这样第 n 个实例发出的请求,响应才能准确回到该实例并恢复其等待中的任务。
请求处理方配置
mbb.Handle<EchoRequest, EchoResponse>(x => x .Topic("echo-request") .SubscriptionName("handler") .WithHandler<EchoRequestHandler>() .Instances(2));注意:请求发到主题就从主题消费,发到队列就从队列消费,两者不能混用。请求消息可选实现标记接口IRequest<TResponse>(定义见 src/SlimMessageBus/RequestResponse/IRequest.cs),让类型关系一目了然。
自动拓扑供给:省去手动建 Topic 的烦恼 🛠️
从 1.19.0 起,SlimMessageBus 支持自动拓扑供给:应用启动时自动创建配置中声明的队列、主题、订阅和过滤规则(已存在的资源保持不变)。这意味着:
- 新环境部署时不用再手动登录 Azure Portal 建 Topic;
- 通过
CanProducerCreateTopic/CanConsumerCreateSubscription等开关,可在多服务间明确"谁拥有 Topic 创建权、谁只创建自己的订阅",实现职责分离; - 支持设置分区(Partitioning)、去重(Duplicate Detection)等创建选项。
注意:拓扑供给要求连接字符串使用
Manage权限级别的密钥。
进阶能力速览 ✨
| 能力 | 说明 |
|---|---|
| Sessions 会话 | 通过EnableSession()启用 FIFO 顺序保证,同一客户的消息严格有序 |
| 消息修改器 | .WithModifier()设置分区键、消息 ID、SessionId 等原生属性 |
| Outbox 模式 | 配合 Outbox 插件 实现本地事务 + 可靠投递 |
| 熔断器 | 消费者可接入熔断与健康检查,自动降级 |
| Hybrid 总线 | 同一应用内同时使用多种 Broker |
总结:为什么选择这套组合?
- 云原生友好:Azure Service Bus 提供企业级 SLA、自动扩缩、死信与诊断能力;
- 开发体验极佳:声明式配置 + 强类型 API,消息流转清晰可测;
- 架构灵活:pub/sub 解耦事件流,request-response 保留调用语义,二者按需组合。
下一步建议阅读 docs/UseCases/RequestResponse.md 了解请求响应在复杂计算场景中的落地方式,或在本地克隆仓库后运行 Samples 中的示例:
git clone https://gitcode.com/gh_mirrors/sl/SlimMessageBus从此让你的 .NET 微服务通信既简单,又可靠。
【免费下载链接】SlimMessageBusLightweight message bus interface for .NET (pub/sub and request-response) with transport plugins for popular message brokers.项目地址: https://gitcode.com/gh_mirrors/sl/SlimMessageBus
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考