本文作者潘堂磊，腾讯WXG（微商事业群）开发工程师，毕业于中山大学。内容已修改。
1、内容概览
本文总结了企业微信的IM消息系统架构设计，阐述了企业业务给IM架构设计带来的技术难点和挑战，以及技术方案的对比分析。同时总结了一些常用的IM后台开发方法，适用于IM消息系统。
*推荐阅读：企业微信团队分享的另一篇文章《企业微信客户端组织架构数据同步更新方案优化》也值得一读。
学习交流：
- 即时通讯/推送技术开发交流群5：215477170[推荐]
- 移动IM开发入门文章：《初学者入门：从零开始开发移动IM》
- 开源IM框架源码：
（本文同时发表于：）
2、词汇表
以下是本文内容所涉及的技术术语的缩写，具体含义如下：
3、技术背景
作为办公协作产品，微信消息是最基本的功能。消息系统的稳定性、可靠性和安全性尤为重要。
消息系统的构建和设计存在很多困难。而且toB场景的消息系统需要支持更复杂的业务场景。
toB场景的特殊服务包括：
4、整体架构设计一：架构分层
如上图，整体架构分层如下。
1）接入层：统一入口，接收客户端的请求，根据类型转发到对应的CGI层。客户端可以通过长连接或短连接连接到 wwproxy。对于活动客户端，首选长连接来发起请求。如果长连接失败，则使用短连接重试。
2）CGI层：http服务原创qq技术，从wwproxy接收数据包，验证用户会话状态，使用后台分发的秘钥解包。如果解密失败，请求被拒绝。如果解密成功，则将明文包体转发到后端逻辑层对应的svr。
3）逻辑层：大量的微服务和异步处理服务，使用自研的hikit rpc框架，svr之间使用tcp短连接进行通信。执行数据集成和逻辑处理。通过http协议与外部系统通信，包括微信互通、手机厂商推送平台等。
4）存储层：消息存储是基于levelDB模型msgkv开发的。 SeqSvr 是一个序列号生成器，它确保分派的 seq 是单调递增的，不会回滚。它用于消息发送和接收协议。
5、整体架构设计2：消息模型
企业微信的消息收发模型采用推挽方式，可靠性高，设计简单。
下面是消息的push和pull的时序图：
PS：如上图，发送方请求后台，将消息写入接收方存储，然后推送通知接收方。接收者收到推送后，主动上来后台接收消息。
不重、不丢失、及时访问，这三个是消息系统的核心指标：
6、整体架构设计3：消息扩散写作
在 IM 中有两种典型的消息分发方式：
6.1 扩散阅读
即每条消息只存储一份，群聊的所有成员读取相同的数据。
好处：节省存储容量。
缺点：
6.2 扩散写作
即每条消息存储多个副本，每个群聊成员在自己的存储中都有一个副本。
优点：
同一条消息在每个人的眼中会以不同的方式呈现。例如，对于一条回执消息，发送方可以看到已读和未读列表，而接收方只能看到是否已读的状态。从云端删除群组消息后，它会在自己的消息列表中消失，而其他消息仍然可见。
缺点：存储容量增加。
企业微信采用扩散写法，消息收发简单稳定。存储容量的增加可以通过冷热分离的方案来解决。冷数据存储在廉价的SATA磁盘中，扩散读取体验稍差，协议设计相对复杂。
下图为扩散写入的协议设计：
如上图：
7、系统稳定性设计一：灵活策略7.1 背景
企业微信作为to B场景的聊天IM工具，用于工作场景的交流，峰值效应比较明显（如下图）。
如上图：工作时间为9:00am~12:00pm0、14:00pm~18:00pm，是聊天的高峰期，消息量急剧增加。工作日和节假日也有明显的对比。
高峰期的高系统压力、偶尔的网络波动或机器过载都可能导致大量系统故障。 im系统对时效性要求比较高，不能进行削峰处理。那么就需要引入一些灵活的策略来保证系统的稳定性和可用性。
具体方法是启动过载保护策略：当svr达到最大处理能力时，表示处于过载状态，随着负载的增加，服务能力会急剧下降。如果 svr 过载，会拒绝一些正常的请求，以防止机器不堪重负，仍然能够对外服务。通过统计svr的调用时间和worker使用情况来判断svr是否处于过载状态。过载保护策略在请求高峰期保护系统，防止雪崩效应。
下图显示了由于过载而被拒绝的请求：
7.2 个问题
前面总结的过载保护策略导致的问题是：系统过载无法返回，前端消息无法显示，显示红点，会严重影响产品体验。
发送消息是im系统最基本的功能，可用性要求几乎是100%，所以这个策略必须优化。
7.3 个解决方案
解决思路是：即使失败，也返回前端成功，后端保证最终成功。
为了保证消息系统的可用性，避免高峰期系统过载故障导致前端出现红点，做了很多优化。
具体策略如下：
优化后，后台的波动基本不会被前端感知到。
以下是优化前后的流程对比：
8、系统稳定性设计2：系统解耦
由于产品形态的原因，企业微信的消息系统会依赖很多外部模块，甚至是外部系统。
例如：与微信消息通信，发送消息的权限需要由 ImUnion 确定。 ImUnion是外部系统，调用时间长。
再比如：金融版的消息审计功能需要将消息同步到审计模块，增加rpc调用。
再比如：客服单聊群聊消息，消息需要同步到crm模块，增加rpc调用。为了避免外部系统或外部模块出现故障，拖拽消息系统，增加耗时，需要对系统进行解耦。
我们的解决方案：与外部系统的所有交互都设计为异步的。
思考点：如何将需要同步返回结果的请求设计成异步的？
比如群聊消息需要经过ImUnion认证才能返回结果，前端用来显示消息是否发送成功。让客户端先成功，异步失败，然后回调客户端打个红点。
如果是非主进程，保证异步重试成功，主进程不受影响，比如消息审计同步功能。那么，只要保证内部系统的稳定性，发送消息的主要过程就不会受到影响。
解耦渲染：
9、系统稳定性设计3：业务隔离
企业微信有多种消息：
群聊根据群内人数分为3类：
服务很多，如果不隔离，其中一个服务的波动可能会导致整个消息系统的瘫痪。
最重要的一点：要保证核心环节的稳定性，也就是企业内部的单人聊天和100人以下的群聊，因为这个业务是最基础最敏感的稍有问题，投诉量就很大。
其他业务：相互隔离并减少参与。根据优先级和重要性进行隔离，同时调整相应的并发，尽可能保证核心环节的稳定性。
解耦和隔离的渲染：
10、To B业务功能设计与优化1：万人10.1技术背景
企业微信群成员上限为10,000。只要群里的每个人都发一条消息，传播就是10,000 * 10,000 = 1亿次调用，这是巨大的。
完成10000人的投递需要很长时间原创qq技术，影响消息的及时性。
10.2 问题分析
由于超群扩散写入量大且耗时，自然会考虑是否可以单独取出超群进行扩散读取。
我们来分析一下将超大组设计为单一副本所面临的困难：
总结一下，单副本方案太贵了。
下面将介绍我们为千人传播而编写的一些优化实践。
10.3 优化一：并发限制
10,000 人的传播范围很大。为了保证消息尽可能及时到达，使用了多协程来分发消息。但不是无限制地增加并发。
为了避免某万人群发消息高频次，对整个消息系统造成压力，消息分发是基于group id，限制了单个group的分发并发向一个人分发一条消息需要8ms，所以一万人的总时间是80s，并发限制是5，所以完成消息分发需要16s。耗时16s从产品角度看是可以接受的，大群对时效不敏感。同时将并发控制在合理范围内。
除了限制单个group id的并发外，还限制了数万人的整体并发。单台机器，小团体人数为250人，10000人团体人数为30人。
千人频繁发消息，worker数满，导致队列积压：
由于并发限制，调用次数变平，无请求无限增加，系统稳定：
10.4 优化2：合并插入
工作场景中的聊天多以小群进行，大群用于管理员发通知或老板发红包。
大群新闻有一个共同的模式：通常新闻很少，突然活跃起来。比如：老板在群里发个大红包，群里的人都在嘘，这时候就会产生很多消息。
消息量增加，并发受限，无法处理任务，所以队列自然会积压。积压中可能有多条消息需要分发给同一组的组成员。
此时：这些消息可以合并为一个请求写入消息存储，消息系统的吞吐量可以翻倍。
在日常监控中可以捕捉到这个场景，峰值可以同时插入20条消息，对整个系统非常友好。
10.5 优化3：业务降级
例如群人变动、群名变更、群设置变更等，都会在群内传播无形的控制信息。当群成员收到此控制消息时，会请求后台同步新数据。
例如：10000人的群中，由于消息频繁，对群员造成骚扰，部分群员选择退出群拒绝消息。假设有 1000 人选择退出群组。那么扩散的控制消息量为1000w，用户收到控制消息后向后台请求数据，带来额外的1000w数据请求，对系统造成巨大压力。
小群需要控制消息，让群成员实时感知群信息的变化。
但是在一个大群里：群信息的变化不是那么实时，用户感觉不到。因此，结合业务场景，实现降级服务，控制消息可以直接丢弃，不大群分发，减少对系统的调用。
11、To B业务功能设计与优化2：回执消息11.1技术背景
回执消息是办公场景中经常使用的功能。可以看到消息接收者的阅读状态。
回执消息的阅读状态会被频繁修改，群消息被修改的次数与群成员的数量成正比。每天数亿条消息，读写频繁，请求量巨大，很难保证每条消息的状态在接收方之间保持一致。
11.2 实施计划
消息的阅读状态存储有两种方案。
选项 1：
思路：使用消息存储，插入一条新消息指向旧消息，这条新消息具有最新的阅读状态。客户端收到新消息时，将旧消息的内容显示替换为新消息的内容，从而达到显示阅读状态的效果。
优点：多路复用消息通道，增量同步消息可以获取接收状态，多路复用通知机制和收发协议，前后端转换小。
缺点：
选项 2：
思路：独立存储每条消息的阅读状态，消息发送者通过消息id拉取数据。
优点：一致的状态。
缺点：
企业微信采用第一种方案，简单可靠，改动小：数据入盘时可以通过LevelDB合并存储冗余的问题，只需要最终状态的消息即可保留；一致性问题将在下文介绍如何解决。
上图是协议流程（referid：指向的消息id，senderid：消息发送者的msgid）：
11.3 优化一：异步
接收方已读取消息，客户端可以感知同步成功，但发送方的状态不需要同步修改。由于发送方的状态修改，接收方不知道。然后，可以采用异步策略来减少同步调用的耗时。
具体方法是：
11.4 优化2：合并处理
客户端收到大量消息，不是一条消息被读取并确认，而是多条消息一起被读取并确认。为了提高回执消息的处理效率，可以将多条消息合并处理。
如上图：
组合处理后，处理效率大大提高。下图是在线高峰期采集的通话数据。可以看出优化后的效果一共节省了44%的写入量。
11.5 读写覆盖解决方案
发送方的消息处理方式是先读取数据，修改后重写写入存储。如果有多个receiver，sender数据会并发写入，无法避免覆盖问题。
流程如下：
有几种方法可以处理此类问题。
方案一：因为并发操作是分布式的，所以可以使用分布式锁来保证一致性。操作存储前，先申请分布式锁。这个方案太重了，不适合这种高频多账号的场景。
选项 2：使用版本号读写。一个账号的消息流只有一个版本锁。在高频写入的场景下，容易出现版本冲突，导致写入效率低。
选项3：mq序列化处理。避免覆盖问题的关键是在合并场景中发挥好作用。同一账户的请求被序列化，即使有队列积压，组合策略也能提高处理效率。
企业微信采用方案3，相同id的用户请求串行处理，简单易实现，逻辑改动少。
12、To B业务功能设计与优化3：提现消息12.1技术难点
“撤回消息”相当于更新原始消息的状态。也可以被referid指向吗？
已分析回执消息：通过referid点，必须知道原始消息的msgid。
与接收消息不同：撤回消息需要修改所有收件人的消息状态，而不仅仅是发件人和单个收件人。消息扩散写入每个接收者的消息流，每个消息流对应的msgid不同。如果使用referid方式，需要记录所有receiver的msgid。
12.2 解决方案
分析：召回消息比回执消息更简单。调用消息只需要更新消息的状态，而不需要知道原始消息的内容。接收方消息的APPinfo是一样的，可以通过APPinfo指向。
协议流程：
该方案优点明显，可靠性高，协议简单。
召回消息示意图：
13、思考与总结
企业微信的IM消息结构与微信类似，但在to B业务场景中面临一些新的挑战。结合产品形态、分析策略、优化方案，保证消息系统的可靠性、稳定性和安全性。
企业微信to B业务复杂，定制需求多。消息系统的设计需要考虑通用性和可扩展性，以支持各种需求。例如，撤销消息的方案可以应用于消息任意属性的更新，满足更多场景。
附录：更多精选文章
[1] IM架构设计文章：
《IM系统架构设计》
《简述移动IM开发的坑：架构设计、通信协议和客户端》
《一套面向海量在线用户的移动端IM架构设计实践分享（含详细图片）》
《一种独创的分布式即时通讯（IM）系统理论架构方案》
《从零到卓越：京东客服即时通讯系统技术架构演进》
《蘑菇街即时通讯/IM服务器开发架构选择》
《腾讯QQ1.4亿在线用户PPT的技术挑战与架构演进》
《基于时间序列的海量数据冷热分层架构微信后台设计实践》
《微信技术总监谈架构：微信之道——极简之道（全文）》
《如何解读《微信技术总监谈架构：微信之道——极简之道》
《快速裂变：见证微信强大后台架构从0到1的演进（一）》
《17年实践：腾讯海量产品的技术方法论》
移动IM中大规模群消息推送的效率和实时性如何保证？ 》
《现代IM系统中聊天消息的同步与存储方案探讨》
《朋友圈千亿访问背后的技术挑战与实践总结》
《以微博应用场景为例，总结海量社交系统的架构设计步骤》
《弹幕短信背后：网易云信首席架构师分享亿级IM平台技术实践》
《IM开发基础知识补课》（五)：通俗易懂、正确理解和善用MQ消息队列”
《微信技术分享：微信群发IM聊天消息序列号生成实践（算法原理）》
《微信技术分享：微信群发IM聊天消息序列号生成实践（灾备方案）》
《初学者入门：零基础了解大规模分布式架构的演进历史、技术原理和最佳实践》
《一套高可用、易扩展、高并发的IM群聊、单聊架构设计实践》
《社交软件红包技术解密（一)：QQ红包技术方案综合解密-架构、技术实现等》
《解密社交软件红包技术（二)：微信摇红包解密从0到1的技术演进》
《社交软件红包技术解密（三)：微信背后的技术细节撼动红包雨》
《解密社交软件红包技术（四)：微信红包系统如何处理高并发》
《解密社交软件红包技术（五)：微信红包系统如何实现高可用》
《解密社交软件红包技术（六)：微信红包系统存储层架构演进实践》
《社交软件红包技术解密（七)：支付宝红包海量高并发技术实践》
《社交软件红包技术解密（八)：微博红包技术方案综合解密》
《解密社交软件红包技术（九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等）
《社交软件红包技术解密（十)：2020年春节红包手Q客户端技术实践》
《解密社交软件红包技术（十一)：解密微信红包随机算法（含代码实现）》
《即时通讯简介：一篇文章中的Nginx是什么？能实现IM负载均衡吗？》
《从游击队到正规军（一)：马蜂窝旅游网IM系统架构演进》
《从游击队到正规军（二)：马蜂窝旅游网IM客户端架构演进与实践总结》
《从游击队到正规军（三)：基于围棋的马蜂窝旅游网分布式IM系统技术实践》
《IM Development Fundamentals Supplementary Course (六): NoSQL or SQL for Database？读完就够了！》
《瓜子IM智能客服系统数据架构设计（现场演讲整理，附PPT）》
《阿里巴巴钉钉技术分享：企业IM之王——钉钉后端架构优势》
《微信后端基于时间序列的新一代海量数据存储架构设计实践》
《IM开发基础知识补课》（九)：想开发IM集群？先了解RPC是什么！”
《阿里技术分享：电商IM消息平台，群聊直播场景下的技术实践》
《亿万用户的一套IM架构技术干货（上）：整体架构、服务拆分等》
《亿万用户的一套IM架构技术干货（下）：可靠性、有序性、弱网优化等》
《从新手到专家：如何设计一个拥有 1 亿条消息的分布式 IM 系统》
[2] QQ、微信团队原创技术文章：
《朋友圈千亿访问背后的技术挑战与实践总结》
《腾讯技术分享：腾讯如何大幅降低带宽和网络流量（图片压缩）》
《腾讯技术分享：腾讯如何大幅降低带宽和网络流量（音视频技术）》
《微信团队分享：微信移动端全文检索多音字问题的解决方案》
《腾讯技术分享：安卓手Q缓存监控与优化实践》
《微信团队分享：iOS版微信高性能通用键值组件技术实践》
《微信团队分享：iOS版微信如何防止特殊字符引起的群爆和APP崩溃？ 》
《腾讯技术分享：安卓手机QQ线程死锁监控系统技术实践》
《微信团队原创分享：iOS版微信内存监控系统技术实践》
《让互联网更快：腾讯新一代QUIC协议技术实践分享》
《iOS后台唤醒实战：微信支付回执语音提醒技术总结》
《腾讯科技分享：社交网络图片带宽压缩技术演进》
《微信团队分享：视频图像超分辨率技术原理及应用场景》
《微信团队分享：破译微信每日数十亿实时音视频聊天背后的技术》
《QQ音乐团队分享：Android中图像压缩技术详解（上）》
《QQ音乐团队分享：Android中图像压缩技术详解（二）》
《腾讯团队分享：手Q人脸识别炫酷动画效果详解》
《腾讯团队分享：手Q聊天界面图片展示Bug追踪过程分享》
《微信团队分享：微信安卓版小视频编码填的坑》
《微信移动端本地数据全文检索优化》
《企业微信客户端架构数据同步更新同步》优化》
《微信团队披露：微信界面来龙去脉卡住超级Bug“15...”》
《QQ 18年：解密8亿月活跃QQ后台服务接口隔离技术》
《月活跃8.89亿超级IM微信如何进行安卓兼容性测试》
《以手Q为例，探讨手机IM中的“轻应用”》
《一文搞定微信开源移动数据库组件WCDB！》
《微信客户端组长技术专访：如何开始客户端性能监控与优化》
《基于时间序列的海量数据冷热分层架构微信后台设计实践》
《微信团队原创分享：Android微信的臃肿与模块化实践》
《微信后台团队：微信后台异步消息队列优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
"Tencent original sharing (一): How to greatly improve the picture transmission speed and success rate of mobile QQ under the mobile network"
"Tencent original sharing (二): How to greatly reduce the traffic consumption of APP under the mobile network (Part II)"
"Tencent original sharing (三): How to greatly reduce the traffic consumption of APP under the mobile network (Part 1)"
"WeChat Mars: The network layer encapsulation library being used inside WeChat will be open source soon"
"As promised: WeChat's own mobile IM network layer cross-platform component library Mars has been officially open source"
"Open source libco library: the cornerstone of the background framework that supports 10 million connections on a single machine and supports 800 million WeChat users [source code download]"
"WeChat Next-Generation Communication Security Solution: Detailed Explanation of MMTLS Based on TLS1.3"
"WeChat team original sharing: Android version WeChat background keep-alive actual combat sharing (process keep-alive)"
"WeChat team original sharing: Android version WeChat background keep-alive actual combat sharing (network keep-alive chapter)"
"Technical evolution of WeChat for Android from 300KB to 30MB (PPT presentation) [Attachment download]"
"WeChat Team Original Sharing: The Technological Evolution of Android WeChat from 300KB to 30MB"
"WeChat Technical Director Talking About Architecture: The Way of WeChat - The Great Way to Simple (full speech)"
"WeChat Technical Director Talking About Architecture: The Way of WeChat - The Great Way to Simple (PPT Lecture) [Attachment Download]"
"How to Interpret "WeChat Technical Director Talking About Architecture: The Way of WeChat - The Great Way to Simplicity"
"Background System Storage Architecture Behind Massive WeChat Users (Video + PPT) [Attachment Download]"
"WeChat Asynchronous Transformation Practice: The Background Solution Behind 800 Million Monthly Active Users and 10 Million Connections on a Single Machine"
"WeChat Moments Massive Technology PPT [Attachment Download]"
"Technical Experiment and Analysis of WeChat's Influence on the Internet (Full Paper)"
"A Summary Note on the Technical Architecture of Wechat Background"
"The Way of Architecture: 3 Programmers Achieve an Average Daily Publishing of 1 Billion in WeChat Moments [with Video]"
"Fast Fission: Witness the Evolution of Wechat's Powerful Background Architecture from 0 to 1 (一）"
"Fast Fission: Witness the Evolution of WeChat's Powerful Background Architecture from 0 to 1 (二）"
"WeChat Team Original Sharing: Summary of Android Memory Leak Monitoring and Optimization Skills"
"Comprehensive summary of the various "pits" encountered by the iOS version of WeChat to upgrade iOS9"
"WeChat Team Original Resource Obfuscation Tool: Make Your APK Instantly Reduce 1M"
"WeChat team's original Android resource obfuscation tool: AndResGuard [with source code]"
"The actual combat record of "WeChat installation package "weight loss" for Android version"
"iOS version of WeChat installation package "weight loss" actual combat record"
"Mobile IM practice: iOS version WeChat interface stuck monitoring plan"
"Technical Problems Behind WeChat "Red Packet Photos""
"Mobile IM Practice: A Record of the Technical Solution for the iOS Version of WeChat Small Video Function"
《Mobile IM Practice: How the Android version of WeChat greatly improves the interactive performance (一）》
《Mobile IM Practice: How the Android version of WeChat greatly improves the interactive performance (二）》
"Mobile IM Practice: Realizing the Intelligent Heartbeat Mechanism of Android WeChat"
"Mobile IM Practice: Analysis of Heartbeat Strategy of WhatsAPP, Line and WeChat"
"Mobile IM Practice: Research on Google Message Push Service (GCM) (from WeChat)"
"Mobile IM Practice: Discussion on the Multi-device Font Adaptation Scheme of WeChat for iOS"
"Original of the carrier pigeon team: walking through the pit of message push (APNS) on iOS10"
"Tencent carrier pigeon technology sharing: practical experience of tens of billions of real-time message push"
"Detailed explanation of IPv6 technology: basic concepts, application status, technical practice (Part 1)"
"Detailed explanation of IPv6 technology: basic concepts, application status, technical practice (Part II)"
"Tencent TEG Team Original: Ten Years of Forging Experience Sharing of MySQL-based Distributed Database TDSQL"
"Interview with WeChat Multimedia Team: Learning of Audio and Video Development, Audio and Video Technology and Challenges of WeChat, etc."
"Understanding iOS Message Push is enough: the most complete detailed explanation of iOS Push technology in history"
"Tencent Technology Sharing: The Story Behind WeChat Mini Program Audio and Video Technology"
"Summary of Tencent Senior Architect: Understanding All Aspects of Large-Scale Distributed System Design in One Article"
"Interview with Liang Junbin, Wechat Multimedia Team: Talking About Audio and Video Technology I Know"
"Tencent Audio and Video Lab: Using AI Black Technology to Realize Ultra-low Bit Rate HD Real-Time Video Chat"
"Tencent Technology Sharing: Technical Ideas and Practices for Interworking Wechat Mini Program Audio and Video and WebRTC"
"Teach you to read the chat records of Android version WeChat and mobile QQ (for technical research only)"
"WeChat Technology Sharing: WeChat Mass IM Chat Message Serial Number Generation Practice (Algorithm Principles)"
"WeChat Technology Sharing: WeChat Mass IM Chat Message Serial Number Generation Practice (Disaster Recovery Plan)"
"Tencent Technology Sharing: Detailed Explanation of GIF Animation Technology and Practice of Mobile QQ Dynamic Expression Compression Technology"
"WeChat team sharing: Kotlin is gradually recognized, the technology early adopter journey of Android version WeChat"
"QQ design team shared: the new version of QQ 8.0 The functional design ideas behind the revision of voice messages"
"WeChat Team Sharing: Extreme Optimization, Practical Summary of 3 Times Faster Compilation Speed of WeChat for iOS"
Is the IM "scanning" function easy to do? Take a look at the complete technical implementation of WeChat's "scanning to recognize things""
"WeChat Team Sharing: Thoughts on Mobile Software Architecture brought by WeChat Payment Code Refactoring"
"IM Development Collection: The Most Complete History, A Summary of Wechat's Various Function Parameters and Logical Rules"
"WeChat Team Sharing: The Evolution of 15 Million Online Message Architecture in WeChat Live Chat Room"
This article has been simultaneously published on the "Instant Messaging Technology Circle" public account.
▲ The link of this article on the official account is: Click here to enter. The sync release link is:
