微服务实战.06 ｜微服务对话时，你选择打电话还是发邮件？

第6章：微服务对话艺术：何时用REST"打电话"，何时用消息队列"发邮件"？

哈喽，我是黑棠

下面想象一个真实的"黑色星期五"电商秒杀场景：晚上8点整，10万台iPhone 16库存瞬间释放。

方案A：所有服务"打电话" (REST)：

订单服务在创建订单前，必须同步调用 库存服务完成实时扣减。

这意味着，如果库存服务因为瞬间流量（10万QPS）而响应变慢到500毫秒，那么订单服务的线程也会被阻塞、等待500毫秒。这会导致订单服务迅速耗光所有线程池资源，最终整个下单接口完全瘫痪，用户看到的将是"服务不可用"或白屏。一个下游服务的延迟，会像多米诺骨牌一样引发整个链路的雪崩。

方案B：关键链路"发邮件" (消息队列)：

订单服务的核心职责被精简为"快速接收订单、校验基础信息、持久化订单、然后立刻返回"。

• 至于扣减库存、发放优惠券、发送短信通知等后续操作，则被转化为一条条消息，投入消息队列这个"邮局"。库存服务等消费者可以按照自身能力，从容地从队列中取出消息处理。即使瞬间流量是平时的100倍，系统也只是在队列中堆积了一些待处理的"邮件"，而不会崩溃，用户体验始终流畅。

这个选择的本质，是在"强一致性"与"高可用/高性能"之间寻找最佳平衡。 本章将为你建立清晰的决策框架。

---

REST与消息队列的本质差异

为了更直观地理解，我们可以用"团队协作"来类比：

特性维度	REST / gRPC（"紧急电话会议"）	消息队列，如RabbitMQ/Kafka（"异步工作邮件"）
通信模式	同步阻塞。像立即召开的电话会议，所有人必须在线并实时响应，会议才能继续。	异步非阻塞。像发送工作邮件，发出后即可继续手头工作，对方会在方便时查看处理。
耦合程度	紧耦合。调用方必须明确知道被调用方的地址（IP/域名）和详细接口合同（API契约），一方宕机，另一方直接报错。	松耦合。通过消息中间件这个"秘书处"解耦。生产者只需知道"秘书处"地址，无需关心谁来处理；消费者也只需订阅感兴趣的消息类型。双方可独立升级、扩容。
实时性	强实时性 。要求毫秒级响应，适用于业务核心链路的强一致性操作。	最终一致性 。允许秒级甚至分钟级的延迟，适用于核心链路之外的扩展性、补偿性操作。
可靠性保障	依赖网络和对方服务的可用性。通常需在客户端实现重试、熔断（如Polly）来容错，但无法保证请求必达。	设计上高可靠 。消息可持久化磁盘，支持消费者确认（ACK）机制、失败重投、死信队列等，确保消息至少被成功处理一次（At-Least-Once）。
流量处理	直接对冲。流量洪峰直接冲击服务实例，对资源规划要求高。	削峰填谷。洪峰被消息队列缓冲，消费者可以平稳速率处理，保护下游系统。
典型场景	用户登录鉴权 、实时支付扣款 、购物车实时计价。	用户注册后发送欢迎邮件 、订单完成后更新用户积分/排行榜 、收集业务日志进行大数据分析。
技术栈代表	HTTP/HTTPS (WebAPI), gRPC	RabbitMQ (企业级消息代理), Apache Kafka (高吞吐流平台), Redis Streams (轻量级)

决策心法口诀：

• 需要"立即确认"才能走下一步的，打电话（REST）。例如："银行扣款成功了吗？成功了我才敢生成订单。"
• 只需"通知一声"，且后续操作可独立完成的，发邮件（消息队列）。例如："订单已生成，相关的库存、物流、营销系统请你们各自依此处理。"

---

实战演练：代码里的"电话"与"邮件"

我们延续电商案例，用代码具象化这两种模式。假设你已经完成了第5章多服务环境的搭建。

场景1：REST"打电话"------下单前实时查询商品详情

这是典型的需要即时结果的场景。

用户在选择商品时，页面必须立即展示最新的价格、库存和优惠信息。
关键实现：在订单服务的 OrderController 中，通过注入的 HttpClient 调用商品服务。

步骤1：优化商品服务接口（标准化RESTful）

修改ProductApi的ProductController，添加接口版本、统一响应格式：

步骤2：订单服务添加REST调用的超时/重试（Polly）

1. 安装Polly包（处理超时、重试）

    cd order-service && dotnet add package Microsoft.Extensions.Http.Polly

2. 修改OrderService的Program.cs，配置HttpClient的重试/超时策略：

步骤3：验证REST同步调用

1. 重新构建并启动服务：

    docker-compose up -d --build

2. 模拟发送POST请求到http://localhost:8082/api/order

    curl -v -X POST http://localhost:8082/api/orders -H "Content-Type: application/json" -d "{'productId': 1, 'quantity': 1}"

3. 模拟商品服务故障：

   # 停止商品服务
   docker-compose stop product-service
   # 再次调用订单接口，会触发重试，最终返回失败
   curl -v -X POST http://localhost:5000/api/orders -H "Content-Type: application/json" -d "@payload.json"

4. 恢复商品服务后，调用恢复正常：

   # 启动商品服务
   docker-compose start product-service
   # 再次调用订单接口
   curl -v -X POST http://localhost:5000/api/orders -H "Content-Type: application/json" -d "@payload.json"

场景2：消息队列"发邮件"------订单创建后异步扣减库存与发券

这是经典的解耦场景。

创建订单是核心事务，必须快速响应。而扣库存、发优惠券等是重要但可稍后完成的操作。
关键实现：RabbitMQ异步通信（订单创建→库存减库存）

我们需要新增"库存服务"，实现订单创建后异步通知库存服务减库存，搞定消息持久化、重试、死信队列。

前置准备

1. 安装RabbitMQ容器（添加到docker-compose.yml）：

   # 在docker-compose.yml的services中添加
   rabbitmq:
    image: rabbitmq:3.12.7-management-alpine
    container_name: ms-rabbitmq
    ports:
      - "5672:5672"  # AMQP端口
      - "15672:15672" # 管理后台端口
    volumes:
      - rabbitmq-data:/var/lib/rabbitmq
    networks:
      - app-network
    restart: always
    environment:
      - RABBITMQ_DEFAULT_USER=admin
      - RABBITMQ_DEFAULT_PASS=123456
   
   # 在volumes中添加
   rabbitmq-data:

步骤1：创建库存服务（StockService）

# 新建库存服务项目
dotnet new webapi -n StockService -o stock-service -f net10.0 

# 安装RabbitMQ包
cd StockService && dotnet add package RabbitMQ.Client --version 6.8.1

编写库存服务代码

1. 创建OrderCreatedConsumer.cs（消息消费者）：

• 拓扑声明 ：自动声明业务交换机 ( order_exchange )、业务队列 ( order_created_queue )、死信交换机 ( dead_letter_exchange ) 和死信队列 ( dead_letter_queue )。
• 消息接收 ：后台监听队列消息，模拟扣减库存（内存字典）。
• 容错处理 ：消息处理失败时拒绝并发送至死信队列（ requeue: false ）。
  

2. Program.cs配置RabbitMQ连接，注册消费者
   

3. 编写StockService的Dockerfile（参考OrderService），并添加到docker-compose.yml：

   stock-service:
   build: ./stock-service
   container_name: stock-service
   ports:
     - "8083:80"
   environment:
     - RABBITMQ_HOST=rabbitmq
     - ASPNETCORE_ENVIRONMENT=Production
   depends_on:
     - rabbitmq
   networks:
     - app-network
   restart: always

步骤2：改造订单服务（生产者）

1. 安装RabbitMQ包：

    dotnet add order-service/OrderService.csproj package RabbitMQ.Client --version 6.8.1

2. 修改OrderService的Program.cs，添加RabbitMQ配置：

   注入 RabbitMQ IConnection 和 IModel
   

3. 修改OrderController，发送订单创建事件：
   

步骤3：验证异步通信

1. 启动所有服务：

   docker-compose up -d --build

2. 访问RabbitMQ管理后台：http://localhost:15672，账号admin/123456，能看到交换机、队列已创建；

3. 调用订单创建接口：

   curl -v -X POST http://localhost:5000/api/orders -H "Content-Type: application/json" -d "{ \"productId\": 1, \"quantity\": 2 }"

4. 查看库存服务日志：

   docker-compose logs stock-service

   能看到"商品1库存减2，剩余：98"的日志，说明异步通信成功；

5. 模拟库存服务故障：

   docker-compose stop stock-service

   再次创建订单，消息会堆积在RabbitMQ队列中，恢复库存服务后，消息会被消费。

关键点 ：消费者使用 autoAck: false 配合手动确认，只有业务处理成功后才 BasicAck，保证了消息的可靠处理。处理失败时可 BasicNack 进入死信队列（DLX）进行后续审计和补偿。

---

选型决策框架与避坑指南

决策流程图：下次面临选择时，按此路径思考

渲染错误: Mermaid 渲染失败: Parse error on line 3: ... -- 是 --> C["选择同步调用 (REST/gRPC)"]; B -----------------------^ Expecting 'SQE', 'DOUBLECIRCLEEND', 'PE', '-)', 'STADIUMEND', 'SUBROUTINEEND', 'PIPE', 'CYLINDEREND', 'DIAMOND_STOP', 'TAGEND', 'TRAPEND', 'INVTRAPEND', 'UNICODE_TEXT', 'TEXT', 'TAGSTART', got 'PS'

常见"坑"与最佳实践

• 同步调用之坑 ：
  • 超时设置不当 ：HTTPClient默认无超时，必须显式设置 Timeout 和 Polly 策略。
  • 未做熔断 ：下游持续故障时，应快速失败，避免资源耗尽。使用Polly的 CircuitBreaker。
• 异步消息之坑 ：
  • 消息丢失 ：确保生产者使用 Publisher Confirms，队列和消息都设置为持久化（durable: true）。
  • 消息重复消费（幂等性） ：网络问题可能导致消费者已处理但ACK未送达，消息重新投递。消费者逻辑必须支持幂等（如通过订单ID+状态判断）。
  • 消息顺序：大部分队列（如RabbitMQ）仅保证单个队列内单个消费者的顺序。需要全局顺序的场景，设计要格外小心（可考虑Kafka分区键）。

---

总结一下

1. 架构是权衡的艺术 ：REST和消息队列是互补 的，共同构成微服务通信的骨架。REST保证强一致与实时，消息队列追求高可用与解耦。你的架构图应该是两者的有机组合。
2. 划清边界 ：将你的业务操作区分为 "核心事务" 和 "周边能力" 。保证支付成功是核心（同步），但成功后的积分更新、短信通知可以异步。
3. 异步的价值超越"快" ：引入消息队列的核心收益是 "解耦" 和 "削峰" ，而不仅仅是"异步"。它让服务变得健壮且易于扩展。

下一章 ：《系统门面担当：用 Ocelot 搭建 API 网关，统一管控所有流量》，我们将为企业级微服务架构打造一个统一的、安全的、强大的总入口。

---

本文首发于CSDN：黑棠会长，转载请注明来源。

关注我，一起用更务实的方法把AI落到生产流程里。