微服务并发上来先守住哪条线并发突然上来时最危险的不是某个指标变红而是入口仍在把请求送往已经变慢的依赖。线程池、连接池和内部队列会依次堆满原本可以快速拒绝的一小段流量最后变成整站超时。对于带 Embedding、向量检索、重排的 RAG 服务这个问题更明显每一段的容量和耗时不同不能用一个“整体 QPS”掩盖差异。线程池耗尽通常只是后果同步调用等待下游时会占着请求线程。向量库响应变慢更多线程被卡住线程不够后请求开始排队排队时间又拖长连接占用。此时单纯加大线程池可能只是让更多请求同时压向同一个瓶颈。换成响应式 I/O 能减少等待线程但它不会替服务决定该拒绝多少请求也不会让下游凭空增加处理能力。排查应把线程栈、连接池占用、等待队列、依赖延迟和超时原因放到同一个时间段里看。若大量线程在等待同一客户端优先确认该客户端的并发限制、连接数和超时若入口已经排队继续扩大业务线程通常不是第一步。容量要按链路阶段拆开估先按请求类型列出经过的阶段短问题是否需要重排长文本的 Embedding 占用怎样冷缓存会多一次什么调用。记录每段的服务时间、连接占用、临时内存、失败与取消比例。到达率乘以平均在途时间可以帮助估算并发但长尾、重试和排队会让这个估算过于乐观因此上限必须由分级压测校正。压测不应只跑理想短查询。至少要有冷缓存、慢向量库、重排不可用、客户端中断和大输入等场景并观察活动请求、队列长度、连接池、堆内存和垃圾回收。停止加压后数据是否回落同样重要。得到的限制应绑定当前版本、实例规格和数据集换了模型或索引结构就应重新确认。在依赖前设置明确的舱壁入口限流、依赖舱壁、连接池和超时应来自同一份容量计划。下面的 WebFlux 片段把保护范围放在向量检索这个 Publisher 上Embedding 与重排若有独立瓶颈应各自配置不要共用一个看似方便的数字。public MonoRagContextDTO search(String query) { return createEmbedding(query) .flatMap(embedding - vectorSearch(embedding) .transformDeferred(BulkheadOperator.of(vectorBulkhead)) .transformDeferred(CircuitBreakerOperator.of(vectorBreaker))) .onErrorResume(BulkheadFullException.class, error - busyResponse(query)); }busyResponse不应悄悄伪装成完整检索结果。若产品允许缓存、关键词召回或跳过重排返回内容要标明来源和能力变化对准确性要求高的场景明确告知繁忙往往比给出未经确认的上下文更负责任。舱壁是立即拒绝还是允许短暂等待也需结合调用方的重试策略一起决定。监控的是在途工作而非单个线程数日常看板至少应包含入口接受与拒绝、每级队列、舱壁剩余槽位、连接池、下游延迟、超时和降级比例。恢复条件最好有一定迟滞避免服务在正常与降级之间反复跳转。并发上来先守住的那条线很朴素进入下游的在途工作必须有上限超过上限要尽早结束并让用户和调用方知道发生了什么。