diff --git a/hzh/MS/02-服务治理.md b/hzh/MS/02-服务治理.md
index cf2831a..a4d8f35 100644
--- a/hzh/MS/02-服务治理.md
+++ b/hzh/MS/02-服务治理.md
@@ -169,6 +169,49 @@ message Item {
}
```
+### 典型请求链路
+
+一次下单操作会串联多个服务和两种通信模式:
+
+```mermaid
+sequenceDiagram
+ participant C as Client
+ participant GW as API Gateway
+ participant O as Order Service
+ participant I as Inventory Service
+ participant P as Payment Service
+ participant MQ as Message Queue
+
+ C->>GW: POST /orders (HTTP/JSON)
+ GW->>O: CreateOrder (gRPC)
+
+ rect rgb(200, 220, 250)
+ Note over O,P: 同步 RPC 链
+ O->>I: CheckStock (gRPC)
+ I-->>O: {ok: true, quantity: 1}
+ O->>P: Charge (gRPC)
+ P-->>O: {success: true}
+ end
+
+ O-->>GW: {orderId: "ORD-001"}
+ GW-->>C: 200 OK
+
+ rect rgb(255, 240, 220)
+ Note over O,MQ: 异步事件解耦
+ O->>MQ: Publish OrderCreated Event
+ MQ->>N: Consume → SendSms
+ Note right of N: 通知类场景,不阻塞主流程
+ end
+```
+
+> [!keypoint] 关键洞察
+>
+> - 同步链路(蓝色):**gRPC 直连**,延迟低,适合核心事务(查库存 → 扣款)
+> - 异步链路(橙色):**消息队列**,解耦非关键路径(发短信、发积分),即使失败也不影响下单主干
+> - API Gateway 负责统一鉴权和限流,下游服务之间通过 gRPC 高效通信
+>
+> 这就是「同步 RPC 保性能,异步 MQ 保解耦」的组合拳。
+
### 同步 vs 异步
> [!question] 关键时刻的判断
@@ -232,12 +275,30 @@ func retryWithBackoff(ctx context.Context, maxRetries int, fn func() error) erro
当下游服务频繁失败时,快速失败避免线程堆积雪崩:
```mermaid
-stateDiagram-v2
- [*] --> Closed: "正常状态"
- Closed --> Open: "失败率超过阈值"
- Open --> HalfOpen: "等待探测间隔"
- HalfOpen --> Closed: "探测成功"
- HalfOpen --> Open: "探测失败"
+flowchart TD
+ CB{{🔘 CIRCUIT BREAKER}}
+
+ subgraph CL ["CLOSED — 正常"]
+ C["请求放行
⏱ 实时统计成功率
⚠️ 连续失败 → 熔断"]
+ end
+
+ subgraph OP ["OPEN — 熔断"]
+ O["🚫 请求短路
💥 直接返回降级响应
🛡 不调下游,防雪崩"]
+ end
+
+ subgraph HO ["HALF-OPEN — 半开"]
+ H["🔍 放行少量探测请求
✅ 成功 → 恢复全量流量
❌ 失败 → 重新熔断"]
+ end
+
+ CB --> CL
+ CL -.->|失败 > N| OP
+ OP -.->|等待超时| HO
+ HO -->|探测成功| CL
+ HO -->|探测失败| OP
+
+ style CL fill:#e6f9e6,stroke:#4caf50,stroke-width:3px,color:#000
+ style OP fill:#ffebee,stroke:#ef5350,stroke-width:3px,color:#000
+ style HO fill:#fff8e1,stroke:#ffa726,stroke-width:3px,color:#000
```
```go