屏障是什么
屏障与顺序是两件事：顺序规定「先做哪个再做哪个」，屏障规定「等到什么条件才继续」。屏障有三种常见判定：完成后屏障（这一批全部结束）、法定数量屏障（至少 N 个节点就绪即可继续）、时间屏障（固定等待，用于给外部系统留缓冲）。实现方式可以是分批执行并等待批次标记、检查服务就绪状态、用分布式锁互斥，或利用编排平台自带的分批参数与滚动等待。核心要求始终一致：判定条件必须可观测，等待必须有上限。
基本信息
| 屏障类型 | 完成后屏障、法定数量屏障、时间屏障 |
|---|---|
| 实现手段 | 分批加批次标记、服务就绪检查、分布式锁、平台滚动等待 |
| 判定依据 | 状态查询接口、就绪探针、批次完成标记，不用进程存活代替 |
| 关键约束 | 屏障必须带超时与人工破障路径 |
典型使用场景
- 滚动升级：同一时刻只允许一个或一小组节点不可用
- 主从切换：确认新主已接受写入后再切换下游连接
- 双活或机房切换：等待流量归零后再动后端
- 依赖就绪：数据库结构变更完成才启动应用发布
- 缓存预热：预热完成后再放量，避免刚上线就把后端打穿
- 下游保护：上游批次数量受限，等下游消费消化完再发下一批
带超时的等待与破障
带超时的等待与破障
# 等本批全部结束再放行下一批，超时必须中止而不是无限等待
deadline=$(( $(date +%s) + 600 ))
while :; do
running=$(curl -fsS "https://center.example.com/batch/current" | grep -c 'running' || true)
if [ "$running" -eq 0 ]; then echo "本批已完成，放行下一批"; break; fi
if [ "$(date +%s)" -ge "$deadline" ]; then
echo "等待超时，需人工确认后破障" >&2; exit 1
fi
sleep 10
done
# 就绪判定要用服务自检，而不是进程是否存活
# kubectl rollout status deploy/app --timeout=10m # 平台自带就绪等待
# 锁类屏障务必设 TTL，避免持锁进程异常退出后永久死锁屏障类型与风险
| 类型 | 继续条件 | 优点 | 风险 |
|---|---|---|---|
| 完成后屏障 | 本批全部结束 | 最稳，适合不可逆步骤 | 受最慢节点拖累 |
| 法定数量屏障 | 达到 N 个就绪 | 容忍个别慢节点 | 数量算错会带着故障继续 |
| 时间屏障 | 固定等待 | 实现最简单 | 等待时长靠经验，易过短或过长 |
| 锁屏障 | 取得互斥锁 | 防并发重入有效 | 锁无 TTL 时死锁风险高 |
屏障把并行换成可控，代价是总时长拉长。窗口规划时要把屏障等待时间算进作业时长，否则批次还没走完窗口就结束了，剩下的部分被迫顺延。
屏障判定要观测服务真实状态：进程存在不等于服务可用，端口监听不等于能写入。用「进程退出」当继续条件，往往在依赖还没准备好时就进入下一步，把故障推迟到更晚暴露。