企业创新管理腾讯海量服务之道

1.4亿在线背后的故事腾讯科技（深圳）有限公司即通平台部高级技术总监icezhuang——QQIM后台架构的演化与启示7亿活跃账户1.4亿同时在线过万台IM服务器百亿级的关系链对数每天千亿级的服务请求99.99%的可用性团队经历了QQ在线从10万到1.4亿的整个过程，吸取了很多教训对海量服务的理解是长期积累的结果目录从十万级到百万级在线千万级在线亿级在线总结IM后台1.0适用情况同时在线数较低（十万级）业务功能非常简单接入服务器存储服务器UIN10003,[FriendUin,Flag]升序FList,L1FList,L2FList,L31.0接入服务器的核心数据结构0110001100021000310004POS0POS1POS2POS3UIN10001LEVEL1,POS1UIN10004LEVEL1,POS3UIN10002LEVEL2,POS2UIN10003LEVEL3,POS1UIN，标志位，资料在线状态，IP/Port好友表位置OnlineIndexOnlineRecordIM后台1.0的典型业务流程登录实时通知定期拉取在线状态的获取接入服务器存储服务器IM后台1.5需要更好地支持业务支持视频、语音、传文件等实时宽带业务支持更多类型的用户资料增加长连接服务器为无法直连的客户端进行实时宽带数据中转对存储服务器进行轻重分离核心服务器保证稳定扩展服务器快速支持业务长连接服务器扩展存储服务器接入服务器核心存储服务器第一代架构难以支持百万级在线达到一百万在线时，老架构会有各方面的瓶颈出现以接入服务器的内存为例，单个在线用户的存储量约为2KB索引和在线状态50字节好友表400个好友*5字节/好友=2000字节大致来说，2G内存只能支持一百万在线用户进一步地，还有CPU/网卡包量和流量/交换机流量等瓶颈其他服务器也有类似情况单台服务器支撑不下所有在线用户/注册用户第一代架构无以为继，必须升级！IM后台2.0单台服务器扩展成集群增加状态同步服务器在接入服务器之间同步在线状态UIN10001LEVEL1,POS1UIN10004LEVEL1,POS32.0接入服务器的核心数据结构0110001100021000310004LocalPOS0LocalPOS1RemotePOS2RemotePOS3OnlineIndexLocalOnlineRecordUIN10002@ServerID3UIN10003@ServerID5RemoteOnlineRecordUIN在线状态，IP/Port接入服务器IDIM后台2.0的典型业务流程2001年，QQ同时在线突破一百万登录定期拉取实时通知在线状态的获取（三种方式）IM后台2.5支持QQ群等新业务启示：十万级到百万级在线的关键技术高性能；7乘24小时连续服务Kenny“违抗”PonyMa的故事ARPU对比：中国移动73，腾讯2.5PCU/Box：某著名IM数万；QQ数十万CTO：IT成本的高低决定互联网企业的存亡只用传统IT行业1/10到1/100的IT成本高性能OICQ的故事用户忍耐度对比：信用卡系统维护VS用脚投票7乘24小时连续服务QQ后台如何实现高性能绝不使用企业级解决方案逻辑层多进程万有一失的无锁设计用户态IPCMySQL分库分表好友表自写文件存储……接入服务器接入进程登录进程好友进程状态进程用户10003，好友表：10001,0x0；10020,0x0用户10003，好友表：10001,0x0；10020,0x1用户10003，好友表：10001,0x0；10005,0x1；10020,0x0QQ后台如何实现高性能绝不使用企业级解决方案逻辑层多进程万有一失的无锁设计用户态IPCMySQL分库分表好友表自写文件存储……UIN10001UIN10001FList,L2FList,L3UIN10001LEVEL1,POS1UIN10004LEVEL1,POS3OnlineRecordUIN10004UIN1000？QQ后台如何实现7乘24小时连续服务大系统小做平滑重构在高速行驶的列车上更换发动机核心数据放入共享内存接入层与逻辑层分离命令分发动态配置化目录从十万级到百万级在线千万级在线亿级在线总结第二代架构难以支持千万级在线同步流量太大，状态同步服务器遇到单机瓶颈所有在线用户的在线状态信息量太大，单台接入服务器存不下如果在线数进一步增加，则甚至单台状态同步服务器也存不下单台状态同步服务器支撑不下所有在线用户单台接入服务器支撑不下所有在线用户的在线状态信息第二代架构无以为继，必须再次升级！IM后台3.0状态同步服务器改造成同步集群其他集群也做相应的改造2005年，QQ同时在线突破一千万根本来不及高兴：我们再也受不了了！手机从不敢离身发布新代码提心吊胆时不时要扩容，又烦又怕时不时要紧急恢复服务时不时被用户骂、被老板K到底怎么了？深入分析，我们发现了什么后台机器越来越多，单机死机/故障经常出现，IDC故障也不少，影响服务，也影响人员生活每周有新代码发布，BUG不断出现，严重影响服务监控机制原始、报警设置不全，出事了都不知道运维操作通过vim或者mysql进行，非常容易失误问题分析和解决（1）后台机器越来越多，单机死机/故障经常出现，IDC故障也不少，影响服务，也影响人员生活传统行业设备少单价高，故障很少出现互联网行业设备多单价低，故障是常态IM后台3.0的容错/容灾分析每个集群只有一份机器选择全人工配置集中在一个IDCIDC的实际可用性只有2个9老架构没前途，必须进行容灾改造！租来的IDC的级别：B或C容灾改造的思路存储集群：半自动切换模式主/从服务器从服务器死机，业务不受影响主服务器死机，多数命令不受影响，修改资料命令受影响业务集群、接入集群、同步集群：自动切换模式迅速应对死机等情况，基本不影响业务分布在两套IDC可以应对IDC整体故障业务集群的容灾改造业务命令流设备状态流接入集群业务集群@IDC1业务集群@IDC2指挥中心@IDC1指挥中心@IDC2问题分析和解决（2）每周有新代码发布，BUG不断出现，严重影响服务大部分子系统每周发布一个版本的新代码解决方法代码review灰度发布第一周周末灰度发布演示号段7-8号段7-8号段5-6号段5-6号段3-4号段3-4号段1-2号段1-2第一周周一第一周周二第一周周三第一周周四第一周原来周一周二周三周四问题分析和解决（3）监控机制原始、报警设置不全，出事了都不知道CPU100%的故事解决方法完善监控和报警完善监控和报警完善监控和报警完善监控和报警完善监控和报警完善监控和报警问题分析和解决（4）运维操作通过vim或者mysql进行，非常容易失误Grandy的故事解决方法运维操作Web化（半自动化）、自动化•IM后台3.5的运维页面已经废除，后面有IM后台4.0的运维页面截图服务可用性终于提升到了行业先进水平IM后台3.5架构长连接集群同步集群接入集群存储集群若干个业务集群长连接集群同步集群接入集群存储集群若干个业务集群容灾指挥集群IDC1IDC2运维控制集群监控报警集群容灾指挥集群运维控制集群监控报警集群运维控制集群监控报警集群监控报警集群运维控制集群监控报警集群运维控制集群监控报警集群运维控制集群监控报警集群容灾指挥集群运维控制集群监控报警集群运维控制集群监控报警集群容灾指挥集群容灾指挥集群运维控制集群监控报警集群运维控制集群监控报警集群启示：千万级在线的关键技术对外提供高可用性的服务对内提供高可运维性的系统灰度发布运营监控容灾运维自动化/半自动化高可用性；高可运维性目录从十万级到百万级在线千万级在线亿级在线总结随着亿时代的接近，新烦恼又来了灵活性：“昵称”长度增加一半，需要两个月增加“故乡”字段，需要两个月最大好友数从500变成1000，需要三个月亿时代的重要能力：上万好友隐私权限控制PCQQ与手机QQ别互踢微信与QQ互通异地容灾IM后台从1.0到3.5都是在原来基础上做改造升级，但是：持续打补丁已经难以支撑亿级在线IM后台4.0必须从头开始，重新设计实现！太差！想都别想！IM后台4.0存储系统架构IM后台4.0存储系统运维页面IM后台4.0存储系统成果历时3年完成千万级好友隐私权限控制灵活扩展字段高可运维性运维操作组件化负载自动转移高性能自写存储层IM后台4.0通信系统逻辑架构IM后台4.0通信系统物理架构IM后台4.0通信系统运维页面IM后台4.0通信系统阶段成果历时2+年完成多点登录支持5至10亿个实例同时在线方便接入微信等多种业务区域自治高可运维性物理架构详细到机架故障分析智能化启示：亿级在线的关键技术提供高灵活性的业务支持传统IT行业可以半年到两年出一个新版本互联网行业要求每个月出一个新版本同时保持高性能、高可用性、高可运维性高性能；高可用性；高可运维性；高灵活性腾讯IM服务的未来之路全球化分布高效率的研发监控告警的智能化目录从十万级到百万级在线千万级在线亿级在线总结QQIM后台技术演化的启示1.0十万级、2.0百万级高性能；7乘24小时连续服务3.0千万级高可用性；高可运维性4.0亿级高性能；高可用性；高可运维性；高灵活性QQIM后台技术演化的启示只实现功能，不难高性能/低成本高可用性高可运维性高灵活性很难！在线量每提升一个量级，技术难度也提升一个量级7亿活跃账户1.4亿同时在线过万台IM服务器百亿级的关系链对数每天千亿级的服务请求99.99%的可用性团队经历了QQ在线从10万到1.4亿的整个过程，吸取了很多教训对海量服务的理解是长期积累的结果互联网与传统IT行业区别很大互联网行业有自己的技术规律，需要做自己的技术积累传统IT行业互联网行业ARPU数十元低于三元IT成本的重要性只占总成本的不到10%占总成本的大部分设备数量与单价数量少单价高数量多单价低设备故障极少常态对延迟的忍耐度较高很低对数据错误的忍耐度万无一失万有一失版本更新速度半年以上一个月左右腾讯在海量服务方面的技术积累和总结：《海量服务之道》系列课程Set模型全网调度灰度升级过载保护立体监控自动部署柔性可用大系统做小先扛住再优化边重构边生活干干净净有损服务动态运营