从手机 QQ 技术发展,看架构设计核心 3 原则

阅读数:5604 2019 年 5 月 16 日

《从 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 开始学架构》专栏

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论