流量一涨再扩就来不及，弹性伸缩得提前留出余量
流量一涨就加机器，听着直白，难的是加多快、加几台、什么时候收。加得慢，涨上来那段已经把人卡住了；收得急，刚缓下去又来一波，来回抖比不扩还伤。一、指标选哪个
拿什么判断该扩，要看这套活真正被什么卡住。算得重的看处理器占用，等下游的看排队长度，只盯一个通用数值，常在该动的时候没动，不该动的时候猛加。审批时要求附上依赖里扛得少的那一环能接多少，光写自己这边要扩到几台，看的人没法判断这波加上去会不会把库那边先压住。
指标要平滑一小段再看，单点尖刺别当信号。一次偶发的抖动就拉起一批实例，等它们真能接活，尖刺早过去了，白忙一轮还把后面的判断带偏。发版窗口避开每天那两段涨量，改完的阈值得在真实起伏里跑过才算数，挑个平的时候上线，看着一切正常，等高峰来了才知道触发点早不合适了。
二、扩得快缩得慢
加的时候步子大些，宁可多留一点余量；收的时候一格一格往下试，试完看一阵再决定下一格。这个不对称是拿教训换来的，对称了就容易在谷底来回摆。月度盘点数一数触发过几次回退到保底的情况，次数多说明低谷估得偏了，调保底比反复调扩容步子更省事，也更贴实际。
每格之间留个安静时间，时间没到不连着动作。连着动作的时候，前一批还没热起来，后一批的判断依据已经是旧状态，两批叠上去，实际数量早超出需要。成本上把多留的那点余量折成每月数字，和卡住一次请求带来的损失放一起看，余量该留多少就不是拍出来的，两边都有数才好定。
三、保底别归零
再省也留一份底，别让实例数掉到空。掉到空之后头一笔请求得等环境现起，那一等恰好落在没人值班的时段，等问题被发现，前面已经丢了一批。和上游对预期时说清超出并发之后会怎么回应，是排队还是友好退回，对方早知道，就能在自己的页面上把等待讲明白，不至于把慢都算到这边头上。
保底数按低谷里真实还会来的量定，不按拍脑袋的整数。定高了常年白养，定低了等于没留，隔几天看一次曲线，慢慢调到贴着走就行。值班面板上把伸缩动作和错误率画在同一条时间线上，动作之后指标有没有回来一眼可见，没回来就别继续加，加了也只是把账单往上抬。
四、并发要限
扩得再快也有个顶，顶上加一道并发限制，超出的请求排队或者友好地退回去。没有这道限，瞬间涌进来的量会把下游一起拖住，扩出来的机器也只能干等。排期里给日志集中收那一步留足时间，它不产生新功能，却决定往后查一次问题要开几个页面，省下这半天，后面往往要还上好几倍。
限制按依赖里扛得少的那一环定，不是按自己能扛多少定。自己扛得住，库那边早撑不住了，这时候多扩几台只是把压力换个地方堆着。复盘时把每回白动的伸缩挑出来看，是尖刺误判还是阈值旧了，归成几类之后调起来有准头，比笼统说一句策略不太稳有用得多。
五、观察窗口
伸缩动作之后留一段观察窗口，看错误率和耗时有没有跟着回来。没回来说明卡的不在算力上，继续加机器只是把账单往上抬，问题还在原处。
窗口里把动作和指标记在同一条时间线上，事后好复盘哪次判断准、哪次是白动。记久了能看出这套阈值是不是还贴合眼下的流量形状。新人演练先让他造一波受控的涨量，看它怎么加、怎么收，再让他自己把量收回去，走完整一轮，比读几页参数说明更记得住节奏的重要。
六、演练一次
挑个低峰时段造一波受控的涨量，看它是不是真按设想加、按设想收。没演练过的策略，纸面上再漂亮也不知道触发时会不会卡在某个权限或者配额上。
演练连着回退一起走，造完能干净地收回原状。收不回来就说明还差一步，这一步在演练里发现，比在真涨量那天发现便宜太多。归档把每次阈值调整当时的流量曲线存一份，日后有人问为什么定在这个数，翻出来就有依据，不用把当时那几个人拉回来凭印象解释。
弹性伸缩拼的是节奏不是数量，快慢之间那段空隙才是真功夫。指标、快慢、保底、并发、观察、演练，六处调顺，涨量来了才接得住；只把数字调大，抖起来一样难受。 认真看完了整篇内容，感觉受益匪浅，期待楼主后续更多优质的分享。 很多建议都很接地气，能直接用在生活或工作中，实用性很强。
页:
[1]