大厂架构演进系列② | QQ 25 年进化史：从UDP到NT架构，支撑亿级在线的技术之路
大厂架构演进系列② | QQ 25 年进化史：从UDP到NT架构，支撑亿级在线的技术之路
摘要
作为中国互联网存活最久的国民级 IM，QQ 的 25 年架构演进是一部 “业务推动技术进步” 的实战教科书。从 1999 年 OICQ 单台服务器撑 90 人在线，到 2024 年支撑 1.4 亿同时在线、日消息万亿级传输，QQ 历经 6 次关键架构跃迁：用 UDP 协议突破带宽瓶颈，靠内存存储扛住偷菜洪峰，以动态心跳适配移动弱网，最终通过云原生与 NT 架构实现多端统一。 本文精准还原各阶段时间线，结合架构图深度拆解 “业务需求→技术挑战→解决方案” 的完整逻辑，为技术爱好者呈现 IM 系统从单体到云原生的进化全貌。第一章
初创求生期（1999.02-2001.12）：UDP + 单体，抢下 IM 生死线
1.1 业务背景
- 1999.02.10：OICQ 99b 正式上线，核心功能仅文字聊天、好友列表、在线状态，对标 ICQ
- 1999 年底：注册用户破 100 万，同时在线峰值从初期 90 人突破 1 万，开发团队用小号 “刷在线” 突破象征性门槛
- 2000 年：正式更名 QQ，上线QQ 群（初期上限 10 人）、QQ 秀、视频聊天，用户数呈指数增长
- 2001 年底：注册用户破 1 亿，同时在线冲百万级，跻身国内顶级 IM 产品
- 核心业务诉求：在带宽稀缺、服务器昂贵的年代 “先活下来”，在 ICQ、MSN 等竞品围剿中抢占市场
1.2 核心架构设计（附架构图）
架构模型：极简 C/S 单体架构（接入 + 逻辑 + 存储合一）关键技术选型：
- 传输协议：UDP 为主 + 应用层可靠性补充（超时重传、去重、有序化），UDP 头部仅 8 字节，比 TCP 省带宽
- 存储方案：用户资料文件存储，在线状态全内存加载，离线消息暂存服务器
- 通信流程：应用层封装 UDP 数据报，限制单包大小≤1472 字节，避免 IP 分片
1.3 核心业务痛点→技术挑战→解决方案
|
业务痛点 |
技术挑战 |
解决方案 |
|
带宽成本高，TCP 三次握手延迟高，影响实时聊天体验 |
带宽稀缺 + 连接建立开销大，并发连接扛不住 |
选用 UDP 协议，应用层实现可靠性机制（超时重传、校验和验证、消息有序化） |
|
单服务器撑不住万级在线，扩容只能堆机器 |
C10K 瓶颈初现，单机连接数上限限制用户增长 |
拆分接入模块为独立接入机，通过轻量状态同步实现水平扩展 |
|
消息传输易丢失，离线用户无法接收消息 |
UDP 无连接特性导致消息不可靠，无离线存储 |
服务器落地存储消息，客户端上线后拉取；设计消息回执机制，未确认则重传 |
|
开发周期短（仅 3 个月），需快速上线验证市场 |
架构设计与开发效率矛盾，无时间做复杂设计 |
采用单体架构，业务与架构强耦合，优先保障核心通信功能可用 |
1.4 架构痛点
- 单点故障：全链路耦合，单服务器宕机导致全服不可用
- 扩容困难：无集群架构，扩容只能垂直升级服务器或简单堆机器
- 功能扩展受限：新业务（如 QQ 群、视频聊天）需修改核心代码，迭代效率低
- 监控缺失：无实时监控系统，需人工查看日志判断服务状态
1.5 阶段成果
- 2001 年底注册用户破 1 亿，同时在线达百万级，成功抢占 IM 市场主导地位
- UDP 协议使带宽利用率提升 30%，消息延迟控制在 100ms 内，优于同期竞品
- 验证了 “轻量级协议 + 极简架构” 在早期互联网环境的可行性
第二章
百万在线攻坚期（2002-2004）：分拆服务，扛住指数增长
2.1 业务背景
- 2002 年：同时在线突破 300 万，上线文件传输、远程协助功能
- 2003 年：推出网络硬盘、QQ 邮箱绑定，业务边界从即时通信向工具化延伸
- 2004 年 6 月 16 日：腾讯港股上市，QQ 成为核心营收支柱；同时在线突破 3000 万
- 核心业务诉求：解决单体架构的扩容瓶颈，支撑百万级并发，保障多业务稳定运行
2.2 核心架构优化（附架构图）
核心优化方向：三层架构拆分（接入层 + 逻辑层 + 存储层）+ 服务化雏形
关键技术突破：
- 接入层独立：负责长连接管理、负载均衡、协议解析，支持水平扩容
- 逻辑层拆分：按业务域拆分用户、消息、群、状态服务，降低耦合
- 存储层升级：引入 MySQL 主从架构实现读写分离，用 Memcached 缓存热点数据
- 协议标准化：自研 QDP 协议替代原始 ICQ 兼容层，提升通信效率
2.3 核心业务痛点→技术挑战→解决方案
|
业务痛点 |
技术挑战 |
解决方案 |
|
百万级并发连接打满单机，接入层成为瓶颈 |
单机连接数上限不足，负载不均 |
接入层集群化部署，采用 “最小连接数” 负载均衡策略，支持动态扩容 |
|
数据库查询量暴增，读写冲突严重 |
单库并发瓶颈，查询响应超时 |
实施 MySQL 主从分离，写操作走主库、读操作走从库；热点数据缓存至 Memcached |
|
群聊消息扩散延迟高，多人聊天卡顿 |
群消息需向所有成员推送，同步处理阻塞 |
采用 “写扩散” 模型，消息批量投递；引入消息队列异步处理扩散逻辑 |
|
多端登录（PC + 手机）导致状态同步混乱 |
多设备登录时在线状态、消息同步不一致 |
搭建统一状态中心，会话原子更新，确保多端状态实时同步 |
2.4 关键决策与技术细节
- 读写分离策略：主库仅处理用户注册、消息发送等写操作，从库负责好友列表查询、历史消息拉取等读操作，读请求压力分散至多个从库
- 缓存设计：Memcached 集群缓存用户在线状态、好友关系链等高频访问数据，缓存命中率达 90% 以上，数据库压力降低 60%
- 容灾雏形：深圳主 IDC + 上海备份节点，核心数据多副本存储，降低单点故障风险
2.5 阶段成果
- 2004 年同时在线突破 3000 万，支撑文件传输、远程协助等新业务稳定运行
- 系统可用性提升至 99.9%，数据库查询响应时间从 500ms 降至 50ms 内
- 奠定了 “分层架构 + 服务拆分” 的基础，为后续业务扩张预留空间
第三章
生态爆炸期（2005-2010）：内存架构，扛住偷菜洪峰
3.1 业务背景
- 2005 年：QQ 空间、QQ 音乐、QQ 宠物上线，从 IM 工具向社交生态延伸
- 2007 年：同时在线突破 8000 万，成为全球首个同时在线破亿的 IM 产品
- 2009 年：QQ 农场上线，“偷菜” 引爆全民热潮，峰值请求量单日破 100 亿次
- 2010 年：QQ 空间日均上传图片超 1 亿张，非结构化数据呈爆炸式增长
- 核心业务诉求：应对 “偷菜” 带来的超高并发读写，解决非结构化数据存储压力，支撑社交生态多元化
3.2 核心架构革命（附架构图）
核心架构变革：全链路内存存储为主 + 分布式缓存 + 对象存储关键技术突破：
- 内存优先：核心业务（偷菜、消息、在线状态）全内存存储，磁盘异步落盘
- 分布式缓存：自研分布式 KV 库 + Memcached 集群，冷热数据自动调度
- 异步化：引入消息队列削峰填谷，处理偷菜等突发流量
- 存储分离：结构化数据用 MySQL 分库分表，非结构化数据用对象存储独立治理
3.3 核心业务痛点→技术挑战→解决方案
|
业务痛点 |
技术挑战 |
解决方案 |
|
QQ 农场偷菜峰值请求达 100 亿次 / 日，数据库彻底顶不住 |
超高并发读写，磁盘 IO 瓶颈 |
采用 All DRAM 架构，偷菜核心逻辑全内存运行，仅异步落盘至磁盘 |
|
QQ 空间日均 1 亿张图片上传，存储成本高、访问慢 |
非结构化数据存储扩容难、效率低 |
引入对象存储服务，图片分片存储 + CDN 加速，冷热数据分离 |
|
夜间偷菜高峰与白天低谷流量落差达 20 倍，资源浪费严重 |
潮汐流量导致资源供需失衡 |
弹性调度机制，在线服务与离线任务（数据分析、备份）混跑，提升资源利用率 |
|
社交、游戏、IM 多业务共享资源，一个业务故障影响全局 |
业务耦合导致故障扩散 |
业务域隔离，核心 IM 服务资源优先保障，非核心业务（如游戏）独立部署 |
3.4 关键技术细节
- 偷菜业务架构：服务端维护全局状态机（种植→生长→成熟→可偷→冷却），客户端仅负责渲染，所有判定逻辑在服务端执行，防止外挂作弊
- 缓存策略：热点数据（如作物成熟状态、用户在线状态）内存缓存，缓存失效时间按业务场景动态调整，确保数据实时性
- 分库分表：按用户 ID 哈希分片，将 1 亿用户数据分散至数百个数据库节点，单库并发压力降低至可控范围
3.5 阶段成果
- 2007 年同时在线突破 1 亿，2010 年峰值达 1.2 亿
- QQ 农场峰值并发处理能力达 10 万次 / 秒，无明显卡顿
- 系统可用性维持 99.9%，非结构化数据存储成本降低 40%
第四章
移动互联网转型期（2011-2014）：弱网优化，动态心跳保在线
4.1 业务背景
- 2011 年：智能手机普及，手机 QQ 用户快速增长，上线移动版 QQ 空间、语音消息
- 2012 年：2G/3G 弱网环境成为主流，用户反馈掉线频繁、费流量、费电
- 2013 年：手机 QQ 同时在线突破 1 亿，移动端占比首次超过 PC 端
- 2014 年：同时在线峰值达 2 亿，上线QQ 红包，开启移动支付布局
- 核心业务诉求：解决移动弱网环境下的连接稳定性问题，优化流量与电量消耗，支撑移动端业务扩张
4.2 核心架构升级（附架构图）
核心架构特征：移动专用接入网 + 弱网优化 + 多地多中心部署
关键技术突破：- 动态心跳算法：根据网络类型（WiFi/4G/2G）自动调整心跳频率，弱网环境延长心跳间隔
- 协议优化：二进制序列化 + 协议压缩，减少包体大小；合并推送，降低请求次数
- 就近接入：全国部署接入节点，根据用户地理位置调度至最近节点，降低延迟
- 弱网补偿：消息缓冲、批量同步、快速重连机制，提升弱网下的消息送达率
4.3 核心业务痛点→技术挑战→解决方案
|
业务痛点 |
技术挑战 |
解决方案 |
|
2G/3G 弱网环境下频繁掉线，连接稳定性差 |
网络波动大、NAT 超时，长连接易断开 |
研发智能动态心跳算法，WiFi 环境 1 分钟 / 次心跳，2G 环境 5 分钟 / 次心跳；实现快速重连机制 |
|
移动端流量消耗大，用户投诉频繁 |
协议冗余、请求次数多，流量开销大 |
采用二进制协议替代文本协议，包体压缩率达 60%；合并多条消息推送，减少请求次数 |
|
后台运行时电量消耗快，影响用户使用时长 |
频繁网络请求导致 CPU 唤醒频繁 |
优化后台保活策略，与系统级保活协同；心跳请求批量处理，减少 CPU 唤醒次数 |
|
跨运营商、跨地域访问延迟高，消息同步慢 |
网络路由跳转多，传输延迟大 |
全国部署 20 + 接入节点，基于 IP 地理位置实现就近接入；优化跨网传输链路 |
4.4 关键技术细节
- 动态心跳机制：通过采集用户网络状态（信号强度、延迟、丢包率）动态调整心跳间隔，平衡连接稳定性与资源消耗
- 弱网消息传输：消息分优先级，文本消息优先传输，图片 / 视频等大文件在网络恢复后异步上传；支持断点续传
- 电量优化：后台仅保留核心连接线程，非核心功能（如广告推送）在后台暂停，唤醒时批量处理
4.5 阶段成果
- 移动端同时在线突破 1 亿，弱网环境掉线率从 30% 降至 5% 以下
- 消息送达率提升至 99.5%，流量消耗降低 40%，电量消耗降低 30%
- 支撑 QQ 红包业务稳定运行，2014 年春节收发总量达 1 亿个
第五章
云原生与微服务期（2015-2021）：解耦巨石，弹性扛洪峰
5.1 业务背景
- 2015 年：业务极度复杂，涵盖聊天、群、直播、游戏、支付、小程序等数十个场景
- 2017 年：QQ 开始上云，初期将 15% 的用户从私有云迁移至腾讯云
- 2019 年：30% 的用户完成上云，采用 “三云一地” 混合云架构
- 2021 年：全面拥抱云原生，完成近 20 万台服务器上云迁移
- 核心业务诉求：解决巨石架构的迭代效率问题，支撑极端并发（如春节红包），降低运维成本
5.2 核心架构变革（附架构图）
架构迁移路径：私有云→混合云→全云原生
关键技术选型：- 微服务拆分：将巨石 IM 拆分为近百个微服务，按业务域独立部署迭代
- 容器化：基于 K8s 实现容器编排，支持弹性伸缩
- 服务治理：采用服务网格 TSeer，实现限流、熔断、降级、服务发现
- 全链路可观测：整合监控、日志、链路追踪，实现故障快速定位
5.3 核心业务痛点→技术挑战→解决方案
|
业务痛点 |
技术挑战 |
解决方案 |
|
巨石架构迭代慢，改一处动全身，发布风险高 |
业务耦合严重，发布周期长，故障影响范围大 |
微服务拆分，按业务域解耦；引入蓝绿部署、灰度发布、一键回滚机制 |
|
春节红包、直播带货等场景突发流量，资源不足 |
流量波动剧烈，传统架构弹性伸缩响应慢 |
基于 K8s 的 HPA 自动扩缩容，预测式弹性调度，峰值时 Pod 数量快速扩容 10 倍 |
|
近 20 万台服务器上云，数据迁移风险高、周期长 |
数据一致性难保障，业务中断风险大 |
采用 “主备同步 + 切换” 迁移方案，先迁移非核心业务，再迁移核心服务；拉 4N 专线保障网络稳定性 |
|
微服务依赖复杂，故障定位困难 |
服务调用链路长，问题排查效率低 |
搭建全链路可观测平台，实现监控告警、日志分析、链路追踪一体化，故障定位时间从小时级降至分钟级 |
5.4 关键技术细节
- 上云迁移策略：分三阶段推进，2017 年试点迁移 15% 用户，2019 年迁移 30% 用户，2021 年完成全量迁移；采用 “三云一地” 架构（华北、华东、华南云区域 + 深圳自研机房），用户可跨区域调度
- 微服务治理：核心服务（如消息、支付）采用多副本冗余，强弱依赖分离，非核心服务故障不影响核心功能；通过服务网格实现流量控制与故障隔离
- 资源优化：利用云原生的弹性伸缩能力，资源利用率从原来的 30% 提升至 60% 以上，运维成本降低 25%
5.5 阶段成果
2021 年完成全面上云，同时在线峰值稳定在 1.4 亿极端并发场景（如春节红包）可用性达 99.99%，交易故障率低于 0.001%研发迭代效率提升 40%，新功能上线周期从周级缩短至天级第六章
多端统一新纪元（2022 - 至今）：NT 架构，一次编写全端运行
6.1 业务背景
- 2022 年：PC/Android/iOS/macOS/Linux 多端开发维护成本极高，新功能同步慢
- 2023 年：推出QQ NT 架构（New Technology），基于 Electron 实现跨平台统一
- 2024 年：NT 架构全面普及，支持模块化插件、AI 辅助功能
- 核心业务诉求：解决多端开发重复劳动问题，实现全端体验一致，提升研发效率，支撑未来功能扩展
6.2 核心架构终极升级（附架构图）
核心架构特征：跨平台统一 + 模块化 + 异步架构
关键技术突破：- 跨平台统一：基于 Electron 技术栈，一套代码多端运行，覆盖 Windows/macOS/Linux
- 模块化设计：拆分为 100 + 业务模块，支持插件化加载，按需启用功能
- 异步架构：采用异步调用替代线程锁，降低死锁风险，提升并发性能
- 性能优化：关键功能（如消息处理）用 C++ 实现，平衡跨平台与性能
6.3 核心业务痛点→技术挑战→解决方案
|
业务痛点 |
技术挑战 |
解决方案 |
|
多端代码重复开发，维护成本高，新功能同步慢 |
多端技术栈不统一，代码复用率低 |
基于 Electron 实现跨平台统一，一套逻辑多端复用，开发效率提升 60% |
|
传统架构卡顿臃肿，内存占用高 |
线程锁导致并发性能差，资源消耗大 |
采用异步架构，减少线程锁使用；优化进程管理，将聊天场景内存压至 300MB 内 |
|
多端数据同步不一致，体验碎片化 |
各端存储逻辑不同，同步机制复杂 |
设计统一数据同步层，基于云服务实现多端数据实时一致，同步延迟≤1 秒 |
|
未来功能扩展困难，新特性接入成本高 |
架构耦合严重，模块依赖复杂 |
插件化 + 模块化设计，新功能以插件形式接入，不影响核心架构；支持热更新 |
6.4 关键技术细节
- NT 架构组成：Electron 提供跨平台能力，C++ 实现核心高性能模块（如音视频、加密），异步架构保障并发性能，模块化设计支持功能扩展
- 性能优化措施：安装包从 210MB 瘦身至 150MB；优化窗口进程创建 / 销毁机制；禁用非核心功能可进一步降低内存占用
- 兼容性保障：保留传统功能的同时，支持新特性快速迭代，老用户可平滑过渡
6.5 阶段成果
- 多端开发维护成本降低 60%，新功能全端同步上线周期从 1 个月缩短至 1 周
- 全端体验一致性提升，跨平台功能同步率达 100%
- 模块化设计支持 AI 辅助、插件扩展等新功能，为未来演进预留空间
第七章
QQ 架构演进的核心规律与技术启示
7.1 四大核心设计思想
1. 业务驱动的 “问题导向” 迭代：每一次架构升级都精准对应业务痛点- UDP 协议→解决带宽稀缺问题
- 分层拆分→解决并发增长问题
- 内存架构→解决偷菜洪峰问题
- 弱网优化→解决移动化问题
- 云原生→解决迭代效率问题
- NT 架构→解决多端统一问题
7.2 关键技术启示
- IM 系统架构演进的本质：跟随用户规模与使用场景的扩展，从 “集中式” 向 “分布式”“云原生” 逐步升级，核心是解决高并发、高可用、扩展性三大问题
- 弱网优化的核心方法论：动态适配（心跳、协议）+ 补偿机制（重传、缓冲）+ 资源优化（流量、电量），可复用至所有移动互联网应用
- 跨平台架构的取舍：NT 架构证明 “跨平台 + 性能” 可通过 “核心功能原生实现 + 非核心功能跨平台” 平衡，避免单一技术栈的局限性
- 上云迁移的关键：分阶段迁移 + 数据一致性保障 + 网络冗余，大型应用上云需兼顾稳定性与效率
7.3 架构演进的普适规律
核心逻辑：用户规模决定架构复杂度，业务场景决定技术选型，技术演进与业务发展同频共振总结
QQ 的 25 年架构演进，是中国互联网技术发展的缩影。从 1999 年的 UDP 单体服务到 2024 年的 NT 云原生架构，QQ 始终以 “业务痛点” 为核心驱动力，通过 6 次关键跃迁，成功解决了从万级到亿级用户的并发挑战、从 PC 到移动的场景切换、从单一功能到多元生态的业务扩张。其核心成功要素在于：一是坚持 “业务驱动技术”，拒绝为技术而技术；二是在关键节点敢于重构，从分层拆分到云原生迁移，每一次架构升级都为业务增长打开空间；三是平衡短期需求与长期发展，在保障当前稳定的同时预留未来扩展能力。对于技术爱好者而言，QQ 的演进历程提供了一个完整的 IM 系统架构参考模型：初创期追求 “极简可用”，成长期聚焦 “并发扩展”，成熟期注重 “稳定高效”，创新期拥抱 “生态兼容”。这种 “循序渐进、问题导向” 的架构演进思路，值得所有互联网应用借鉴与落地。