微服务环境下跨服务闭环设计

单服务的闭环好搞——一个进程里，指标、决策、执行都在一块儿。但微服务环境下，一个业务流程横跨三五个服务，闭环就复杂了。订单服务降级了，支付服务不知道；库存服务扩容了，物流服务没跟上。各服务各搞各的闭环，要么重复动作，要么互相矛盾。

这篇聊跨服务闭环怎么设计。

单服务闭环为什么不管用了

假设一个电商下单流程：订单→库存→支付→物流。每个服务都有自己的闭环：

• 订单服务：错误率高→自动降级
• 库存服务：CPU飙→自动扩容
• 支付服务：超时→自动重试

问题来了：订单服务降级后，库存服务的请求量骤降，它的扩容闭环触发不了（因为压力没了），但它其实应该缩容。支付服务重试三次后成功了，但订单服务已经超时降级了，这笔订单就卡在中间状态。

根本原因：每个服务的闭环只看自己的指标，看不到全局状态。

三种跨服务闭环模式

模式一：中心协调器

最直觉的方案——加一个全局协调器，汇总所有服务的指标，做统一决策。

[订单服务] ──→ ┌──────────┐ ←── [库存服务]
[支付服务] ──→ │ 协调器    │ ←── [物流服务]
               │ 全局指标  │
               │ 统一决策  │
               └────┬─────┘
                    │
              ┌─────┼─────┐
              ▼     ▼     ▼
          [降级] [扩缩] [限流]

优点：全局视角，决策一致。缺点：单点故障，协调器挂了全完。

实现上，协调器不需要是独立服务，可以用现有的监控系统代替。Prometheus + Alertmanager 本质上就是中心协调器——所有服务往 Prometheus 推指标，Alertmanager 做统一告警和决策。

模式二：事件驱动

每个服务把自己的状态变更发到事件总线，其他服务订阅感兴趣的事件，各自做决策。

[订单服务] ──发布──→ [事件总线] ──订阅──→ [库存服务]
[库存服务] ──发布──→           ──订阅──→ [支付服务]
[支付服务] ──发布──→           ──订阅──→ [订单服务]

# 事件定义
class ServiceEvent:
    service: str       # "order-service"
    event_type: str    # "degraded" | "recovered" | "overloaded" | "healthy"
    reason: str
    timestamp: float

# 订阅者处理
def handle_upstream_event(event: ServiceEvent):
    if event.event_type == "degraded" and event.service == "order-service":
        # 下游服务：订单降级了，预计流量下降，准备缩容
        auto_scaler.set_target("payment-service", min_replicas=2)
    
    elif event.event_type == "overloaded" and event.service == "inventory-service":
        # 上游服务：库存扛不住了，限流保护
        rate_limiter.set_limit("order-service", max_rps=100)

优点：没有单点，服务自治。缺点：事件风暴——一个故障引发连锁事件，每个服务都在做决策，可能互相冲突。

模式三：Saga 闭环

把跨服务闭环和 Saga 模式结合。Saga 本来是做分布式事务的，但它的补偿机制天然适合闭环的”回滚”逻辑。

class SagaLoop:
    """用Saga模式管理跨服务闭环动作"""
    
    def __init__(self):
        self.compensations = []  # 补偿动作栈
    
    def execute_step(self, service: str, action: str, params: dict):
        """执行一步，同时记录补偿动作"""
        result = call_service(service, action, params)
        
        if result.success:
            # 记录补偿动作，万一后面失败可以回滚
            self.compensations.append({
                "service": service,
                "compensate_action": self._get_compensation(action),
                "params": params
            })
        else:
            # 这步失败了，执行所有补偿
            self._rollback()
        
        return result
    
    def _get_compensation(self, action: str) -> str:
        return {
            "degrade": "recover",
            "scale_up": "scale_down",
            "throttle": "unthrottle",
        }.get(action, "noop")
    
    def _rollback(self):
        """逆序执行所有补偿动作"""
        while self.compensations:
            comp = self.compensations.pop()
            call_service(
                comp["service"],
                comp["compensate_action"],
                comp["params"]
            )

优点：有事务性，动作要么全成功要么全回滚。缺点：不是所有场景都需要事务性，有时候部分降级就够了，强制全有全无反而过重。

实际怎么选

场景	推荐模式	原因
服务少（<5个），链路简单	中心协调器	简单直接，维护成本低
服务多，团队独立	事件驱动	去中心化，各团队自治
涉及资金/库存等强一致场景	Saga 闭环	必须保证事务性
混合场景	事件驱动 + 关键路径Saga	灵活组合

大多数团队用事件驱动就够了。中心协调器在小规模时好用，规模大了就是瓶颈。Saga 只在钱和库存相关的场景才值得上。

分布式追踪：跨服务闭环的眼睛

不管用哪种模式，跨服务闭环的前提是能看到请求在服务间的流转。没有分布式追踪，你连问题出在哪个服务都不知道，更别说自动闭环了。

OpenTelemetry 是现在的标准方案：

# 在每个服务里加trace
from opentelemetry import trace

tracer = trace.get_tracer("order-service")

@tracer.start_as_current_span("create_order")
def create_order(order_id: str):
    # 标注关键节点
    span = trace.get_current_span()
    span.set_attribute("order.id", order_id)
    
    try:
        inventory_check(order_id)   # 调库存服务
        process_payment(order_id)   # 调支付服务
        schedule_shipping(order_id) # 调物流服务
    except Exception as e:
        span.set_status(Status(StatusCode.ERROR, str(e)))
        # 闭环决策：追踪到哪一步失败的
        span.set_attribute("error.step", "payment")
        raise

闭环决策可以用 trace 数据做输入：如果 80% 的失败都卡在支付服务这一步，那降级策略应该优先保护支付服务，而不是无脑降级订单服务。

一个容易忽略的问题：循环触发

服务A降级→服务B流量下降→服务B缩容→服务A恢复→流量回到服务B→服务B扛不住→服务B降级→……

这种循环在单服务闭环里不会出现，但在跨服务场景下特别常见。解法是加冷却期：

import time

class CooldownGuard:
    def __init__(self, cooldown_seconds: int = 300):
        self.last_action = {}
        self.cooldown = cooldown_seconds
    
    def can_act(self, service: str, action: str) -> bool:
        key = f"{service}:{action}"
        now = time.time()
        last = self.last_action.get(key, 0)
        if now - last < self.cooldown:
            return False
        self.last_action[key] = now
        return True

5 分钟冷却期，同一服务同一动作 5 分钟内不重复触发。足够让系统稳定下来，避免来回横跳。

服务网格：基础设施层的闭环

如果你用 Istio 或 Linkerd，很多闭环动作其实可以在基础设施层做，不用业务代码操心：

• 熔断：Istio DestinationRule 的 outlierDetection，服务错误率超阈值自动摘除
• 限流：Istio RateLimit，QPS 超限自动排队
• 重试：VirtualService 的 retries，失败自动重试

服务网格的好处是对业务透明——业务代码不需要知道自己在被闭环保护。坏处是配置复杂，而且只能做通用的闭环（熔断、限流），业务语义的闭环（比如”支付失败后自动取消订单”）还是得在应用层做。

最佳实践：通用闭环走网格，业务闭环走应用层。 别在一个层面做所有事。

跨服务闭环的检查清单

• 各服务的闭环动作是否会互相冲突？有协调机制吗？
• 一个服务降级后，上下游服务能感知到吗？怎么感知的？
• 有冷却期吗？循环触发的问题考虑到了吗？
• 分布式追踪上了吗？闭环决策能看到 trace 数据吗？
• 服务网格能覆盖的闭环，是不是已经交给了基础设施层？
• Saga 场景下，补偿动作测试过吗？（补偿失败怎么办？）

跨服务闭环的难度不在代码，在设计。想清楚服务间的依赖关系、动作的副作用、故障的传播路径，比写代码重要得多。

---

相关阅读：

• Chris Richardson, “Microservices Patterns” - Chapter 7 (Saga)
• Istio 文档 - Outlier Detection & Circuit Breaking
• Google SRE Book Chapter 19 - “Service Mesh”