相关链接：

• ① MobileIMSDK-鸿蒙端的详细介绍
• ② MobileIMSDK-鸿蒙端的开发手册new（* 精编PDF版）

一、理论知识准备

您需要对鸿蒙Next和ArkTS开发有所了解：

• 1）HarmonyOS NEXT星河版零基础入门到实战（B站视频）
• 2）零基础快速上手HarmonyOS ArkTS开发（系列文章）
• 3）HarmonyOS 第一课（鸿蒙官方视频教程）

您需要对WebSocket技术有所了解：

• 1）新手快速入门：WebSocket 简明教程
• 2）WebSocket 详解（一）：初步认识 WebSocket 技术
• 3）WebSocket 从入门到精通，半小时就够！
• 4）从零理解 WebSocket 的通信原理、协议格式、安全性
• 5）WebSocket详解（二）：技术原理、代码演示和应用案例
• 6）WebSocket详解（三）：深入WebSocket通信协议细节
• 7）WebSocket详解（四）：刨根问底HTTP与WebSocket关系(上)
• 8）WebSocket详解（五）：刨根问底HTTP与WebSocket关系(下)
• 9）WebSocket详解（六）：刨根问底WebSocket与Socket的关系

HTML5的标准WebSocket协议文档、API手册：

• 1）WebSocket 的 API 手册
• 2）WebSocket 的标准文档

鸿蒙Next的WebSocket文档和手册：

• 1）鸿蒙Next的WebSocket官方文档

小提示：鸿蒙Next中的WebSocket API跟标准HTML5中的WebSocket接口及用法略有不同，但主要API都能一一对应，相差不大。

二、开发工具准备

1）DevEco-Studio：

（JackJiang 使用的版本号如上图所示，为了方便直接引用工程，建议你也使用此版或较新版本）

2）一站式下载地址：鸿蒙官网下载地址 点此进入。（需要注册成为开发者才能下载哟！）

3）DevEco-Studio效果预览：

三、SDK 文件用途说明

3.1文件概览

纯ArkTS实现，无任何第3方库依赖，更无本地原生代码混编：

MobileIMSDK-鸿蒙端SDK本身只是ets文件源码的集合，自带的Demo代码只是为了方便随时测试SDK代码，目的主要是用于演示SDK的API调用，Demo代码不属于SDK框架的一部分。

大致的目录说明：

3.2详细说明

SDK 各模块/文件作用说明：

四、主要API接口和用途说明

* 主要API文档地址是：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/

1）ClientCoreSDK.getInstance().loginHasInit：

• 用途：是否已经完成过首次登陆。
• 说明 ：用户一旦从自已的应用中完成登陆IM服务器后，本方法就会一直返回true（直到退出登陆IM）。
• 返回值：{boolean}，true表示已完成首次成功登陆（即已经成功登陆过IM服务端了，后面掉线时不影响此标识），否则表示尚未连接IM服务器。

2）ClientCoreSDK.getInstance().connectedToServer：

• 用途：是否在线。
• 说明 ：表示网络连接是否正常。
• 返回值：{boolean}，true表示网络连接正常，否则表示已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。

3）ClientCoreSDK.getInstance().currentLoginInfo：

• 用途：保存登陆时提交的登陆信息（用户名、密码/token等）。
• 说明 ：格式形如：{loginUserId:'',loginToken:''}，此返回值的内容由调用登陆函数 loginImpl()时传入的内容决定。字段定义详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1697l。

4）ClientCoreSDK.getInstance().init(eventHub: common.EventHub): void：

• 用途：初始化SDK核心。
• 说明：不同于MobileIMSDK的iOS和Java客户端，本方法需要由开发者调用，以确保MobileIMSDK核心已被初始化完成。
• 本方法被调用后， #isInitialed() 将返回true，否则返回false。

5）ClientCoreSDK.getInstance().release(): void：

• 用途：保释放MobileIMSDK框架资源统一方法。
• 说明 ：本方法建议在退出登陆（或退出APP时）时调用。调用时将尝试关闭所有MobileIMSDK框架的后台守护线程并同设置核心框架init=false、loginHasInit=false、connectedToServer=false。

6）LocalDataSender.getInstance().sendLogin(loginInfo: PLoginInfo | undefined): number：

• 用途：发送登陆(连接)信息给服务端。
• 说明 ：不同于其它IM框架，本框架的登录和连接高度封装在了一个sendLogin方法中，无需单独再去connect服务器，大大简化了SDK的使用。loginInfo登陆信息各字段定义见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1697。

7）LocalDataSender.getInstance().sendLoginout(): number：

• 用途：发送注销登陆信息。
• 说明：此方法的调用将被本库理解为退出库的使用，本方法将会额外调用资源释放方法 ClientCoreSDK#release() ，以保证资源释放。本方法调用后，除非再次进行登陆过程，否则核心库将处于初始未初始化状态。

8）LocalDataSender.getInstance().sendCommonDataPlain(dataContentWidthStr: string, to_user_id: string, QoS: boolean = true, fingerPrint: string = '', typeu: number = -1): number：

• 用途：向某人发送一条消息。
• 参数dataContentWidthStr：要发送的数据内容（字符串方式组织）。
• 参数to_user_id：要发送到的目标用户id。
• 参数QoS ：true表示需QoS机制支持，否则不需要。
• 参数fingerPrint：QoS机制中要用到的指纹码（即消息包唯一id），可设为null，生成方法见 Protocal.genFingerPrint()。
• 参数typeu：应用层专用字段——用于应用层存放聊天、推送等场景下的消息类型。注意：此值为-1时表示未定义。MobileIMSDK框架中，本字段为保留字段，不参与框架的核心算法，专留作应用层自行定义和使用。
• 返回值：0表示数据发出成功，否则返回的是错误码，see ErrorCode。

9）LocalDataSender.getInstance().sendCommonData(p: Protocal): number：

• 用途：通用数据协议包的发送根方法。
• 参数p：{Protocal} 要发送的消息协议包对象，Protocal详情请见“/module/mb_constants.js”下的createCommonData函数说明。
• 返回值：0表示数据发出成功，否则返回的是错误码，see ErrorCode。

10）SocketEvent.SOCKET_EVENT_ON_RECIEVE_MESSAGE事件通知：

• 用途：以便收到聊天消息时在UI上展现出来（事件通知于收到IM消息时）。
• 推荐用法 ：开发者可在此通知中处理收到的各种IM消息。
• 参数1： {Protocal}：详情请见Protocal类定义：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1350。

11）SocketEvent.SOCKET_EVENT_ON_LOGIN_RESPONSE事件通知：

• 用途：本地用户的登陆结果回调事件通知（此事件发生时表示客户端已登陆/连接或重连完成）。
• 推荐用法：开发者可在此事件中处理登录连接和掉线重连响应反馈。
• 参数1： {PLoginInfoResponse}：API文档详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1434。

12）SocketEvent.SOCKET_EVENT_ON_LINK_CLOSE事件通知：

• 用途：与服务端的通信断开的回调事件通知（此事件发生时表示客户端已掉线）。
• 该消息只有在客户端连接服务器成功之后网络异常中断之时触发。导致与与服务端的通信断开的原因有（但不限于）：无线网络信号不稳定、WiFi与2G/3G/4G/5G等同开情况下的网络切换、手机系统的省电策略等。
• 推荐用法 ：开发者可在此通知中处理掉线时的界面状态更新等，比如设置将界面上的“在线”文字更新成“离线”。

13）SocketEvent.SOCKET_EVENT_PING事件通知：

• 用途：本地发出心跳包后的回调通知（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 推荐用法 ：开发者可在此回调中处理底层网络的活动情况。

14）SocketEvent.SOCKET_EVENT_PONG事件通知：

• 用途：收到服务端的心跳包反馈的回调通知（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 推荐用法 ：开发者可在此回调中处理底层网络的活动情况。

15）SocketEvent.SOCKET_EVENT_KICKOUT事件通知：

• 用途：收到服务端反馈的错误信息指令（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 参数1：{PKickoutInfo}：非空，详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1428。

16）SocketEvent.SOCKET_EVENT_ON_ERROR_RESPONSE事件通知：

• 用途：收到服务端反馈的错误信息指令（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 参数1：{PErrorResponse}：非空，详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1430。

17）SocketEvent.SOCKET_EVENT_RECONNECT_ATTEMPT事件通知：

• 用途：“自动重连尝试中”事件（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 参数 code ：{numeric}：0：已停止，1：持续运行中，2：单次脉搏

18）SocketEvent.SOCKET_EVENT_MESSAGE_LOST事件通知：

• 用途：消息未送达的回调事件通知。
• 发生场景：比如用户刚发完消息但网络已经断掉了的情况下，表现形式如：就像手机qq或微信一样消息气泡边上会出现红色图标以示没有发送成功）。
• 建议用途：应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送失败”以便即时告之用户。
• 参数1：{Array}：由框架的QoS算法判定出来的未送达消息列表。

19）SocketEvent.SOCKET_EVENT_MESSAGE_BE_RECIEVED事件通知：

• 用途：消息已被对方收到的回调事件通知。
• 说明 ：目前，判定消息被对方收到是有两种可能：1) 对方确实是在线并且实时收到了；2) 对方不在线或者服务端转发过程中出错了，由服务端进行离线存储成功后的反馈（此种情况严格来讲不能算是“已被收到”，但对于应用层来说，离线存储了的消息原则上就是已送达了的消息：因为用户下次登陆时肯定能通过HTTP协议取到）。
• 建议用途：应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送成功”以便即时告之用户。
• 参数1：{String}：已被收到的消息的指纹特征码（唯一ID），应用层可据此ID找到原先已发的消息并可在UI是将其标记为”已送达“或”已读“以便提升用户体验。

五、如何引入SDK库文件

5.1方法一：源码形式

第一步：先将整个sdk源码module复制到您的鸿蒙工程中：

第二步：配置您的工程，确保正确引用了MobileIMSDK鸿蒙SDK的源码module：

5.2方法二：.har包形式

第一步：先将MobileIMSDK鸿蒙端SDK的.har包放入您的鸿蒙Next主module中（比如新建的libs目录下）：

第二步：配置您的工程，确保正确引用了MobileIMSDK鸿蒙SDK的.har包：

六、如何调用SDK代码

6.1第一步：设置ws/wss连接URL

设置您自已部署的MobileIMSDK服务端IP或域名的（示例详见Demo中的 IMClientManager.ets 文件）：

提示：MobileIMSDK的服务端Demo部署指南请见 http://www.52im.net/thread-63-1-1.html。

6.2第二步：初始化SDK

调用ClientCoreSDK中的init()方法进行初始化（示例详见Demo中的I MClientManager.ets 文件）：

6.3第三步：注册框架事件

注册MobileIMSDK框架级的事件监听（示例详见Demo中的 IMClientManager.ets 文件）：

6.4第四步：调用登录方法（框架内部会自动启动connect全过程）

调用登录方法（示例详见Demo中的 LoginPage.ets 文件）：

提示：不同于其它IM框架，本框架的登录和连接高度封装在了一个sendLogin方法中，无需单独再去connect服务器，大大简化了SDK的使用。

七、Demo运行效果和功能说明

八、Demo运行方法

8.1重要说明

特别说明：MobileIMSDK的鸿蒙端工程（包括Demo代码），不依赖任何第3方库，也不存在任何Native代码混编，完全使用ArkTS、ArkUI官方标准API实现，所以你在拿到MobileIMSDK的鸿蒙端工程后直接开箱即可运行，切莫搞复杂、不要私自加戏！

8.2配置要连接的MobileIMSDK服务器IP

注意：下图中登陆连接的IP地址请设置为您自已的MobileIMSDK服务器地址哦。

友情提示： MobileIMSDK的服务端该怎么部署就不是本手册要讨论的内容了，你可以参见《即时通讯框架MobileIMSDK的Demo使用帮助：Server端》。

▲ 配置要连接的服务器IP（以上代码详见IMClientManager.ets文件）

8.3启动模拟器

注意：如果没有新建模拟器可以自已新建一个。另外也可以使用支持鸿蒙Next的真机，打开“开发者模式”并插入USB线即可使用。

▲ 点击绿色箭头，立即启动模拟器！

8.4一键运行

如下图所示，点击绿色“运行”按钮后，将自动在模拟器或真机里显示自带的Demo界面了：

8.5运行效果

1）Demo的登陆界面运行截图：

2）Demo的主界面运行截图：

3）Demo运行的同时，可以查看详细的log输出（方便调试）：

九、引用资料

[1] 鸿蒙Next官方开发资料

[2] MobileIMSDK开源框架的API文档

[3] MobileIMSDK开源IM框架源码（Github地址点此）

[4] MobileIMSDK-鸿蒙Next端发布公告

[5] MobileIMSDK-鸿蒙Next端详细介绍

[6] MobileIMSDK-鸿蒙Next端开发手册（* 精编PDF版）

[7] MobileIMSDK的Server端Demo使用帮助

本文来自微信团队工程师方乐明的技术分享，由InfoQ编辑发布，下文有修订和改动。

一、引言

微信红包业务量级的高速发展，对后台系统架构的可用性要求越来越高。在保障微信红包业务体验的前提下，红包后台系统进行了一系列高可用方面的优化设计。

本次分享介绍了微信红包后台系统的高可用实践经验，主要包括后台的 set 化设计、异步化设计、订单异地存储设计、存储层容灾设计与平行扩缩容等。听众可以了解到微信红包后台架构的设计细节，共同探讨高可用设计实践上遇到的问题与解决方案。

补充说明：本文对应的演讲PPT详见《微信红包系统可用性设计实践(PPT) [附件下载]》。

技术交流：

二、分享者

方乐明：现任微信支付应用产品系统负责人，主要从事微信红包、微信转账、微信群收款等支付应用产品的系统设计、可用性提升、高性能解决方案设计等，曾连续多年负责春节微信红包系统的性能优化与稳定性提升，取得良好的效果。

三、系列文章

系列文章目录：

• 《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
• 《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
• 《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
• 《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
• 《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》（* 本文）
• 《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
• 《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
• 《社交软件红包技术解密(八)：全面解密微博红包技术方案》
• 《社交软件红包技术解密(九)：谈谈手Q春节红包的设计、容灾、运维、架构等》
• 《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
• 《社交软件红包技术解密(十一)：最全解密微信红包随机算法(含演示代码)》
• 《社交软件红包技术解密(十二)：解密抖音春节红包背后的技术设计与实践》
• 《社交软件红包技术解密(十三)：微信团队首次揭秘微信红包算法，为何你抢到的是0.01元》

四、微信红包介绍

微信红包从 2014 年开始发展到现在，中间经历了几年时间。在这几年的时间里，整个系统可用性产生了很大的提升。2015 年年初的时候，每天晚上九点钟是微信红包的业务高峰期，系统经常性地出现性能问题。到了今天，即使在节假日高峰期，系统也不会出现问题。

▲ 红包印象 – 产品形态（点此查看本图出处）

如上图所示，微信红包的业务包含包、发、抢、拆、查询发送红包和收红包数量，其中最关键的步骤是发红包和抢红包。

微信红包是微信支付的商户，微信红包这个商户出售的是钱。发红包用户在微信红包平台使用微信支付购买一份钱，微信红包将钱发放到相对应的微信群。群里的用户抢红包得到微信零钱。这个过程中，微信红包和微信支付之间的关系是商家和第三方支付平台的关系。

微信红包和微信支付之间的交互，与普通商家与微信支付的交互一样，需要经过六个步骤。用户发红包时，进入微信红包下一笔订单，系统记录发红包用户、发红包金额、红包数量和要发送到的用微信群。然后微信红包系统请求微信支付服务器进行下单，用户使用微信支付进行支付。

支付成功后，微信支付后台系统通知微信红包后台系统支付成功结果，微信红包后台系统收到通知后推送微信红包消息到微信群。微信群里用户便可抢红包。这就是微信红包和微信支付的关系以及交互过程。

五、微信红包系统架构

5.1 微信红包的系统流程

▲ 微信红包的系统流程（点此查看本图出处）

上图是微信红包系统角度上的流程，业务主流程是包、发、抢、拆四个操作，每个操作包括几个关键步骤。

包红包：系统为每个红包分配一个唯一 ID，即红包发送订单号，然后将发红包用户、红包个数、红包数额写入存储，最后去微信支付下单。

发红包：用户使用微信支付完成付款，微信红包后台系统收到微信支付系统的支付成功通知。红包系统将红包发送订单状态更新为用户已支付，并写入用户发红包记录（用户发红包记录，就是微信钱包中，查看到的用户每一年总共发出及收到的红包记录）。最后微信红包后台系统发送微信红包消息到微信群。

抢红包：指微信群里的用户收到微信红包消息后，点开红包消息。这个过程，微信红包后台系统会检查红包是否已被抢完，是否已过期，是否已经抢过。

拆红包是最复杂的业务是操作，包括：

• 1）查询这个红包发送订单，判断用户是否可拆，然后计算本次可拆到的红包金额；
• 2）然后写入一条抢红包记录。如果把拆红包过程，类比为一个秒杀活动的过程，相当于扣库存与写入秒杀记录的过程；
• 3）更新库存对应于更新红包发送订单，写入秒杀记录对应于写入这个红包的领取红包记录；
• 4）另外，还要写入用户整体的红包领取记录；
• 5）最后请求微信支付系统给拆到红包用户转入零钱，成功后更新抢红包的订单状态为已转账成功。

5.2 微信红包的整体架构

▲ 微信红包的系统架构（点此查看本图出处）

上图所示，是微信红包的系统架构。包括微信统一接入层，下面是微信红包系统 API，包括发、抢、拆、查红包详情、查红包用户列表。再下面是封装微信红包关键业务的逻辑服务；最下面一层是数据存储层，微信红包最主要的数据是订单数据，包括发红包订单和拆红包订单两部分。业务逻辑和存储服务器之间是数据接入层，它最重要的作用是封装数据库操作的领域逻辑，使得业务逻辑服务不需要感知对 MySQL 的连接管理、性能、容灾等问题。

微信红包数据的访问热度，随着时间流逝会急剧降低，也就是数据的访问时间段非常集中，一般红包发出三天后，99% 的用户不会再去点开这个红包了。因此微信红包系统采取按时间做冷热数据分离，降低数据的存储成本，同时提升了热数据的访问性能。

数据平台用于对红包数据的分析计算，比如朋友圈里的文章，统计从 某年 1 月 1 日到 2017 年 1 月一个用户总共抢红包的金额，在全国的排名情况，发红包数最多的城市等。另外一个作用就是对账，红包的订单和微信支付的订单需要对账，以保证最终资金的一致性；订单的数据和订单的 cache 需要做对账，以保证数据的完整性；订单数据和用户的收发记录需要对账，以保证用户列表完整性。

六、微信红包系统可用性实践

6.1系统可用性影响因素

系统的可用性影响因素可分成两类：

• 一类计划外；
• 一类计划内。

计划外包含很多因素，系统用到的所有东西都可能产生故障，都可能成功影响可用性的因素。从这个角度上来讲，可以说故障是无法避免的，系统的运作一定会产生故障，尤其是服务器有成千上万个的时候。计划内的影响因素，主要有与升级相关、运维相关的操作，以及日常的备份等。这一类影响因素，通过精细地设计方案，是可以避免对可用性造成影响的。

6.2微信红包系统可用性设计方向

基于上面两个分析结论，可以总结出微信红包后台系统的可用性的设计方向。就是在不能避免意外故障的情况下，尽可能降低出现意外故障时对可用性的影响。另一方面，绝大多数计划内的日常维护可以通过方案的设计避免影响可用性，其中平行扩容特指关于存储层的平行扩容。

下面从降低故障影响和微信红包系统的平行扩容两方面进行分析。

首先是降低意外故障的影响，重点讲解订单存储层在订单 DB 故障的情况下如何降低对红包系统可用性的影响。

6.3业务逻辑层 - 部署方案设计

首先是业务逻辑层的部署方案。业务逻辑层是无状态的，微信红包系统的业务逻辑层，部署在两个城市，即两地部署，每一个城市部署至少三个园区，即三个 IDC。并且每个服务需要保证三个 IDC 的部署均衡。另外，三个 IDC 总服务能力需要冗余三分之一，当一个 IDC 出现故障时，服务能力仍然足够。从而达到 IDC 故障不会对可用性产生影响。

6.4业务逻辑层 - 异步化设计

▲ 业务逻辑层 – 异步化（点此查看本图出处）

第二是异步化设计。如上图所示，微信红包的某些步骤不实时完成也不会影响用户对红包业务可用性的体验。比如拆红包，正常的业务流程很长，但关键步骤只有订单相关的几步。至于转零钱、写红包记录等操作不需要实时。用户抢到红包时，一般不会实时去钱包查看微信零钱，而是在微信群中点开消息查看本次抢到金额和他人抢红包金额。所以拆红包时只需要从 cache 查询用户是否拆过红包，然后写入拆红包的订单记录，更新发红包订单，其他的操作都可以异步化。当然，不是每个业务都可以进行异步化设计，需要进行业务分析，判断是否存在非关键步骤之外的事情可以将其异步化，并通过异步对账保证最终一致。

▲ 订单存储层 – 早期架构（点此查看本图出处）

接下来是微信红包订单存储设计。上图是 2014 年微信红包存储层的模型。业务逻辑层请求数据层操作时，使用订单号 hash 路由到订单 SERVER。订单 SERVER 与每一组 MYSQL 数据库连接。

微信红包的订单号是在发红包时系统生成唯一标识，使用序列号服务生成唯一 ID，后面拼接三位微信红包的订单分库表的标识。所以，总共可以分一百个逻辑库，每个逻辑库含有十张表。一百个逻辑库均匀地分布到十组物理 DB，每组 DB 存十个逻辑库。

这个架构的最大问题是，一组 DB 故障时，会影响其他 DB。2014-2015 年期间，微信红包量涨得特别快，扩容速度跟不上业务增长速度。一组 DB 的性能出现瓶颈时，数据操作变慢, 拆红包的事务操作在 MYSQL 排队等待。由于所有十组 DB 机器与所有的订单 SERVER 连接，导致所有的订单 SERVER 都被拖住，从而影响红包整体的可用性。这个架构的另一个问题是扩容不方便，后面会介绍。

为解决 DB 间的相互影响，需要将 DB 间相互隔离，订单存储层 SET 化。SET 化指订单 DB 和订单接入 SERVER 垂直 stick 一起。业务逻辑层访问订单时，根据订单倒数第二、三位数字找到所属订单 SET，一个 SET 的请求不能路由到其他 SET。

找到对应的订单接入服务器之后，在服务器内的多个进程中找到指定进程，让同个红包的所有拆请求串行化。当一组 DB 出现故障，只会影响该组 DB 对应的 SERVER。

这里有一个问题，DB 故障拖住某些订单 SERVER，会不会也拖住更上层业务逻辑服务？业务逻辑层为什么不一起 SET 化？业务逻辑层承载了用户维度相关的业务操作，不可以按照订单的维度分业务逻辑，例如务逻辑层会请求用户的头像、昵称等，如果继续按照订单分业务逻辑，会导致跨地域调用。

微信红包系统采取的方案是，在订单 SERVER 服务端增加快速拒绝服务的能力。SERVER 主动监控 DB 的性能情况，DB 性能下降、自身的 CPU 使用升高，或者发现其他的监控维度超标时，订单 SERVER 直接向上层报错，不再去访问 DB，以此保证业务逻辑层的可用性。

一组 DB 故障不会影响整个系统的可用性。有影响的，只有十分之一，若扩成 100 组，影响便只有一百分之一。所以通过 SET 化得到的好处是，控制 DB 连接数、隔离故障影响和分流并发。

▲ 订单存储层 – 故障自愈（点此查看本图出处）

完成 SET 化之后，DB 故障仍对业务有十分之一影响，那么这十分之一该怎么解决？通过对系统进行研究分析之后，发现 DB 可以做到故障自愈。

如上图所示，所设尾号 90-99 的 SET 故障时，如果业务逻辑服务后续不再生成属于这个 SET 的订单，那后续的业务就可以逐渐恢复。

也就是在发生故障时，业务逻辑层发布一个版本，屏蔽故障号段的单号生成，就可以恢复业务。进一步想，除了人为发版本，有没有方法可以让 DB 故障时自动恢复？在 DB 故障导致业务失败时，业务逻辑层可获取到故障 DB 的号段，在发红包时，将这些故障的号段，换一个可用的号段就可恢复业务。订单号除了最后三位，前面的部分已能保证该红包唯一性，后面的数字只代表着分库表信息，故障时只需要将最后三位换另外一个 SET 便可自动恢复。

完成这个设计后，即使 DB 出现故障，业务的可用性也不会有影响。这里还有一点，新的发红包请求可避免 DB 故障的影响，但那些故障之前已发出未被领取的红包，红包消息已发送到微信群，单号已确定，拆红包时还是失败。对这种情况，由于不会有增量，采用正常的主备切换解决即可。

6.5平行扩缩容设计

▲ 平行扩缩容 – 早期方案（点此查看本图出处）

上图是微信红包早期的扩缩容方式。这个扩容方式，对扩容的机器数有限制。前面讲到，红包系统按红包单号后面两个数字分多 SET，为了使扩容后数据保持均衡，扩容只能由 10 组 DB 扩容到 20 组、50 组或者 100 组。另外，这个扩容方式，过程也比较复杂。首先，数据要先从旧数据库同步复制到新扩容的 DB，然后部署 DB 的接入 SERVER，最后在凌晨业务低峰时停服扩容。

这个扩容方式的复杂性，根本原因是数据需要从旧 SET 迁到新 SET。如果新产生数据与旧数据没关系，那么就可以省掉这部分的迁移动作，不需停服输。分析发现，需要把旧数据迁出来的原因是订单号段 00-99 已全部被用，每个物理数据库包含了 10 个逻辑库。如果将订单号重新设计，预留三位空间，三位数字每一个代表独立的物理 DB，原来 10 组 DB 分别为 000-009 号段。

这种设计，缩容时，比如要缩掉 000 这组，只需在业务逻辑服务上不生成订单号为 000 的红包订单。扩容时，比如扩为 11 组，只需多生成 010 的订单号，这个数据便自动写入新 DB。当然，缩容需要一个前提条件，也就是冷热分离，缩容后数据变为冷数据，可下线热数据机器。以上就是红包的平行扩缩容方案。

▲ 改进后的平行扩容（点此查看本图出处）

七、写在最后

微信红包系统的可用性实践，主要包括了部署设计、SET 化设计、异步化设计、DB 故障自愈能力建设、平行扩容设计。在完成这些设计后，微信红包系统的可用性得到了很大提升，在 近几年的春节实现了 0 故障，在平常的运行中达到 99.99% 可用性。

（原文链接：点此进入）

八、更多鹅厂技术文章汇总

《微信朋友圈千亿访问量背后的技术挑战和实践总结》

《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》

《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》

《IM全文检索技术专题(二)：微信移动端的全文检索多音字问题解决方案》

《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》

《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》

《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》

《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》

《微信团队原创分享：iOS版微信的内存监控系统技术实践》

《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》

《iOS后台唤醒实战：微信收款到账语音提醒技术总结》

《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》

《微信团队分享：视频图像的超分辨率技术原理和应用场景》

《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》

《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》

《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》

《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》

《腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践》

《微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅》

《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》

《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》

《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》

《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》

《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》

《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》

《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》

《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》

《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》

《社交软件红包技术解密(十三)：微信团队首次揭秘微信红包算法，为何你抢到的是0.01元》

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

本文来自微信团队工程师方乐明的技术分享，由InfoQ编辑发布，下文收录时有修订和改动。

一、引言

每年节假日，微信红包的收发数量都会暴涨，尤以除夕为最。如此大规模、高峰值的业务需要，背后需要怎样的技术支撑？百亿级别的红包规模，如何保证并发性能与资金安全？

本文将为读者介绍微信百亿级别红包背后的高并发设计实践，内容包括微信红包系统的技术难点、解决高并发问题通常使用的方案，以及微信红包系统的所采用高并发解决方案。

技术交流：

二、分享者

方乐明：现任微信支付应用产品系统负责人，主要从事微信红包、微信转账、微信群收款等支付应用产品的系统设计、可用性提升、高性能解决方案设计等，曾连续多年负责春节微信红包系统的性能优化与稳定性提升，取得良好的效果。

三、系列文章

❶ 系列文章目录：

• 《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
• 《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
• 《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
• 《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》（* 本文）
• 《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
• 《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
• 《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
• 《社交软件红包技术解密(八)：全面解密微博红包技术方案》
• 《社交软件红包技术解密(九)：谈谈手Q春节红包的设计、容灾、运维、架构等》
• 《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
• 《社交软件红包技术解密(十一)：最全解密微信红包随机算法(含演示代码)》
• 《社交软件红包技术解密(十二)：解密抖音春节红包背后的技术设计与实践》
• 《社交软件红包技术解密(十三)：微信团队首次揭秘微信红包算法，为何你抢到的是0.01元》

❷ 其它相关文章：

• 《技术往事：“QQ群”和“微信红包”是怎么来的？》
• 《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》
• 《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
• 《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
• 《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
• 《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
• 《如何解读《微信技术总监谈架构：微信之道——大道至简》》
• 《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
• 《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
• 《微信朋友圈海量技术之道PPT [附件下载]》
• 《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
• 《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
• 《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
• 《微信“红包照片”背后的技术难题》
• 《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
• 《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》

四、微信红包的两大业务特点

微信红包（尤其是发在微信群里的红包，即群红包），业务形态上很类似网上的普通商品“秒杀”活动。

就像下面这样：

• 1）用户在微信群里发一个红包，等同于是普通商品“秒杀”活动的商品上架；
• 2）微信群里的所有用户抢红包的动作，等同于“秒杀”活动中的查询库存；
• 3）用户抢到红包后拆红包的动作，则对应“秒杀”活动中用户的“秒杀”动作。

不过除了上面的相同点之外，微信红包在业务形态上与普通商品“秒杀”活动相比，还具备自身的特点。

首先：微信红包业务比普通商品“秒杀”有更海量的并发要求。

微信红包用户在微信群里发一个红包，等同于在网上发布一次商品“秒杀”活动。假设同一时间有 10 万个群里的用户同时在发红包，那就相当于同一时间有 10 万个“秒杀”活动发布出去。10 万个微信群里的用户同时抢红包，将产生海量的并发请求。

其次：微信红包业务要求更严格的安全级别。

微信红包业务本质上是资金交易。微信红包是微信支付的一个商户，提供资金流转服务。

用户发红包时，相当于在微信红包这个商户上使用微信支付购买一笔“钱”，并且收货地址是微信群。当用户支付成功后，红包“发货”到微信群里，群里的用户拆开红包后，微信红包提供了将“钱”转入折红包用户微信零钱的服务。

资金交易业务比普通商品“秒杀”活动有更高的安全级别要求。普通的商品“秒杀”商品由商户提供，库存是商户预设的，“秒杀”时可以允许存在“超卖”（即实际被抢的商品数量比计划的库存多）、“少卖”（即实际被抢的商户数量比计划的库存少）的情况。但是对于微信红包，用户发 100 元的红包绝对不可以被拆出 101 元；用户发 100 元只被领取 99 元时，剩下的 1 元在 24 小时过期后要精确地退还给发红包用户，不能多也不能少。

以上是微信红包业务模型上的两大特点。

五、 微信红包系统的技术难点

在介绍微信红包系统的技术难点之前，先介绍下简单的、典型的商品“秒杀”系统的架构设计，如下图所示。

该系统由接入层、逻辑服务层、存储层与缓存构成：

• 1）Proxy 处理请求接入；
• 2）Server 承载主要的业务逻辑；
• 3）Cache 用于缓存库存数量；
• 4）DB 则用于数据持久化。

一个“秒杀”活动，对应 DB 中的一条库存记录。当用户进行商品“秒杀”时，系统的主要逻辑在于 DB 中库存的操作上。

一般来说，对 DB 的操作流程有以下三步：

• 1）锁库存；
• 2）插入“秒杀”记录；
• 3）更新库存。

其中，锁库存是为了避免并发请求时出现“超卖”情况。同时要求这三步操作需要在一个事务中完成（所谓的事务，是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行）。

“秒杀”系统的设计难点就在这个事务操作上。商品库存在 DB 中记为一行，大量用户同时“秒杀”同一商品时，第一个到达 DB 的请求锁住了这行库存记录。在第一个事务完成提交之前这个锁一直被第一个请求占用，后面的所有请求需要排队等待。同时参与“秒杀”的用户越多，并发进 DB 的请求越多，请求排队越严重。因此，并发请求抢锁，是典型的商品“秒杀”系统的设计难点。

微信红包业务相比普通商品“秒杀”活动，具有海量并发、高安全级别要求的特点。

在微信红包系统的设计上，除了并发请求抢锁之外，还有以下两个突出难点：

首先，事务级操作量级大：

上文介绍微信红包业务特点时提到，普遍情况下同时会有数以万计的微信群在发红包。这个业务特点映射到微信红包系统设计上，就是有数以万计的“并发请求抢锁”同时在进行。这使得 DB 的压力比普通单个商品“库存”被锁要大很多倍；

其次，事务性要求严格：

微信红包系统本质上是一个资金交易系统，相比普通商品“秒杀”系统有更高的事务级别要求。

六、解决高并发问题通常使用的方案

普通商品“秒杀”活动系统，解决高并发问题的方案，大体有以下几种。

6.1方案一：使用内存操作替代实时的 DB 事务操作

如图 2 所示，将“实时扣库存”的行为上移到内存 Cache 中操作，内存 Cache 操作成功直接给 Server 返回成功，然后异步落 DB 持久化。

这个方案的优点是用内存操作替代磁盘操作，提高了并发性能。

但是缺点也很明显，在内存操作成功但 DB 持久化失败，或者内存 Cache 故障的情况下，DB 持久化会丢数据，不适合微信红包这种资金交易系统。

6.2方案二：使用乐观锁替代悲观锁

所谓悲观锁，是关系数据库管理系统里的一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作对某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。对应于上文分析中的“并发请求抢锁”行为。

所谓乐观锁，它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。

商品“秒杀”系统中，乐观锁的具体应用方法，是在 DB 的“库存”记录中维护一个版本号。在更新“库存”的操作进行前，先去 DB 获取当前版本号。在更新库存的事务提交时，检查该版本号是否已被其他事务修改。如果版本没被修改，则提交事务，且版本号加 1；如果版本号已经被其他事务修改，则回滚事务，并给上层报错。

这个方案解决了“并发请求抢锁”的问题，可以提高 DB 的并发处理能力。

但是如果应用于微信红包系统，则会存在下面三个问题：

• 1）如果拆红包采用乐观锁：那么在并发抢到相同版本号的拆红包请求中，只有一个能拆红包成功，其他的请求将事务回滚并返回失败，给用户报错，用户体验完全不可接受；
• 2）如果采用乐观锁：将会导致第一时间同时拆红包的用户有一部分直接返回失败，反而那些“手慢”的用户，有可能因为并发减小后拆红包成功，这会带来用户体验上的负面影响；
• 3）如果采用乐观锁的方式：会带来大数量的无效更新请求、事务回滚，给 DB 造成不必要的额外压力。

基于以上原因，微信红包系统不能采用乐观锁的方式解决并发抢锁问题。

七、微信红包系统的高并发解决方案

综合上面的分析，微信红包系统针对相应的技术难点，采用了下面几个方案，解决高并发问题。

7.1系统垂直 SET 化，分而治之

微信红包用户发一个红包时，微信红包系统生成一个 ID 作为这个红包的唯一标识。接下来这个红包的所有发红包、抢红包、拆红包、查询红包详情等操作，都根据这个 ID 关联。

红包系统根据这个红包 ID，按一定的规则（如按 ID 尾号取模等），垂直上下切分。切分后，一个垂直链条上的逻辑 Server 服务器、DB 统称为一个 SET。

各个 SET 之间相互独立，互相解耦。并且同一个红包 ID 的所有请求，包括发红包、抢红包、拆红包、查详情详情等，垂直 stick 到同一个 SET 内处理，高度内聚。通过这样的方式，系统将所有红包请求这个巨大的洪流分散为多股小流，互不影响，分而治之，如下图所示。

这个方案解决了同时存在海量事务级操作的问题，将海量化为小量。

7.2逻辑 Server 层将请求排队，解决 DB 并发问题

红包系统是资金交易系统，DB 操作的事务性无法避免，所以会存在“并发抢锁”问题。但是如果到达 DB 的事务操作（也即拆红包行为）不是并发的，而是串行的，就不会存在“并发抢锁”的问题了。

按这个思路，为了使拆红包的事务操作串行地进入 DB，只需要将请求在 Server 层以 FIFO（先进先出）的方式排队，就可以达到这个效果。从而问题就集中到 Server 的 FIFO 队列设计上。

微信红包系统设计了分布式的、轻巧的、灵活的 FIFO 队列方案。其具体实现如下：

首先，将同一个红包 ID 的所有请求 stick 到同一台 Server。

上面 SET 化方案已经介绍，同个红包 ID 的所有请求，按红包 ID stick 到同个 SET 中。不过在同个 SET 中，会存在多台 Server 服务器同时连接同一台 DB（基于容灾、性能考虑，需要多台 Server 互备、均衡压力）。

为了使同一个红包 ID 的所有请求，stick 到同一台 Server 服务器上，在 SET 化的设计之外，微信红包系统添加了一层基于红包 ID hash 值的分流，如下图所示。

其次，设计单机请求排队方案。

将 stick 到同一台 Server 上的所有请求在被接收进程接收后，按红包 ID 进行排队。然后串行地进入 worker 进程（执行业务逻辑）进行处理，从而达到排队的效果，如下图所示。

最后，增加 memcached 控制并发。

为了防止 Server 中的请求队列过载导致队列被降级，从而所有请求拥进 DB，系统增加了与 Server 服务器同机部署的 memcached，用于控制拆同一个红包的请求并发数。

具体来说，利用 memcached 的 CAS 原子累增操作，控制同时进入 DB 执行拆红包事务的请求数，超过预先设定数值则直接拒绝服务。用于 DB 负载升高时的降级体验。

通过以上三个措施，系统有效地控制了 DB 的“并发抢锁”情况。

7.3双维度库表设计，保障系统性能稳定

红包系统的分库表规则，初期是根据红包 ID 的 hash 值分为多库多表。随着红包数据量逐渐增大，单表数据量也逐渐增加。而 DB 的性能与单表数据量有一定相关性。当单表数据量达到一定程度时，DB 性能会有大幅度下降，影响系统性能稳定性。采用冷热分离，将历史冷数据与当前热数据分开存储，可以解决这个问题。

处理微信红包数据的冷热分离时，系统在以红包 ID 维度分库表的基础上，增加了以循环天分表的维度，形成了双维度分库表的特色。

具体来说，就是分库表规则像 db_xx.t_y_dd 设计，其中，xx/y 是红包 ID 的 hash 值后三位，dd 的取值范围在 01~31，代表一个月天数最多 31 天。

通过这种双维度分库表方式，解决了 DB 单表数据量膨胀导致性能下降的问题，保障了系统性能的稳定性。同时，在热冷分离的问题上，又使得数据搬迁变得简单而优雅。

综上所述：微信红包系统在解决高并发问题上的设计，主要采用了 SET 化分治、请求排队、双维度分库表等方案，使得单组 DB 的并发性能提升了 8 倍左右，取得了很好的效果。

八、本文小结

微信红包系统是一个高并发的资金交易系统，最大的技术挑战是保障并发性能与资金安全。

这种全新的技术挑战，传统的“秒杀”系统设计方案已不能完全解决。在分析了业界“秒杀”系统解决方案的基础上，微信红包采用了 SET 化、请求排队串行化、双维度分库表等设计，形成了独特的高并发、资金安全系统解决方案，并在平时节假日、春节红包雨实践中充分证明了可行性，取得了显著的效果。以2017 鸡年除夕夜为例，微信红包收发峰值达到 76 万每秒，收发微信红包 142 亿个，微信红包系统的表现稳定，实现了除夕夜系统零故障。

九、更多鹅厂技术文章汇总

《微信朋友圈千亿访问量背后的技术挑战和实践总结》

《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》

《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》

《IM全文检索技术专题(二)：微信移动端的全文检索多音字问题解决方案》

《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》

《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》

《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》

《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》

《微信团队原创分享：iOS版微信的内存监控系统技术实践》

《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》

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

本文由腾讯技术团队原创分享于鹅厂黑板报，下文有排版优化。

1、写在前面

直至现在，「微信鸿蒙版」这五个字，依然被赋予着太多意义。

这是一款产品，也不仅仅是一款产品。开发它的本质，是让两个高速前进，相互影响的复杂系统，彼此磨合和熟悉，像是执行一场空中加油任务。

不管外界如何评价和鞭策，这款产品本身，依然需要研发团队一个键一个键敲出来，从内核，到架构，到内测，到公测，再到一轮一轮的 debug，他们要在不到一年的时间里，走完微信14 年的路。

回顾鹅厂所做过的产品里，也许从未有过一款，被如此放在放大镜下凝视。每一次上架，每一个 bug，乃至于每一个里程碑，几乎都预定当天热搜。

站在正式版发布的1 月 9 日，或许这一切都可以风轻云淡地说：the show must go on。但这过去的 295 天里，他们的经历，我们认为值得记录下来，分享给关心微信鸿蒙版的用户朋友们。

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

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

2、2024年3月，集结

鹅厂指派了从塞班（Symbian）时期就负责微信开发工作的团队，来主导微信鸿蒙版。从塞班到智能手表、车机、Linux PC 端的微信，这个团队在内部素以擅长攻克不同环境、不同语言的开发工作著称。

同样很重要的一点是，得益于智能手表端微信的研发工作，微信和华为的两个团队是老相识，这也让双方的对接更加顺畅紧密起来。从三月贯穿到四月，两边通过拉通会、分享会学习鸿蒙系统研发框架，不定时组织技术专题讨论。

双方都很清楚，这不是一场三天两夜就能解决的小规模战斗，而是旷日持久的兵团级战役。兵马未动，粮草先行，敲下第一行代码之前，还有许许多多的工作需要准备。

3、2024年4月，基建

万丈高楼平地起，基建是最重要的第一步。

搞基建，“三通一平”（通电/通路/通水/土地平整）是基本要求，进取一些，可以做到“五通一平”（加入通讯/排污），再进一步，还有“七通一平”（加入通气/有线电视），乃至于“十通一平”（加入宽带/铁路/暖气）。通得越多，越有利于后期扩展和长远发展。

经过塞班、手机、手表等各种终端上的长期打磨，这个团队积累了一套名为Alita（阿丽塔）的跨平台内核。这也为鸿蒙版微信的基建打下了基础。这个阶段的重中之重是，快速熟悉鸿蒙系统，移植基础库，让 Alita 内核能够在鸿蒙系统上运行起来，和华为一边沟通、一边验证推进。

4、2024年5月，架构

接下来考验的是架构能力。开发团队需要设计好鸿蒙微信客户端的架构、编写好各模块文档，支撑各业务进场后能够高效开发。

这一步的难点，在于充分预判到业务之间的复杂解耦，既要降低各业务之间的依赖性，又要提高整体的稳定性，还要留出高可扩展性，属于典型的“我全都要”难题。

这就好比从零开始建设一座城市，要预估到这座百年之后超级都市的人口规模、交通状况、人居需求、产业结构、商业发展等因素，以及提前平衡这些因素之间的关系，需要具备极大的前瞻视角。

技术团队继续摇人，招聘也快马加鞭推进。TAPD（腾讯敏捷产品研发平台）流程图里，他们的首个目标是做出一个基础版本，保证用户能实现收发消息、语音通话等最基础、也是最重要的功能。

5、2024年6月，磨合

进入了真正的手搓环节。flutter（跨平台应用程序开发框架）、liteapp（专为移动端设计的跨平台开发框架）等，都是这个阶段的关键工作。

为了这桌“年夜饭”，技术小哥们一边在厨房切菜烧饭，一边去客厅招呼各方沏茶倒水，让支付和VoIP（语音通话技术）等基础能力陆续凑上一桌。

除了内外部密切的技术沟通，微信和华为团队对彼此的技术标准保持了互相尊重。以相册选图发送功能为例，在 Android 系统上，选图需要获取整个相册权限，也就是说应用可以访问用户的所有照片。在鸿蒙上的选图功能，为了保障用户隐私，微信采用的是 Picker 控件的方式，相册照片的展示和选择逻辑都由 Picker 控件提供，微信只能读取到用户勾选的照片。

6、第一个里程碑：bug 如约而至

赶在6月21日前，团队做好了第一个内部体验版本，包含收发消息、通话功能。和2011年1月21日发布的 iOS和安卓版的微信1.0版本相比，多了语音消息发送。

你可能会不以为然：大动干戈这么久，就整了个这毛坯房？

其实这里蕴含的开发思路，是验证最小可用的原则，本质上是对第一阶段研究鸿蒙语言和系统的成果验收。重要的是把基本功练好，才能为后续的开枝散叶打好底子。

但即便是如此普通的版本，也出了个闪退型 bug，最后查出来是系统的底层 API 问题：同样的代码逻辑，在 iOS 和安卓上能用，但在鸿蒙上行不通。两边团队为此绞尽脑汁，交了两个星期的学费，最后还是靠着某位技术小哥灵光一现想到的。

这个 bug也像是一场结业考试，经此一役，开发进入了快节奏。

微信集合了众多产品功能，各功能间又有复杂的交互和依赖关系，比如小程序的开发就涉及到与支付功能的打通，而支付能力又需要与基础会话功能打通。在完成基建的前提下，基础、支付、小程序……能进场的业务模块都陆续进了场。一个共同的目标是——10月8号鸿蒙公测那天，做出一个新版本。这个版本，将新增微信支付、朋友圈等功能。

7、2024年10月8日：喜欢您来

10月8日，微信鸿蒙原生版开启内测邀请，尝鲜版本包含基础社交通讯音视频通话、朋友圈、微信支付的二维码收/付款等功能。

内测开启，意味着微信和其他所有适配原生鸿蒙的第三方App一样，从内测到应用尝鲜再到公测，走上了鸿蒙系统第三方软件开发的三部曲。

为什么要限量内测而不是一口气开放下载呢？

在全新的平台上，要支撑海量用户、高并发通讯需求，同时涉及支付、小程序、视频等多个大功能模块，还要满足极高频使用下的稳定性，是很大的挑战。

所以，用内测 → 找bug → 修bug → 加大内测的方式，是一个更符合软件开发规律的方式。

经历了4天紧张的测试和debug，包括微信支付在内的多个功能经过严格测试流程后，合入大版本，10 月 12 日，微信鸿蒙原生版正式开始公测。

8、2024年10月～11 月：这都能遇到灰产啊啊啊

公测放量过程中，有一次实际登陆人数不到放量总数的十分之一？某平台上竟然有人公然售卖测试名额？

一系列插曲打破了原定的放量节奏，双方共同排查后发现，原来有人把安装包拿去二手平台牟利。应用商店完善机制后，把漏洞补上。

安装包都能拿来卖，也堪称是国产软件开发史上浓墨重彩的一笔。

微信鸿蒙版在尝鲜专区上线了2万测试名额，但后台显示，登录数据一直较低，我们和华为一同复盘发现，因为有人用脚本去抢名额，触发了应用商店的安全机制，同时扰乱了应用商店的计数逻辑，导致大概90% 的放量被拦截，最终实际下载的用户只有 10%左右。

又是浓墨重彩的一笔......

如何让用户尽可能体验到微信测试版本？

在基本保障尝鲜专区不断档的情况下，11 月 6 日，双方紧急协商，华为将微信鸿蒙版的测试名额大幅扩容，微信再次邀请扩容后的用户分批有序参与内测，共同完善新版本的各种体验。

在不断收集用户反馈、历经数次迭代后，目前的版本已经可以使用视频号、聊天引用、发文件等功能，所有鸿蒙用户也都可以直接下载，更多功能在持续上线。

9、2025年1月9日：不止是微信

吸收了广大用户的反馈和多轮debug后，鸿蒙版微信顺利结束公测，1月9日正式版本上线。你除了能稳定下载和使用微信外，还可以用到 QQ、腾讯视频、腾讯新闻、QQ 音乐等App。

自今年起，腾讯20多款产品通过敏捷开发，实现鸿蒙系统的适配工作，更多腾讯的产品适配也在路上。

一个发生在2024年10月29日的插曲，某种程度上，可以反映微信鸿蒙版开发团队的工作情形和协作流程：

19:20，项目组微信支付团队发现，即将要上架的最新尝鲜版的微信，小部分用户转账入口出现bug，点击后无反应。

20:15，客服团队同步后台客诉情况。

20:57，微信支付团队初步定位，有问题的代码是今日合入导致的，疑似是LiteApp（跨端的框架，微信转账是鸿蒙第一个使用这个框架的功能）的问题。

21:31，进一步定位问题，发现在一些极端情况下， LiteApp的文件缓存写入被系统提示权限不足，联系华为技术团队一起定位。

21:47，支付技术团队完成最新内测版微信的修复，合入后，提交版本给测试团队。

22:32，支付技术团队复盘问题，提出后续改进措施。

22:41，微信基础技术团队向华为应用商店提审新版本内测包。

22:54，向华为应用商店提审尝鲜版。

23:30，最新尝鲜版微信通过审核，上架尝鲜专区，转账问题修复。

微信公众平台曾有一句 slogan 深入人心：再小的个体，也有自己的品牌。同样的，再小的问题，放在微信上，都会被亿量级地扩大。

我们知道，永远等不来“完美交付”这一天。灰度测试、持续迭代，让产品在和用户的互动中得到改进，是腾讯一直以来的产品理念。

感谢微信用户、鸿蒙用户始终跟我们站在一起，7x24小时反馈bug、提出优化意见。如果把新产品开发比做一场足球赛，那希望你们一直都在，做我们敏捷开发“球队”的第12人。

10、微信的其它故事

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文由转转王棕生分享，原题“IM系列(一)：转转IM系统架构探秘”，下文进行了排版和内容优化。

1、引言

转转是二手电商平台，在这个平台上，人人可以是买家，人人也可以是卖家。转转从最初的信息模式升级为一个闭环的交易模式，IM打通了买家与卖家之间的通道。本文描述了转转IM为整个平台提供的支撑能力，给出了系统的整体架构设计，分析了系统架构的特性。

2、系列文章

本文是系列文章中的第1篇，本系列文章的大纲如下：

• 转转平台IM系统架构设计与实践(一)：整体架构设计（* 本文)
• 转转平台IM系统架构设计与实践(二)：详细设计与实现（稍后发布..）

3、本文作者

王棕生：转转架构平台部高级研发工程师，负责IM系统、推送系统和分布式存储系统。

4、系统能力定义

转转IM需要提供如下的支撑能力：

1）有的用户习惯使用APP、有的用户习惯免安装的小程序；还有的用户习惯于在“58同城”APP上搜索二手；所以IM需要支持APP、小程序、M端等各种终端类型，以及由转转平台衍生出的其他垂类APP。

2）IM是转转平台中的一个独立系统，需要向平台中的其他系统（如客服系统、风控系统）提供“联系人”和“私信”等IM能力。

3）在转转平台的各种运营活动中，需要借助于IM通道将商品消息、订单消息、交易消息及活动通知等实时的发送给用户。

总之：IM为转转平台提供一个可靠和稳定的通道，为用户与用户之间、业务系统与用户之间、平台与用户之间打造一个可以即时通讯的环境。

5、系统架构概览

转转IM系统架构设计如下图所示，自上而下包括四层：用户层、入口层、逻辑层和原子存储层。

转转IM系统架构设计图：

6、系统架构之“用户层”

用户层是IM服务的调用者，用户层支撑各类业务应用，包括APP、小程序、M端、平台运营类业务系统和ZZRPC。

APP基于TCP协议与IM服务端进行消息传输，小程序和M端则是通过HTTP协议。

ZZRPC是转转平台使用Java语言自研的RPC框架，而转转IM系统是使用C++语言进行研发的，所以IM需要通过适配支持ZZRPC服务的相互调用。

7、系统架构之“入口层”

入口层是IM系统的入口网关，包括：

• 1）Entry
• 2）Http-Entry
• 3）转转自研的分布式消息中间件ZZMQ；
• 4）IMUI。

Entry：负责维护与APP之间的TCP连接，把APP发送的业务请求包向后直接转发到逻辑层进行处理。Entry逻辑较为简单，不参与具体的业务处理，这样设计的原因是为了避免Entry因业务改造升级进行模块重启，而丢失与APP之间的TCP连接，影响大量用户。

Http-Entry：是HTTP版的Entry实现，Http-Entry负责维护的是与小程序和M端之间通过HTTP协议模拟的“长连接”。

HTTP“长连接”的实现原理是：小程序发送http_request到Http-Entry，Http-Entry会hold住连接不返回、不释放；当产生了该用户的私信数据时或hold住连接超过一定时间（如15秒）时，Http-Entry则返回http_response到小程序；小程序收到http_response时需要立即再次发送http_request到Http-Entry......。

ZZMQ：是转转自研的分布式消息队列，接收平台各个运营类业务系统生产的系统消息、广播消息和推送类消息，然后由IM逻辑模块进行消费处理。ZZMQ解耦了平台业务系统和IM系统。

IMUI：用于IM系统适配ZZRPC的调用；IMUI作为ZZRPC服务的提供者，接收ZZRPC客户端的请求后，按照IM系统的内部协议格式同步访问逻辑层，再将逻辑层的操作结果按ZZRPC协议进行封装，然后返回到ZZRPC的客户端。

8、系统架构之“逻辑层”

逻辑层包括Logic和Extlogic两个模块组件：

• 1）Logic负责实现IM系统核心的和轻量级的业务逻辑，如用户登录、获取未读数、发送私信等；
• 2）非核心的和重量级的业务由Extlogic进行实现；
• 3）Logic和Extlogic两个逻辑模块通过ZZMQ进行解耦。

例如：在私信逻辑处理流程中，Logic接收私信和用户在线时的私信推送，而对于离线私信Logic则会通过ZZMQ通知Extlogic进行离线消息的召回逻辑处理。

9、系统架构之“原子存储层”

IM需要持久化存储的数据包括私信消息、系统消息和联系人等。

这些数据通过传统的关系型数据库MySQL和NewSQL数据库TiDB进行保存：

• 1）TiDB是分布式数据库，具有天然的弹性扩容特性；
• 2）MySQL通过通用的分库分表策略来应对存储和查询负载。

Das接收逻辑层对持久化数据的读写请求，将请求放入本地队列中，然后按顺序对数据库进行同步读写操作。

ZZRedis是转转自研的分布式缓存系统，负责对用户的在线信息进行缓存。

Jtransit与IMUI类似，用于适配ZZRPC服务；Jtransit作为ZZRPC服务的调用，接收逻辑层的请求后，按照ZZRPC协议格式访问平台其他系统提供的服务，获取数据后封装成IM系统的协议数据返回到逻辑层。

10、架构特性1：伸缩性

对转转IM系统架构设计，从伸缩性、高可用、可靠性、可扩展性和高性能分别进行分析。

当转转并发访问的用户量不断增加，IM系统资源紧张时，需要通过增加机器进行水平弹性扩容，主要是通过服务管理平台控制中心进行实施的。入口层、逻辑层和原子层服务之间相互调用的关系如下表所示。

Entry和Http-Entry会作为调用方调用Logic的服务，Logic和Extlogic会作为调用方调用Das的服务和Entry与Http-Entry的服务，这些服务之间的关系通过控制中心进行管理。

首先：

• 1）服务方组件与控制中心建立TCP长连接，将服务内容包括本实例ip、端口、服务接口等等注册到控制中心；
• 2）调用方组件与控制中心建立TCP长连接，从控制中心轮询服务列表；
• 3）服务方组件增加机器弹性扩容时，新的实例会注册到控制中心，进而被调用方实时拉取到。

另外：

• 1）App通过域名连接Entry时会首先访问TGW，由TGW转发请求到Entry，所以增加Entry实例时需要在TGW进行注册；
• 2）小程序到Http-Entry的HTTP请求都是由Nginx进行中转，所以增加Http-Entry机器需要在Nginx上进行配置；
• 3）Extlogic作为ZZMQ的消费者，可以自由增加实例。

存储层扩容：

• 1）数据库MySQL通过分库和分表的方式进行扩容；
• 2）分布式数据库TiDB以及分布式缓存ZZRedis；
• 3）还有分布式消息队列ZZMQ自身具有天然的弹性伸缩特性。

11、架构特性2：高可用

1）入口层高可用：入口层Entry和Http-Entry的可用性分别由TGW和Nginx进行探活和迁移。

2）Logic高可用：Logic的可用性由入口层实例进行控制；为了保证同一用户消息的顺序性，Entry和Http-Entry会将同一个用户的请求通过哈希算法打到相同的Logic实例；若一索引号为x的Logic实例挂掉以后，Entry和Http-Entry会在重试后将请求打到索引号为(x+p)%n的Logic实例上（n为Logic实例数目，p的取值区间为[1,n) ）；注意p的取值不能固定，否则很容易将瞬时流量打到固定的Logic实例，引起雪崩效应。

3）Extlogic高可用：Extlogic负责消费消息队列ZZMQ中的消息，挂掉任意一个实例后，不影响业务的正常处理。

4）Das高可用：Das的高可用由Logic和Extlogic进行控制，原理与Logic高可用一致，在挂掉任意一个Das实例后，Logic和Extlogic会将请求打到索引号为(x+p)%n的Das实例上。

5）存储层高可用：MySQL通过一主两备模式保证其高可用，在主库挂掉以后，其中的一个备库变为主库继续对Das提供服务；分布式数据库TiDB、分布式缓存ZZRedis，分布式消息队列ZZMQ自身具有天然的高可用特性。

12、架构特性3：可靠性

程序的正确处理保证系统的可靠性，影响IM系统可靠性的因素主要是瞬时高峰导致的逻辑层Logic实例的系统资源被用光和原子层Das对数据库的访问超时。

1）Logic可靠性：逻辑层实例的系统资源被用光发生在业务的相互影响；例如瞬时大量用户登录IM系统时，Logic大部分或全部线程被调度用于处理用户登录业务，而没有足够的资源去处理私信等业务。提高Logic可靠性的方案，可以根据微服务思想对Logic按功能职责进行拆分，如拆分成Login_Logic、Msg_Logic、Contact_Logic等。

2）Das可靠性：对数据库的访问超时发生在数据库负载较高时，例如推送千万级广播系统消息时，会有大量的更新操作落到数据库上，此时数据库响应较慢或超时；因为Das对数据库的操作是同步的，所以会造成Das内部队列请求的堆积，其他业务请求也会被堆积而导致超时。提高Das可靠性的方案，可以根据业务类型在Das内部分别创建不同的请求队列，从而避免业务的相互影响。

13、架构特性4：可扩展性和高性能

1）可扩展性：转转IM系统架构的可扩展性体现在逻辑层，逻辑层Logic和Extlogic通过消息队列ZZMQ进行解耦，定制类的功能需求在Extlogic中进行实现，避免对核心业务Logic的影响。

ZZMQ除了解耦Logic和Extlogic外，还对平台的业务系统和IM系统进行解耦。

2）高性能：分析IM系统架构，入口层和逻辑层主要是计算模块，原子存储层主要是IO模块，系统的性能瓶颈集中在数据库端。提升性能方案有：通过增强机器配置、增加机器、研究和新的存储方式，如用户联系人可以通过KList引擎进行存储。

14、本文小结

转转IM为用户与用户之间、客服与用户之间、平台与用户之间打造了一个高效和可靠的通讯通道。

按微服务私信和分层模式对IM系统架构进行分布式设计，架构中每个组件模块的功能职责明确。

具体的功能职责如下：

• 1）Entry负责维护TCP连接；
• 2）Http-Entry负责维护HTTP连接；
• 3）Logic负责处理核心的轻量级业务，Logic要求服务稳定；
• 4）Extlogic负责处理非核心的重量级业务，Extlogic要求服务可扩展；
• 5）Das负责对数据库进行读写访问；
• 6）IMUI和Jtransit负责对平台的RPC框架ZZRPC进行适配；
• 7）MySQL、TiDB和ZZRedis负责持久化和缓存数据；
• 8）ZZMQ负责对平台的业务系统和IM系统，以及Logic和Extlogic之间进行解耦。

转转IM的系统架构具有伸缩性、高可用、可靠性、功能扩展性和高性能。

15、参考资料

[1] 浅谈IM系统的架构设计

[2] 简述移动端IM开发的那些坑：架构设计、通信协议和客户端

[3] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[4] 一套原创分布式即时通讯(IM)系统理论架构方案

[5] 从零到卓越：京东客服即时通讯系统的技术架构演进历程

[6] 蘑菇街即时通讯/IM服务器开发之架构选择

[7] 现代IM系统中聊天消息的同步和存储方案探讨

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

[9] 马蜂窝旅游网的IM系统架构演进之路

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

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

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

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

[14] 闲鱼亿级IM消息系统的架构演进之路

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

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

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

[18] 一套分布式IM即时通讯系统的技术选型和架构设计

[19] 微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗

[20] 携程技术分享：亿级流量的办公IM及开放平台技术实践

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

相关链接：

• ① MobileIMSDK-鸿蒙端的详细介绍
• ② MobileIMSDK-鸿蒙端的开发手册new（* 精编PDF版）

一、理论知识准备

您需要对鸿蒙Next和ArkTS开发有所了解：

• 1）HarmonyOS NEXT星河版零基础入门到实战（B站视频）
• 2）零基础快速上手HarmonyOS ArkTS开发（系列文章）
• 3）HarmonyOS 第一课（鸿蒙官方视频教程）

您需要对WebSocket技术有所了解：

• 1）新手快速入门：WebSocket 简明教程
• 2）WebSocket 详解（一）：初步认识 WebSocket 技术
• 3）WebSocket 从入门到精通，半小时就够！
• 4）从零理解 WebSocket 的通信原理、协议格式、安全性
• 5）WebSocket详解（二）：技术原理、代码演示和应用案例
• 6）WebSocket详解（三）：深入WebSocket通信协议细节
• 7）WebSocket详解（四）：刨根问底HTTP与WebSocket关系(上)
• 8）WebSocket详解（五）：刨根问底HTTP与WebSocket关系(下)
• 9）WebSocket详解（六）：刨根问底WebSocket与Socket的关系

HTML5的标准WebSocket协议文档、API手册：

• 1）WebSocket 的 API 手册
• 2）WebSocket 的标准文档

鸿蒙Next的WebSocket文档和手册：

• 1）鸿蒙Next的WebSocket官方文档

小提示：鸿蒙Next中的WebSocket API跟标准HTML5中的WebSocket接口及用法略有不同，但主要API都能一一对应，相差不大。

二、开发工具准备

1）DevEco-Studio：

（JackJiang 使用的版本号如上图所示，为了方便直接引用工程，建议你也使用此版或较新版本）

2）一站式下载地址：鸿蒙官网下载地址 点此进入。（需要注册成为开发者才能下载哟！）

3）DevEco-Studio效果预览：

三、SDK 文件用途说明

3.1文件概览

纯ArkTS实现，无任何第3方库依赖，更无本地原生代码混编：

MobileIMSDK-鸿蒙端SDK本身只是ets文件源码的集合，自带的Demo代码只是为了方便随时测试SDK代码，目的主要是用于演示SDK的API调用，Demo代码不属于SDK框架的一部分。

大致的目录说明：

3.2详细说明

SDK 各模块/文件作用说明：

四、主要API接口和用途说明

* 主要API文档地址是：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/

1）ClientCoreSDK.getInstance().loginHasInit：

• 用途：是否已经完成过首次登陆。
• 说明 ：用户一旦从自已的应用中完成登陆IM服务器后，本方法就会一直返回true（直到退出登陆IM）。
• 返回值：{boolean}，true表示已完成首次成功登陆（即已经成功登陆过IM服务端了，后面掉线时不影响此标识），否则表示尚未连接IM服务器。

2）ClientCoreSDK.getInstance().connectedToServer：

• 用途：是否在线。
• 说明 ：表示网络连接是否正常。
• 返回值：{boolean}，true表示网络连接正常，否则表示已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。

3）ClientCoreSDK.getInstance().currentLoginInfo：

• 用途：保存登陆时提交的登陆信息（用户名、密码/token等）。
• 说明 ：格式形如：{loginUserId:'',loginToken:''}，此返回值的内容由调用登陆函数 loginImpl()时传入的内容决定。字段定义详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1697l。

4）ClientCoreSDK.getInstance().init(eventHub: common.EventHub): void：

• 用途：初始化SDK核心。
• 说明：不同于MobileIMSDK的iOS和Java客户端，本方法需要由开发者调用，以确保MobileIMSDK核心已被初始化完成。
• 本方法被调用后， #isInitialed() 将返回true，否则返回false。

5）ClientCoreSDK.getInstance().release(): void：

• 用途：保释放MobileIMSDK框架资源统一方法。
• 说明 ：本方法建议在退出登陆（或退出APP时）时调用。调用时将尝试关闭所有MobileIMSDK框架的后台守护线程并同设置核心框架init=false、loginHasInit=false、connectedToServer=false。

6）LocalDataSender.getInstance().sendLogin(loginInfo: PLoginInfo | undefined): number：

• 用途：发送登陆(连接)信息给服务端。
• 说明 ：不同于其它IM框架，本框架的登录和连接高度封装在了一个sendLogin方法中，无需单独再去connect服务器，大大简化了SDK的使用。loginInfo登陆信息各字段定义见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1697。

7）LocalDataSender.getInstance().sendLoginout(): number：

• 用途：发送注销登陆信息。
• 说明：此方法的调用将被本库理解为退出库的使用，本方法将会额外调用资源释放方法 ClientCoreSDK#release() ，以保证资源释放。本方法调用后，除非再次进行登陆过程，否则核心库将处于初始未初始化状态。

8）LocalDataSender.getInstance().sendCommonDataPlain(dataContentWidthStr: string, to_user_id: string, QoS: boolean = true, fingerPrint: string = '', typeu: number = -1): number：

• 用途：向某人发送一条消息。
• 参数dataContentWidthStr：要发送的数据内容（字符串方式组织）。
• 参数to_user_id：要发送到的目标用户id。
• 参数QoS ：true表示需QoS机制支持，否则不需要。
• 参数fingerPrint：QoS机制中要用到的指纹码（即消息包唯一id），可设为null，生成方法见 Protocal.genFingerPrint()。
• 参数typeu：应用层专用字段——用于应用层存放聊天、推送等场景下的消息类型。注意：此值为-1时表示未定义。MobileIMSDK框架中，本字段为保留字段，不参与框架的核心算法，专留作应用层自行定义和使用。
• 返回值：0表示数据发出成功，否则返回的是错误码，see ErrorCode。

9）LocalDataSender.getInstance().sendCommonData(p: Protocal): number：

• 用途：通用数据协议包的发送根方法。
• 参数p：{Protocal} 要发送的消息协议包对象，Protocal详情请见“/module/mb_constants.js”下的createCommonData函数说明。
• 返回值：0表示数据发出成功，否则返回的是错误码，see ErrorCode。

10）SocketEvent.SOCKET_EVENT_ON_RECIEVE_MESSAGE事件通知：

• 用途：以便收到聊天消息时在UI上展现出来（事件通知于收到IM消息时）。
• 推荐用法 ：开发者可在此通知中处理收到的各种IM消息。
• 参数1： {Protocal}：详情请见Protocal类定义：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1350。

11）SocketEvent.SOCKET_EVENT_ON_LOGIN_RESPONSE事件通知：

• 用途：本地用户的登陆结果回调事件通知（此事件发生时表示客户端已登陆/连接或重连完成）。
• 推荐用法：开发者可在此事件中处理登录连接和掉线重连响应反馈。
• 参数1： {PLoginInfoResponse}：API文档详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1434。

12）SocketEvent.SOCKET_EVENT_ON_LINK_CLOSE事件通知：

• 用途：与服务端的通信断开的回调事件通知（此事件发生时表示客户端已掉线）。
• 该消息只有在客户端连接服务器成功之后网络异常中断之时触发。导致与与服务端的通信断开的原因有（但不限于）：无线网络信号不稳定、WiFi与2G/3G/4G/5G等同开情况下的网络切换、手机系统的省电策略等。
• 推荐用法 ：开发者可在此通知中处理掉线时的界面状态更新等，比如设置将界面上的“在线”文字更新成“离线”。

13）SocketEvent.SOCKET_EVENT_PING事件通知：

• 用途：本地发出心跳包后的回调通知（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 推荐用法 ：开发者可在此回调中处理底层网络的活动情况。

14）SocketEvent.SOCKET_EVENT_PONG事件通知：

• 用途：收到服务端的心跳包反馈的回调通知（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 推荐用法 ：开发者可在此回调中处理底层网络的活动情况。

15）SocketEvent.SOCKET_EVENT_KICKOUT事件通知：

• 用途：收到服务端反馈的错误信息指令（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 参数1：{PKickoutInfo}：非空，详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1428。

16）SocketEvent.SOCKET_EVENT_ON_ERROR_RESPONSE事件通知：

• 用途：收到服务端反馈的错误信息指令（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 参数1：{PErrorResponse}：非空，详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1430。

17）SocketEvent.SOCKET_EVENT_RECONNECT_ATTEMPT事件通知：

• 用途：“自动重连尝试中”事件（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 参数 code ：{numeric}：0：已停止，1：持续运行中，2：单次脉搏

18）SocketEvent.SOCKET_EVENT_MESSAGE_LOST事件通知：

• 用途：消息未送达的回调事件通知。
• 发生场景：比如用户刚发完消息但网络已经断掉了的情况下，表现形式如：就像手机qq或微信一样消息气泡边上会出现红色图标以示没有发送成功）。
• 建议用途：应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送失败”以便即时告之用户。
• 参数1：{Array}：由框架的QoS算法判定出来的未送达消息列表。

19）SocketEvent.SOCKET_EVENT_MESSAGE_BE_RECIEVED事件通知：

• 用途：消息已被对方收到的回调事件通知。
• 说明 ：目前，判定消息被对方收到是有两种可能：1) 对方确实是在线并且实时收到了；2) 对方不在线或者服务端转发过程中出错了，由服务端进行离线存储成功后的反馈（此种情况严格来讲不能算是“已被收到”，但对于应用层来说，离线存储了的消息原则上就是已送达了的消息：因为用户下次登陆时肯定能通过HTTP协议取到）。
• 建议用途：应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送成功”以便即时告之用户。
• 参数1：{String}：已被收到的消息的指纹特征码（唯一ID），应用层可据此ID找到原先已发的消息并可在UI是将其标记为”已送达“或”已读“以便提升用户体验。

五、如何引入SDK库文件

5.1方法一：源码形式

第一步：先将整个sdk源码module复制到您的鸿蒙工程中：

第二步：配置您的工程，确保正确引用了MobileIMSDK鸿蒙SDK的源码module：

5.2方法二：.har包形式

第一步：先将MobileIMSDK鸿蒙端SDK的.har包放入您的鸿蒙Next主module中（比如新建的libs目录下）：

第二步：配置您的工程，确保正确引用了MobileIMSDK鸿蒙SDK的.har包：

六、如何调用SDK代码

6.1第一步：设置ws/wss连接URL

设置您自已部署的MobileIMSDK服务端IP或域名的（示例详见Demo中的 IMClientManager.ets 文件）：

提示：MobileIMSDK的服务端Demo部署指南请见 http://www.52im.net/thread-63-1-1.html。

6.2第二步：初始化SDK

调用ClientCoreSDK中的init()方法进行初始化（示例详见Demo中的I MClientManager.ets 文件）：

6.3第三步：注册框架事件

注册MobileIMSDK框架级的事件监听（示例详见Demo中的 IMClientManager.ets 文件）：

6.4第四步：调用登录方法（框架内部会自动启动connect全过程）

调用登录方法（示例详见Demo中的 LoginPage.ets 文件）：

提示：不同于其它IM框架，本框架的登录和连接高度封装在了一个sendLogin方法中，无需单独再去connect服务器，大大简化了SDK的使用。

七、Demo运行效果和功能说明

八、Demo运行方法

8.1重要说明

特别说明：MobileIMSDK的鸿蒙端工程（包括Demo代码），不依赖任何第3方库，也不存在任何Native代码混编，完全使用ArkTS、ArkUI官方标准API实现，所以你在拿到MobileIMSDK的鸿蒙端工程后直接开箱即可运行，切莫搞复杂、不要私自加戏！

8.2配置要连接的MobileIMSDK服务器IP

注意：下图中登陆连接的IP地址请设置为您自已的MobileIMSDK服务器地址哦。

友情提示： MobileIMSDK的服务端该怎么部署就不是本手册要讨论的内容了，你可以参见《即时通讯框架MobileIMSDK的Demo使用帮助：Server端》。

▲ 配置要连接的服务器IP（以上代码详见IMClientManager.ets文件）

8.3启动模拟器

注意：如果没有新建模拟器可以自已新建一个。另外也可以使用支持鸿蒙Next的真机，打开“开发者模式”并插入USB线即可使用。

▲ 点击绿色箭头，立即启动模拟器！

8.4一键运行

如下图所示，点击绿色“运行”按钮后，将自动在模拟器或真机里显示自带的Demo界面了：

8.5运行效果

1）Demo的登陆界面运行截图：

2）Demo的主界面运行截图：

3）Demo运行的同时，可以查看详细的log输出（方便调试）：

九、引用资料

[1] 鸿蒙Next官方开发资料

[2] MobileIMSDK开源框架的API文档

[3] MobileIMSDK开源IM框架源码（Github地址点此）

[4] MobileIMSDK-鸿蒙Next端发布公告

[5] MobileIMSDK-鸿蒙Next端详细介绍

[6] MobileIMSDK-鸿蒙Next端开发手册（* 精编PDF版）

[7] MobileIMSDK的Server端Demo使用帮助

一、基本介绍

MobileIMSDK-鸿蒙端是一套基于鸿蒙Next（纯血鸿蒙）系统的IM即时通讯客户端库：

• 1）超轻量级（编译后库文件仅50KB）、无任何第3方库依赖（开箱即用）；
• 2）纯ArkTS编写、无Native代码、高度提炼、简单易用；
• 3）基于鸿蒙Next标准WebSocket  API，简洁优雅；
• 4）可运行于任何支持鸿蒙Next的平台；
• 5）能与 MobileIMSDK的各种客户端完美互通；
• 6）可应用于鸿蒙Next中的消息推送、客服聊天、企业OA、IM等场景。

二、与MobileIMSDK的关系

MobileIMSDK-鸿蒙端是基于鸿蒙Next标准WebSocketAPI的 MobileIMSDK配套客户端库。

以下是MobileIMSDK的最新通信架构图：

MobileIMSDK是一套专为移动端开发的原创开源IM通信层框架：

• 1）历经10年、久经考验；
• 2）超轻量级、高度提炼，lib包50KB以内；
• 3）精心封装，一套API同时支持UDP、TCP、WebSocket三种协议（可能是全网唯一开源的）；
• 4）客户端支持iOS、Android、标准Java、H5(暂未开源)、微信小程序(暂未开源)、Uniapp(暂未开源)、鸿蒙Next(Demo工程源码)new；
• 5）服务端基于Netty，性能卓越、易于扩展；
• 6）可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等；
• 7）可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。

PS：MobileIMSDK一直在持续开发和升级中，本鸿蒙客户端是MobileIMSDK工程的最新成果。

三、设计目标

直接使用鸿蒙Next的WebSocket API开撸，有以下问题和劣势：

• 1）功能有限：没有心跳保活、断线重连、消息送达保证（重传和去重）等即时通讯关键算法和逻辑；
• 2）API 简陋：在如此有限的API接口下，能逻辑清晰且健壮地实现并组合心跳保活、断线重连、消息送达保证等算法，需要相当高的技术掌控力；
• 3）逻辑耦合：经验欠缺的开发人员，会将WebSocket通信逻辑与前端ArkUI界面代码混在一起，使得UI界面的编写、维护、改版都非常困难。

针对以上问题，而MobileIMSDK-鸿蒙端库将让开发者专注于UI应用层的开发，网络通信层的专业代码交由SDK开发人员，从而解偶UI前端和通信层的逻辑耦合性，大大降低技术复杂度和应用门槛。

MobileIMSDK-鸿蒙端库的设计目标是为您的开发带来以下便利：

• 1）界面与通信解偶：UI界面与网络通信层代码解耦，UI界面的重构、维护、改版都非常容易和优雅；
• 2）轻量级和兼容性：受益于坚持使用鸿蒙Next的标准WebSocket API，简洁轻量，无需任何额外库依赖；
• 3）核心内聚和收敛：得益于长期的提炼和经验积累，SDK核心层高度封装，开发者无需理解复杂算法即可简单上手。
• 4）纯 ArkTS 实现：纯ArkTS编写，无重量级框架和库依赖（更无Native代码），可干净利落地对接各种既有系统；
• 5）跨平台运行能力：受益于鸿蒙系统的跨端特性，理论上本SDK可运行于任何支持鸿蒙Next的平台上。

四、技术亮点

• 1）超级轻量纯净：超轻量级——纯ArkTS编写且无任何第3方库依赖，编译后库文件仅50KB；
• 2）高内聚易使用：高度提炼——简单易用，所有核心类皆设计为单例——到手即用、高度容错；
• 3）跨端支持好：基于鸿蒙Next的标准WebSocket API（无Native代码依赖），理论上可很好地运行于任何支持最新鸿蒙的平台上；
• 4）断网恢复能力：拥有网络状况自动检测、断网自动治愈的能力；
• 5）送达保证机制：完善的QoS消息送达保证机制（自动重传、消息去重、状态反馈等），不漏过每一条消息；
• 6）通信协议封装：实现了一个对上层透明的即时通讯通信协议模型；
• 7）身份认证机制：实现了简单合理的身份认证机制；
• 8）完善的log信息：在开发调试阶段，确保每一个算法关键步骤都有日志输出，让您的运行调试更为便利；
• 9）界面代码解耦：实现了UI界面代码与SDK网络通信代码解偶，防止界面代码跟IM核心代码混在一起，不利于持续升级、重用和维护；
• 10）多端协议兼容：实现了与MobileIMSDK各种客户端完全兼容的协议模型。

五、文件组成

完整工程文件概览：

 

SDK代码文件用途说明：

精编注释级的源码：

六、Demo功能说明

（点击可看大图 ▲）

七、实际运行效果

1）Demo 的登陆界面运行截图（点击可看大图 ▼）：

2）Demo 的主界面运行截图（点击可看大图 ▼）：

3）Demo 运行的同时，可以查看详细的 log 输出（方便调试）：

八、详尽开发者手册

① 开发者手册（网页版）：点此进入 ◀

② 开发者手册（PDF精编版）：点此进入 ◀（* 推荐）

九、相关资料

[1] 鸿蒙Next官方开发资料

[2] MobileIMSDK开源框架的API文档

[3] MobileIMSDK开源IM框架源码（Github地址点此）

[4] MobileIMSDK-鸿蒙Next端发布公告

[5] MobileIMSDK-鸿蒙Next端开发手册（* 推荐）

本文由转转QA刘宝成分享，原题“抓包工具wireshark的使用”，下文进行了排版和内容优化。

1、引言

跟网络通信有关的应用场景下（比如Web系统、IM聊天应用、消息推送系统等），经常要用到网络抓包工具，用以验证客户端和服务器之间收发的数据包是否正确。以IM聊天系统为例，TLS/SSL加密开启到底有没有成功？加密效果怎么样？端到端加密后的聊天内容安全强度够不够？等等这些疑问，都需要通过网络抓包抓出样本来分析和验证。

Wireshark是一款开源和跨平台的抓包工具。它通过调用操作系统底层的API，直接捕获网卡上的数据包，因此捕获的数据包详细、功能强大。但Wireshark本身稍显复杂，本文将以用抓包实例，手把手带你一步步用好Wireshark，并真正理解抓到的数据包的各项含义。

2、系列文章

本文是系列文章中的第16篇，本系列文章的大纲如下：

网络编程懒人入门(一)：快速理解网络通信协议（上篇）

网络编程懒人入门(二)：快速理解网络通信协议（下篇）

网络编程懒人入门(三)：快速理解TCP协议一篇就够

网络编程懒人入门(四)：快速理解TCP和UDP的差异

网络编程懒人入门(五)：快速理解为什么说UDP有时比TCP更有优势

网络编程懒人入门(六)：史上最通俗的集线器、交换机、路由器功能原理入门

网络编程懒人入门(七)：深入浅出，全面理解HTTP协议

网络编程懒人入门(八)：手把手教你写基于TCP的Socket长连接

网络编程懒人入门(九)：通俗讲解，有了IP地址，为何还要用MAC地址？

网络编程懒人入门(十)：一泡尿的时间，快速读懂QUIC协议

网络编程懒人入门(十一)：一文读懂什么是IPv6

网络编程懒人入门(十二)：快速读懂Http/3协议，一篇就够！

网络编程懒人入门(十三)：一泡尿的时间，快速搞懂TCP和UDP的区别

网络编程懒人入门(十四)：到底什么是Socket？一文即懂！

网络编程懒人入门(十五)：外行也能读懂的网络硬件设备功能原理速成

网络编程懒人入门(十六)：手把手教你使用网络编程抓包神器Wireshark（* 本文)

3、Wireshak的安装和基本使用

安装：直接通过官方下载对应的安装包即可 https://www.wireshark.org/download.html。

使用：

如上图所示：

• 1）左上角为几个最常用的按钮：开始捕获、停止捕获、重新捕获、捕获选项；
• 2）中间为捕获过滤器，用于过滤需要捕获的数据包；
• 3）捕获过滤器下面可以选择需要捕获的网络连接。

下图是用Wireshark捕获的数据包：

可以看到，数据包结构是与OSI的七层模型相对应的，会详细显示每层的信息。

更多Wireshak的基本用法和手册，可以详读以下两篇：

1. 理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程
2. 网络通讯数据抓包和分析工具 Wireshark 使用教程(中文) [附件下载]

4、快速理解Wireshak的过滤器

由于Wireshark直接捕获底层网络数据包，导致其捕获的数据包数量通常较大。为了便于筛选数据包，Wireshark提供了两种过滤器。

4.1捕获过滤器

用于设置什么样的数据包保存在捕获结果中，避免产生过大的日志文件。

需要在开始捕获之前设置，相对简单：

捕获过滤器语法如上，一般用于过滤协议、IP、端口等基本信息。

例如：

• 1）显示目的TCP端口为8080的包：tcp dst port 8080
• 2）显示来源IP地址为192.168.171.201的封包：ip src host 192.168.171.201

4.2显示过滤器

用于在捕获日志中查找数据包，可以在捕获过程中或者捕获后随时更改。

功能更加强大和复杂：

显示过滤器语法如上，比捕获过滤器更为强大，可以针对不同协议，过滤不同的字段。

例如：

• 1）源地址是192.168.171.0网段的数据包：ip.src == 192.168.171.0/24
• 2）所有的HTTP POST请求：http.request.method== "POST"
• 3）显示包含TCP SYN标志的包：tcp.flags.syn == 0×02
• 4）URL中包含baidu的http请求：http.request.uri contains "baidu"

5、用什么例子来动手学习Wireshak？

本来想借用RainbowChat 这种IM聊天中的TLS/SSL数据包来的分析来实战Wireshak，但考虑到IM通常都是私有协议，不利于理解。

因而接下来的内容将以HTTPS为例，来详细讲解如何借助Wireshak抓出的数据包（正好也顺验证之前那么多跟TLS/SSL加密有关的文章），详细理解和学习Wireshak的使用，同进加深对HTTPS协议本身的理解。

6、什么是HTTPS

SSL/TLS：SSL (Secure Sockets Layer)，最初由Netscape公司设计，后来逐渐演变为TLS(Transport Layer Security Protocol)，即“传输层安全协议”。

该协议工作在TCP层之上，应用层之下。在TCP连接完成后，进行通信双方的身份认证，并协商一些跟加密相关的工作。完成协商之后，就可以对双方发送的信息进行加密/解密了。

HTTPS：可以理解为HTTP over SSL/TLS。即在SSL/TLS协议之上运行HTTP协议，以保证通信的安全性。

更多深入的学习，可以从下面这几篇精选的资料开始：

1. 如果这样来理解HTTPS原理，一篇就够了
2. 你知道，HTTPS用的是对称加密还是非对称加密？
3. 为什么要用HTTPS？深入浅出，探密短连接的安全性
4. 一分钟理解 HTTPS 到底解决了什么问题
5. 一篇读懂HTTPS：加密原理、安全逻辑、数字证书等

7、HTTPS的SSL/TLS握手过程

SSL/TLS的握手过程主要需要解决两个问题：

• 1）证明通信双方身份的真实性；
• 2）协商后续通信过程中使用的密钥；

如下图所示：左侧是一个简单的握手流程，右侧为对应的抓包结果，我们可以对比分析一下SSL/TLS的握手过程。

1）C：ClientHello

客户端发送协议版本号、sessionid、随机数、加密算法列表、扩展字段等信息：

2）S：ServerHello

与客户端类似，不同之处在于确定了所使用的加密算法等：

3）S：Certificate

服务端向客户端发送自己的CA证书。客户端通过证书信任链查看该证书的真实性，以验证服务端的身份。其实SSL/TLS协议还支持客户端的CA证书验证，不过在实际中使用较少。

4）S：ServerKey Exchange

服务端根据之前选择的加密算法，传输密钥协商需要的参数。从之前的报文可以看到，这里选择的是EC-DH算法。

5）S：ServerHello Done

该报文表示服务端发送完成。

6）C：ClientKey Exchange

同理，客户端也要根据之前选择的加密算法，传输相应的参数。

7）C：ChangeCipher Spec

经过上述步骤，客户端和服务器双方已经完成了身份认证，并且交换了生成密钥的全部参数。双方会根据对应的算法，各自生成加密密钥，然后就可以进行加密通信了。这个报文表示切换到密文模式，后续消息都通过加密传输。

8）C：Finished

客户端表示握手完成。这里会发送一段Verify Data，是使用新生成的密钥加密后的一段信息。双方通过该信息验证加密算法、密钥是否有效。

9）S：Change Cipher Spec

10）S：Finished

服务段也会发送对应的两条消息作为回应，不再赘述。

8、解密HTTPS报文

握手完成之后，就可以查看客户端发出的HTTP请求了。但我们看到的只是一段加密后的字符串？那么如何对HTTPS报文进行解密呢？

要想解密HTTPS报文，就必须要获取到加密密钥。Chrome、Firefox等浏览器支持将访问网站时使用的密钥输出到文件中。仅需要配置环境变量SSLKEYLOGFILE 即可。

如下：

然后需要将该密钥文件导入到Wireshark中。打开编辑-首选项，选择Protocol-SSL，填写刚才设置的文件路径。

现在，就可以通过Wireshark查看HTTPS请求中的具体信息了！

9、参考资料

[1] TCP/IP详解 - 第17章·TCP：传输控制协议

[2] 理论经典：TCP协议的3次握手与4次挥手过程详解

[3] 理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程

[4] 网络通讯数据抓包和分析工具 Wireshark 使用教程(中文) [附件下载]

[5] 如果这样来理解HTTPS原理，一篇就够了

[6] 你知道，HTTPS用的是对称加密还是非对称加密？

[7] 为什么要用HTTPS？深入浅出，探密短连接的安全性

[8] 一分钟理解 HTTPS 到底解决了什么问题

[9] 一篇读懂HTTPS：加密原理、安全逻辑、数字证书等

[10] IM聊天系统安全手段之通信连接层加密技术

[11] IM聊天系统安全手段之传输内容端到端加密技术

[12] 传输层安全协议SSL/TLS的Java平台实现简介和Demo演示

[13] 微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解

[14] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

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