请求-响应是什么
请求-响应是最直观的交互模式：调用方发起请求并等待响应。实现简单、语义清晰、便于调试与追踪，代价是双方在时间与可用性上紧耦合：下游慢，上游线程就跟着等；下游不可用，上游很快跟着失败。
配套手段
同步调用必须配齐超时、重试、熔断与降级，否则一次下游抖动会顺着调用链放大成全局故障。同步链路每增加一跳，延迟叠加与失败概率都会上升，因此关键链路要控制跳数，长耗时动作优先改成异步处理。
基本信息
| 适用 | 读操作、需要即时结果的交互、低延迟链路 |
|---|---|
| 同步开销 | 调用链路过长时延迟叠加，故障向上传播 |
| 配套手段 | 超时、重试退避、熔断、降级 |
| 超时分解 | 入口 1000ms，服务 A 800ms，服务 B 500ms，逐级留出处理与网络余量 |
关键设计点
- 超时：按下游 P99 加余量设定，外层超时大于内层之和
- 重试：仅限幂等操作，指数退避加随机抖动，并限制次数
- 熔断：错误率超阈值快速失败，保护线程与连接资源
- 降级：预置默认值或返回缓存旧值，维持核心路径可用
- 隔离：按下游拆分线程池或信号量，避免连锁阻塞
可用性怎么算
串行同步调用的可用性约等于各环节可用性相乘：三个可用性均为 99.9% 的下游串起来，整体可用性降到约 99.7%，即每月多出两小时不可用。这也是同步链路必须控制跳数的量化理由。相比之下，异步消息把下游可用性从请求路径上移开，代价是结果不再即时返回。
同步链路每增加一跳都会放大整体延迟与失败概率；关键链路应控制跳数，把批量与广播类场景交给发布订阅。
读多写少且需要即时反馈的场景适合同步；如果一次请求要通知十个下游，用同步循环调用得到的可用性约等于各下游可用性相乘，通常低到无法接受。