并发边界是服务弹性与故障隔离的核心契约，需明确定义实例级、服务级、业务级三层并发上限，并通过自定义指标（如service_concurrent_requests）、信号量舱壁、分池连接等手段强制落地，且必须可验证、不可绕过。
因为并发边界直接决定服务在流量洪峰下的稳定性、可预测性与故障收敛范围——它不是线程数配置技巧，而是把“谁可以同时操作什么资源”这件事，在服务设计初期就固化为契约。
并发边界定义服务的真实弹性粒度
高频迭代中，一个服务的扩缩容决策不能只看CPU或内存水位。如果没明确定义并发边界，就会出现：扩容10个实例后，因共享下游数据库连接池或缓存锁，实际并发能力只提升2倍；或者灰度发布时新旧版本共用同一限流计数器，导致误熔断。
- 每个微服务必须声明自己的核心资源并发上限：比如“订单创建接口最大并行处理数=200”，该数值需与下游DB连接池、Redis QPS配额、第三方API调用额度对齐
- 边界要分层表达：实例级（单Pod内最大协程数）、服务级（全集群总并发许可数）、业务级（如“秒杀库存扣减”专属信号量桶）
- Kubernetes HPA不能只靠metrics-server指标，必须接入自定义指标如
service_concurrent_requests，该指标应由服务主动上报，并受边界策略约束
并发边界是隔离失效传播的第一道墙
高并发下，局部慢请求会通过线程阻塞、连接占满、锁竞争等方式反向拖垮上游。没有显式边界的系统，故障会像墨水滴入清水一样无序扩散。
- 网关层必须为每个下游服务设置独立的信号量舱壁（SemaphoreBulkhead），而非复用全局线程池——这是防止雪崩的硬隔离
- 数据库访问层需按业务场景切分连接池：读写分离池、报表查询池、后台任务池，彼此不抢占
- 本地缓存（如Caffeine）要配置maximumSize + expireAfterWrite，避免GC压力传导到整个JVM
并发边界必须可验证、可演进、不可绕过
很多团队写了限流规则，但CI/CD流水线不校验其有效性，上线后才发现阈值设错或被代码绕过。
- 所有并发控制策略（信号量、连接池、队列深度）必须在OpenAPI Spec中用
x-concurrency字段标注，并纳入契约扫描 - 服务启动时强制校验：若配置的并发许可数超过下游依赖方承诺的SLA（如Redis集群maxclients=10000），则拒绝启动并告警
- 每次接口变更PR，静态检查工具需确认是否新增了未声明并发约束的同步方法或共享状态变量
不复杂但容易忽略
