为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第21 期。

[- 1 -] 新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践

[链接] http://www.52im.net/thread-2007-1-1.html

[摘要] 本文我们就来聊聊分布式架构的演进过程，希望能给大家带来眼前一亮的感觉。

[- 2 -] 一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等

[链接] http://www.52im.net/thread-2494-1-1.html

[摘要] 本文将从负载均衡技术的分类、技术原理、常见实现算法、常用方案等入手，为您详细讲解负载均衡技术的方方面面。这其中，四层和七层负载均衡技术最为常用，它们也是本文介绍的重点。

[- 3 -] 从新手到架构师，一篇就够：从100到1000万高并发的架构演进之路

[链接] http://www.52im.net/thread-2665-1-1.html

[摘要] 本文以设计淘宝网的后台架构为例，介绍从一百个并发到千万级并发情况下服务端的架构的14次演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知。

[- 4 -] 腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面

[链接] http://www.52im.net/thread-1811-1-1.html

[摘要] 本文结合作者多年的互联网系统设计实践经验，从最基本的技术概念开始，带你探寻服务器端系统架构的方方面面。

[- 5 -] 快速理解高性能HTTP服务端的负载均衡技术原理

[链接] http://www.52im.net/thread-1950-1-1.html

[摘要] 本文将以简洁通俗的文字，为你讲解主流的HTTP服务端实现负载均衡的常见方案，以及具体到方案中的负载均衡算法的实现原理。理解和掌握这些方案、算法原理，有助于您今后的互联网项的技术选型和架构设计，因为没有哪一种方案和算法能解决所有问题，只有针对特定的场景使用合适的方案和算法才是最明智的选择。

[- 6 -] 知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路

[链接] http://www.52im.net/thread-1968-1-1.html

[摘要] 本文作者陈鹏是该系统的负责人，本次文章深入介绍了该系统的方方面面，值得互联网后端程序员仔细研究。

[- 7 -] 阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史

[链接] http://www.52im.net/thread-2050-1-1.html

[摘要] 阿里数据库事业部研究员张瑞，将为你讲述双11数据库技术不为人知的故事。在零点交易数字一次次提升的背后，既是数据库技术的一次次突破，也见证了阿里技术人永不言败的精神，每一次化“不可能”为“可能”的过程都是阿里技术人对技术的不懈追求。

[- 8 -]  阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路

[链接] http://www.52im.net/thread-2072-1-1.html

[摘要] OceanBase 是蚂蚁金服自研的分布式数据库，在其 9 年的发展历程里，从艰难上线到找不到业务场景濒临解散，最后在双十一的流量考验下浴火重生，成为蚂蚁金服全部核心系统的承载数据库。这一路走来的艰辛和故事，蚂蚁金服高级研究员、OceanBase 团队负责人阳振坤将为你娓娓道来。

[- 9 -] 达达O2O后台架构演进实践：从0到4000高并发请求背后的努力

[链接] http://www.52im.net/thread-2141-1-1.html

[摘要] 达达的业务组成简单直接——商家下单、配送员接单和配送，也正因为理解起来简单，使得达达的业务量在短时间能实现爆发式增长。而支撑业务快速增长的背后，正是达达技术团队持续不断的快速技术迭代的结果，本文正好借此机会，总结并分享了这一系列技术演进的第一手实践资料，希望能给同样奋斗在互联网创业一线的你带来启发。

[- 10 -] 优秀后端架构师必会知识：史上最全MySQL大表优化方案总结

[链接] http://www.52im.net/thread-2157-1-1.html

[摘要] 本文将总结和分享当MySQL单表记录数过大时，增删改查性能急剧下降问题的优化思路，这也是资深后端架构师、程序员所必备的知识内容之一，希望本文对你有用。

[- 11 -] 通俗易懂：如何设计能支撑百万并发的数据库架构？

[链接] http://www.52im.net/thread-2510-1-1.html

[摘要] 本篇文章我们一起来学习一下，对于一个支撑日活百万用户的高并发系统，数据库架构应该如何设计呢？

[- 12 -] 多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了

[链接] http://www.52im.net/thread-2625-1-1.html

[摘要] 本文将从17个维度综合对比Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ这5款当前最主流的MQ消息中间件产品，希望能为您的下一次产品的架构设计和MQ消息中间件选型提供参考依据。

[- 13 -] 小米技术分享：解密小米抢购系统千万高并发架构的演进和实践

[链接] http://www.52im.net/thread-2323-1-1.html

[摘要] 本次分享将为大家解密该系统的技术演进、设计思路、实践总结等，希望能带给您启发。

[- 14 -] 美团技术分享：深度解密美团的分布式ID生成算法

[链接] http://www.52im.net/thread-2751-1-1.html

[摘要] 对于美团的Leaf-segment这个ID生成方案，因为生成的ID全局唯一、全局有序，所以非常适合IM这种应用场景，这也是即时通讯网整理并分享给社区的原因。

[- 15 -] 12306抢票带来的启示：看我如何用Go实现百万QPS的秒杀系统(含源码)

[链接] http://www.52im.net/thread-2771-1-1.html

[摘要] 本文内容虽是从秒杀系统谈起，并未直接涉及即时通讯相关知识，但有关Go的高并发实践，仍然值得广大即时通讯网的技术爱好者们研究和学习，必竟业务可以不同，但技术都是相通的，或许能为你即时通讯系统的高并发架构带来新的思路和灵感。

👉52im社区本周新文：《企业微信针对百万级组织架构的客户端性能优化实践 http://www.52im.net/thread-4437-1-1.html》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第20 期。

[-1-] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[链接] http://www.52im.net/thread-3638-1-1.html

[摘要] 本文根据融云亿级IM消息系统的技术实践，总结了分布式IM消息的可靠投递机制，希望能为你的IM开发和知识学习起到抛砖引玉的作用。

 [-2 -] IM开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计

[链接] http://www.52im.net/thread-3675-1-1.html

[摘要] 本文将重点讨论的是“关注”功能对应的技术实现：先总结常用的基于时间线Feed流的后台技术实现方案，再结合具体的业务场景，根据实际需求在基本设计思路上做一些灵活的运用。

 [-3 -] 阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路

[链接] http://www.52im.net/thread-3699-1-1.html

[摘要] 本文分享的是闲鱼即时消息系统架构从零开始的技术变迁之路，以期更多的同行们在此基础上汲取经验，得到有价值的启发。

 [-4 -] 阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践

[链接] http://www.52im.net/thread-3706-1-1.html

[摘要] 那么基于闲鱼现有的即时消息系统架构和技术体系，如何来优化它的消息稳定性、可靠性？应该从哪里开始治理？当前系统现状到底是什么样？如何客观进行衡量？希望本文能让大家看到一个不一样的闲鱼即时消息系统。

 [-5 -] 阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践

[链接] http://www.52im.net/thread-3726-1-1.html

[摘要] 本文将根据闲鱼IM消息系统在消息及时性方面的优化实践，详细分析了IM在线通道面临的各种技术问题，并通过相应的技术手段来优化从而保证用户消息的及时到达。

 [- 6 -] 阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化

[链接] http://www.52im.net/thread-3748-1-1.html

[摘要] 本文将要分享的是闲鱼IM消息在解决离线推送的到达率方面的技术实践，内容包括问题分析和技术优化思路等，希望能带给你启发。

 [-7-] 阿里IM技术分享(八)：深度解密钉钉即时消息服务DTIM的技术设计

[链接] http://www.52im.net/thread-4012-1-1.html

[摘要] 本篇文章内容将从模型设计原理到具体的技术架构、最底层的存储模型到跨地域的单元化等，全方位展现了 DTIM 在实际生产应用中所遇到的各种技术挑战及相应的解决方案，希望借本文内容的分享能为国内企业级IM的开发带来思考和启发。

 [-8 -]  阿里IM技术分享(九)：深度揭密RocketMQ在钉钉IM系统中的应用实践

[链接] http://www.52im.net/thread-4106-1-1.html

[摘要] 在钉钉的IM中，我们通过 RocketMQ实现了系统解耦、异步削峰填谷，还通过定时消息实现分布式定时任务等高级特性。同时与 RocketMQ 深入共创，不断优化解决了很多RocketMQ本身的问题，并且孵化出 POP 消费模式等新特性，使 RocketMQ 能够完美支持对性能稳定性和时延要求非常高的 IM 系统。本文将为你分享这些内容。

 [-9 -] 基于实践：一套百万消息量小规模IM系统技术要点总结

[链接] http://www.52im.net/thread-3752-1-1.html

[摘要] 本文内容将从开发者的视角出发（主要是我自已的开发体会），围绕项目背景、业务需求、技术原理、开发方案等主题，一步一步的与大家一起剖析：设计一套百万消息量的小规模IM系统架构设计上需要注意的技术要点。

 [-10 -] 跟着源码学IM(十)：基于Netty，搭建高性能IM集群（含技术思路+源码）

[链接] http://www.52im.net/thread-3816-1-1.html

[摘要] 本文将根据笔者这次的业余技术实践，为你讲述如何基于Netty+Zk+Redis来搭建一套高性能IM集群，包括本次实现IM集群的技术原理和实例代码，希望能带给你启发。

 [-11 -] 一套十万级TPS的IM综合消息系统的架构实践与思考

[链接] http://www.52im.net/thread-3954-1-1.html

[摘要] 下面就由我来介绍一下我所负责的公司IM综合消息系统所经历的架构设计历程，以及架构设计过程中的一些思路和总结，希望能给你带来启发。

 [-12 -]  直播系统聊天技术(八)：vivo直播系统中IM消息模块的架构实践

[链接] http://www.52im.net/thread-3994-1-1.html

[摘要] 本文针对秀场直播，结合我们一年以来通过处理不同的业务线上问题，进行了技术演进式的IM消息模块架构的升级与调整，并据此进行了技术总结、整理成文，希望借此机会分享给大家。

 [-13-] 得物从0到1自研客服IM系统的技术实践之路

[链接] http://www.52im.net/thread-4153-1-1.html

[摘要] 本篇文章将基于工程实践，分享我们从0到1自研一套客服IM系统时在各种关键技术点上的设计思路和实践方法。

 [-14-] 海量用户IM聊天室的架构设计与实践

[链接] http://www.52im.net/thread-4404-1-1.html

[摘要] 本文将分享网易云信针对海量用户IM聊天室的架构设计与应用实践，希望能带给你启发。

👉52im社区本周新文：《IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存优化实践 http://www.52im.net/thread-4429-1-1.html》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由vivo 互联网服务器团队Yu Quan分享，本文收录时有内容修订和重新排版。

1、引言

如今，Android端的即时通讯IM这类应用想实现离线消息推送，难度越来越大（详见《Android P正式版即将到来：后台应用保活、消息推送的真正噩梦》、《Android保活从入门到放弃：乖乖引导用户加白名单吧》）。

于是，使用手机厂商自建的ROOM级消息推送通道进行IM离线消息推送是个不得不面对的问题，我们也正好借此文机会，一窥主流手机厂商的ROOM级推送通道的技术实现吧。

vivo手机的厂商级消息推送系统的现状是最高推送速度140w/s，单日最大消息量200亿，端到端秒级在线送达率99.9%。同时推送系统具备不可提前预知的突发大流量特点。

本文将要分享的是vivo技术团队针对消息推送系统的高并发、高时效、突发流量等特点，从长连接层容灾、逻辑层容灾、流量容灾、存储容灾等方面入手，如何保证百亿级厂商消息推送平台的高可用性的。

* 推荐阅读：vivo技术团队分享的另一篇消息推送技术文章《vivo手机上的系统级消息推送平台的架构设计实践》。

2、推送系统介绍

vivo推送平台是vivo公司向开发者提供的消息推送服务，通过在云端与客户端之间建立一条稳定、可靠的长连接，为开发者提供向客户端应用实时推送消息的服务，支持百亿级的通知/消息推送，秒级触达移动用户。

推送系统主要由3部分组成：

• 1）接入网关；
• 2）逻辑推送节点；
• 3）长连接。

其中，长连接负责与用户手机终端建立连接，及时把消息送达到手机终端。

推送系统的特点是：

• 1）并发高；
• 2）消息量大；
• 3）送达及时性较高。

下面将针对这几个方面来分享我们的技术实践。

3、长连接层容灾的技术实现

长连接是推送系统最重要的部分，长连接的稳定性直接决定了推送系统的推送质量和性能。因此，需要对长连接层做好容灾和实时调度能力。

3.1面临的问题

原有推送系统架构是长连接层都部署在华东，所有vivo IDC逻辑节点通过VPC与华东的Broker建立连接，手机端跟华东的broker进行长连接通信。

这种部署方式存在以下问题。

1）问题一：华北、华南手机都需要连接华东的Broker，地域跨度大，长连接网络稳定性和时效性相对较差。

2）问题二：逻辑层跟华东的Broker之间由一条VPC连接，随着业务的发展，推送流量越来越大，带宽会出现瓶颈，有超限丢包的风险。另外当该VPC出现故障时，会造成全网消息无法送达。

注：长连接层节点名为Broker。

原始长连接架构图：

3.2解决方法

基于以上架构存在问题，我们对架构进行了优化。即将Broker进行三地部署，分别部署在华北、华东、华南。

华北、华东、华南三地用户采用就近接入方式。

优化后的架构，不仅可以保证长连接网络稳定性和时效性。同时具有较强的容灾能力，华东、华南Broker通过云网跟华北Broker连接，华北Broker通过VPC与vivo IDC连接。当华北、华东、华南某个地区Broker集群故障或者公网故障，不会影响到全网设备收发消息。

三地部署后的架构图：

3.3进一步优化

但是上述这种方式还是存在一个问题，就是某个地区Broker集群故障或者公网故障，会出现该区域部分设备无法收到推送消息的情况。

针对上述单个地区异常导致该区域部分设备无法收到推送消息的问题，我们设计了一套流量调度系统，可以做到实时流量调度和切换。global scheduler节点负责策略调度和管理。

vivo phone进行注册时：dispatcher会下发多个地区的ip地址，默认情况下，进行就近连接。单多次连接失败后，尝试连接其他ip。当某个地区Broker出现长连接数瓶颈或者VPC出现故障，可以通过global scheduler节点下发策略，让该故障地区的设备重新从dispatcher获取新的ip集的ip，与其他地区Broker建立长连接，逻辑节点下发消息到重连后的Broker。等到该地区恢复后，可以重新再下发策略，进行回调。

流量调度系统图：

4、逻辑层容灾的技术实现

长连接层做好容灾后，逻辑层也需要做相应容灾。

之前我们逻辑层都部署在一个机房，不具备机房间容灾能力，当一个机房出现断电风险，会出现服务整体不可用问题，因此我们做"同城双活"部署方案改造。

逻辑层单活架构：

逻辑层分别在vivo IDC1和vivo IDC2进行部署，网关层根据路由规则将流量按照一定比例分别下发到两个IDC，实现逻辑层同城双活。

我们发现：数据中心还是只有一个，部署在vivo IDC1，根据成本、收益，以及多数据中心数据同步延迟问题综合考虑，数据中心暂时还是以单数据中心为主。

逻辑层双活架构：

5、流量容灾的技术实现

5.1概述

做好系统架构的容灾能力后，推送系统的网关层还需要应对突发流量做相应的应对措施，做好流量控制，保证系统稳定性。历史上，我们曾经因为热点和突发新闻事件，并发推送流量巨大，导致服务出现异常，可用性降低问题。

为了应对突发大流量，保证突发流量的情况下，系统可用性不变，同时能兼顾性能和成本。为此，我们分别对比了设计了以下两种方案。

5.2常规方案

常规的方案是一般是根据历史情况估算冗余部署大量机器，来应对突发流量。

单这种方式成本较高，突发流量可能只持续5分钟或更短时间，而系统为了满足5分钟突发流量，需要冗余部署大量机器。

一旦流量超过了部署机器可承担的上限，无法及时扩容，可能导致可用性下降，甚至出现雪崩效应。

传统方案下的推送架构：

那如何设计一套既可以控制成本，面对突发大流量弹性扩容，又保证消息不漏并兼顾推送性能的方案呢？

5.3优化方案

优化后的方案：

• 1）在原有架构的基础上，在接入层增加缓冲通道，当流量洪峰到来时，对于系统可处理的上限能力外的流量，打入缓冲队列；
• 2）通过消息队列形式，增加bypass接入层，限速消费消息队列；
• 3）在流量洪峰过去后，提升bypass消费速度，处理缓存队列消息；
• 4）bypass接入层通过docker部署，支持动态扩缩容，默认最小化集群，当消息队列积压很多，并且下游有能力处理时，提升消费速度，bypass根据CPU负载动态扩容，快速消费消息队列；
• 5）处理完毕后动态缩容。

消息队列：选用吞吐量较大的KAFKA中间件，并且与离线计算KAFKA集群共用，能充分利用资源。

bypass接入层：采用docker部署，支持根据CPU负载和时间动态扩缩容。默认最小集群部署。对于已知的流量高峰时段，可以提前扩容服务，保证流量快速处理。未知时段流量高峰，可以bypass接入层，根据CPU负载情况进行动态扩缩容。

增加缓存队列后的推送架构：

5.4进一步优化

进行上述改造后：还存在一个问题，就是如何进行接入层全局控速。

我们采用的方式是：收集下游推送节点的推送流量情况。

比如：流量达到系统可承受上限的80%时下发限速指令，调整接入层推送速度。让消息先积压在消息队列，等到下游流量降低之后，下发解除限速指令，让bypass接入层加速消费消息队列，进行推送。

增加控速后的推送架构：

优化后方案与传统方案对比：

6、存储容灾的技术实现

6.1问题

做好并发流量控制后，能很好的预发突发热点问题。但在推送系统内部，由于使用Redis集群缓存消息，出现过因为Redis集群故障导致消息无法及时送达问题。

因此：我们考虑对Redis集群做相关容灾方案设计，实现系统在Redis集群故障期间，也能及时推送消息并保证消息不丢失。

推送消息体缓存在Redis集群中，推送时从Redis中获取消息体，如果Redis集群宕机，或者内存故障，会导致离线消息体丢失。

6.2方案

原有消息流程：

1）方案一：

引入另一个对等Redis集群，采用推送双写方式，双写两个Redis集群。该方案需要冗余部署规模对等的备Redis集群。推送系统需要双写Redis操作。

2）方案二：

原有Redis集群，采用RDB+AOF方式同步到另一个备Redis集群。

该方案不在需要推送系统双写Redis改造，直接利用将原有Redis集群数据同步到另一个备Redis集群。也需要冗余部署规模对等的备Redis集群。可能存在部分数据同步延迟导致推送失败问题。

3）方案三：

应用另一个分布式存储系统，磁盘KV，兼容Redis协议，同时具有持久化能力。可以保证消息体不丢失。但是为了节省成本，不再直接使用Redis集群对等资源。

而是根据推送特点，推送分为单推、群推。单推是一对一推送，一个用户一条消息体。群推是一对多推送，一个消息体对应多个用户。

群推往往是任务级别推送。因此我们使用一个相对小一些的磁盘KV集群，主要用于冗余存储，群推消息体，即任务级别的消息。对于单推，还是只保存到Redis中，不进行冗余存储。

如果Redis集群故障，对于单推消息，推送系统可以携带消息体往下游推送，确保消息可以继续下发。对于群推消息，因为消息体冗余存储在磁盘KV中，当Redis集群故障后，可以降级到读取磁盘KV。

6.3优化

方案三还存在一个问题，就是磁盘KV的写入性能和Redis集群不是一个数量级，特别是时延，磁盘KV在平均在5ms左右。

而Redis集群却在0.5ms。如果在推送系统对群推消息体进行双写。这个时延是不能接受的。

因此只能采用异步写入磁盘KV的方式。

这里将备份群推消息体，先写入消息中间件KAFKA，由bypass节点消费KAKFA进行异步写入磁盘KV。这样在使用的灾备磁盘KV资源较少的前提下，保证推送系统的高并发能力，同时可以保证群推消息体不丢失，Redis异常时，单推消息携带消息体推送，群推消息体读取磁盘KV。

存储容灾方案对比：

7、本文小结

本文从长连接层容灾、逻辑层容灾、流量容灾、存储容灾等几个方面讲述了推送系统容灾建设过程。系统容灾需要根据业务发展，成本收益，实现难度等多方面考虑。

当前我们长连接层已具备三地部署，逻辑层具备同城双活，数据中心为单数据中心。后续我们会持续研究和规划双数据中心，两地三中心部署架构方式来逐步加强推送系统容灾能力。

8、参考资料

[1] vivo手机上的系统级消息推送平台的架构设计实践

[2] 魅族2500万长连接的实时消息推送架构的技术实践分享

[3] 专访魅族架构师：海量长连接的实时消息推送系统的心得体会

[4] 百万在线的美拍直播弹幕系统的实时推送技术实践之路

[5] 京东京麦商家开放平台的消息推送架构演进之路

[6] 解密“达达-京东到家”的订单即时派发技术原理和实践

[7] 长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践

[8] 喜马拉雅亿级用户量的离线消息推送系统架构设计实践

[9] 微信直播聊天室单房间1500万在线的消息架构演进之路

[10] 百度直播的海量用户实时消息系统架构演进实践

[11] 消息推送技术干货：美团实时消息推送服务的技术演进之路

[12] 技术干货：从零开始，教你设计一个百万级的消息推送系统

9、vivo技术团队分享的其它文章

《IM消息ID技术专题(七)：深度解密vivo的自研分布式ID服务(鲁班)》

《直播系统聊天技术(八)：vivo直播系统中IM消息模块的架构实践》

《IM跨平台技术学习(三)：vivo的Electron技术栈选型、全方位实践总结》

《vivo手机上的系统级消息推送平台的架构设计实践》

（本文已同步发布于：http://www.52im.net/thread-4416-1-1.html）

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第19 期。

[-1-] 微信后台基于时间序的新一代海量数据存储架构的设计实践

[链接] http://www.52im.net/thread-2970-1-1.html

[摘要] 时隔3年，微信再次分享了基于时间序的新一代海量数据存储架构的设计实践（可以认为是《微信后台基于时间序的海量数据冷热分级架构设计实践》一文中所述架构的升级版），希望能带给你启发。

[-2-] 阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践

[链接] http://www.52im.net/thread-3252-1-1.html

[摘要] 本文来自淘宝消息业务团队的技术实践分享，分析了电商IM消息平台在非传统IM应用场景下的高发并、强互动群聊和直播业务中的技术特点，总结并分享了在这些场景下实现大量多对多实时消息分发投递的一些架构方面的设计实践。

[-3-] 瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）

[链接] http://www.52im.net/thread-2807-1-1.html

[摘要] 此次演讲，从数据架构层面讲解系统遇到的挑战及解决办法。

[-4-]阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处

[链接] http://www.52im.net/thread-2848-1-1.html

[摘要] 业界的 IM 产品在功能上同质化较高，而企业级的 IM 产品对于高可用、安全性又有更高的要求，如何打造具备差异化的产品，又在高可用、安全性、数据一致性等方面具备较高的品质，是企业级 IM 产品成功的关键。钉钉在过去短短几年时间里，用户数已破 2 亿，企业组织数破千万，钉钉是在规划企业级 IM 产品的架构上有何过人之处？本文将围绕这个话题进行展开。

[-5-] 从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路

[链接] http://www.52im.net/thread-2675-1-1.html

[摘要] 本文将分享马蜂窝旅游网的IM系统架构从零演进的整个过程，希望能给你的IM技术选型和方案确定带来启发。

[-6 -] 从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结

[链接] http://www.52im.net/thread-2796-1-1.html

[摘要] 本文由马蜂窝电商业务 IM 移动端研发团队分享了马蜂窝电商业务 IM 移动端的架构演进过程，以及在IM技术力量和资源有限的情况下所踩过的坑等。

[-7-] 从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践

[链接] http://www.52im.net/thread-2909-1-1.html

[摘要] 本文我们将结合马蜂窝旅游电商IM系统的发展历程，单独介绍基于Go重构分布式IM系统过程中的实践和总结（本文相当于《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》一文的进阶篇），希望可以给有相似问题的朋友一些借鉴。

[-8 -]  微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）

[链接] http://www.52im.net/thread-1999-1-1.html

[摘要] 本篇将会介绍 seqsvr 分布式容灾架构的演变。

[-9 -] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[链接] http://www.52im.net/thread-2015-1-1.html

[摘要] 本文将分享的是一套生产环境下的IM群聊消息系统的高可用、易伸缩、高并发架构设计实践，属于原创第一手资料，内容较专业，适合有一定IM架构经验的后端程序员阅读。

[-10 -] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[链接] http://www.52im.net/thread-3393-1-1.html

[摘要] 本篇主要总结和分享这套IM架构的总体设计和服务拆分等。

[-11 -] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[链接] http://www.52im.net/thread-3445-1-1.html

[摘要] 本文主要聚焦这套亿级用户的IM架构的一些比较细节但很重要的热门问题上，比如：消息可靠性、消息有序性、数据安全性、移动端弱网问题等。

[-12 -]  从新手到专家：如何设计一套亿级消息量的分布式IM系统

[链接] http://www.52im.net/thread-3472-1-1.html

[摘要] 本文将在亿级消息量、分布式IM系统这个技术前提下，分析和总结实现这套系统所需要掌握的知识点，内容没有高深的技术概念，尽量做到新手老手皆能读懂。

[-13-] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[链接] http://www.52im.net/thread-3631-1-1.html

[摘要] 本文总结了企业微信的IM消息系统架构设计，阐述了企业业务给IM架构设计带来的技术难点和挑战，以及技术方案的对比与分析。同时总结了IM后台开发的一些常用手段，适用于IM消息系统。

👉52im社区本周新文：《揭秘vivo百亿级厂商消息推送平台的高可用技术实践 http://www.52im.net/thread-4416-1-1.html》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由网易云信资深服务端开发工程师曹佳俊分享，本文收录时有内容修订和重新排版。

1、引言

聊天室是一类非常重要的 IM 业务形态，不同于单聊和群聊，聊天室是一种大规模的实时消息分发系统。聊天室有多种技术实现方案，业界也有一些开源的实现，每种实现都有自己的特点和应用场景。

本文将分享网易云信针对海量用户IM聊天室的架构设计与应用实践，希望能带给你启发。

2、本文作者

曹佳俊：网易云信资深服务端开发工程师，中科院研究生毕业后加入网易，一直在网易云信负责 IM 服务器相关的开发工作。对 IM 系统构建以及相关中间件的开发有丰富的实战经验。

3、聊天室整体架构

首先，我们先来看一下网易云信当前聊天室的详细技术架构，以及我们在架构升级优化过程中做的一些事情。

如下图，是网易云信聊天室的技术架构：

主要包括以下部分：

• 1）接入层的 ChatLink；
• 2）网络传输层的 WE-CAN、WE-CAN bridge；
• 3）调度层的 Dispatcher；
• 4）服务层的 Callback、Queue、Presence、Tag、History 等；
• 5）CDN 分发层的 CDN Manager、CDN Pusher、CDN Source。

下面，我们针对每一层展开详细分析。

4、聊天室的接入层

接入层根据客户端的类型不同会有不同的实现，例如常见客户端（iOS、Andriod、Windows、Mac 等）基于私有二进制协议，Web 端基于 Websocket 协议实现。

接入层作为距离客户端的最后一公里，其接入速度、质量以及数据安全都是至关重要的，下面我们逐一讨论。

1）接入速度和质量：

目前我们搭建了覆盖全国各省份以及全世界各大洲的边缘节点，缩短最后一公里，减少不确定性，提升服务的稳定性。

2）数据安全：

基于对称+非对称加密，客户端与服务器之前实现 0-RTT，完成秘钥交换和登录，同时也支持 RSA/AES/SM2/SM4 等各种加密算法。

接入层除了接受来自客户端的请求，还负责进行消息的单播和广播，因此接入层需要管理本节点的所有长连接，包括每个聊天室房间的连接以及每个连接的标签属性。

此外接入层会上报自己的负载信息给后端服务，方便调度层进行合理的调度。

当流量洪峰来临时，因为需要进行消息的广播，接入层往往是压力最大的，为了保证服务的稳定性，我们做了很多优化策略。

3）自适应的流控策略：

单机流控：接入层服务会监控本机整体的网络带宽使用情况，并设置 2 个阈值 T1 和 T2，当带宽使用率超过 T1 时，触发流控，如果进一步超过了 T2，则不仅触发流控还会不断的调整流控的强度。最终的目标是使带宽使用率稳定在 T1 和 T2 之间。

单连接流控：除此之外，接入层服务还会记录每个长连接的消息分发速度，并进行细粒度的调整，避免单机粗粒度流控导致单个连接分发过少或者过多，做到消息分发的平滑，即减少了带宽流量的波动尖刺，也改善了端侧的体验。

4）性能优化：

ChatLink 高负载运行时，除了网络带宽，调用链路上的各个环节都可能成为性能的瓶颈。我们通过减少编解码的次数（包括序列化、压缩等）、多线程并发、减少内存拷贝、消息合并等多种方式，显著地提升了服务性能。

5、聊天室的网络传输层

我们的IM聊天室系统最初的架构是将接入层和后端服务层都部署在同一个机房的，大部分用户都是直连 BGP 机房的 ChatLink，对于偏远地区或者海外，则通过专线的方式部署代理节点完成加速。

该方案存在明显的缺点就是服务能力上限受制于单机房的容量。此外，专线也是一笔不小的开销。

在我们接入 WE-CAN 大网后，接入层 ChatLink 可以做到客户端就近接入，提高服务质量的同时降低了成本。此外，多机房的架构也使得我们的服务能力上升了一个台阶。

为了适配 WE-CAN 大网，我们设计了 WE-CAN Bridge 层，作为大网接入协议和聊天室协议的桥接层，负责协议转换、会话管理、转发接收。通过这种分层架构，接入层和后端业务层可以少修改或者不修改，减少对已有系统的改造成本，也降低了架构升级带来的风险。

什么是WE-CAN？

WE-CAN（Communications Acceleration Network）是网易自研的新一代大规模分布式传输网络，WE-CAN的根本目标是建立一个能将任意数据从全球任一点稳定、快速、高效地发送到全球任何其他角落的通用传输网络，且这个网络是架设在公共互联网之上的 —— 即无需借助任何特殊的硬件设备或架设专线，而是通过软件方案来达到目标。

6、聊天室的调度层

调度层是客户端接入聊天室系统的前提。客户端登录聊天室之前需要先获取接入地址，分配服务我们称之为 Dispatcher。

Dispatcher 是中心化的，会接受来自 WE-CAN 和 ChatLink 的心跳信息，根据心跳情况来选择最佳接入点。

调度系统设计主要考虑的是以下两个关键点。

1）调度精度：

调度系统会根据请求方的 IP 判断地域和运营商信息，对比各个边缘节点的所属区域、运营商以及节点本身的负载（如 CPU、网络带宽等）。

此外还考虑边缘节点到中心机房的链路情况（来自 WE-CAN），计算综合打分，并把最优的若干节点作为调度结果。

2）调度性能：

面对高并发场景，比如一个大型聊天室，活动初期往往伴随着大量人员的同时进入，此时就需要调度系统做出快速的反应。

为此，我们会将上述的调度规则以及原始数据进行本地缓存优化。

此外，为了避免心跳信息滞后导致分配不合理引起节点过载，分配服务时还会动态调整负载因子，在保证调度性能的前提下，尽量做到分配结果的平滑。

7、聊天室的服务层

服务层实现了各种业务功能，包括：

• 1）在线状态；
• 2）房间管理；
• 3）云端历史；
• 4）第三回调；
• 5）聊天室队列；
• 6）聊天室标签等。

其中最基础的是在线状态管理和房间管理：

• 1）在线状态管理：管理某个账号的登录状态，包括登录了哪些聊天室、登录在了哪些接入点等；
• 2）房间管理：管理某个聊天室房间的状态，包括房间分布在哪些接入点，房间里有哪些成员等。

在线状态管理和房间管理的难点在于如何有效管理海量用户和房间。

由于 PaaS 平台的特性，使得我们可以根据不同的租户来进行 Region 划分，从而做到水平扩展。

此外：由于状态数据有快速变化的特点（短 TTL），当某些核心用户或者某个客户报备了大型活动时，可以在短时间内进行相关资源的快速拆分和隔离。

服务层除了要支持海量客户接入、水平扩展外，还有一个很重要能力，就是需要提供各种各样的扩展性功能来适配客户各种应用场景。

为此我们还提供了丰富的功能，比如：

• 1）第三方回调：方便客户干预 C 端用户的登录、发消息等核心环节，自定义实现各种业务逻辑（因为涉及到服务调用，而这个调用是跨机房甚至是跨地区的，为了避免第三方服务故障导致云信服务异常，我们设计了隔离、熔断等机制来减少对关键流程的影响）；
• 2）聊天室队列：可以方便用户实现一些诸如麦序、抢麦等业务场景需求；
• 3）聊天室标签：作为特色功能，支持消息的个性化分　　发（其实现原理是通过客户端登录时设置标签组以及发消息时设置标签表达式，来定义消息分发和接收的规则。标签信息会同时保存在服务层以及接入层，通过将部分标签计算下推到接入层，节省了中心服务的带宽和计算资源）。

8、聊天室的CDN 分发层

当我们评价一个牛x的IM聊天室系统时，常用的一个词是无上限。

架构支持无上限不代表真的无上限。

一个IM聊天室系统，在逻辑上，各个组成单元都是可以水平扩展的，但是每个服务所依赖的物理机、交换机、机房带宽等都是有容量上限的。因此，能够合理地调配多个地域的多个机房，甚至是外部的其他资源，才能真正体现出一个聊天室系统所能支撑的容量上限。

在我们的聊天室系统中，用户所有的接入点遍布各地机房，天然的将各地的资源进行了整合，所能支撑的容量上限自然高于单机房或者单地区多机房的部署模式。

进一步的：当面临一个更大规模的聊天室，此时如果能利用一些外部的通用能力不失为一种合适的选择。融合 CDN 弹幕方案就是这样一种技术实现方案，它可以利用各大 CDN 厂商部署在各地的边缘节点，利用静态加速这样的通用能力来支持超大规模的聊天室消息分发。

基于融合 CDN 弹幕分发方案，其核心点就是弹幕的分发和管理，这是一个可选的模块，我们内部对此进行了封装，可以根据不同的业务特点来选择是否开启而不需要修改任何业务代码。

在开启融合 CDN 弹幕分发方案的情况下，所有的弹幕广播会划分成两条链路：

• 1）重要的且需要实时送达的消息会走长连接到达客户端；
• 2）其他的海量消息则会进入 CDN Pusher，通过各种策略进行聚合后送达 CDN Source。

客户端 SDK 会采取一定的策略定时从 CDN 边缘节点获取弹幕消息。SDK 会聚合不同来源的消息，排序后回调给用户，App 层无需关系消息来自哪里，只需根据自己的业务需求进行处理即可。

如上图，展示了 CDN 弹幕分发链路的消息流转过程。

CDN Manager 负责：

• 1）管理不同 CDN 厂商的分配策略（登录时会通过长连接下发，且能动态调整）
• 2）负责管理平台上各个聊天室融合 CDN 模式的开启和关闭；
• 3）对应的 CDN Pusher 资源的调配和回收。

CDN Pusher 实际负责：

• 1）接收来自客户端消息；
• 2）并根据消息的类型、消息的优先级等，组装成以一个一个的静态资源，推给 CDN Source，等待 CDN 回源拉取。

9、大规模场景应用案例

在2020年8月，网易云音乐 TFBoys 的 7 周年线上演唱会就是一个聊天室大规模场景应用的典型案例。

在这场活动创造了 78w+ 的在线付费演唱会的世界纪录，其弹幕互动的实现方式采用了我们基于融合 CDN 弹幕分发方案。

事实上：在筹备环节，我们的聊天室系统达成了 20 分钟完成从 0 到 1000w 在线，上行消息 tps 达到 100w 的性能指标。

如上图：是支持本次活动弹幕分发的架构图，普通弹幕和礼物消息分别通过客户端 SDK 以及服务器 API 到达云信服务器，并最终进入弹幕广播服务，随后分流到长连接和 CDN 上，再通过 pull / push 混合的方式送达客户端。

PS：有兴趣的同学可以深入阅读关于这个案例的技术分享：《直播系统聊天技术(九)：千万级实时直播弹幕的技术实践》。

10、聊天室标签应用案例

近年来，随着互联网的发展，在线教育越来越火爆，最近又兴起了“超级小班课”模式。

所谓超级小班课，指的是大型多人课堂与小班互动模式结合。在线直播场景下，文字互动作为其中重要的一环，是IM聊天室的典型应用场景。

但在超级小班课的模式下，常规的IM聊天室系统却存在各种各样的问题，不管是建立多个聊天室，还是单个聊天室进行消息过滤，都存在一些严重的问题。

由此我们开放了聊天室标签功能，完美支持了上述业务场景。

基于聊天室标签：可以灵活地支持聊天室消息定向收发、聊天室权限定向管理、聊天室成员定向查询等个性化功能，真正实现大型直播下多场景的分组互动。

比如：

• 1）对学生进行分组标签后，方便进行因材施教；
• 2）分小组讨论，小组间内部讨论和组间 PK 等等。

如上图，展示了超级小班课的一个场景：1 个主讲教师+ N 个互动小班+ N 个助教，所有学生被划分成了一个一个的小班，由对应的助教完成预习提醒、课后答疑、作业监督、学员学习情况反馈等工作，同时又接收来自主讲老师的直播画面，做到了大课的规模，小课的效果。

11、本文小结

以上，就是本文的全部分享，主要介绍了我们构建一个大型聊天室系统的主要技术以及架构原理。

任何系统的搭建都不是一蹴而就的，我们也会继续打磨底层技术，就像引入 WE-CAN 来提升网络传输效果，也会继续丰富完善我们的功能图谱（如独创的聊天室标签功能等）。

12、参考资料

[1] 直播系统聊天技术(九)：千万级实时直播弹幕的技术实践

[2] 海量实时消息的视频直播系统架构演进之路(视频+PPT)

[3] 百万在线的美拍直播弹幕系统的实时推送技术实践之路

[4] 阿里电商IM消息平台，在群聊、直播场景下的技术实践

[5] 微信直播聊天室单房间1500万在线的消息架构演进之路

[6] 百度直播的海量用户实时消息系统架构演进实践

[7] 百万人在线的直播间实时聊天消息分发技术实践

[8] 直播间海量聊天消息的架构设计难点实践

[9] vivo直播系统中IM消息模块的架构实践

[10] 万人群聊消息投递方案的思考和实践

[11] IM中的万人群聊技术方案实践总结

（本文已同步发布于：http://www.52im.net/thread-4404-1-1.html）

本文由QQ技术团队王辉、吴浩、陈俊文分享，编辑Tina整理，本文收录时有内容修订和排版优化。

1、引言

在瞬息万变的互联网行业中，年过二十四的即时通讯IM应用 QQ 堪称超长寿的产品，见证了中国互联网崛起的完整历程。

然而，如今这个元老级产品经历了一次从内到外彻底的重构。在这次重构中，QQ 选择了 Electron 作为 UI 跨平台开发框架。

尽管 Electron 被 Slack、Visual Studio Code 和 Discord 等大型产品广泛使用，但也引发了一些网友的担忧，例如内存占用、安装包体积和启动速度等方面的问题。本文内容整理自 QQ 技术团队的采访，我们一起来看看QQ团队选择Electron作为桌面版跨端框架背后的决策与思考。

2、系列文章

本文是系列文章中的第8篇，本系列总目录如下：

• 《IM跨平台技术学习(一)：快速了解新一代跨平台桌面技术——Electron》
• 《IM跨平台技术学习(二)：Electron初体验(快速开始、跨进程通信、打包、踩坑等)》
• 《IM跨平台技术学习(三)：vivo的Electron技术栈选型、全方位实践总结》
• 《IM跨平台技术学习(四)：蘑菇街基于Electron开发IM客户端的技术实践》
• 《IM跨平台技术学习(五)：融云基于Electron的IM跨平台SDK改造实践总结》
• 《IM跨平台技术学习(六)：网易云信基于Electron的IM消息全文检索技术实践》
• 《IM跨平台技术学习(七)：得物基于Electron开发客服IM桌面端的技术实践》
• 《IM跨平台技术学习(八)：新QQ桌面版为何选择Electron作为跨端框架》（* 本文）

3、老QQ桌面版的技术债

3.1多端代码不统一

QQ 的第一个版本发布于 1998 年，在 Windows 技术栈的基础上用纯原生的方式开发，在当时互联网带宽非常小的情况下，QQ 将安装包控制在了只有 200K 左右。

2007 年后智能手机开始露出苗头，腾讯行动得比较早，部分前端技术开发开始转型到了移动端，在桌面端， QQ 随着业务和组织的发展，针对三大操作系统陆续组建了三支不同的研发团队，各自负责自己的一套代码。

▲ 初版QQ的注册向导页

▲ 初版QQ的主要功能为即时聊天

三端不同代码，老产品历史包袱，加上移动时代研发人员的转型，导致桌面 QQ 维护成本很高。

QQ 技术团队介绍，拿之前的桌面 QQ 为例，Windows QQ 以前的 UI 框架用的是腾讯自研的 GF 框架，10 多年了，GF 这个框架文档还不全，新加入这个项目的团队人员，要基于这个基础框架去做一些事情，是效率很低的一件事情，慢慢的就没有人愿意去用这个框架了。简而言之，就是技术债。

PS：如果你对QQ的发展史感兴趣可以看看下面这些文章：

1. 《闲话即时通讯：腾讯的成长史本质就是一部QQ成长史》
2. 《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
3. 《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
4. 《QQ的成功，远没有你想象的那么顺利和轻松》
5. 《还原真实的腾讯：从最不被看好，到即时通讯巨头的草根创业史》

3.2多端功能不一致

旧版的桌面端 QQ，Windows 的功能最丰富，Mac OS 次之， Linux 功能非常简洁。

比如“屏幕共享”这个功能，移动端有，Windows 端有，但是 Mac OS 端是没有的。那用户就会遇到一个问题，像 Mac OS 端无法与其它端 QQ 用户一起来使用这个功能。

“多端不统一不利于用户对于 QQ 的统一认知。我们这次的架构升级就是想尽量通过一套核心代码去拉平所有平台的体验，让它具有更好的可维护性和可扩展性，让桌面 QQ 能够更好地迭代产品交互和功能，升级用户体验，再次焕发生长的生命力。”

3.3QQ NT 项目的诞生

于是 QQ NT 项目的诞生了！

QQ NT 项目是在 2022 年 3 月份正式启动， Mac OS QQ 在 6 月份开始发布内测， 9 月份正式上架了 App Store，迭代了几个版本之后，QQ 团队就同步开发 Linux。

在 2022 年，QQ 发布了新的 macOS 和 Linux 版本，包括 QQ 后台其实也做了很大的改变和重构，核心系统做了全新重写，云原生成熟度也得到了很大的提升。

从 2023 年开始，QQ 团队聚焦做 Windows 端的开发，在 3 月底就开始内测，7 月初上架官网。

同时移动端 QQ NT 也在 7 月初完成了核心系统的重写和全量升级。

在目前全新的框架设计下，无论是核心系统、功能迭代还是设计语言上，都可以尽可能地“原子化”，来让 QQ 后续更好地迭代功能。

4、新QQ桌面版重构的技术挑战

4.1业务功能上的挑战

QQ 的重构其实是两方面的重构：

• 1）一个是面向复杂业务的梳理重构；
• 2）一个是面向工程技术债的全新技术重构。

重构之路也是两者相互伴随的过程。

首先：在整个 QQ 重构过程中最大的挑战来自于 QQ 功能的复杂化，QQ 有很多十分复杂的历史功能，这些功能模块也曾经由非常多不同的人经手负责过。其中哪些功能是不合理的或没有价值的，如何去做取舍往往是最难的。“虽然技术上我们做了很多事情，但技术上的实现或许并没有那么难，我们处理起来更有经验和从容。相比于技术的复杂度，业务上的往往需要考虑的更多，这本身就是很大的挑战。”

因为 QQ 已经是近 25 年的产品了，有很多细小复杂的功能。虽然这些功能看看起来很小，但用户量其实又很大，稍微改动可能就会有很多的用户反馈，QQ 团队都得非常的关注。仅从产品功能角度上看，有些功能本身就已经是很重的负债，而 QQ 团队内部有一个叫做“QQ 节能计划”的项目，会有比较严谨的项目流程去评估是否需要下架。

4.2技术重构上的挑战

技术上重构也有不少挑战，这次重构是一次跨平台的重构，而在多个平台里面比较有挑战则是 Linux 平台。

作为程序员，很多人免不了要跟 Linux 打交道。但是这么多年来，对于使用 Linux 系统的用户来讲，有一个特别让人烦恼的问题，那就是没有一个好用的 IM 聊天工具。被寄予厚望的 QQ，此前在 Linux 版本上功能也没有 Windows 和 Mac OS 版本全面，迭代速度也明显慢过其他两个版本。业界甚至猜测 Linux 第一个版本是由腾讯实习生所写，毕竟这个说法进一步加重了其初版的“简陋”特性，也为其“停更”的原因提供了更合理的解释。

QQ 技术团队表示，较之另两个版本，Linux 版本的研发最为复杂：

• 1）一方面操作系统本身很多碎片化，市面上有非常多的发行版，也不缺乏一些千奇百怪的版本；
• 2）另一方面因为机器运行环境或编译器的缺失，使得解决适配问题的难度很大。

许多发行版相关的机器和开发环境实际上他们并没有，有时还需要外部公司帮助进行一些测试工作。由于没有相应的开发环境，一旦出现闪退等问题，解决难度自然会变得更大。此外，有时候需要与国产操作系统厂商进行特殊的合作，甚至需要对方寄送特定的编译好的代码库，但前后往往会花费一个月的时间才能收到。

而在本次重构之后，“Linux 功能跟 Windows 一样多了”。

4.3选型Electron的质疑

技术上的另一大挑战便是外界对于 QQ 桌面端使用 Electron 的质疑，尤其是内存方面。

外界有些用户在没有使用和分析的情况下对此发表一些夸大和否定的言论，也确实给 QQ 技术团队带来不小压力，但他们却始终坚定选型方向，也相信其中的问题可以被攻克和解决。

5、为何选择Electron而非纯Native技术栈？

5.1为什么Windows端不用原生实现？

确实当时有很多人在问，为什么 Windows 不用原生去实现？为什么不用 Qt？

首先：不太想和以前一样，Windows、Mac OS、Linux 三端各由一个团队分开负责。在国内这种人才环境里面，相关的纯原生的开发人员其实非常难招了，桌面端的人才稀缺，同时也投入比较大。

而对于 Qt 技术栈，他们首先考虑的其实还是人才的问题，国内熟练 Qt 技术栈的人非常少。如果对这个框架不了解，使用它反而是一个负向作用。

至于微软的 Webview2，从本质上讲，Webview2 和 Electron 并没有太大的区别，只是相对在其中打包了一些微软自身的优化措施，其他方面也不是很完善，而且还无法跨平台。虽然内存方面相较于 Electron 做了更多的优化。但据了解，比如微软 Teams 也没有完全切到 Webview2。并且由于它没有开源，因此也没有办法基于 Webview2 做定制优化。

包括 Flutter，QQ 团队表示他们当时也有过调研。他们放弃的一个原因是 Flutter 在桌面端的完善程度并不高，也担心标准化的问题。虽然当前 Flutter 非常流行，但谁也说不好这是不是“2015 年的 React Native”。大家担心随着时间推移，这套技术可能会失去维护支持，因为本身 Google 使用 Flutter 的占比也比较小。

“虽然它很热，但我们历史上踩过了很多很多非标准化的坑，一旦某个技术栈热度一过、维护力度不够，它就会成为全新的负债，做选型时必然也是避免再有类似经历。”

5.2选择Electron的几个考量

至于为什么最后选择 Electron，QQ 技术团队表示主要是基于以下几个考量。

1）首先最看重的是框架成熟度和技术栈的标准化：

Electron 基于 Web 技术栈，有足够低的上手和使用成本，不需要为了使用框架本身，还需要投入额外巨大人力成本去做基建和周边工具链的建设，以前在 RN、Flutter 的实践上都有类似的情况。而使用 Electron，现有的 Web 前端的大部分基建都可以直接复用，而且使用 Web 开发 UI 的效率，在主流技术栈里算是很高的了。至于迭代效率我觉得从新版桌面 QQ 功能的迭代速度就可以证明，这放在以前是完全办不到的。

另外由于 Web 技术栈是标准化的，假如 Electron 修改开源协议或者要闭源了，他们也能很方便的去写出一套类似的框架。只不过现在已经有开源的了，没必要再去重复建设一个。而且随着 Web 标准长久发展，Web 技术栈也不会有大的问题，而且还会越来越好。

2）其次是技术经验及人才储备：

技术选型是否适合当前团队也是一个很重要的考虑点，团队是否有相关的技术积累，是否有人才储备来持续投入这个技术栈。

Qt 的确在性能上是一个很好的选择，但目前团队对 Qt 没有太多积累，基建基本没有，而且相关人才其实比较匮乏，招聘就更难了。

而当前 QQ 技术团队 Web 前端团队还是有比较多的积累，在 QQ 频道项目中，也完整验证了 Electron 的技术可行性。

3）最后就是 Electron 具备的桌面端跨平台的优势：

但 QQ NT 架构并不是仅指 Electron，Electron 主要是作为 UI 跨平台的框架，只是占比很小的一部分，并且 QQ 桌面端不是全部用 Electron 实现，QQ NT 最核心的部分还是 QQ 底层通用抽象的模块，称之为 NT 内核，包括核心登录、消息系统、关系链、富媒体、长连接、数据库等等模块，完全用 C++ 实现，全平台通用。因此底层是完全跨平台的架构，而 Electron 只是上层桌面端 UI 跨平台较薄的一层。

“其实我们当时选型的时候，也的确看得到大家对 Electron 的评价褒贬不一，但我们还是有信心去解决这个问题，前期也做了一些技术的 Demo 和预研。实际上 Electron 并没有糟糕到这个地步。我们觉得可能是国内很多没有用过 Electron 的开发者，对这个框架有些忌惮。其实你到 Electron 的网站去看，还是有非常多国内外的亿级 DAU 产品都使用 Electron 框架。目前这几年主流的桌面端应用基本都选择了 Electron，如 Visual Studio Code、Discord、Slack、Skype、Whatsapp、Figma 等等，新的应用基本上也是首选 Electron，版本的迭代速度和社区氛围都很在线。”

“我们觉得不需要单纯因为口碑问题，就对这个选型没有了期待。还是要从实际出发，哪种技术栈适合你的产品，看看到底能不能有技术实力去把这个事情搞定。”

6、如何有效控制Electron的内存占用？

外界之所以会觉得 Electron 内存占用高，是因为其本身是一个多进程的架构，主进程基于 Node.js, 而每个窗口都对应一个渲染进程以及 V8 实例。可以说从技术框架层面上，上手写代码很容易，但不容易去管控它的内存。

QQ 技术团队认为：Electron 的开发者更多的是前端的开发者，可能在思维上没有去考虑怎么在这样一套技术框架里，去对内存数据进行管理和管控。开发者需要从前端开发者的思维，转变为客户端开发者的思维。

综合来看：对内存的看法其实不完全是 Electron 的技术框架所导致的，更多的是门槛上、开发思维上，导致内存没有得到很好的关注和优化。其实最简单的 Electron 应用大概也就只有几十兆的内存占用。因为前端原本更多还是停留在开发即用即走的 Web 站点，很少实现一个超大客户端，缺乏控制内存的经验，所以面对 QQ 这么大一个产品的时候，你就必须非常在意内存的使用和管控。

至于优化内存的突破口，可以说是从各个层面：从消息的链路中的每条消息的收发上，数据是怎么管理，包括像窗口及会话的管理，都得精打细算，也会做一些数据本地化和一些机制的按需加载，包括渲染上他们也提出一个根本的原则：“要做到所见才占用”，既我们看到的内容才占用这一部分内存，没看到和用不到的任何场景的内存就不应该再占用，通过各种方式来去让内存达到一个设定的目标。

他们也使用了不同维度的内存分析工具，从 V8 引擎到进程，再到整个应用程序，打通整个链路进行多角度的细节分析，以此来定位内存使用的瓶颈。之后采取一系列的针对性优化策略，包括缓存策略、按需加载、优雅降级等，同时使用线上监控、自动化测试手段，包括借助开发框架、工具建设、代码审查等，来阻止性能退化。（更多细节可以参看技术文章：《IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存占用优化》）

经过一系列组合优化之后：QQ 的内存在长时间挂机的条件下，平均稳定在 220M 左右。“现在优化还是不错的，比老版本要好很多。我们认为这个难题还是可以被很好的攻克，内存并不是大家认为的这么不可控，但是也需要团队去花费相当精力去探索和实践，才能去把内存控制到一个比较理想的状态。”

7、未来展望

目前 QQ 的前端团队作为一个公线团队，不仅负责桌面 QQ 的研发，还有 QQ 基础运营、QQ 空间以及基于 QQ 生态的创新项目研发，有比较多的线上项目的开发与维护和内部研效工具的建设。涉及的技术栈，包括 H5、Electron、Cocos、小程序、WebGL、WebAssembly、WebRTC 等。他们也表示会继续夯实这些技术，同时也不断地打破立下的性能目标，希望让桌面 QQ 覆盖更多平台。

他们也正在积极拥抱 AI：让 AI 在质量和效率上辅助日常开发。比如：前端设计稿还原，之前更多是一个耗时的体力活，D2C 是 QQ 前端一直探索的方向，之前使用纯规则转换生成代码，在视觉还原上效果还不错，但是代码可读性和可维护性不能很好的满足预期，所以除了一些日抛型的运营活动有些使用之外，比较难扩大成果。现在 D2C 结合大模型，生成的代码质量高了很多，也能很方便的将代码与 UI 组件库做映射，达到可以在核心业务中高效使用，达到通过 AI 提升研发效率的目的。针对一些无设计稿的管理平台开发，使用 P2C 提效，目前也有了一些不错的案例。

另外：QQ 技术团队也在积极探索 AI 更广阔的应用场景，比如代码评审，基本的 Lint 检检是难以实现的，但将已经掌握的内存泄漏模式通过规则的形式给到 AI，可以很方便地给开发同学一些不错的建议，为性能看家护院提供多一道保障。

8、写在最后

QQ NT 项目于 2022 年 3 月份启动，Mac OS QQ 花了该团队 3 个月的开发时间，9 月份上架 App Store，迭代了几个版本后同步开始开发 Linux QQ，并于这一年的最后一天上架各 Linux 应用市场，作为给 Linux 用户的一份特殊的新年礼物。2023 年 QQ 团队开始去聚焦做 Windows QQ NT 的开发，7 月正式上架应用市场和官网。同时移动端的 QQ 从 2022 年的 Q4 开始开发，也已经完成了全量升级和发布。

另外：桌面 QQ 也是在 NT 版本中第一次支持 64 位，这需要将音视频、安全、字节码、图形库等 C++ 模块，包括 Electron 框架都重新进行编译，花费了比较大的工作量。但在 64 位系统上，QQ 从此便不再需要以 32 位应用的方式通过额外的兼容和转换来运行。毕竟额外操作会增加开销，导致性能下降。

至此：QQ 实现了多个系统平台之间架构的统一。而团队的未来规划还是不断地打破性能目标，并覆盖更多平台，同时探索更多提升研发效率的办法，加快研发速度。

腾讯 QQ 用跨平台 Electron 取代之前原生应用程序的开发模式，这一举动引发的反响确实巨大。但我们也能看出，不同于小型产品团队，在大公司里具有一定规模的产品组织架构之下，快速满足用户需求，并逐渐需要为第三、第四乃至第五种运行平台提供支持时，保持一致性和协调性并不是想象中的那么容易。而缓慢而低效，最终会令你输掉比赛。

不管使用什么跨平台开发框架，都要去选择最合适自己团队的，也因此在 Web 标准技术栈上有丰富积累的 QQ 团队才会选择 Electron。并且我们认为没有人真正讨厌 Electron，只是我们对 QQ，对国内 App 寄予了非常高的期盼。

9、相关资料

[1] Electron官方开发者手册

[2] 快速了解新一代跨平台桌面技术——Electron

[3] Electron初体验(快速开始、跨进程通信、打包、踩坑等)

[4] Electron 基础入门 简单明了，看完啥都懂了

[5] vivo的Electron技术栈选型、全方位实践总结

[6] 融云基于Electron的IM跨平台SDK改造实践总结

[7] 闲鱼IM基于Flutter的移动端跨端改造实践

[8] 网易云信基于Electron的IM消息全文检索技术实践

[9] 闲话即时通讯：腾讯的成长史本质就是一部QQ成长史

[10] 技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码

[11] 技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史

[12] QQ的成功，远没有你想象的那么顺利和轻松

[13] 还原真实的腾讯：从最不被看好，到即时通讯巨头的草根创业史

附录：更多有关QQ、微信的技术故事

《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》

《QQ和微信凶猛成长的背后：腾讯网络基础架构的这些年》

《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》

《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》

《技术往事：“QQ群”和“微信红包”是怎么来的？》

《开发往事：深度讲述2010到2015，微信一路风雨的背后》

《开发往事：微信千年不变的那张闪屏图片的由来》

《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》

《一个微信实习生自述：我眼中的微信开发团队》

《首次揭秘：QQ实时视频聊天背后的神秘组织》

《为什么说即时通讯社交APP创业就是一个坑？》

《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》

《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》

《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》

《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？》

《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》

《QQ和微信止步不前，意味着即时通讯社交应用创业的第2春已来？》

《那些年微信开发过的鸡肋功能，及其带给我们的思考》

《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》

《同为IM社交产品中的王者，QQ与微信到底有什么区别》

《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》

《社交应用教父级人物的张小龙和马化腾的同与不同》

《专访马化腾：首次开谈个人经历、管理心得、技术创新、微信的诞生等》

《一文读懂微信之父张小龙：失败天才、颠覆者、独裁者、人性操控师》

（本文已同步发布于：http://www.52im.net/thread-4391-1-1.html）

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅支持 UDP 、TCP 、WebSocket 三种协议，支持 iOS、Android、H5、标准Java、小程序、Uniapp，服务端基于Netty编写。

工程开源地址是：

• 1）Gitee码云地址：https://gitee.com/jackjiang/MobileIMSDK
• 2）Github托管地址：https://github.com/JackJiang2011/MobileIMSDK

关于RainbowChat

► 详细产品介绍：http://www.52im.net/thread-19-1-1.html
► iOS端更新记录：http://www.52im.net/thread-2735-1-1.html
► 全部运行截图：iOS端全部运行截图 （另：Android端运行截图 点此查看）
► 在线体验下载：App Store安装地址 （另：Android端下载体验 点此查看）

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。

* RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架 MobileIMSDK 实现）。

v7.0 版更新内容

此版更新内容（更多历史更新日志）：

• 1）[新增] 新增了支持从相册中选取视频并发送；
• 2）[bug] 解决了代码中设置聊天界面中消息文字颜色无作用的问题；
• 3）[bug] 解决了聊天消息列表中查看短视频后返回时，最后一行消息被输入框档住的问题；
• 4）[bug] 解决了一处因后台任务未显式结束导致的潜在内存泄漏问题；
• 5）[bug] 当处于群聊界面是，群主更新群名称时，不能直接刷新群聊界面当前的标题上群名称的最新显示；
• 6）[优化] 登陆界面中，密码输入框增加了密文和明文切换显示功能；
• 7）[优化] 解决了iOS16.4+系统上因UIAlertView兼容性导致的某些功能中确认事件不能执行的问题；
• 8）[优化] 解决了从其它界面返回到注册界面的动画跳转时，原界面导航栏变成黑色块的问题；
• 9）[优化] 解决了聊天界面下方的功能面板打开状态下，再点“+” 号会切换到文本输入，而不是取消功能面板显示的问题；
• 10）[优化] 升级了图片选择库以适配最新的iOS系统；
• 11）[优化] 解决了聊天界面中发送大文件后，会立即弹出软键盘并进入文字输入状态的问题；
• 12）[优化] 查看图片界面中，长按弹出菜单效果UI美化；
• 13）[优化] 重新优化了闪屏、登录、帮助、忘记密码、注册、注册成功、查找用户、邀请朋友共计8个界面的UI设计；
• 14）[优化] 其它未提及的ui细节优化和美感提升。

此版部分界面更新（更多截图点此查看）：