知识卡片
手机QQ按用户规模倒逼架构升级:从渐进重构到亿级推倒重来
内容
手机QQ的后台架构演进按在线用户规模可以粗分为十万级、百万级、千万级、亿级四个阶段,其共同模式是”用户规模先涨上去,暴露出具体的容量/性能瓶颈,再倒逼架构升级”——从十万级到千万级的三次升级,问题性质相似,都是可以量化定位的资源瓶颈(如百万级阶段单台接入服务器内存只能支撑百万在线用户、千万级阶段单台状态同步服务器和单台接入服务器都存不下所有在线用户信息),对应的解法也都是渐进式的架构改造,属于[[演化原则:软件架构的主题是变化而非建筑式的永恒]]里”迭代、扩展、重构”这个层次的演化。真正值得注意的转折出现在亿级阶段:这一次暴露出的不再是单纯的资源瓶颈,而是架构本身的灵活性彻底跟不上业务需求(例如仅仅把昵称长度增加一半就需要两个月开发周期,加一个”故乡”字段需要两个月,好友数上限从500改到1000需要三个月),并且已经支撑不了一些关键新功能(好友数上万、隐私权限控制、多端互踢限制、跨产品互通、异地容灾)。更关键的是,此时”持续在原有基础上打补丁”这条路本身已经走到尽头——不是新一轮局部优化能解决的问题,而是必须从头重新设计整个系统,最终形成的IM 4.0架构把整体拆分为存储架构和通信架构两大模块。这个案例把演化原则里容易被忽略的一层含义具体化了:演化不总是意味着渐进式的小步快跑,当积累的问题已经从”资源不够”质变为”架构本身的结构性缺陷”时,演化路径本身也会跳变为一次彻底的重写,而识别”该小改还是该重写”这个转折点,正是架构师面对不确定性时最难、也最重要的判断之一。
参考来源
- 位置:《从零开始学架构》第09讲《架构设计原则案例》"手机QQ"(源文件:_epub-src/OEBPS/text00000.html,内容摘自《QQ 1.4 亿在线背后的故事》)
- 结论依据:原文说明"基本上都是用户规模先上去,然后产生各种问题,倒逼技术架构升级",并在亿级阶段列出灵活性差与关键功能无法支撑的具体表现后指出"IM 后台从 1.0 到 3.5 都是在原来基础上做改造升级的,但是持续打补丁已经难以支撑亿级在线,IM 后台 4.0 必须从头开始,重新设计实现",直接支撑本卡片结论。
- 原始内容:不同的用户规模,IM 后台的架构也不同,而且基本上都是用户规模先上去,然后产生各种问题,倒逼技术架构升级……灵活性很差,比如"昵称"长度增加一半,需要两个月……IM 后台从 1.0 到 3.5 都是在原来基础上做改造升级的,但是持续打补丁已经难以支撑亿级在线,IM 后台 4.0 必须从头开始,重新设计实现!