三年架构设计：从0到10亿的高可用技术底座

文章配图，仅供参考

　　记得第一次灰度上线，后端小李拍着胸脯说“绝对扛得住”，结果凌晨三点手机炸了——新注册用户埋点全丢。我原以为缓存策略写错了，结果爬起来一看日志，好家伙，他为了省内存把用户行为数据存Redis的String类型里，每个字段用竖线分隔。我说你这跟把面条塞进保温杯有什么区别？他挠头说“我以为Redis快啊”——快是快，可你存十万条数据，每次取都得split()，CPU直接飚到90%，不丢才怪。后来改用Hash，虽然占用多了点，但至少数据能完整落盘了。

　　机箱风扇一直在转，嗡嗡的。我往嘴里塞了口凉透的煎饼果子，继续翻监控。这时候前端小张凑过来：“哥，你看这回流重绘是不是有点狠？”他手机里是测试机上的页面，滑动时文字会突然跳一下——典型的layout thrashing。我瞅了眼他的Chrome标签页，三十来个没关，内存占用快8G了。“你先把其他标签关了试试”，他哦了一声，切回去操作，页面突然白屏——构建进度条卡在百分之八十七。我叹气：“你这本地环境都崩了，还测个屁的真机？”他挠头：“我以为是网络问题……”

　　其实最头疼的不是技术细节，是产品经理改需求。去年双十一前两周，突然说要加个“拼团倒计时”组件，要求实时更新且不能影响主流程性能。我原以为直接用WebSocket推数据就行，结果测试说部分安卓机型会白屏——查了半天发现是旧版WebView对WebSocket的兼容性问题。最后没办法，降级成轮询，每3秒发一次请求，虽然多了点流量，但至少所有机型都能显示了。后来产品又说“倒计时要精确到毫秒”，我直接拍桌子：“你要毫秒可以，但用户手机时间不准怎么办？服务器时间下发又会有延迟，到时候用户看到的时间跳来跳去，你负责？”他沉默了两秒，说“那还是秒吧”。

　　水杯底结了一圈渍，我拿纸巾擦了擦，继续说：“高可用这事儿，说白了就是‘能扛的留下，不能扛的滚蛋’。比如我们一开始用单体架构，所有服务堆在一个进程里，后来流量上来，一个接口卡死，整个服务都挂。后来拆成微服务，每个服务独立部署，虽然运维复杂了点，但至少一个服务崩了不影响其他。再比如缓存策略，一开始用本地缓存，结果多台机器数据不一致；改用分布式缓存，又遇到缓存穿透，被恶意请求打穿；最后上了布隆过滤器，才算稳住。每一步都是被流量逼着改的，哪有什么‘完美方案’？”

　　外卖塑料袋响个不停，隔壁工位的前端小妹在拆奶茶。她突然说：“哥，你说我们现在的架构，能扛住十亿吗？”我笑了：“十亿不是目标，是结果。你现在问我能不能扛住，我肯定说‘应该行’，但真到那天，肯定还有新问题。比如现在我们的数据库分片策略是按用户ID哈希，但如果用户量暴增，单片数据量太大，还是得继续拆；再比如现在所有服务都部署在同一个云厂商，万一人家机房出问题，我们得有跨云容灾的方案……这些都得提前想，但不用急着做，等流量真的往那个方向冲了，再改也来得及。”

　　桌上的数据线缠成一团，我扒拉了两下没解开，索性不管了。突然想起去年双十一当天，监控大屏上的QPS曲线像坐火箭一样往上窜，我们几个人盯着屏幕，手心全是汗。当曲线终于平稳在每秒百万级时，后端小李突然喊：“哥，你看这GC停顿时间！”我凑过去一看，好家伙，原本每次GC停顿200ms，现在降到50ms了——原来是他偷偷优化了内存分配策略。我说：“你小子藏得够深啊，怎么不早说？”他挠头：“我怕优化错了，先在测试环境跑了两天，确认没问题才敢上生产。”

　　所以你说高可用技术底座是怎么来的？不是靠提前规划个三年五年的“完美架构”，而是靠每天被流量暴打，被bug折磨，被产品改需求逼疯，然后一边骂娘一边改代码，把能扛的方案留下，扛不住的扔掉。就像自然选择一样，活下来的，就是最适合当前流量的。至于未来？等流量真的冲到十亿了，我们自然会找到新的“优胜劣汰”方案——但现在，先把眼前的坑填好再说。

　　对了，上周测试又报了个bug，说部分用户登录后页面白屏。我查了半天发现是静态资源CDN缓存没刷，导致新版本JS没加载。小张说：“哥，要不我们加个版本号？”我白了他一眼：“版本号早加了，是CDN的缓存策略有问题——他们默认缓存24小时，我们发布频率太高，根本等不及。”后来我们改用哈希命名文件，每次发布自动生成新文件名，CDN没得缓存，问题才算解决。你看，连这种小细节都得被流量逼着优化，哪有什么“一劳永逸”的高可用？

　　机箱风扇还在转，我摸了摸，有点烫手。算了，先不管了，等这波大促过了再说——反正到时候肯定又有新问题要改。

（编辑：站长网）

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