先纠正一个普遍认知
百度斗篷是本文的核心主题。做百度投放的，十个人里有八个觉得只要服务器没报警、页面还能打开，容量就没问题。这个想法在日均几百个点击的时候确实站得住脚，随便一台配置正常的云服务器都绰绰有余。但你把这套判断搬到日均三五千点击、跳转链路中间还夹着两三个环节的场景里试试，问题马上就冒出来了：某个中间层的连接池在某个时间点悄悄耗尽了，页面表现不是打不开，而是打开慢了八百毫秒；不是给你报500，而是一部分请求静悄悄地走了降级页面。你坐在那还以为容量挺够的，实际上转化已经在无声无息地漏了。
全链路压测与容量评估模型要抓的就是这种"看着没事、实际已经在丢量"的状态。它跟单纯给服务器做一次并发测试完全是两码事，它把百度斗篷链路上的每一层——入口请求、规则匹配、目标选择、跳转执行、落地页返回——全部放进压力推演里，找出哪个环节最先摸到天花板，然后赶在它真正影响业务之前，把资源预留和降级阈值定好。
概念定义与边界
百度斗篷全链路压测与容量评估模型，放在百度流量分发的语境里说，就是把整条跳转链路当成一个整体来压，用尽量贴近真实流量特征的压测流量，一层一层地量出各环节的容量上限和衰减拐点，再拿这些数据去推资源预留策略和降级触发阈值的一套方法。 这个概念里藏着三个关键词，得一个一个掰开看。头一个是"全链路"，意思是压测对象从来不是某一台机器或者某一个接口，而是从用户点广告那一下开始，到最后看见落地页为止，中间所有的网络和计算环节全算进去。第二个是"容量评估"，它要回答的压根不是"现在够不够用"，而是"什么条件下会不够、不够的时候哪个地方先坏、坏了以后系统能不能自己降级扛住"。第三个是"模型"，说明这东西是一套能反复用、能调参数的推演框架，不是出一份压测报告就完事了。
这个模型有它明确的边界。第一，它管的是百度生态里的流量分发场景，你直接拿去套Google Ads或者其他广告平台的链路特征，对不上。第二，它只负责容量和稳定性问题，内容审核规则、素材合规这些事不归它管。第三，它的价值得在链路层级多、流量波动明显的项目里才看得出来。要是你只有一条301跳转、日均几百个点击，硬上这个模型，成本比收益还高。
模型的核心组成
压测基线的推导逻辑
压测基线这个东西，最怕的就是拍脑袋说"每秒三百并发"。它得从历史流量数据里往外推。先拉最近七到十四天的分时点击量，找到峰值时段和峰值倍数。举个例子，日均一千二点击的项目，峰值时段可能就集中在上午十点和晚上八点，峰值分钟级请求量能达到日均分钟级的四到六倍。压测基线就应该从峰值分钟级请求量起步，再乘一个安全系数。
有个地方特别容易踩坑：拿日均量直接除以86400秒，得出每秒请求数，然后照着这个数去压。这么测出来的结果基本没有参考价值，因为流量从来就不是均匀铺开的。对的做法是找到最要命的那一分钟，把那一分钟的请求量当作压测起点。要是新项目手里没历史数据，可以用投放预算反推：预算除以平均点击价格，拿到预期日点击量，再按行业常见的峰值倍数估一个出来。
资源预留的三个层次
资源预留从来不是留一台备用服务器就完事了。百度斗篷链路里，资源预留得掰成三层来看。 第一层是计算资源预留。规则匹配服务和跳转决策服务的CPU、内存使用率，平时就该压在最大容量的一半以下。这样峰值来的时候才有弹性空间可以往上顶。第二层是网络资源预留。带宽和连接数是最容易被漏掉的瓶颈，尤其是跳转链路里夹着独立中间层服务的时候，连接池耗尽的速度往往比CPU还快。第三层是外部依赖的资源预留。链路里要是调了第三方API、DNS解析服务或者对象存储，这些外部依赖的容量上限也得算进评估里。第三方的限流阈值不会提前跟你打招呼，只能靠压测去摸。
降级阈值的设定方法
降级阈值是整个模型里最有决策分量的部分。它要回答的问题是：某个环节容量快顶到天花板的时候，系统该先扔什么？ 合理的降级顺序应该是这样的：先关掉非核心的日志采集和统计功能，再降低规则匹配的精度，再压缩中间层的超时时间，最后才轮到切换降级页面。每一层降级都得有明确的触发指标和恢复阈值，别让系统在"降级—恢复—再降级"之间来回抖。
用词上得说清楚：这里讲的降级，不是把跳转链路给断了，而是把一部分非核心功能暂时关掉，保住核心跳转能力不失效。
适用条件与决策边界
全链路压测与容量评估模型，不是每个百度斗篷项目都得上。它的适用条件有四个。 第一，日均点击量在两千以上，而且峰值倍数超过三。低于这个量级，单机配置合理的话很难触发容量瓶颈，做全链路压测的收益不明显。第二，跳转链路包含两个或以上中间环节。要是只有一条从广告直接到落地页的302，压测对象太单薄了，基础的并发测试就能应付。第三，流量波动有明显的周期性或突发性。每天的点击量曲线如果几乎是一条直线，容量评估做一次就够了，犯不着持续维护模型。第四，业务对跳转延迟的容忍度在500毫秒以内。业务本身要是能接受一两秒的跳转延迟，容量衰减到阈值的时候对转化的影响有限，这事儿的优先级可以往后放。
说白了，这个模型管的是"复杂链路在压力下能不能稳住、能不能降级"的问题。一个项目如果链路简单、流量平稳、延迟容忍度高，那精力花在规则维护和内容适配上，回报会大得多。
与相邻概念的对比
容量评估经常跟性能测试、压测工具选型搅在一起聊，三者的边界其实不一样。
性能测试关心的是"单个请求跑多快"，比如首字节时间、完整跳转时长。压测工具选型关心的是"用什么工具来造压力"，Apache Bench还是wrk。容量评估关心的则是"整条链路在什么条件下开始变慢、变坏、变不可用，以及怎么在它变坏之前插手"。前两个是手段，最后这个才是目的。
还有一个容易搞混的是灰度发布里的流量分配。灰度发布解决的是"新规则上线时怎么一步步放量"，容量评估解决的是"量放上去之后系统扛不扛得住"。两者之间有衔接关系，但决策目标不同。灰度发布的回滚阈值看的是业务指标，容量评估的降级阈值看的是技术指标。
一个实战复盘
有个做本地生活服务的投放项目，日均点击量三千六左右，峰值能冲到一万二。跳转链路是广告点击先进自有中间页，中间页做完规则匹配，再决定跳到哪个落地页。服务器用的是四核八G的云主机，平时CPU使用率不到30%。
上线三个月后，客户反馈转化率在晚高峰时段明显往下掉。一开始怀疑是落地页加载慢，查了落地页的监控，响应时间挺正常的。后来把中间页的访问日志拉出来按分钟聚合，发现晚高峰有一批请求的跳转耗时从平时的280毫秒涨到了900毫秒以上。再往下追，是中间页和数据库之间的连接池在高峰时被耗干了，请求全在排队等可用连接。
问题找到了，但处理起来没那么痛快。直接加大连接池，能缓一阵，但到底加到多少才够，心里没数。后来用全链路压测的思路重新做了容量推演：先按峰值分钟级的请求量构造压测流量，再一层层加压，把连接池耗尽、响应时间超阈值、错误率开始上涨的三个拐点全记下来。结果发现，连接池大小从默认的50加到120，能扛住峰值流量的1.8倍。同时设了一个降级阈值：连接池使用率超过75%的时候，先关掉中间页的实时日志写入，把连接让出来给核心查询用。
调完之后，晚高峰的跳转耗时稳定在350毫秒以内，转化率也回到了正常水平。这个案例的教训就一条：容量问题往往不在你盯得最紧的页面加载上，它藏在某个连接池、某个缓存、某个外部依赖的"看着还挺正常"的衰减里。
概念性FAQ
普通服务器压测只测单台机器或者单个接口的并发能力。全链路压测把从广告点击到落地页返回的所有环节全塞进压力范围里，中间的规则匹配层、数据库连接层、外部API调用、DNS解析一个不落。前者回答"这台机器能扛多少"，后者回答"这条链路会先在哪个环节断"。
资源预留多少才够？
没有一个放之四海皆准的比例，但有一套能验证的推导逻辑：以峰值分钟级请求量为基线，乘上1.5到2的安全系数，逐层压测找出第一个瓶颈点，把那个点的资源上限调到压测值的两倍。预留多少取决于瓶颈点在哪、恢复要多久，这事跟简单按CPU使用率定个固定值是两条路子。
容量评估模型需要多久更新一次？
流量规模稳定的话，每季度或者每次投放策略大调整之后做一次全量评估就够了。投放预算、页面结构或者链路层级有变化，得在变化上线前做增量评估。流量波动剧烈的行业，建议把核心指标的监控和降级阈值绑在一起，用自动化监控替掉人工定期检查。
