企业微信的 IM 架构设计揭秘：消息模型、万人群、已读回执、消息撤回等
本文作者潘唐磊，腾讯 WXG（微信事业群）开发工程师，毕业于中山大学。内容有修订。
1、内容概述
本文总结了企业微信的 IM 消息系统架构设计，阐述了企业业务给 IM 架构设计带来的技术难点和挑战，以及技术方案的对比与分析。同时总结了 IM 后台开发的一些常用手段，适用于 IM 消息系统。
* 推荐阅读：企业微信团队分享的另一篇《企业微信客户端中组织架构数据的同步更新方案优化实战》也值得一读。
学习交流：
- 移动端 IM 开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源 IM 框架源码：https://github.com/JackJiang2011/MobileIMSDK
2、名词解释
以下是本文内容中涉及到的技术名词缩写，具体意义如下：
1）seq：自增长的序列号，每条消息对应一个（见：《微信的海量IM聊天消息序列号生成实践》）；
2）ImUnion：消息互通系统，用于企业微信与微信的消息打通；
3）控制消息：即控制指令，属不可见消息，是复用消息通道的一种可靠通知机制；
4）应用消息：系统应用下发的消息；
5）api 消息：第三方应用下发的消息；
6）appinfo：每条消息对应的唯一 strid，全局唯一。同一条消息的 appinfo 在所有的接收方中是相同的。
3、技术背景
企业微信作为一款办公协同的产品，聊天消息收发是最基础的功能。消息系统的稳定性、可靠性、安全性尤其重要。
消息系统的构建与设计的过程中，面临着较多的难点。而且针对 toB 场景的消息系统，需要支持更为复杂的业务场景。
针对 toB 场景的特有业务有：
1）消息鉴权：关系类型有群关系、同企业同事关系、好友关系、集团企业关系、圈子企业关系。收发消息双方需存在至少一种关系才允许发消息；
2）回执消息：每条消息都需记录已读和未读人员列表，涉及频繁的状态读写操作；
3）撤回消息：支持 24 小时的有效期撤回动作；
4）消息存储：云端存储时间跨度长，最长可支持 180 天消息存储，数百 TB 用户消息需优化，减少机器成本；
5）万人群聊：群人数上限可支持 10000 人，一条群消息就像一次小型的 DDoS 攻击；
6）微信互通：两个异构的 im 系统直接打通，可靠性和一致性尤其重要。
4、整体架构设计 1：架构分层
如上所示，整体架构分层如下。
1）接入层：统一入口，接收客户端的请求，根据类型转发到对应的 CGI 层。客户端可以通过长连或者短连连接 wwproxy。活跃的客户端，优先用长连接发起请求，如果长连失败，则选用短连重试。
2）CGI 层：http 服务，接收 wwproxy 的数据包，校验用户的 session 状态，并用后台派发的秘钥去解包，如解密失败则拒绝请求。解密成功，则把明文包体转发到后端逻辑层对应的 svr。
3）逻辑层：大量的微服务和异步处理服务，使用自研的 hikit rpc 框架，svr 之间使用 tcp 短连进行通信。进行数据整合和逻辑处理。和外部系统的通信，通过 http 协议，包括微信互通、手机厂商的推送平台等。
4）存储层：消息存储是采用的是基于 levelDB 模型开发 msgkv。SeqSvr 是序列号生成器，保证派发的 seq 单调递增不回退，用于消息的收发协议。
5、整体架构设计 2：消息收发模型
企业微信的消息收发模型采用了推拉方式，这种方式可靠性高，设计简单。
以下是消息推拉的时序图：
PS：如上图所示，发送方请求后台，把消息写入到接收方的存储，然后 push 通知接收方。接受方收到 push，主动上来后台收消息。
不重、不丢、及时触达，这三个是消息系统的核心指标：
1）实时触达：客户端通过与后台建立长连接，保证消息 push 的实时触达；
2）及时通知：如果客户端长连接不在，进程被 kill 了，利用手机厂商的推送平台，推送通知，或者直接拉起进程进行收消息；
3）消息可达：假如遇到消息洪峰，后台的 push 滞后，客户端有轮训机制进行兜底，保证消息可达；
4）消息防丢：为了防止消息丢失，只要后台逻辑层接收到请求，保证消息写到接收方的存储，失败则重试。如果请求在 CGI 层就失败，则返回给客户端出消息红点；
5）消息排重：客户端在弱网络的场景下，有可能请求已经成功写入存储，回包超时，导致客户端重试发起相同的消息，那么就造成消息重复。为了避免这种情况发生，每条消息都会生成唯一的 appinfo，后台通过建立索引进行排重，相同的消息直接返回成功，保证存储只有一条。
6、整体架构设计 3：消息扩散写
IM 中消息分发的典型方式，一般有两种：
1）扩散读；
2）扩散写。
6.1 扩散读
即：每条消息只存一份，群聊成员都读取同一份数据。
优点：节省存储容量。
缺点：
① 每个用户需存储会话列表，通过会话 id 去拉取会话消息；
② 收消息的协议复杂，每个会话都需要增量同步消息，则每个会话都需要维护一个序列号。
6.2 扩散写
即：每条消息存多份，每个群聊成员在自己的存储都有一份。
优点：
① 只需要通过一个序列号就可以增量同步所有消息，收消息协议简单；
② 读取速度快，前端体验好；
③ 满足更多 ToB 的业务场景：回执消息、云端删除。
同一条消息，在每个人的视角会有不同的表现。例如：回执消息，发送方能看到已读未读列表，接受方只能看到是否已读的状态。云端删除某条群消息，在自己的消息列表消失，其他人还是可见。
缺点：存储容量的增加。
企业微信采用了扩散写的方式，消息收发简单稳定。存储容量的增加，可以通过冷热分离的方案解决，冷数据存到廉价的 SATA 盘，扩散读体验稍差，协议设计也相对复杂些。
下图是扩散写的协议设计：
如上图所示：
1）每个用户只有一条独立的消息流。同一条消息多副本存在于每个用户的消息流中；
2）每条消息有一个 seq，在同个用户的消息流中，seq 是单调递增的；
3）客户端保存消息列表中最大 seq，说明客户端已经拥有比该 seq 小的所有消息。若客户端被 push 有新消息到达，则用该 seq 向后台请求增量数据，后台把比此 seq 大的消息数据返回。
7、系统稳定性设计 1：柔性策略
7.1 背景
企业微信作为一款 to B 场景的聊天 im 工具，用于工作场景的沟通，有着较为明显的高峰效应（如下图所示）。
正如上图所示：工作时间上午 9:00~12:00、下午 14:00~18:00，是聊天的高峰，消息量剧增。工作日和节假日也会形成明显的对比。
高峰期系统压力大，偶发的网络波动或者机器过载，都有可能导致大量的系统失败。im 系统对及时性要求比较高，没办法进行削峰处理。那么引入一些柔性的策略，保证系统的稳定性和可用性非常有必要。
具体的做法就是启动过载保护策略：当 svr 已经达到最大处理能力的时候，说明处于一个过载的状态，服务能力会随着负载的增高而急剧下降。如果 svr 过载，则拒绝掉部分正常请求，防止机器被压垮，依然能对外服务。通过统计 svr 的被调耗时情况、worker 使用情况等，判定是否处于过载状态。过载保护策略在请求高峰期间起到了保护系统的作用，防止雪崩效应。
下图就是因过载被拒绝掉的请求：
7.2 问题
上一小结中过载保护策略所带来的问题就是：系统过载返回失败，前端发消息显示失败，显示红点，会严重影响产品体验。
发消息是 im 系统的最基础的功能，可用性要求达到几乎 100%，所以这个策略肯定需要优化。
7.3 解决方案
解决方案思路就是：尽管失败，也返回前端成功，后台保证最终成功。
为了保证消息系统的可用性，规避高峰期系统出现过载失败导致前端出红点，做了很多优化。
具体策略如下：
1）逻辑层 hold 住失败请求，返回前端成功，不出红点，后端异步重试，直至成功；
2）为了防止在系统出现大面积故障的时候，重试请求压满队列，只 hold 住半小时的失败请求，半小时后新来的请求则直接返回前端失败；
3）为了避免重试加剧系统过载，指数时间延迟重试；
4）复杂的消息鉴权（好友关系，企业关系，集团关系，圈子关系），耗时严重，后台波动容易造成失败。如果并非明确鉴权不通过，则幂等重试；
5）为了防止作恶请求，限制单个用户和单个企业的请求并发数。例如，单个用户的消耗 worker 数超过 20%，则直接丢弃该用户的请求，不重试。
优化后，后台的波动，前端基本没有感知。
以下是优化前后的流程对比：
8、系统稳定性设计 2：系统解耦
由于产品形态的原因，企业微信的消息系统，会依赖很多外部模块，甚至外部系统。
例如：与微信消息互通，发送消息的权限需要放到 ImUnion 去做判定，ImUnion 是一个外部系统，调用耗时较长。
再如：金融版的消息审计功能，需要把消息同步到审计模块，增加 rpc 调用。
再如：客户服务的单聊群聊消息，需要把消息同步到 crm 模块，增加 rpc 调用。为了避免外部系统或者外部模块出现故障，拖累消息系统，导致耗时增加，则需要系统解耦。
我们的方案：与外部系统的交互，全设计成异步化。
思考点：需要同步返回结果的请求，如何设计成异步化？
例如：群聊互通消息需经过 ImUnion 鉴权返回结果，前端用于展示消息是否成功发送。先让客户端成功，异步失败，则回调客户端使得出红点。
如果是非主流程，则异步重试保证成功，主流程不受影响，如消息审计同步功能。那么，只需要保证内部系统的稳定，发消息的主流程就可以不受影响。
解耦效果图：
9、系统稳定性设计 3：业务隔离
企业微信的消息类型有多种：
1）单聊群聊：基础聊天，优先级高；
2）api 消息：企业通过 api 接口下发的消息，有频率限制，优先级中；
3）应用消息：系统应用下发的消息，例如公告，有频率限制，优先级中；
4）控制消息：不可见的消息。例如群信息变更，会下发控制消息通知群成员，优先级低。
群聊按群人数，又分成 3 类：
1）普通群：小于 100 人的群，优先级高；
2）大 群：小于 2000 人的群，优先级中；
3）万人群：优先级低。
业务繁多：如果不加以隔离，那么其中一个业务的波动有可能引起整个消息系统的瘫痪。
重中之重：需要保证核心链路的稳定，就是企业内部的单聊和 100 人以下群聊，因为这个业务是最基础的，也是最敏感的，稍有问题，投诉量巨大。
其余的业务：互相隔离，减少牵连。按照优先级和重要程度进行隔离，对应的并发度也做了调整，尽量保证核心链路的稳定性。
解耦和隔离的效果图：
10、to B 业务功能的设计与优化 1：万人群
10.1 技术背景
企业微信的群人数上限是 10000，只要群内每个人都发一条消息，那么扩散量就是 10000 * 10000 = 1 亿次调用，非常巨大。
10000 人投递完成需要的耗时长，影响了消息的及时性。
10.2 问题分析
既然超大群扩散写量大、耗时长，那么自然会想到：超大群是否可以单独拎出来做成扩散读呢。
下面分析一下超大群设计成单副本面临的难点：
① 一个超大群，一条消息流，群成员都同步这条流的消息；
② 假如用户拥有多个超大群，则需要同步多条流，客户端需维护每条流的 seq；
③ 客户端卸载重装，并不知道拥有哪些消息流，后台需存储并告知；
④ 某个超大群来了新消息，需通知所有群成员，假如 push 没触达，客户端没办法感知有新消息，不可能去轮训所有的消息流。
综上所述：单副本的方案代价太大。
以下将介绍我们针对万人群聊扩散写的方案，做的一些优化实践。
10.3 优化 1：并发限制
万人群的扩散量大，为了是消息尽可能及时到达，使用了多协程去分发消息。但是并不是无限制地加大并发度。
为了避免某个万人群的高频发消息，造成对整个消息系统的压力，消息分发以群 id 为维度，限制了单个群的分发并发度。消息分发给一个人的耗时是 8ms，那么万人的总体耗时是 80s，并发上限是 5，那么消息分发完成需要 16s。16s 的耗时，在产品角度来看还、是可以接受的，大群对及时性不敏感。同时，并发度控制在合理范围内。
除了限制单个群 id 的并发度，还限制了万人群的总体并发度。单台机，小群的 worker 数为 250 个，万人群的 worker 数为 30。
万人群的频繁发消息，worker 数用满，导致队列出现积压：
由于并发限制，调用数被压平，没有请求无限上涨，系统稳定：
10.4 优化 2：合并插入
工作场景的聊天，多数是在小群完成，大群用于管理员发通知或者老板发红包。
大群消息有一个常见的规律：平时消息少，会突然活跃。例如：老板在群里发个大红包，群成员起哄，此时就会产生大量的消息。
消息量上涨、并发度被限制、任务处理不过来，那么队列自然就会积压。积压的任务中可能存在多条消息需要分发给同一个群的群成员。
此时：可以将这些消息，合并成一个请求，写入到消息存储，消息系统的吞吐量就可以成倍增加。
在日常的监控中，可以捕获到这种场景，高峰可以同时插入 20 条消息，对整个系统很友善。
10.5 优化 3：业务降级
比如：群人员变更、群名称变动、群设置变更，都会在群内扩散一条不可见的控制消息。群成员收到此控制消息，则向后台请求同步新数据。
举个例子：一个万人群，由于消息过于频繁，对群成员造成骚扰，部分群成员选择退群来拒绝消息，假设有 1000 人选择退群。那么扩散的控制消息量就是 1000w，用户收到控制消息就向后台请求数据，则额外带来 1000w 次的数据请求，造成系统的巨大压力。
控制消息在小群是很有必要的，能让群成员实时感知群信息的变更。
但是在大群：群信息的变更其实不那么实时，用户也感觉不到。所以结合业务场景，实施降级服务，控制消息在大群可以直接丢弃、不分发，减少对系统的调用。
11、to B 业务功能的设计与优化 2：回执消息
11.1 技术背景
回执消息是办公场景经常用到的一个功能，能看到消息接受方的阅读状态。
一条回执消息的阅读状态会被频繁修改，群消息被修改的次数和群成员人数成正比。每天上亿条消息，读写频繁，请求量巨大，怎么保证每条消息在接受双方的状态是一致的是一个难点。
11.2 实现方案
消息的阅读状态的存储方式两个方案。
方案一：
思路：利用消息存储，插入一条新消息指向旧消息，此新消息有最新的阅读状态。客户端收到新消息，则用新消息的内容替换旧消息的内容展示，以达到展示阅读状态的效果。
优点：复用消息通道，增量同步消息就可以获取到回执状态，复用通知机制和收发协议，前后端改造小。
缺点：
① 存储冗余，状态变更多次，则需插入多条消息；
② 收发双方都需要修改阅读状态（接收方需标志消息为已读状态），存在收发双方数据一致性问题。
方案二：
思路：独立存储每条消息的阅读状态，消息发送者通过消息 id 去拉取数据。
优点：状态一致。
缺点：
① 构建可靠的通知机制，通知客户端某条消息属性发生变更；
② 同步协议复杂，客户端需要准确知道哪条消息的状态已变更；
③ 消息过期删除，阅读状态数据也要自动过期删除。
企业微信采用了方案一去实现，简单可靠、改动较小：存储冗余的问题可以通过 LevelDB 落盘的时候 merge 数据，只保留最终状态那条消息即可；一致性问题下面会介绍如何解决。
上图是协议流程（referid：被指向的消息 id，senderid：消息发送方的 msgid）：
1）每条消息都有一个唯一的 msgid，只在单个用户内唯一，kv 存储自动生成的；
2）接收方 b 已读消息，客户端带上 msgid=b1 请求到后台；
3）在接受方 b 新增一条消息，msgid=b2，referid=b1，指向 msgid=b1 的消息。并把 msgid=b2 的消息内容设置为消息已读。msgid=b1 的消息体，存有发送方的 msgid，即 senderid=a1；
4）发送方 a，读出 msgid=a1 的消息体，把 b 加入到已读列表，把新的已读列表保存到消息体中，生成新消息 msgid=a2，referid=a1，追加写入到 a 的消息流；
5）接收方 c 已读同一条消息，在 c 的消息流走同样的逻辑；
6）发送方 a，读出 msgid=a1 的消息体，把 c 加入到已读列表，把新的已读列表保存到消息体中，生成新消息 msgid=a3，referid=a1，追加写入到 a 的消息流。a3>a2，以 msgid 大的 a3 为最终状态。
11.3 优化 1：异步化
接受方已读消息，让客户端同步感知成功，但是发送方的状态没必要同步修改。因为发送方的状态修改情况，接受方没有感知不到。那么，可以采用异步化的策略，降低同步调用耗时。
具体做法是：
1）接受方的数据同步写入，让客户端马上感知消息已读成功；
2）发送方的数据异步写入，减少同步请求；
3）异步写入通过重试来保证成功，达到状态最终一致的目的。
11.4 优化 2：合并处理
客户端收到大量消息，并不是一条一条消息已读确认，而是多条消息一起已读确认。为了提高回执消息的处理效率，可以对多条消息合并处理。
如上图所示：
1）X>>A：表示 X 发了一条消息给 A；
2）A 合并确认 3 条消息，B 合并确认 3 条消息。那么只需要处理 2 次，就能标志 6 条消息已读；
3）经过 mq 分发，相同的发送方也可以合并处理。在发送方，X 合并处理 2 条消息，Y 合并处理 2 条消息，Z 合并处理 2 条消息，则合并处理 3 次就能标志 6 条消息。
经过合并处理，处理效率大大提高。下图是采集了线上高峰时期的调用数据。可以看得出来，优化后的效果一共节省了 44%的写入量。
11.5 读写覆盖解决
发送方的消息处理方式是先把数据读起来，修改后重新覆盖写入存储。接收方有多个，那么就会并发写发送方数据，避免不了出现覆盖写的问题。
流程如下：
1）发送方某条消息的已读状态是 X；
2）接收方 a 确认已读，已读状态修改为 X+a；
3）接收方 b 确认已读，已读状态修改为 X+b；
4）接收方 a 的状态先写入，接受方 b 的状态后写入。这最终状态为 X+b；
5）其实正确的状态是 X+a+b。
处理这类问题，无非就一下几种办法。
方案一：因为并发操作是分布式，那么可以采用分布式锁的方式保证一致。操作存储之前，先申请分布式锁。这种方案太重，不适合这种高频多账号的场景。
方案二：带版本号读写。一个账号的消息流只有一个版本锁，高频写入的场景，很容易产生版本冲突，导致写入效率低下。
方案三：mq 串行化处理。能避免覆盖写问题，关键是在合并场景起到很好的作用。同一个账号的请求串行化，就算出现队列积压，合并的策略也能提高处理效率。
企业微信采用了方案三，相同 id 的用户请求串行化处理，简单易行，逻辑改动较少。
12、to B 业务功能的设计与优化 3：撤回消息
12.1 技术难点
“撤回消息”相当于更新原消息的状态，是不是也可以通过 referid 的方式去指向呢？
回执消息分析过：通过 referid 指向，必须要知道原消息的 msgid。
区别于回执消息：撤回消息需要修改所有接收方的消息状态，而不仅仅是发送方和单个接收方的。消息扩散写到每个接收方的消息流，各自的消息流对应的 msgid 是不相同的，如果沿用 referid 的方式，那就需要记录所有接收方的 msgid。
12.2 解决方案
分析：撤回消息比回执消息简单的是，撤回消息只需要更新消息的状态，而不需要知道原消息的内容。接收方的消息的 appinfo 都是相同的，可以通过 appinfo 去做指向。
协议流程：
1）用户 a、b、c，都存在同一条消息，appinfo=s，sendtime=t；
2）a 撤回该消息，则在 a 的消息流插入一条撤回的控制消息，消息体包含{appinfo=s,sendtime=t}；
3）客户端 sync 到撤回的控制消息，获取到消息体的 appinfo 与 sendtime，把本地 appinfo=s 且 sendtime=t 的原消息显示为撤回状态，并删除原消息数据。之所以引入 sendtime 字段，是为了防止 appinfo 碰撞，加的双重校验；
4）接收方撤回流程和发送方一致，也是通过插入撤回的控制消息。
该方案的优点明显，可靠性高，协议简单。
撤回消息的逻辑示意图：
13、思考与总结
企业微信的 IM 消息架构与微信类似，但是在 to B 业务场景面临了一些新的挑战。结合产品形态、分析策略，通过优化方案，来确保消息系统的可靠性、稳定性、安全性。
企业微信的 to B 业务繁杂，有很多定制化的需求，消息系统的设计需要考虑通用性和扩展性，以便支持各种需求。例如：撤回消息的方案，可以适用于消息任何属性的更新，满足更多场景。
附录：更多精华文章
[1] 有关 IM 架构设计的文章：
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
《即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》
《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》
《一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等》
《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》
[2] QQ、微信团队原创技术文章：
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践》
《微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅》
《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》
《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》
《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》
《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》
《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》
《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》
本文已同步发布于“即时通讯技术圈”公众号。
还未添加个人签名 2019.08.26 加入
开源IM框架MobileIMSDK、BeautyEye的作者。
评论