流量一上来就崩老实说是你没提前想明白做后端这几年我见过太多系统在流量洪峰面前瞬间“社会性死亡”。最典型的场景是业务方兴冲冲跑来说“我们要搞个大促/直播/活动预期流量翻五倍”结果活动刚开始十分钟监控面板一片飘红报警电话打爆数据库连接池被打穿接口超时率飙到90%用户疯狂刷“白屏了”“转圈了”。然后大家开始熬夜紧急扩容、重启、拆缓存……折腾到凌晨两三点流量高峰过去了系统“莫名其妙”又恢复了。你以为这是运气问题是硬件不够好是代码写得烂老实说都不是。根子在于你压根没在流量进来之前把几件事想明白你的系统到底能扛多少扛不住的时候先牺牲谁依赖的下游要是先挂了怎么办你有没有在代码层面提前埋好“保命开关”这篇文章我不想讲什么高深理论就结合我自己踩过的坑、做过的压测、复盘过的故障聊聊一个后端团队在流量这件事上必须提前想明白的东西。内容适合所有正在被“流量焦虑”折磨的开发者、架构师和技术负责人。1. 先别急着加机器先搞清楚“崩”到底崩在哪很多人一听到“系统扛不住”第一反应就是加服务器、加带宽、加数据库配置。但大多数情况下你加的机器根本没解决真正的问题。因为流量上来之后系统崩溃通常不是单一原因而是一条链路上某个环节最先被击穿然后引发连锁反应把整个系统拖下水。1.1 你以为的瓶颈往往不是真正的瓶颈我参与过很多次故障复盘发现一个共性规律大家最初怀疑的原因基本都跟根因对不上。举一个真实例子。某个业务做秒杀活动开始之后用户纷纷反馈页面打不开。运维同事第一反应是“带宽是不是满了”结果查了发现带宽只用了30%。然后怀疑Nginx连接数不够看了指标也还好。最后查后端应用发现CPU也不高内存也不紧张。绕了一大圈最终定位到数据库——主库的CPU打满了大量慢查询把数据库拖死然后所有依赖数据库的接口全部阻塞连接池耗尽应用线程全部卡在等数据库响应上表现为应用“假死”、接口超时。这个案例说明什么说明系统的瓶颈点可能藏在调用链路的任何一个环节。如果你连自己的系统哪个组件最先会扛不住都没搞清楚加再多机器也只是把钱扔进水里。我的经验是在谈容量之前先花时间回答以下几个问题当前系统的调用链路是什么样从用户请求到最终响应经过了哪些服务、哪些存储、哪些外部依赖每个环节的负载上限是多少不是“理论上能扛多少”而是“实测压到多少开始劣化”各个环节之间的依赖关系如何是同步调用还是异步解耦是强依赖还是可以降级瓶颈点是单个还是多个会不会同时被打穿如果这些问题你需要在故障发生后才开始排查那说明你之前确实没有“提前想明白”。1.2 容量崩溃这件事本质是个排队论问题说到这我想引入一个形象的类比。很多刚入行的同学会把系统性能理解成“一条水管能流多少水”以为只要水管够粗流量再大也没问题。但现实中的系统更像一个复杂的“交通网络”不是简单的一条管道而是由多个路口、多个收费站、多个服务区组成的系统。举一个最简单的模型假设你的应用每秒能处理1000个请求数据库每秒只能处理500个请求那么当流量达到800 QPS时应用扛得住但数据库已经超负荷了请求开始排队。排队越长响应越慢响应越慢用户就越着急重试重试越多请求量就越大请求量越大排队就更严重——这就是典型的“雪崩效应”。更可怕的是这个排队不只是发生在数据库层还可能发生在应用线程池、连接池、消息队列、第三方接口调用等每一个环节。每个环节都有它的“服务速率”和“排队容量”只要有一个环节的服务速率小于请求到达速率整个链路就会被拖垮。所以说处理流量问题的第一课不是“优化代码”而是“建立系统思维”——你需要把整个调用链路上每一环的承载力都盘点清楚找出那个“最先见底”的环节。这个环节才是你真正需要投入资源去加强的地方。2. 容量评估的核心不是拍脑袋是建立流量-资源换算模型搞清楚了“崩在哪”之后接下来要考虑的就是“到底能扛多少”。这件事很多团队做得非常随意通常是“感觉应该没问题吧”“去年也就这个量”“服务器是8核的应该够吧”。老实说这就是典型的拍脑袋。容量评估必须建立在一个可计算的模型之上。这个模型要回答一个问题给定一个预估流量我需要多少实例、多少内存、多少数据库连接才能稳定扛住。2.1 先把流量估清楚峰值 QPS 到底是多少做容量规划的第一步是把你预判的流量峰值转成一个具体的数字每秒多少个请求。我在做业务方的技术方案时通常会让他们回答几个问题活动预计多少用户参与是10万还是100万用户主要在什么时间段内涌入是全天均匀分布还是集中在某一个小时一个用户从进入活动到结束平均会产生多少次请求这些请求是按什么比例分布到各个接口的比如浏览、下单、支付各占多少有了这些信息就可以做一个简单的估算。假设预计100万用户参与活动持续4小时高峰期集中在第一个小时那第一个小时内大概有60%的用户也就是60万用户涌入。如果每个用户在这一个小时内平均会触发20次请求那这一个小时内总请求量大约是1200万次平均QPS大约是3333。考虑到流量不会完美均匀分布通常会按2到3倍的峰值系数来预留也就是说你至少要按每秒7000到10000的QPS来做容量规划。这套估算逻辑虽然粗糙但比拍脑袋靠谱得多。它给你一个可验证的基数后面压测也是基于这个数字去设计和评判的。2.2 用压测找出“单机承载力”再反推实例数流量估出来了接下来就要知道“一台机器能扛多少”。这个数据不能靠猜只能靠压测。我常用的做法是这样的找一台配置和线上一致的测试机部署好完整的应用把依赖中间件全部切到压测环境然后逐步加压记录不同QPS下的响应时间和资源消耗曲线。重点关注三个数据点正常运行水位响应时间在100毫秒以内CPU在40%左右的QPS值容忍水位响应时间在200到300毫秒左右CPU在70%到80%的QPS值崩溃水位响应时间开始指数级上升错误率飙升的QPS值。一台机器的“安全水位”我一般取正常运行水位而不是最大水位。因为你要给突发流量、GC抖动、网络抖动留出冗余。有了单机安全水位实例数就好算了。假设你预估峰值是10000 QPS单机安全水位是500 QPS那你至少需要20台实例。注意这是“至少”还要考虑可用性比如你在云上挂了20台如果有一台宕机剩余19台要扛住全部流量那么每台需要扛到526 QPS已经略微超载了。所以实际部署时我通常会在理论值基础上再加20%到30%的冗余。2.3 别忘了“外部依赖”的容量这才是最容易爆的雷容量规划里最容易漏掉的一块你以为算了自己系统的容量就够了但你的系统还依赖数据库、Redis、消息队列、第三方接口……这些外部组件同样有容量上限。我见过太多系统应用层扩容做得漂漂亮亮结果活动一开始数据库连接数被打满直接成为全局瓶颈。原因很简单应用加了20台机器每台机器的连接池配了30个连接总连接数就是600个数据库的连接数上限可能也就300多个直接翻倍打爆了。所以做容量评估的时候一定要把每个关键依赖的容量一起评估进去数据库当前连接数水位是多少最大连接数是多少如果QPS翻倍新增的连接需求有多少慢查询会不会把CPU打满Redis内存占用率多少操作耗时多少如果大流量来了热点key会不会导致单节点过热消息队列堆积水位如何消费速度能不能跟上生产速度外部HTTP接口你依赖的第三方接口它的限流阈值是多少你给它的调用量预估是多少这些数据都应该在活动前整理成一张容量清单逐项核对。任何一个环节被击穿整个链路的稳定性都无从谈起。3. 限流、熔断、降级与隔离写在代码里的“提前想明白”如果说容量规划是“数学题”那架构层面的保护机制就是“保险杠”。流量永远有不确定性你以为算了峰值实际来了个超预期十倍的大爆发怎么办这时候就得靠提前写好代码里的“保命开关”。3.1 限流不是“拒绝用户”是“保命”很多人对限流有误解觉得限流就是拒绝用户、影响体验所以在系统快崩的时候还死扛着不受限。事实上适度的限流恰恰是为了让更多用户体验到“正常服务”。我通常这样和业务方解释如果系统容量只能支撑1000 QPS流量突然飙到5000 QPS你不限流的结果是什么是5000个请求全部超时、全部失败用户一个也进不去白屏刷屏。如果你做了限流把入口流量控制在1200 QPS那么有1200个用户能流畅使用剩下的3800个用户会被提示“当前排队人数过多请稍后再试”——至少这1200个用户是满意的而且系统不崩过一会儿流量降下来所有人都能继续用。限流的位置很重要。我建议在网关层做一层全局限流在应用层再做一层接口级别的细粒度限流。网关层解决的是“整体入口防爆”接口层解决的是“单点接口被刷”。具体实现上常用的算法有令牌桶和滑动窗口我个人偏爱令牌桶因为它允许一定的突发流量比较贴合真实用户行为。很多现成的组件都内置了限流能力比如Sentinel、Hystrix也有网关自带的限流插件不用重复造轮子。3.2 熔断别让你的系统给“病号下游”陪葬熔断这个念头我是吃过大亏之后才彻底想明白的。有一年我们某个活动依赖了外部的一个营销服务接口。活动开始后外部服务响应突然变慢从原来的50毫秒一路劣化到5秒。我们的应用是同步调用线程全部阻塞在等待响应上线程池很快被耗尽新的请求进不来整个应用陷入假死。最要命的是一台台机器陆续倒下形成“应用崩-健康检查失败-被摘除-流量转移给其他机器-其他机器也崩”的死亡螺旋。复盘的时候我发现代码里根本没有熔断逻辑对第三方接口的调用没有任何超时降级保护。我当时的感受就是你把系统挂在别人的木马上别人一倒你也跟着倒。正确的做法是所有依赖外部系统的调用都必须设置超时时间和熔断阈值。比如调用第三方接口超过500毫秒就主动放弃连续失败20次就打开熔断开关后续请求直接不调用外部接口、返回本地兜底数据。每过30秒放行一小部分请求试探一下如果外部服务恢复了再逐步关闭熔断。熔断的价值在于它让你的系统具备了“局部故障隔离”的能力不会因为一个下游服务的不稳定把整个系统拖下水。3.3 降级脑子里提前想好“什么功能可以不要”降级是很多团队最不愿意做也最不擅长做的事。因为降级往往意味着“牺牲一部分用户体验来保核心功能”需要业务方和开发团队提前对好口径哪些是核心功能必须保哪些是边缘功能可以砍。我举一个实际例子。一个电商App的首页非常复杂包含商品推荐、广告位、购物车角标、消息提醒、用户画像等十几个模块。平时这些模块都是实时拉取数据拼装返回。但在大促高峰期如果全量数据拉取导致响应很慢我就直接把非核心模块全部降级——广告位返回占位图消息提醒不展示购物车角标显示一个默认值。只有商品列表和下单接口走实时数据。结果是什么首页响应时间从2秒直接降到了300毫秒用户下单完全不受影响。你说广告位少展示了亏不亏当然亏。但比起页面白屏、用户流失、口碑崩坏这点损失完全是可以接受的。降级的核心是提前定义好优先级。我建议每个团队都做一张“功能降级清单”紧急情况下先降什么、再降什么、最后保什么。这张清单要在流量高峰期之前想好、写好、验证好而不是在服务器报警的那天晚上拍脑袋。3.4 隔离别让一个毒瘤拖垮全院这个教训来自一次实时数据处理项目的经历。当时多个业务方共享同一个大数据计算集群其中一个业务的数据量突然暴涨占满了整个集群的计算资源导致其他业务的任务全部排队等资源SLA完不成。我后来反思这就是典型的缺乏隔离。理想的架构应该做到物理或逻辑隔离——某个业务的数据再猛也只能消耗它自己被分配到的那个资源池不能挤占别人。隔离在流量稳定性的语境下同样很重要。我见过不少团队把所有服务都部署在一个大集群里没有做独立的资源池划分。结果呢A业务流量突发把B业务的容器资源全抢走了B业务无端被拖累。正确的做法是关键业务、高流量业务、低流量业务在部署层面就要做好资源隔离至少要配置独立的资源配额。在代码层面线程池隔离也是关键。不要把所有的外部调用都丢到同一个线程池里否则一个慢接口会耗尽整个线程池连累其他接口。按业务类型、按依赖方向拆分成多个独立线程池是基本的设计要求。4. 一次大促压测真实复盘从15分钟崩溃到扛住10倍流量上面的内容偏方法论下面我用一次真实的压测和大促复盘来串一遍你应该能更直观地感受到“提前想明白”到底意味着什么。这次项目是某零售品牌的线上大促主阵地是微信小程序预期流量是平时的8到10倍。4.1 第一轮压测系统15分钟就崩了我们按照预估峰值做了压测。结果非常惨烈压测开始15分钟系统整体崩溃。当时的表象是应用服务器CPU只有50%但接口成功率急剧下降到20%。查日志发现大部分请求超时。再往下查发现数据库连接池被占满大量线程阻塞在获取数据库连接上。根因是什么我们的应用配置了100个数据库连接但压测流量是平时的10倍每个请求持有的连接时间变长因为查询的数据量变大连接池里的100个连接很快就被全部占用后面的请求全部排队等待连接。线程池里的工作线程也在等连接越等越多最终线程池也满了新请求直接被拒绝。说白了就是数据库连接池配置太小没有跟着流量峰值做适配。4.2 逐一排查瓶颈每个环节都不能放过第一轮崩了之后我们没有急着加连接池而是把整个链路重新捋了一遍。我带着团队把压测过程中的各项指标拉出来逐项分析最后定位了四个问题第一个是数据库连接池过小这是崩溃的直接原因。第二个是数据库层面存在几个慢查询平时流量小看不出来流量一上来就放大成致命问题。第三个是Redis热key问题大促商品详情页的库存信息全部打在同一个Redis key上导致单节点CPU和带宽全部跑满。第四个是依赖的短信通知服务接口响应很慢拖慢了部分请求的响应时间。这四个问题单独看都很“小”但合在一起在大流量下就形成了压倒性的连锁反应。这也印证了我在前面说的系统是一个整体一个环节出问题会引发连锁雪崩。4.3 针对性优化参数代码架构三条线同时改针对定位到的问题我们做了如下调整这里不是说教就是我自己实操下来有效的手段把数据库连接池从100扩大到了300同时在下游数据库的白名单里同步放开了最大连接数限制。这里有个细节要注意连接池不是越大越好每开一个连接都有内存和操作系统层级的开销太大的连接池反而会导致数据库性能下降。我们是在压测中发现300是安全水位同时配合慢查询优化让单请求占用连接的时间变短。重写了两个慢查询。其中一个是把在SQL中使用LIKE进行模糊匹配的查询改成了走搜索引擎另一个是给关联查询涉及的表添加了联合索引。慢查询消灭之后单请求的平均数据库耗时从80ms降到了20ms。热点key拆分。把商品库存从原来一个key存整个商品的库存改成了一个key分散存储多个分片查询的时候按取模规则读取其中一个分片Redis的单节点压力直接降了70%。给短信通知接口增加了线程池隔离和熔断。就算短信服务再慢也只能影响它自己那个线程池里的任务不能再拖累主流程。改完之后我们重新做了一轮压测。这一次系统稳定跑完了全部测试且还有余量。等到真正大促那天实际峰值流量比预估还高了一点点但系统全程没有挂监控面板上最高水位也只到了安全水位的80%。4.4 复盘时的几个“如果”这里特别想分享一个复盘时的技巧每次大促结束我都会带着团队过一遍“如果清单”。如果当时我们没有做压测会怎么样大概率活动当天前15分钟系统就崩了而且是带着全链路一起崩用户口碑直接扑街。如果当时我们只在连接池上加大参数不优化慢查询会怎么样连接池从100加到300慢查询依然会占用大量连接崩溃只是从15分钟延迟到30分钟而已。如果当时我们没有做熔断短信服务在大促当天恰好抖动了呢那主流程一样会被拖垮。这一连串的“如果”让我意识到提前想明白的真正含义不是把某一个参数调到最优而是把系统里每一个“可能最先挂掉的环节”都提前预判、提前加固、提前写好兜底方案。5. 日常就能维护的“提前想明白”习惯压测、巡检与演练流量高峰期不是每天都有的但“提前想明白”这套思维应该融入日常的研发流程里。否则等大促来了才开始手忙脚乱很多早期问题早就埋在代码里了。5.1 每次大功能上线前至少做一轮“小规模压测”大促压测大多数团队都会做但日常把压测融入迭代流程的团队很少。我的建议是不一定每次发版都要全链路压测但是每个涉及核心链路的功能改动至少要做一个“小压测”。做法很简单在测试环境用脚本模拟平时峰值的1.5倍流量跑五分钟看一下接口响应时间有没有明显劣化数据库有没有慢查询新增内存有没有明显上涨。这不需要复杂的压测平台用JMeter或者Locust就能搞定。不要小看这一步。我见过太多故障都是“一个小改动上线几行代码看着没问题结果流量一大就出幺蛾子”。提前做小压测至少能把这种低级故障提前拦截。5.2 建立核心链路的“容量水位看板”如果你不想每次都在故障发生时才从监控里翻数据建议平时就把核心链路的容量水位整理成看板。我这边维护了一个简单的仪表盘上面实时展示各核心接口的当前QPS和峰值QPS每个应用实例的CPU、内存、线程池活跃度和队列长度数据库的QPS、活跃连接数、慢查询数Redis的内存占用和热点key访问量消息队列的积压数量。这套看板的价值在于它把系统真实的负载情况变得一目了然。流量缓步上涨的过程中你可以直观看到哪个指标最先异动并提前着手处理而不是等系统崩了之后才通过报警来触达。5.3 定期做“混沌演练”人为制造故障验证兜底逻辑很多团队的限流、熔断、降级代码写好了但从没真正验证过能不能在关键时刻生效。我见过最讽刺的案例是系统配置了熔断器但阈值得太大实际故障的时候根本没触发熔断还以为是熔断器不好用。后来我养成了一个习惯每次核心链路改动完都偷偷在预发环境做一次“故障演练”。比如直接停掉一个下游服务观察系统能不能快速降级、优雅响应或者把某个接口的响应时间人为调大看熔断器能不能按预期打开。这听起来有点“自虐”但确实能在真正的大促来临前发现一票掉链子的配置。另外说一个我自己的体会故障演练这件事不要只依赖测试团队去做开发工程师一定要亲自参与。因为只有亲手制造故障、亲眼观察系统反应你才会对系统的行为边界有真实的体感而不是停留在“代码写对了”的幻觉里。5.4 流量压力测试是一个持续迭代的过程不是一锤子买卖最后想强调一点容量能力和系统稳定性不是一次性工程。业务在增长代码在变化基础设施在升级你的系统容量水位也在不断变化。三个月前压测能扛到10000 QPS的系统三个月后因为模块重构、数据量增长可能只能扛到5000 QPS了。所以我一般建议每个季度至少做一次完整压测每次大版本迭代后做一次快速回归压测。把容量评估、压测、巡检、演练变成例行公事而不是等着“流量突然上来”再临时抱佛脚。回到开头那句话流量一上来就崩说到底是没提前想明白。想明白流量从哪来、瓶颈在哪、能扛多少、挂了怎么办、怎么验证这些问题都前置解决了流量洪峰也就不再是什么可怕的事情。老实说我就是靠着这套“想明白”的流程从当年那个熬夜救火的工程师变成了现在跑进机房可以先喝杯茶的“老油条”。
系统一遇高流量就崩？容量规划、限流熔断与降级实战指南
流量一上来就崩老实说是你没提前想明白做后端这几年我见过太多系统在流量洪峰面前瞬间“社会性死亡”。最典型的场景是业务方兴冲冲跑来说“我们要搞个大促/直播/活动预期流量翻五倍”结果活动刚开始十分钟监控面板一片飘红报警电话打爆数据库连接池被打穿接口超时率飙到90%用户疯狂刷“白屏了”“转圈了”。然后大家开始熬夜紧急扩容、重启、拆缓存……折腾到凌晨两三点流量高峰过去了系统“莫名其妙”又恢复了。你以为这是运气问题是硬件不够好是代码写得烂老实说都不是。根子在于你压根没在流量进来之前把几件事想明白你的系统到底能扛多少扛不住的时候先牺牲谁依赖的下游要是先挂了怎么办你有没有在代码层面提前埋好“保命开关”这篇文章我不想讲什么高深理论就结合我自己踩过的坑、做过的压测、复盘过的故障聊聊一个后端团队在流量这件事上必须提前想明白的东西。内容适合所有正在被“流量焦虑”折磨的开发者、架构师和技术负责人。1. 先别急着加机器先搞清楚“崩”到底崩在哪很多人一听到“系统扛不住”第一反应就是加服务器、加带宽、加数据库配置。但大多数情况下你加的机器根本没解决真正的问题。因为流量上来之后系统崩溃通常不是单一原因而是一条链路上某个环节最先被击穿然后引发连锁反应把整个系统拖下水。1.1 你以为的瓶颈往往不是真正的瓶颈我参与过很多次故障复盘发现一个共性规律大家最初怀疑的原因基本都跟根因对不上。举一个真实例子。某个业务做秒杀活动开始之后用户纷纷反馈页面打不开。运维同事第一反应是“带宽是不是满了”结果查了发现带宽只用了30%。然后怀疑Nginx连接数不够看了指标也还好。最后查后端应用发现CPU也不高内存也不紧张。绕了一大圈最终定位到数据库——主库的CPU打满了大量慢查询把数据库拖死然后所有依赖数据库的接口全部阻塞连接池耗尽应用线程全部卡在等数据库响应上表现为应用“假死”、接口超时。这个案例说明什么说明系统的瓶颈点可能藏在调用链路的任何一个环节。如果你连自己的系统哪个组件最先会扛不住都没搞清楚加再多机器也只是把钱扔进水里。我的经验是在谈容量之前先花时间回答以下几个问题当前系统的调用链路是什么样从用户请求到最终响应经过了哪些服务、哪些存储、哪些外部依赖每个环节的负载上限是多少不是“理论上能扛多少”而是“实测压到多少开始劣化”各个环节之间的依赖关系如何是同步调用还是异步解耦是强依赖还是可以降级瓶颈点是单个还是多个会不会同时被打穿如果这些问题你需要在故障发生后才开始排查那说明你之前确实没有“提前想明白”。1.2 容量崩溃这件事本质是个排队论问题说到这我想引入一个形象的类比。很多刚入行的同学会把系统性能理解成“一条水管能流多少水”以为只要水管够粗流量再大也没问题。但现实中的系统更像一个复杂的“交通网络”不是简单的一条管道而是由多个路口、多个收费站、多个服务区组成的系统。举一个最简单的模型假设你的应用每秒能处理1000个请求数据库每秒只能处理500个请求那么当流量达到800 QPS时应用扛得住但数据库已经超负荷了请求开始排队。排队越长响应越慢响应越慢用户就越着急重试重试越多请求量就越大请求量越大排队就更严重——这就是典型的“雪崩效应”。更可怕的是这个排队不只是发生在数据库层还可能发生在应用线程池、连接池、消息队列、第三方接口调用等每一个环节。每个环节都有它的“服务速率”和“排队容量”只要有一个环节的服务速率小于请求到达速率整个链路就会被拖垮。所以说处理流量问题的第一课不是“优化代码”而是“建立系统思维”——你需要把整个调用链路上每一环的承载力都盘点清楚找出那个“最先见底”的环节。这个环节才是你真正需要投入资源去加强的地方。2. 容量评估的核心不是拍脑袋是建立流量-资源换算模型搞清楚了“崩在哪”之后接下来要考虑的就是“到底能扛多少”。这件事很多团队做得非常随意通常是“感觉应该没问题吧”“去年也就这个量”“服务器是8核的应该够吧”。老实说这就是典型的拍脑袋。容量评估必须建立在一个可计算的模型之上。这个模型要回答一个问题给定一个预估流量我需要多少实例、多少内存、多少数据库连接才能稳定扛住。2.1 先把流量估清楚峰值 QPS 到底是多少做容量规划的第一步是把你预判的流量峰值转成一个具体的数字每秒多少个请求。我在做业务方的技术方案时通常会让他们回答几个问题活动预计多少用户参与是10万还是100万用户主要在什么时间段内涌入是全天均匀分布还是集中在某一个小时一个用户从进入活动到结束平均会产生多少次请求这些请求是按什么比例分布到各个接口的比如浏览、下单、支付各占多少有了这些信息就可以做一个简单的估算。假设预计100万用户参与活动持续4小时高峰期集中在第一个小时那第一个小时内大概有60%的用户也就是60万用户涌入。如果每个用户在这一个小时内平均会触发20次请求那这一个小时内总请求量大约是1200万次平均QPS大约是3333。考虑到流量不会完美均匀分布通常会按2到3倍的峰值系数来预留也就是说你至少要按每秒7000到10000的QPS来做容量规划。这套估算逻辑虽然粗糙但比拍脑袋靠谱得多。它给你一个可验证的基数后面压测也是基于这个数字去设计和评判的。2.2 用压测找出“单机承载力”再反推实例数流量估出来了接下来就要知道“一台机器能扛多少”。这个数据不能靠猜只能靠压测。我常用的做法是这样的找一台配置和线上一致的测试机部署好完整的应用把依赖中间件全部切到压测环境然后逐步加压记录不同QPS下的响应时间和资源消耗曲线。重点关注三个数据点正常运行水位响应时间在100毫秒以内CPU在40%左右的QPS值容忍水位响应时间在200到300毫秒左右CPU在70%到80%的QPS值崩溃水位响应时间开始指数级上升错误率飙升的QPS值。一台机器的“安全水位”我一般取正常运行水位而不是最大水位。因为你要给突发流量、GC抖动、网络抖动留出冗余。有了单机安全水位实例数就好算了。假设你预估峰值是10000 QPS单机安全水位是500 QPS那你至少需要20台实例。注意这是“至少”还要考虑可用性比如你在云上挂了20台如果有一台宕机剩余19台要扛住全部流量那么每台需要扛到526 QPS已经略微超载了。所以实际部署时我通常会在理论值基础上再加20%到30%的冗余。2.3 别忘了“外部依赖”的容量这才是最容易爆的雷容量规划里最容易漏掉的一块你以为算了自己系统的容量就够了但你的系统还依赖数据库、Redis、消息队列、第三方接口……这些外部组件同样有容量上限。我见过太多系统应用层扩容做得漂漂亮亮结果活动一开始数据库连接数被打满直接成为全局瓶颈。原因很简单应用加了20台机器每台机器的连接池配了30个连接总连接数就是600个数据库的连接数上限可能也就300多个直接翻倍打爆了。所以做容量评估的时候一定要把每个关键依赖的容量一起评估进去数据库当前连接数水位是多少最大连接数是多少如果QPS翻倍新增的连接需求有多少慢查询会不会把CPU打满Redis内存占用率多少操作耗时多少如果大流量来了热点key会不会导致单节点过热消息队列堆积水位如何消费速度能不能跟上生产速度外部HTTP接口你依赖的第三方接口它的限流阈值是多少你给它的调用量预估是多少这些数据都应该在活动前整理成一张容量清单逐项核对。任何一个环节被击穿整个链路的稳定性都无从谈起。3. 限流、熔断、降级与隔离写在代码里的“提前想明白”如果说容量规划是“数学题”那架构层面的保护机制就是“保险杠”。流量永远有不确定性你以为算了峰值实际来了个超预期十倍的大爆发怎么办这时候就得靠提前写好代码里的“保命开关”。3.1 限流不是“拒绝用户”是“保命”很多人对限流有误解觉得限流就是拒绝用户、影响体验所以在系统快崩的时候还死扛着不受限。事实上适度的限流恰恰是为了让更多用户体验到“正常服务”。我通常这样和业务方解释如果系统容量只能支撑1000 QPS流量突然飙到5000 QPS你不限流的结果是什么是5000个请求全部超时、全部失败用户一个也进不去白屏刷屏。如果你做了限流把入口流量控制在1200 QPS那么有1200个用户能流畅使用剩下的3800个用户会被提示“当前排队人数过多请稍后再试”——至少这1200个用户是满意的而且系统不崩过一会儿流量降下来所有人都能继续用。限流的位置很重要。我建议在网关层做一层全局限流在应用层再做一层接口级别的细粒度限流。网关层解决的是“整体入口防爆”接口层解决的是“单点接口被刷”。具体实现上常用的算法有令牌桶和滑动窗口我个人偏爱令牌桶因为它允许一定的突发流量比较贴合真实用户行为。很多现成的组件都内置了限流能力比如Sentinel、Hystrix也有网关自带的限流插件不用重复造轮子。3.2 熔断别让你的系统给“病号下游”陪葬熔断这个念头我是吃过大亏之后才彻底想明白的。有一年我们某个活动依赖了外部的一个营销服务接口。活动开始后外部服务响应突然变慢从原来的50毫秒一路劣化到5秒。我们的应用是同步调用线程全部阻塞在等待响应上线程池很快被耗尽新的请求进不来整个应用陷入假死。最要命的是一台台机器陆续倒下形成“应用崩-健康检查失败-被摘除-流量转移给其他机器-其他机器也崩”的死亡螺旋。复盘的时候我发现代码里根本没有熔断逻辑对第三方接口的调用没有任何超时降级保护。我当时的感受就是你把系统挂在别人的木马上别人一倒你也跟着倒。正确的做法是所有依赖外部系统的调用都必须设置超时时间和熔断阈值。比如调用第三方接口超过500毫秒就主动放弃连续失败20次就打开熔断开关后续请求直接不调用外部接口、返回本地兜底数据。每过30秒放行一小部分请求试探一下如果外部服务恢复了再逐步关闭熔断。熔断的价值在于它让你的系统具备了“局部故障隔离”的能力不会因为一个下游服务的不稳定把整个系统拖下水。3.3 降级脑子里提前想好“什么功能可以不要”降级是很多团队最不愿意做也最不擅长做的事。因为降级往往意味着“牺牲一部分用户体验来保核心功能”需要业务方和开发团队提前对好口径哪些是核心功能必须保哪些是边缘功能可以砍。我举一个实际例子。一个电商App的首页非常复杂包含商品推荐、广告位、购物车角标、消息提醒、用户画像等十几个模块。平时这些模块都是实时拉取数据拼装返回。但在大促高峰期如果全量数据拉取导致响应很慢我就直接把非核心模块全部降级——广告位返回占位图消息提醒不展示购物车角标显示一个默认值。只有商品列表和下单接口走实时数据。结果是什么首页响应时间从2秒直接降到了300毫秒用户下单完全不受影响。你说广告位少展示了亏不亏当然亏。但比起页面白屏、用户流失、口碑崩坏这点损失完全是可以接受的。降级的核心是提前定义好优先级。我建议每个团队都做一张“功能降级清单”紧急情况下先降什么、再降什么、最后保什么。这张清单要在流量高峰期之前想好、写好、验证好而不是在服务器报警的那天晚上拍脑袋。3.4 隔离别让一个毒瘤拖垮全院这个教训来自一次实时数据处理项目的经历。当时多个业务方共享同一个大数据计算集群其中一个业务的数据量突然暴涨占满了整个集群的计算资源导致其他业务的任务全部排队等资源SLA完不成。我后来反思这就是典型的缺乏隔离。理想的架构应该做到物理或逻辑隔离——某个业务的数据再猛也只能消耗它自己被分配到的那个资源池不能挤占别人。隔离在流量稳定性的语境下同样很重要。我见过不少团队把所有服务都部署在一个大集群里没有做独立的资源池划分。结果呢A业务流量突发把B业务的容器资源全抢走了B业务无端被拖累。正确的做法是关键业务、高流量业务、低流量业务在部署层面就要做好资源隔离至少要配置独立的资源配额。在代码层面线程池隔离也是关键。不要把所有的外部调用都丢到同一个线程池里否则一个慢接口会耗尽整个线程池连累其他接口。按业务类型、按依赖方向拆分成多个独立线程池是基本的设计要求。4. 一次大促压测真实复盘从15分钟崩溃到扛住10倍流量上面的内容偏方法论下面我用一次真实的压测和大促复盘来串一遍你应该能更直观地感受到“提前想明白”到底意味着什么。这次项目是某零售品牌的线上大促主阵地是微信小程序预期流量是平时的8到10倍。4.1 第一轮压测系统15分钟就崩了我们按照预估峰值做了压测。结果非常惨烈压测开始15分钟系统整体崩溃。当时的表象是应用服务器CPU只有50%但接口成功率急剧下降到20%。查日志发现大部分请求超时。再往下查发现数据库连接池被占满大量线程阻塞在获取数据库连接上。根因是什么我们的应用配置了100个数据库连接但压测流量是平时的10倍每个请求持有的连接时间变长因为查询的数据量变大连接池里的100个连接很快就被全部占用后面的请求全部排队等待连接。线程池里的工作线程也在等连接越等越多最终线程池也满了新请求直接被拒绝。说白了就是数据库连接池配置太小没有跟着流量峰值做适配。4.2 逐一排查瓶颈每个环节都不能放过第一轮崩了之后我们没有急着加连接池而是把整个链路重新捋了一遍。我带着团队把压测过程中的各项指标拉出来逐项分析最后定位了四个问题第一个是数据库连接池过小这是崩溃的直接原因。第二个是数据库层面存在几个慢查询平时流量小看不出来流量一上来就放大成致命问题。第三个是Redis热key问题大促商品详情页的库存信息全部打在同一个Redis key上导致单节点CPU和带宽全部跑满。第四个是依赖的短信通知服务接口响应很慢拖慢了部分请求的响应时间。这四个问题单独看都很“小”但合在一起在大流量下就形成了压倒性的连锁反应。这也印证了我在前面说的系统是一个整体一个环节出问题会引发连锁雪崩。4.3 针对性优化参数代码架构三条线同时改针对定位到的问题我们做了如下调整这里不是说教就是我自己实操下来有效的手段把数据库连接池从100扩大到了300同时在下游数据库的白名单里同步放开了最大连接数限制。这里有个细节要注意连接池不是越大越好每开一个连接都有内存和操作系统层级的开销太大的连接池反而会导致数据库性能下降。我们是在压测中发现300是安全水位同时配合慢查询优化让单请求占用连接的时间变短。重写了两个慢查询。其中一个是把在SQL中使用LIKE进行模糊匹配的查询改成了走搜索引擎另一个是给关联查询涉及的表添加了联合索引。慢查询消灭之后单请求的平均数据库耗时从80ms降到了20ms。热点key拆分。把商品库存从原来一个key存整个商品的库存改成了一个key分散存储多个分片查询的时候按取模规则读取其中一个分片Redis的单节点压力直接降了70%。给短信通知接口增加了线程池隔离和熔断。就算短信服务再慢也只能影响它自己那个线程池里的任务不能再拖累主流程。改完之后我们重新做了一轮压测。这一次系统稳定跑完了全部测试且还有余量。等到真正大促那天实际峰值流量比预估还高了一点点但系统全程没有挂监控面板上最高水位也只到了安全水位的80%。4.4 复盘时的几个“如果”这里特别想分享一个复盘时的技巧每次大促结束我都会带着团队过一遍“如果清单”。如果当时我们没有做压测会怎么样大概率活动当天前15分钟系统就崩了而且是带着全链路一起崩用户口碑直接扑街。如果当时我们只在连接池上加大参数不优化慢查询会怎么样连接池从100加到300慢查询依然会占用大量连接崩溃只是从15分钟延迟到30分钟而已。如果当时我们没有做熔断短信服务在大促当天恰好抖动了呢那主流程一样会被拖垮。这一连串的“如果”让我意识到提前想明白的真正含义不是把某一个参数调到最优而是把系统里每一个“可能最先挂掉的环节”都提前预判、提前加固、提前写好兜底方案。5. 日常就能维护的“提前想明白”习惯压测、巡检与演练流量高峰期不是每天都有的但“提前想明白”这套思维应该融入日常的研发流程里。否则等大促来了才开始手忙脚乱很多早期问题早就埋在代码里了。5.1 每次大功能上线前至少做一轮“小规模压测”大促压测大多数团队都会做但日常把压测融入迭代流程的团队很少。我的建议是不一定每次发版都要全链路压测但是每个涉及核心链路的功能改动至少要做一个“小压测”。做法很简单在测试环境用脚本模拟平时峰值的1.5倍流量跑五分钟看一下接口响应时间有没有明显劣化数据库有没有慢查询新增内存有没有明显上涨。这不需要复杂的压测平台用JMeter或者Locust就能搞定。不要小看这一步。我见过太多故障都是“一个小改动上线几行代码看着没问题结果流量一大就出幺蛾子”。提前做小压测至少能把这种低级故障提前拦截。5.2 建立核心链路的“容量水位看板”如果你不想每次都在故障发生时才从监控里翻数据建议平时就把核心链路的容量水位整理成看板。我这边维护了一个简单的仪表盘上面实时展示各核心接口的当前QPS和峰值QPS每个应用实例的CPU、内存、线程池活跃度和队列长度数据库的QPS、活跃连接数、慢查询数Redis的内存占用和热点key访问量消息队列的积压数量。这套看板的价值在于它把系统真实的负载情况变得一目了然。流量缓步上涨的过程中你可以直观看到哪个指标最先异动并提前着手处理而不是等系统崩了之后才通过报警来触达。5.3 定期做“混沌演练”人为制造故障验证兜底逻辑很多团队的限流、熔断、降级代码写好了但从没真正验证过能不能在关键时刻生效。我见过最讽刺的案例是系统配置了熔断器但阈值得太大实际故障的时候根本没触发熔断还以为是熔断器不好用。后来我养成了一个习惯每次核心链路改动完都偷偷在预发环境做一次“故障演练”。比如直接停掉一个下游服务观察系统能不能快速降级、优雅响应或者把某个接口的响应时间人为调大看熔断器能不能按预期打开。这听起来有点“自虐”但确实能在真正的大促来临前发现一票掉链子的配置。另外说一个我自己的体会故障演练这件事不要只依赖测试团队去做开发工程师一定要亲自参与。因为只有亲手制造故障、亲眼观察系统反应你才会对系统的行为边界有真实的体感而不是停留在“代码写对了”的幻觉里。5.4 流量压力测试是一个持续迭代的过程不是一锤子买卖最后想强调一点容量能力和系统稳定性不是一次性工程。业务在增长代码在变化基础设施在升级你的系统容量水位也在不断变化。三个月前压测能扛到10000 QPS的系统三个月后因为模块重构、数据量增长可能只能扛到5000 QPS了。所以我一般建议每个季度至少做一次完整压测每次大版本迭代后做一次快速回归压测。把容量评估、压测、巡检、演练变成例行公事而不是等着“流量突然上来”再临时抱佛脚。回到开头那句话流量一上来就崩说到底是没提前想明白。想明白流量从哪来、瓶颈在哪、能扛多少、挂了怎么办、怎么验证这些问题都前置解决了流量洪峰也就不再是什么可怕的事情。老实说我就是靠着这套“想明白”的流程从当年那个熬夜救火的工程师变成了现在跑进机房可以先喝杯茶的“老油条”。
