在《从 0 开始学架构》专栏的第 8 期，我介绍了架构设计的三条核心原则：合适原则、简单原则和演化原则。我们在架构设计实践中，应该时刻谨记这三条设计原则，指导我们设计出合适的架构。即使是代表中国互联网技术最顶尖水平的 BAT，其架构的发展历程也同样遵循这三条原则。今天我就以大家耳熟能详的手机 QQ 作为案例，来简单分析一下。
注：以下内容部分摘自《QQ 1.4 亿在线背后的故事》。
手机 QQ 的发展历程按照用户规模可以粗略划分为 4 个阶段：十万级、百万级、千万级、亿级，不同的用户规模，IM 后台的架构也不同，而且基本上都是用户规模先上去，然后产生各种问题，倒逼技术架构升级。
1. 十万级 IM 1.X
最开始的手机 QQ 后台是这样的，可以说是简单得不能再简单、普通得不能再普通的一个架构了，因为当时业务刚开始，架构设计遵循的是“合适原则”和“简单原则”。
2. 百万级 IM 2.X
随着业务发展到 2001 年，QQ 同时在线人数也突破了一百万。第一代架构很简单，明显不可能支撑百万级的用户规模，主要的问题有：
以接入服务器的内存为例，单个在线用户的存储量约为 2KB，索引和在线状态为 50 字节，好友表 400 个好友 × 5 字节 / 好友 = 2000 字节，大致来说，2GB 内存只能支持一百万在线用户。
CPU/ 网卡包量和流量 / 交换机流量等瓶颈。
单台服务器支撑不下所有在线用户 / 注册用户。
于是针对这些问题做架构改造，按照“演化原则”的指导进行了重构，重构的方案相比现在来说也还是简单得多，因此当时做架构设计时也遵循了“合适原则”和“简单原则”。IM 2.X 的最终架构如图所示。
3. 千万级 IM 3.X
业务发展到 2005 年，QQ 同时在线人数突破了一千万。第二代架构支撑百万级用户是没问题的，但支撑千万级用户又会产生新问题，表现有：
同步流量太大，状态同步服务器遇到单机瓶颈。
所有在线用户的在线状态信息量太大，单台接入服务器存不下，如果在线数进一步增加，甚至单台状态同步服务器也存不下。
单台状态同步服务器支撑不下所有在线用户。
单台接入服务器支撑不下所有在线用户的在线状态信息。
针对这些问题，架构需要继续改造升级，再一次“演化”。IM 3.X 的最终架构如下图，可以看到这次的方案相比之前的方案来说并不简单了，这是业务特性决定的。
4. 亿级 IM 4.X
业务发展到 2010 年 3 月，QQ 同时在线人数过亿。第三代架构此时也不适应了，主要问题有：
灵活性很差，比如“昵称”长度增加一半，需要两个月；增加“故乡”字段，需要两个月；最大好友数从 500 变成 1000，需要三个月。
无法支撑某些关键功能，比如好友数上万、隐私权限控制、PC QQ 与手机 QQ 不可互踢、微信与 QQ 互通、异地容灾。
除了不适应，还有一个更严重的问题：
IM 后台从 1.0 到 3.5 都是在原来基础上做改造升级的，但是持续打补丁已经难以支撑亿级在线，IM 后台 4.0 必须从头开始，重新设计实现！
这里再次遵循了“演化原则”，决定重新打造一个这么复杂的系统，不得不佩服当时决策人的勇气和魄力！
重新设计的 IM 4.0 架构如图所示，和之前的架构相比，架构本身都拆分为两个主要的架构：存储架构和通信架构。
存储架构
通信架构
作者寄语：
每个程序员都有成为架构师的梦想，程序员成长也绕不开架构设计。在专栏中，我从架构基础、三大架构模式和实战的角度分享一整套架构设计方法论。照着做，你也能成为架构师。专栏共 50 期，已更新完毕。目前有超过 3 万人加入学习，互动留言字数超过 20 万。期待你的加入！
作者简介：
《从 0 开始学架构》专栏作者，资深技术专家李运华，目前带领多个研发团队，承担架构设计、架构重构、技术团队管理、技术培训等职责，曾就职于华为和 UCWeb，写过《面向对象葵花宝典》一书。
内容选自极客时间《从 0 开始学架构》专栏
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论