三年架构设计：从0到10亿的弹性成长之路

　　"三年从0到10亿？扯淡。"去年九月老张在茶水间摔杯子时，显示器右下角的时间显示14:27，他刚看完某云厂商的架构白皮书，"这帮人连QPS和TPS都分不清，就敢写'无限弹性'？"我原以为他只是吐槽PPT架构师，结果两周后自己被甲方按在会议室骂了三个小时——他们照着那套"完美方案"压测，数据库连接池直接爆成烟花，冷风机的嗡嗡声里，我盯着监控屏上那条笔直向上的曲线，突然明白老张为什么摔杯子。

　　优胜劣汰这事儿，在架构里比在自然界狠多了。记得第一次扩容到百万级时，运维小王在工位上接了个电话，是他妈催他回家相亲。他"嗯嗯"应着，手指在键盘上敲得飞起，突然一拍桌子："艹！负载均衡策略写反了！"那天我们连夜回滚，桌上的外卖凉了又热，热了又凉，最后小王一边啃冷掉的炒饭一边改配置——后来那套动态权重算法，成了我们对外吹牛的资本，但没人提那天他相亲黄了的事。

　　跟人吵架最烦的是"应该"。去年跟某开源社区的大神撕逼，他说我们的分库分表方案"违背了CAP原则"，我直接把压测报告甩他脸上："你倒是说说，P分区的网络延迟超过300ms时，我们靠本地缓存扛住的99.9%请求，算哪门子违背？"他愣了半天，憋出一句"理论上..."——理论个屁，构建卡在87%那次，我们硬是靠手动调参数把服务顶起来，等修复完代码，天都亮了。显示器右下角的时间跳到05:17，窗外的雨还在下，我盯着屏幕上的"SUCCESS"字样，突然觉得"弹性"这词儿特虚——哪有什么天生弹性，都是被故障逼出来的条件反射。

　　说回那套"从0到10亿"的方案。甲方最初要的是"一键扩容"，我们给做了自动伸缩组，结果第一次大促，ASG的冷却时间没调好，新实例还没启动完，旧实例就被销毁了，流量像潮水一样拍在404页面上。那天我在机房待到凌晨三点，听着冷风机"嗡嗡"的声音，突然想起老张摔杯子时说的话："所有'无限弹性'的宣传，都是因为没遇到过真正的尖峰。"后来我们改了策略——不是不要自动，而是给每个自动操作加了人工确认的钩子，甲方骂我们"不够极客"，可大促再也没出过幺蛾子。

　　同事老李总说我是"保守派"。上次他非要上某新潮的Serverless架构，我拦着没让，结果压测时函数冷启动延迟飙到2秒，他盯着监控屏，手指在桌面上敲得像在弹钢琴："这不可能啊，官方文档说..."我指了指窗外："官方文档没写雨天网络波动会放大冷启动问题。"他愣住，我接着说："去年九月那次故障，就是因为云厂商的某个区域下雨，光纤受潮，我们靠多活架构硬扛，要是用了Serverless，现在早被甲方骂死了。"他没说话，低头改方案去了——后来那套多活架构，成了我们拿下一个千万级项目的关键。

文章配图，仅供参考

　　回到"优胜劣汰"。这三年我们淘汰过多少方案？分库分表从哈希取模换成范围分片，缓存从Redis换到自研的KV，消息队列从RabbitMQ换成Kafka又换回Pulsar——每次换都是被故障逼的。记得换Pulsar那次，运维小王在群里发了个"终于不用再处理RabbitMQ的消息堆积了"的表情包，结果第二天就被打脸——Pulsar的消费者组配置错了，消息积压了整整两个小时。那天我们全员加班，他一边改配置一边嘟囔："这破玩意儿怎么比RabbitMQ还难搞？"我笑："难搞才说明它活下来了，容易搞的早被淘汰了。"

　　现在看那套"从0到10亿"的方案，最站得住脚的不是技术多先进，而是我们给每个"弹性"设计都留了退路。自动伸缩组有手动确认，分库分表有降级开关，多活架构有流量切换按钮——这些"不智能"的设计，才是我们活下来的原因。老张现在不摔杯子了，他最近在研究混沌工程，说要把故障注入做成常态化测试。我问他："要是测出大问题怎么办？"他笑："那就改啊，架构本来就是改出来的，哪有一开始就完美的？"

　　说到底，弹性不是设计出来的，是打出来的。下次再有人跟你吹"三年从0到10亿"，你就问他："你们方案里有多少个'手动确认'按钮？"他要是答不上来，这方案多半是PPT上的——就像去年九月老张摔的那杯子，摔的是对"完美架构"的幻想，捡起来的，是对真实故障的敬畏。

　　至于我们现在的架构？还在改。上周刚把Pulsar换成自研的消息系统，小王说新系统性能提升了30%，但我说不准下次大促会不会出幺蛾子——毕竟，真正的弹性，从来不是靠吹出来的，是靠故障喂出来的。下次再遇到尖峰，我希望显示器右下角的时间别跳得太快，窗外的雨别下得太大，而我们的架构，能像去年九月那样，再扛住一次"不可能"的流量。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!