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

[-1-] 直播系统聊天技术(一)：百万在线的美拍直播弹幕系统的实时推送技术实践之路

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

[摘要] 直播弹幕指直播间的用户，礼物，评论，点赞等消息，是直播间交互的重要手段。美拍直播弹幕系统从 2015 年 11 月到现在，经过了三个阶段的演进，目前能支撑百万用户同时在线。比较好地诠释了根据项目的发展阶段进行平衡演进的过程。这三个阶段分别是快速上线、高可用保障体系建设、长连接演进。具体我将在正文中展开，请继续往下阅读。

[-2-] 直播系统聊天技术(二)：阿里电商IM消息平台，在群聊、直播场景下的技术实践

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

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

[-3-] 直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路

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

[摘要] 本文将回顾微信直播聊天室单房间海量用户同时在线的消息组件技术设计和架构演进，希望能为你的直播聊天互动中的实时聊天消息架构设计带来启发。

[-4-] 直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践

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

[摘要] 本文主要分享的是百度直播的消息系统的架构设计实践和演进过程。

[-5-] 直播系统聊天技术(五)：微信小游戏直播在Android端的跨进程渲染推流实践

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

[摘要] 微信小游戏出于性能和安全等一系列考虑，运行在一个独立的进程中，在该环境中不会初始化视频号直播相关的模块。这就意味着小游戏的音视频数据必须跨进程传输到主进程进行推流，给我们实现小游戏直播带来了一系列挑战。

[-6-] 直播系统聊天技术(六)：百万人在线的直播间实时聊天消息分发技术实践

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

[摘要] 本文将基于融云在直播技术实践的背景，分享了单直播间百万用户在线量的实时消息分发的技术经验总结，希望带给你启发。

[-7-] 直播系统聊天技术(七)：直播间海量聊天消息的架构设计难点实践

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

[摘要] 本文将主要从高可用、弹性扩缩容、用户管理、消息分发、客户端优化等角度，分享直播间海量聊天消息的架构设计技术难点的实践经验。

[-8-] 视频直播技术干货(十一)：超低延时视频直播技术的演进之路

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

[摘要] 本文将带您了解超低延时视频直播技术的优化和演进历程。

[-9 -]  视频直播技术干货(十二)：从入门到放弃，快速学习Android端直播技术

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

[摘要] 本文详细介绍了Android端直播技术的全貌，涵盖了从实时音视频采集、编码、传输到解码与播放的各个环节。文章还探讨了直播中音视频同步、编解码器选择、传输协议以及直播延迟优化等关键问题。希望本文能为你提供有关Andriod端直播技术的深入理解和实践指导。

[-10-] 海量实时消息的视频直播系统架构演进之路(视频+PPT)[附件下载]

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

[摘要] 本次主要分享的是融云视频直播互动平台的实时消息可靠性的设计方案,支撑无上限消息并发的架构演进,单机吞吐性能的优化历程。

[-11 -] YY直播在移动弱网环境下的深度优化实践分享(视频+PPT)[附件下载]

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

[摘要] 本次分享介绍了 YY 直播针对质量较差网络（简称弱网）的环境，基于数据分析，在客户端和云端所采取的一系列技术手段。 同时，就如何改善上下行网络环境，也给出自己的一些解决方案。

[-12 -] 从0到1：万人在线的实时音视频直播技术实践分享(视频+PPT) [附件下载]

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

[摘要] 本次分享由“跟谁学”CTO带来，介绍跟谁学的团队是怎样在很短的时间内，构建了一个支持万人实时音视频直播的在线教室。

[-13 -] 在线音视频直播室服务端架构最佳实践(视频+PPT) [附件下载]

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

[摘要] 本期演讲嘉宾将为大家带来金山视频云在社交直播场景的支撑技术架构和优化方案。

👉52im社区本周新文：《Wasm在即时通讯IM场景下的Web端应用性能提升初探》，欢迎阅读！👈

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

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

[-1-] 实时音频的混音在视频直播中的技术原理和实践总结

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

[摘要] 今天，我们就来聊一聊混音技术在视频直播应用中的实现原理、方案等，及其在创新玩法中的实践应用。

[-2-] 七牛云技术分享：使用QUIC协议实现实时视频直播0卡顿！

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

[摘要] 不做任何开发，就能实现弱网环境下实现实时视频直播零卡顿，听上去是不是天方夜谭？看完这篇文章你就知道，我们是如何做到的。

[-3-] 近期大热的实时直播答题系统的实现思路与技术难点分享

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

[摘要] 我们首先分析一下直播答题和传统直播在技术上的不同，然后深度解释一下直播答题解决方案的海量并发派题和收题。

[-4-] P2P技术如何将实时视频直播带宽降低75%？

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

[摘要] 那整个系统是怎么设计的？使用了哪些技术来达成目标？接下来我来重点分享一下架构设计和技术细节。

[-5-] 网易云信实时视频直播在TCP数据传输层的一些优化思路

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

[摘要] 网易云信的实时视频直播目前使用了TCP进行传输，且基于此，从编码动态适配、发送队列调整、协议优化、socket等做了全流程的优化，确保在限带宽、丢包、时延、抖动，无论单项还是复杂网络，都有非常不错的实际体验。

[-6 -] 首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？

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

[摘要] 快手拥有5亿注册用户，单个直播间人数峰值已经超过180万，他们针对海量用户，基于大数据技术，在首屏和流畅度优化上做了大量的探索与实践。快手直播是如何设计全链路质量监控方案、如何搭建大数据处理Pipeline 、如何解决开播跳帧、首屏卡顿优化等问题的？本文干货满满，全面解密快手直播大数据技术架构与优化实践。

[-7-] 浅谈实时音视频直播中直接影响用户体验的几项关键技术指标

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

[摘要] 这两年互联网领域的一个热门关键词就是实时音视频直播，从刚开始的游戏直播和秀场娱乐开始，实时音视频直播带来了远超传统互动的用户体验，现在实时音视频直播已逐渐深入当今主流的互联网应用形态里。我们将逐一分析和总结实时音视频直播中的这几个重要技术指标。

[-8-] 技术揭秘：支持百万级粉丝互动的Facebook实时视频直播

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

[摘要] 在这篇文章中，我们将粗略地看一下我们在每次发布时解决的问题，我还将向你解释我们为负载均衡和 RTMP 实现问题所选择的解决方案。

[-9 -]  移动端实时视频直播技术实践：如何做到实时秒开、流畅不卡

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

[摘要] 本次分享将为大家揭开移动端实时音视频直播核心技术的神秘面纱。

[-10-] 实现延迟低于500毫秒的1080P实时音视频直播的实践分享

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

[摘要] 实时视频直播是很多技术团队及架构师关注的问题，在实时性方面，大部分直播是准实时的——存在 1-3 秒延迟。本文由袁荣喜分享其将1080P高清实时视屏直播延迟控制在 500ms 的背后的技术挑战以及实践结论等，期待与各同行共同讨论、学习和进步。

[-11 -] 浅谈开发实时视频直播平台的技术要点

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

[摘要] 现在大大小小的公司，甚至个人开发者，都想开发自己的直播网站或App，本文会帮你理清，开发视频直播平台，你需要注意哪些技术要点。

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

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

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

[-13 -] 微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题

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

[摘要] 功耗优化一直是 app 性能优化中让人头疼的问题，尤其是在直播这种用户观看时长特别久的场景。怎样能在不影响主体验的前提下，进一步优化微信iOS端视频号直播的功耗占用，本文给出了一个不太一样的答案。

👉52im社区本周新文：《移动端弱网优化专题(十四)：携程APP移动网络优化实践（弱网识别篇）》，欢迎阅读！👈

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

关于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 实现）。

v9.1 版更新内容

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

• 1）[bug] 解决了与Web产品互通时，收到撤回被引用消息的指令时会崩溃的问题；
• 2）[bug] 解决了“查换用户”界面中精确查找时，输入内容时会导致底部按钮等控件显示高度被错误改变的问题；
• 3）[bug] 解决了聊天输入框中自定义表情和数字、英文混输时，表情图标会消失的问题；
• 4）[优化] 更换了位置消息中的高德地图AppKey，解决每日调用量限制问题；
• 5）[优化] 优化了首页“消息”列表中单聊类型未正确同步时的收发消息和点击后的处理逻辑；
• 6）[优化] 聊天消息自动识别电话、网址、邮箱等内容，点击自动跳转到系统功能；
• 7）[优化] 优化了首页“消息”列表中同一好友和陌生人会话不能自动合并的问题。

部分功能运行截图（更多截图点此查看）：

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统，是RainbowChat的姊妹系统（RainbowChat是一套基于开源IM聊天框架 MobileIMSDK (Github地址)  的产品级移动端IM系统）。

关于RainbowChat

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

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

► 详细产品介绍：http://www.52im.net/thread-19-1-1.html
► 版本更新记录：http://www.52im.net/thread-1217-1-1.html
► 全部运行截图：Android端、iOS端
► 在线体验下载：专业版(TCP协议)、专业版(UDP协议)      （关于 iOS 端，请：点此查看）

关于MobileIMSDK

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

工程开源地址：

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

v11.7 版更新内容

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

（1）Android端主要更新内容：

• 1）[优化] 优化了首页“消息”列表中单聊类型未正确同步时的收发消息和点击后的处理逻辑；
• 2）[优化] 优化了首页“消息”列表中同一好友和陌生人会话不能自动合并的问题；

（2）服务端主要更新内容：

• 1）[优化] 大幅提升群聊性能（改进离线消息存储方式等：异步提交、批量处理）；
• 2）[优化] 升级了mysql驱动至最新版8.4.0；
• 3）[优化] 优化了离线消息处理性能（异步化、无锁队列、批量处理、事务合并）；
• 4）[优化] 优化了聊天记录处理性能（异步化、无锁队列、批量处理、事务合并）；
• 5）[优化] 优化了“接口1008-26-8”，使得与Web产品联合部署明web前端按时间戳加载的消息不与客户端发生重复；
• 6）[优化] 修改了离线消息、聊天记录异步定时器实现，使之运行更健壮；
• 7）[优化] 加好友成功后将成功通知保存至离线消息和消息记录。

部分功能运行截图（更多截图点此查看）：

► 相关链接：

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

一、技术准备

您是否已对Web端即时通讯技术有所了解？

• 1）新手入门贴：史上最全Web端即时通讯技术原理详解
• 2）Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE

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

• 1）新手快速入门：WebSocket简明教程
• 2）WebSocket详解（一）：初步认识WebSocket技术
• 3）WebSocket从入门到精通，半小时就够！
• 4）从零理解WebSocket的通信原理、协议格式、安全性

WebSocket标准文档、API手册：

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

二、开发工具准备

1）WebStorm：

（JackJiang 使用的版本号如上图所示，建议你也使用此版或较新版本）

2）一站式下载地址：WebStorm官方下载地址点此进入。

三、工程文件用途说明

3.1文件概览

纯原生JS实现，无任何重框架依赖：

MobileIMSDK-H5端SDK本身只是JS文件源码的集合，本工程中自带的前端Demo的目的只是为了方便随时测试MobileIMSDK-H5端的SDK代码而已，在此工程中的使用也仅仅只涉及了一个主Demo页面而已。

工程目录说明：

3.2详细说明

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

四、主要 API 接口

4.1主要 API 接口概览

如下图所示：所有 SDK 接口均由/mobileimsdk/mobileimsdk-client-sdk.js 提供。，接口设计跟MobileIMSDK 的APP版一样，均为高内聚和低侵入的回调方式传入SDK处理逻辑，无需（也不建议）开发者直接修改sdk级代码。

▲ 图上为浏览器端SDK的对外接口文件位置

▲ 图上为浏览器SDK为开发者提供的回调接口

▲ 图上浏览器端SDK的对外接口文件全图

4.2主要 API 接口用途说明

1）IMSDK.isLogined()：

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

2）IMSDK.isOnline()：

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

3）IMSDK.getLoginInfo()：

• 用途：返回登陆时提交的登陆信息（用户名、密码/token等）。
• 说明 ：格式形如：{loginUserId:'',loginToken:''}，此返回值的内容由调用登陆函数 loginImpl()时传入的内容决定。字段定义详见：PLoginInfo
• 返回值：{boolean}，true表示网络连接正常，否则表示已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。

4）IMSDK.sendData(p, fnSucess, fnFail, fnComplete)：

• 用途：向某人发送一条消息。
• 参数p：{Protocal} 要发送的消息协议包对象，Protocal详情请见“/module/mb_constants.js”下的createCommonData函数说明。
• 返回值：{int} 0表示成功，否则表示错误码，错码详见“/module/mb_constants.js”下的MBErrorCode对象属性说明。

5）IMSDK.disconnectSocket()：

• 用途：客户端主动断开客户端socket连接。
• 说明 ：当开发者登陆IM后，需要退出登陆时，调用本函数就对了，本函数相当于登陆函数 loginImpl()的逆操作。

6）IMSDK.setDebugCoreEnable(enable)：

• 用途：是否开启MobileIMSDK-H5端核心算法层的log输入，方便开发者调试。
• 参数enable ：{boolean} true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。

7）IMSDK.setDebugSDKEnable(enable)：

• 用途：是否开启MobileIMSDK-H5端框架层的log输入，方便开发者调试。
• 参数enable ：{boolean} true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。

8）IMSDK.setDebugPingPongEnable(enable)：

• 用途：是否开启MobileIMSDK-H5端框架层的底层网络WebSocket心跳包的log输出，方便开发者调试。
• 参数enable ：{boolean} true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。
• 注意：必须 setDebugEnable(true) 且 setDebugPingPongEnable(true) 时，心跳log才会真正输出，方便控制。
• 返回值：true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。

9）IMSDK.loginImpl(varloginInfo, wsUrl)：

• 用途：登陆/连接MobileIMSDK服务器时调用的方法。
• 说明 ：登陆/连接MobileIMSDK服务器由本函数发起
• 参数varloginInfo：{PLoginInfo} 必填项，登陆要提交给Websocket服务器的认证信息，不可为空，对象字段定义见：PLoginInfo
• 参数wsUrl：{string} 必填项：要连接的Websocket服务器地址，不可为空，形如：wss://yousite.net:3000/websocket。

10）IMSDK.callback_onIMLog(message, toConsole)：

• 用途：由开发者设置的回调方法：用于debug的log输出。
• 推荐用法 ：开发者可在此回调中按照自已的意图打印MobileIMSDK微信小程序端框架中的log，方便调试时使用。
• 参数1： {String}：必填项，字符串类型，表示log内容。
• 参数2： {boolean}：选填项，true表示输出到console，否则默认方式(由开发者设置的回调决定)。

11）IMSDK.callback_onIMData(p, options)：

• 用途：由开发者设置的回调方法：用于收到聊天消息时在UI上展现出来（事件通知于收到IM消息时）。
• 推荐用法：开发者可在此回调中处理收到的各种IM消息。
• 参数1： {Protocal}：详情请见“/module/mb_constants.js”下的Protocal类定义)。

12）IMSDK.callback_onIMAfterLoginSucess()：

• 用途：由开发者设置的回调方法：客户端的登陆请求被服务端成功认证完成后的回调（事件通知于 登陆/认证 成功后）。
• 推荐用法 ：开发者可在此回调中进行登陆IM服务器成功后的处理。

13）IMSDK.callback_onIMAfterLoginFailed(isReconnect)：

• 用途：由开发者设置的回调方法：客户端的登陆请求被服务端认证失败后的回调（事件通知于 登陆/认证 失败后）。
• 说明 ：登陆/认证失败的原因可能是用户名、密码等不正确等，但具体逻辑由服务端的 callBack_checkAuthToken回调函数去处理。
• 推荐用法：开发者可在此回调中提示用户登陆IM服务器失败。。
• 参数1： {boolean}：true表示是掉线重连后的认证失败（在登陆其间可能用户的密码信息等发生了变更），否则表示首次登陆时的认证失败。

14）IMSDK.callback_onIMReconnectSucess()：

• 用途：由开发者设置的回调方法：掉线重连成功后的回调（事件通知于掉线重连成功后）。
• 推荐用法 ：开发者可在此回调中处理掉线重连成功后的界面状态更新等，比如设置将界面上的“离线”文字更新成“在线”。

15）IMSDK.callback_onIMDisconnected()：

• 用途：由开发者设置的回调方法：网络连接已断开时的回调（事件通知于与服务器的网络断开后）。
• 推荐用法 ：开发者可在此回调中处理掉线时的界面状态更新等，比如设置将界面上的“在线”文字更新成“离线”。

16）IMSDK.callback_onIMPing()：

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

17）IMSDK.callback_onIMPong()：

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

18）IMSDK.callback_onIMShowAlert(alertContent)：

• 用途：由开发者设置的回调方法：框架层的一些提示信息显示回调（本回调并非MobileIMSDK-H5端核心逻辑，开发者可以不需要实现！）。
• 说明 ：开发者不设置的情况下，框架默认将调用wx.showModal()显示提示信息，否则将使用开发者设置的回调——目的主要是给开发者自定义这种信息的UI显示，提升UI体验，别无它用】。
• 参数1：{String}：必填项，文本类型，表示提示内容。

19）IMSDK.callback_onIMKickout(kickoutInfo)：

• 用途：由开发者设置的回调方法：收到服务端的“踢出”指令（本回调并非MobileIMSDK-H5端核心逻辑，开发者可以不需要实现！）。
• 参数1 ：{PKickoutInfo}：非空，详见：PKickoutInfo

20）IMSDK.callback_onMessagesLost(lostMessages)：

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

21）IMSDK.callback_onMessagesBeReceived(theFingerPrint)：

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

五、前端开发指南

5.1如何引入SDK文件到您的前端工程中？

很简单：只需要将第2节中提到的SDK所有JS文件复制到您的Uniapp工程下即可。

SDK内容见下图：

5.2如何在代码中调用SDK？

第一步：在你的网页中引用SDK的js文件（具体例子详见Demo中的index.html文件）

第二步：直接在你的JS文件中编写回调配置代码（具体例子详见Demo中的index.js文件）

第三步：在你的JS文件中调用IM的登陆方法即可（具体例子详见Demo中的index.js文件）

注意：上图中登录连接的IP地址请设置为您的MobileIMSDK服务器地址哦。

六、Demo运行方法（在WebStorm中直接预览）

6.1重要说明

特别说明：MobileIMSDK的H5端（包括Demo在内），全部是静态的HTML+JS资源，可以通过WebStorm自带的HTML页面预览功能，直接自动加载到电脑的浏览器中运行和预览。

6.2预览方法

1）在Demo中的index.html文件中，移动鼠标，会在右上角出现如下图所示的浮出菜单：

2）点击右上角浮出菜单上相应的浏览器就可以自动预览了（这里以我电脑上已安装的Edge浏览器为例）：

七、Demo运行方法（在Web服务器中部署并访问）

7.1重要说明

特别说明：MobileIMSDK的H5端（包括Demo在内），全部是静态的HTML+JS资源，对于服务端是没有任何依赖的，只需要保证浏览器端能加载到即可，可以把它们放置在Tomcat、Apache、IIS、Nginx等等传统Web服务器中即可，无需任何动态运行环境。

7.2安装Tomcat

提示：以下Demo的部署，以Java程序员最常用和Tomcat为例（Apache、IIS、Nginx等依此类推）。

Tomcat的安装就没什么好说的，直接官网下载对应的版本即可：https://tomcat.apache.org/download-90.cgi。

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

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

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

▲ 配置要连接的服务器IP（以上代码详见demo/index.js 文件）

7.4部署Demo

说“部署”有点扯蛋，因为Demo（包括SDK）在内，全是HTML静态内容，只需要直接复制到任何一种Web服务器即可。

以下是复制到Tomcat服务器网页目录后的截图：

7.5启动Tomcat

提示：本手册中仅以启Tomcat为例，Apache、IIS、Nginx等Web服务器的启动请自动百度。

运行startup.bat启动Tomcat：

7.6Demo的运行效果预览

八、Demo功能预览和说明

九、Demo运行效果实拍图

1）Demo在手机端浏览器中的真机实拍图：

2）Demo在电脑端浏览器中的真机实拍图：

十、更多Demo运行效果截图

1）Demo在PC端浏览器运行效果：

2）Demo在手机端浏览器运行效果：

3）Demo在PC端各主流浏览器的运行效果：

十一、常见问题（FAQ）

11.1为什么浏览控制台下有些log不显示？

原因是浏览器控制台下的日志级别默认进行了过滤，勾选所有日志级别，就能看到SDK的详细日志输出了。

勾选所有的日志输出级别：

然后就能看到SDK中详细的日志输出了（就像下图这样），方便调试和研究：

十二、引用资料

[1] WebSocket 标准API手册

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

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

[4] MobileIMSDK-H5端基本介绍

[5] MobileIMSDK-H5端的开发手册（* 精编PDF版）

[6] MobileIMSDK的Demo使用帮助：Server端

[7] WebSocket从入门到精通，半小时就够！

一、基本介绍

• 1）超轻量级、极少依赖；
• 2）纯JS编写、高度提炼，简单易用；
• 3）基于标准WebSocket协议，客户端兼容性好；
• 4）支持运行于iOS、Android等移动端浏览器和各种PC端浏览器；
• 5）能与 MobileIMSDK（Github托管链接）的各种APP原生代码客户端完美互通；
• 6）可应用于手机端/PC端的网页聊天应用、企业OA、Web端等即时通讯场景。

二、与MobileIMSDK的关系

MobileIMSDK-H5端 是基于标准HTML5的WebSocket协议的 MobileIMSDK配套客户端库。

以下是MobileIMSDK的通信架构图：

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

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

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

三、与MobileIMSDK-Web的关系

• 1）都是Web端即时通讯框架；
• 2）都是纯JS编写；
• 3）都可以运行在手机、pc端的浏览器或web容器内。

• 1）MobileIMSDK-Web可以兼容不支持HTML5的旧版浏览器或容器，而MobileIMSDK-H5端必须运行在当前主流的HTML5浏览器或容器；
• 2）MobileIMSDK-Web需依赖于socket.io这种第3方通信层库，而MobileIMSDK-H5端无任何额外依赖。

• 选择一：如果您的应用必须兼容旧版浏览器（包括旧版IE等）：
  那唯一的选择就是MobileIMSDK-Web，因为它存在的主要价值就是为了兼容旧版浏览器；
• 选择二：如果您的应用只需运行在现今主流的HTML5浏览器或容器：
  那么建议您优先使用MobileIMSDK的H5端，必竟直接调用标准HTML5的WebSocket API，要简洁、轻量多了，也没有第3方依赖。

四、设计目标

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

• 1）前端与通信解偶：前端UI与网络通信代码解耦，UI界面的重构、维护、改版都非常容易和优雅；
• 2）轻量级和兼容性：受益于标准WebSocket，可很好地运行于现今主流的H5浏览器上，且无需额外依赖；
• 3）核心内聚和收敛：得益于长期的提炼和经验积累，SDK核心层高度封装，开发者无需理解复杂算法即可简单上手。
• 4）纯JS轻量级实现：纯JS编写，无Angular、EmberJS、VUE等各种重量级前端框架依赖，方便对接各种既有系统；

五、技术亮点

• 1）轻量易使用：超轻量级——纯JS编写且极少依赖，高度提炼——简单易用；
• 2）兼容性很好：基于标准WebSocket，可很好地运行于现今主流的H5浏览器上，且无需额外依赖；
• 3）断网恢复能力：拥有网络状况自动检测、断网自动治愈的能力；
• 4）送达保证机制：完善的QoS消息送达保证机制（自动重传、消息去重、状态反馈等），不漏过每一条消息；
• 5）支持多种设备：支持运行于iOS、Android等移动端浏览器和各种PC端浏览器；
• 6）通信协议封装：实现了一个对上层透明的即时通讯通信协议模型；
• 7）身份认证机制：实现了简单合理的身份认证机制；
• 8）完善的log信息：在开发调试阶段，确保每一个算法关键步骤都有日志输出，让您的运行调试更为便利；
• 9）前端代码解耦：实现了UI前端代码与sdk网络通信代码解偶，防止前端代码跟IM核心代码混在一起，不利于持续升级、重用和维护；
• 10）多端协议兼容：实现了与MobileIMSDK各APP端完全兼容的协议模型；

六、文件组成

SDK代码文件概览：

SDK代码文件用途说明：

七、Demo功能预览和说明

八、Demo运行效果实拍图

1）Demo在手机端浏览器中的真机实拍图：

2）Demo在电脑端浏览器中的真机实拍图：

八、更多Demo运行效果截图

3）Demo在PC端主流浏览器的运行效果（点击可看大图 ▼）：

十、详尽开发者手册

十一、相关资料

本文由携程技术Jim分享，原题“日访问过亿，办公IM及开放式平台在携程的实践”，下文进行了排版和内容优化。

1、引言

携程内部的办公IM项目最早在2016年立项，经历了初期简单办公场景下的纯IM服务，到支持简单办公组件的IM应用，又演变为一体化办公集成平台，进而演变为目前集成IM功能的开放式企业效率平台。

本文总结了携程办公IM这些年的发展历程及未来的演进方向，并着重从高可用、高性能和可扩展的角度，探讨开放式平台的技术实现及发展方向。

2、关于作者

Jim：携程高级研发经理，关注Java & Go技术栈后端研发。目前致力于TripPal开放平台的高可用、开放化进程及核心衍生服务。

3、什么是IM

IM（Instant Message）即时消息，是一种通过网络提供实时消息传输的在线沟通技术。

在移动互联网时代，IM的使用变得越来越广泛，通过各种技术手段使得用户之间的交流成本变的极低，沟通效率和用户体验有极大的提升。而且IM的出现极大地改变了目前互联网应用的形态，多数互联网应用只要做到了一定规模，一定会有自身IM的需求，而不是单纯地仅仅依托第三方（例如微信、云信等）。

PS：关于什么是IM，您也可详读专题文章《零基础IM开发入门(一)：什么是IM系统？》。

4、 携程办公IM的发展历程

早期携程使用微软的IM软件lync和自研的纯IM软件CtripTeam来支持企业内的沟通需求，这些软件在维护性、拓展性和可用性上都或多或少存在一些缺陷。同时随着互联网的发展，也逐渐不适合日益增长的办公需求和用户体验。

2017年左右，使用基于ejabberd+erlang的自研IM服务的Cchat项目应运而生，该项目的主要目标是在采用自研IM的基础上，实现IM与办公的结合。在完善IM服务的基础上，支持了一些常规的办公场景，如电话、假单、考勤、OA等，通常采用嵌入外部页面、跳转外部地址等方式提供服务。这个改造项目奠定了携程办公IM继续发展的基础。

随着项目的深入，最初的系统交互模式及服务管理模式逐渐不适用越来越复杂的办公场景及服务治理需求。于是在2019年上马了TripPal的改造项目，在结合公司国际化战略的基础上，倾力打造小程序平台，服务号等基础服务。在梳理、优化原有服务的同时，打造了诸多衍生服务。

2020年中开始，在继续推进企业内办公一站式平台的基础上，我们需要支持更多的外部场景，实际需求促使我们向开放式平台转型，这在服务整体架构、安全性、扩展性等方面都提出了新的要求及挑战。

5、携程TripPal开放平台总体架构

5.1Gateway网关层

这一层是所有请求调用流量的入口，主要功能如下：

• 1）服务路由；
• 2）集中式限流、风控、日志监控等功能；
• 3）调用IDS (Identity Service) 验证请求的合法性。

第 3）步中验证通过后，可以将用户ID、Token等基本信息，通过 HttpHeader 的方式向后端服务透传，后端服务可以直接使用UserID，也可以再次对Token进行认证

5.2IDS (Identity Service) 服务

IDS同时支持多种不同类型的访问令牌的鉴权，同时还负责令牌的颁发，以及RBAC+模块级别的接口控权。

另外，针对开放小程序，TripPal提供两种认证方式：

1）常规的Oauth第三方模式接入：

2）另一种是基于Oauth+开放平台签名的第三方认证，对于接入方相对简单：

5.3微服务层

这一层是整个系统的业务层，具体包含三种类型的微服务：

• 1）TripPal开放平台内部系统微服务：只有在特定用户认证和权限验证通过之后，外部才能访问；
• 2）开放平台对外提供的OpenAPI：采用Oauth+RBAC的方式控制权限；
• 3）自研小程序后端服务：根据安全需要，所有使用Oauth+模块权限的第一方小程序服务端。

目前TripPal自身的核心微服务应用达到28个，提供全集团的多端（C端、B端）基础服务能力，服务全公司超过500个业务应用，在线C端用户均值超过2万，日访问量超过亿。

6、 TripPal的IM服务

目前TripPal使用完全自研的基于Java实现的类ejabberd架构，底层采用的XMPP协议进行通讯。

Tips：

XMPP全称是ExtensibleMessageing and Presence Protocol，可扩展消息与存在协议。是目前网络上开源，最灵活，应用最广泛的一种即时消息通信协议。

1999年Jeremie Miller，首先提出了Jabber，一种为实现即时消息和存在的开放技术，后续基于这个协议，开发了一个开源的服务实现jabberd。后续，IETF国际标准组织介入，成立Extensible Messageing and Presence Protocol（XMPP）工作组，并开始标准化工作。

2000年，jabberd服务器1.0版本发布，那时Jabber协议的基本特点（基于XML的流，消息，存在，联系人列表等）都被固定下来。

2004年，IETF出版了RFC 3902和RFC3921，定义了XMPP的核心功能，成为推荐标准。

后续在2011年，IETF出版了RFC6120和RFC 6121，更新了XMPP的核心定义，替代了之前的RFC 3920和3921。

目前XMPP协议被XMPP Standards Foundation负责管理运作，集中于在IETF定义的基础XMPP规范之上，如何开发开放的协议扩展。

IM服务端做了大量的系统性的优化，从底层的数据库调优、底层通讯服务升级，到上层消息、群、群成员等核心功能的大幅改造。

底层通讯服务由之前的erlang完整迁移至java技术栈，服务可靠性、弹性伸缩、安全性和性能获得了提升。同时对上层偏业务的服务进行了改造，极大地提升了接口响应，服务稳定性也得到了提升，为整个产品的研发提供了重要支撑。

目前这套自研的IM 3.0服务在生产环境稳定运行，整体资源消耗比2.0时期有较大下降。

7、 TripPal办公衍生服务

7.1概述

在实际的企业办公场景下，尤其是大型企业复杂组织架构和管理模式的场景下，TripPal逐渐摸索出了自己的一套行之有效且契合携程场景的办公智能应用，如搜索中台，消息卡片，智能审批中台，角色服务，工作流引擎等。

本文简单介绍其中3个服务。

7.2智能审批中台

智能审批中台在集成携程自有的审批系统的同时也集成了自研的智能审批配置服务，该服务支持用户自定义整个审批单及审批流的全部细节。

7.3角色服务

角色服务在灵活定义角色范围及基础角色的基础上，支持用户灵活调整，动态管理，且自动接入审批中台，同时打通应用对接渠道。

整个角色服务在产品定义上分为如下表4个主要概念：

7.4在线文档

在线文档服务主要提供文档的在线协作能力，支持用户同时/实时的查看、编辑、保存和分享的能力。同时结合IM实现通知和反馈等功能。

技术实现上，在线文档是采用CRDT算法实现的无冲突merge（LastWrite Wins）、多端最终一致的分布式方案，同时兼具高可用、可容错的特性，在服务器发生故障时，允许Shift至另一台机器上继续执行，即使服务端完全宕机，客户端依然能够离线工作。

8、 TripPal高可用的实践

目前TripPal部署在3个机房，分为公有云1个机房及私有云2个机房。

总体架构在应用多机房部署、数据层跨机房DRC的基础上，采用就近访问的原则进行服务访问，其中一旦发生任意2个机房全挂的情况，都能保证系统内的核心应用仍能提供服务。

其中公有云机房的一期部署方案已经完成，二期部署方案和测试计划预计于7月完成，届时可以和大家分享一下混合云方案的一些细节和历程。

9、 开放平台的未来架构及演进方向

9.1概述

开放平台主要面向两类群体，开发者和用户。

所以主要有两个方向：

1）一是便捷开发，主要围绕降低开发者门槛、较低研发成本，打通不同开发者、应用之间的壁垒，实现生态共享。

2）另一方面，针对实际用户，在提高用户体验、数据安全的同时，实现用户服务能力整合和主动发现。

9.2开发者

在这方面，目前主流开放平台已经对开发者提供了强大的支持。

主要形式分为以下3种。

1）前端信任：

前端信任的目的是通过减少或杜绝开发者后端跟开放平台OpenAPI交互的方式，来降低开发者接入门槛，减少工作量。主要的做法是通过权限控制、签名、加密等手段使得小程序能够在前端拿到可信数据。

2）低代码(Low-Code)：

由于大量的互联网业务属于简单交互或模型化交互，以此为出发点，基于构建合理模型、简单业务函数等形式，可以允许开发者通过拖拽组件、简单伪业务代码等形式提供编程入口，可以大幅度降低开发者的研发门槛和成本，打破用户和开发者界线，提高开放平台整体生态的活力。

3）ServerLess：

基于云原生的ServerLess结合低代码，开放开发者的云端编程入口，同时提供云端基础组件，允许开发者无需部署实际的后端应用服务，极大降低的开发者的运营维护门槛。

9.3用户层面

目前业界主流开放平台在对用户本身的服务能力整合和挖掘上，投入的都比较少，也没有比较成熟的实践，我们认为在这方面可以围绕两个点展开。

一方面：第三方应用治理模式向商城化的转型。常规开放平台的应用治理和推广，基本是应用方独立管理和推广，但是随着应用数量的大幅度增加，以及应用方单方面推广难度较大等原因，亟需开放平台从生态整体角度进行支持和治理。这样可以在安全性、可维护性、便捷性等维度上对应用进行正向反馈，实现开放平台应用生态的可持续性和能力共享。同时，在特定场景下，结合用户分析、大数据及AI，提高用户主动或被动的应用发现能力。

另一方面：构建符合应用间开放协议的软件联盟，打破应用壁垒，围绕服务集成、开放应用的核心原则，使得不同的互联网业务或行为在一定程度上实现数据/能力共享。一般情况下，一个复杂互联网业务通常由多个异构子业务/子应用构成，这样，通过应用拆分、开放共享等形式，在一定程度上使复杂的互联网业务更加精细化、轻量化、可扩展。

9.4开放平台标准化、互通

目前国内外各大互联网公司、机构和组织都搭建了多种开放平台，用于提供各种各样的信息服务，在可以预见的未来，各个平台之间会有一个整合、标准化、互通的可能性。

那么构建标准开放协议，使得开放平台向底层沉淀的过程则至关重要。

10、 本文小结

通过实现基本IM开放平台架构，以及各种衍生服务，我们总结出了IM开放平台的一些核心能力。

主要是：

• 1）服务集成：根据不同的业务场景集成并提供相应场景下的基础服务能力；
• 2）开放应用：提供第三方接入能力；
• 3）高性能、高可用。

11、参考资料

[1] 零基础IM开发入门(一)：什么是IM系统？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

关于RainbowChat

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

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

► 详细产品介绍：http://www.52im.net/thread-19-1-1.html
► 版本更新记录：http://www.52im.net/thread-1217-1-1.html
► 全部运行截图：Android端、iOS端
► 在线体验下载：专业版(TCP协议)、专业版(UDP协议)      （关于 iOS 端，请：点此查看）

关于MobileIMSDK

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

工程开源地址是：

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

v11.6 版更新内容

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

（1）Android端主要更新内容：

• 1）[bug] 解决了APP从后台恢复时，有一定几率因后台多线程操作好友数据导致的线程安全崩溃问题；
• 2）[优化] 加固了一处好友列表中根据昵称取拼音首字母的非空检查逻辑；

（2）服务端主要更新内容：

• 1）[bug] 升级了MobileIMSDK至v6.5，尝试解决极小几率下Android端会误把“自已”踢掉的问题
• 2）[bug] 解决了因Netty库版本升级导致iOS消息推送失败报错的问题：
• 3）[bug] 解决了消息撤回时，被引用消息的历史记录没有正确处理撤回逻辑；
• 4）[优化] 为“接口1008-26-7”增加了“at_me”字段的返回；
• 5）[优化] 优化了“接口1008-26-8”，使得在跟Web互通时支持按时间戳的聊天记录分页加载方案；
• 6）[优化] 为“接口1008-26-8”增加了“消息发送者昵称”内容的返回；

部分功能运行截图（更多截图点此查看）：

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统，是RainbowChat的姊妹系统（RainbowChat是一套基于开源IM聊天框架 MobileIMSDK (Github地址)  的产品级移动端IM系统）。

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

[- 1 -] 移动端实时音视频直播技术详解（一）：开篇

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

[摘要] 本文是《移动端实时音视频直播技术详解》系列文章之第一篇，我们将从整体介绍直播中的各个环节。

[- 2 -] 移动端实时音视频直播技术详解（二）：采集

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

[摘要] 本文是《移动端实时音视频直播技术详解》系列文章之第二篇：我们将从整体介绍直播中的采集环节。

[- 3 -] 移动端实时音视频直播技术详解（三）：处理

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

[摘要] 本篇是《移动端实时音视频直播技术详解》系列文章之第三篇：我们将从整体讲解常见视频处理功能：如美颜、视频水印、滤镜、连麦等。

[- 4 -] 移动端实时音视频直播技术详解（四）：编码和封装

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

[摘要] 本篇是是《移动端实时音视频直播技术详解》系列文章之第四篇：我们将从整体讲解编码和封装。

[- 5 -] 移动端实时音视频直播技术详解（五）：推流和传输

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

[摘要] 本篇是《移动端实时音视频直播技术详解》系列文章之第五篇：我们将从整体讲解推流和传输。

[- 6 -] 移动端实时音视频直播技术详解（六）：延迟优化

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

[摘要] 本篇是《移动端实时音视频直播技术详解》系列文章之第六篇：我们将从整体讲解延迟优化技术。

[- 7 -] 理论联系实际：实现一个简单地基于HTML5的实时视频直播

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

[摘要] 本次分享就向大家介绍一下分享一下直播的整个流程和一些技术点，并动手实现一个简单的Demo。

[- 8 -] 实时视频直播客户端技术盘点：Native、HTML5、WebRTC、微信小程序

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

[摘要] 连麦视频直播的客户端主要包括：原生 APP、浏览器 H5、浏览器 WebRTC、微信小程序。浏览器上的应用包括 H5 和 WebRTC，前者可以拉流观看，后者可以实现推流和拉流。

[- 9 -]  Android直播入门实践：动手搭建一套简单的直播系统

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

[摘要] 实时视频直播是这两年非常火的技术形态，已经渗透到教育、在线互娱等各种业务场景中。但要搭建一套实时视频直播系统，并非易事，当然相关的直播技术理论在论坛的其它文章里已经写的非常详细，本文不再展开。

[- 10 -] 淘宝直播技术干货：高清、低延时的实时视频直播技术解密

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

[摘要] 本文由淘宝直播音视频算法团队分享，对实现高清、低延时实时视频直播技术进行了较深入的总结，希望分享给大家。

[- 11 -] 技术干货：实时视频直播首屏耗时400ms内的优化实践

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

[摘要] 直播行业的竞争越来越激烈，进过2018年这波洗牌后，已经度过了蛮荒暴力期，剩下的都是在不断追求体验。最近正好在做直播首开优化工作，实践中通过多种方案并行，已经能把首开降到500ms以下，借此机会分享出来，希望能对大家有所启发。

[- 12 -] 新浪微博技术分享：微博实时直播答题的百万高并发架构实践

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

[摘要] 本文将分享新浪微博系统开发工程师陈浩在 RTC 2018 实时互联网大会上的演讲。他分享了新浪微博直播互动答题架构设计的实战经验。其背后的百万高并发实时架构，值得借鉴并用于未来更多场景中

👉52im社区本周新文：《IM跨平台技术学习(十二)：万字长文详解QQ Linux端实时音视频背后的跨平台实践》，欢迎阅读！👈

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

本文由爱奇艺技术团队分享，作者isno，原题“爱奇艺海外App的网络优化实践”，下文进行了排版和内容优化等。

1、引言

做海外市场，特别目标是面向全球的用户，网络的重要性不言而喻。试想一个移动端应用，比如即时通讯IM，聊天消息的本质就是人跟人在说话，一条消息从发送到接受需要10秒的时间，这恐怕会让用户崩溃，随之就是被无情地卸载，开拓海外市场那就是做梦了。

本次分享的文章内容，基于爱奇艺面向全球用户推出的国际版，在海外跨国网络环境复杂的前提下，针对性地做了一系列弱网优化实践，取得了不错的效果，在此总结分享我们的一些做法和优化思路，希望对你有所帮助。

总结下来，跨国弱网优化实践的几个核心就是：

• 1）能不请求网络就不请求；
• 2）请求的链接目标 0-RTT；
• 3）请求的内容越小越好。

正文内容我们将逐个技术点展开了分享。

2、系列文章

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

1. 《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
2. 《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
3. 《移动端IM开发者必读(三)：爱奇艺移动端跨国弱网通信的优化实践》（* 本文）

如果您是IM开发初学者，强烈建议首先阅读《新手入门一篇就够：从零开发移动端IM》。

3、 跨国弱网样本摸底

在 App 初期版本内增加请求链路的采样。样本数足够的情况下，可以清楚你要推广的市场是怎样的环境。样本数据让我们清楚发现了各个国家、地区网络的问题，在大规模宣传和投入前，做好 App 的基础工作非常重要。

海外用户至海外数据中心的网络延迟（这是监测节点数据，用户端延迟更高）：

海外主要国家、地区移动网络情况：

在调研阶段，我们发现了以下问题比较明显，切实影响我们的运营及 App 体验。

这些问题主要是：

• 1）运营商劫持严重，DNS 劫持、HTTP 劫持；
• 2）移动端网络复杂 ，东南亚的网络基础建设还待改善；
• 3）低端 Android 机有一定的占比，数量级别影响决策；
• 4）国际网络用户端到服务器的延迟高。

在初期阶段，技术工作的核心是解决以上问题，为后续的运营做好基础建设。因为业务接口大部分为 HTTP 形式，就开始围绕 HTTPS 进行针对性改进。

一个HTTPS请求阶段分析：

一个 HTTPS 在第一请求会有 5 个 RTT：

1RTT(DNS)+ 1RTT(TCP 握手)+ 2RTT(TLS1.2)+ 1RTT(HTTP 链接)

如果以端到服务 50ms 延迟为例：

一个 HTTPS 的接口延迟 =  350ms =  50*5+ 100ms（服务端）

如果目标是一个非国内用户，打开首页需要 1.1s, 这个时间显然有点长。

下面开始进行技术改进的正文，以下是概括技术性优化的关键点：

4、基础链路的改进优化

4.1DNS 优化调整

DNS 的解析改为 HTTPDNS，DNS 的改进上线后观察初始连接请求提升 17% 的效率。

目的主要是：

• 1）解决域名劫持问题 （东南亚地区回传的数据显示有不少劫持）；
• 2）解决 LocalDNS 非就近分配问题；
• 3）结合业务可以做解析预热。

4.2传输层的优化调整

MTU 的问题 ：

• 1）Client 端和 Server 端不同的 MTU 值会导致丢包率过高。AWS 某些场景实例默认巨型帧：MTU 是 9001，但接收端默认 1500，这时候就会出现一些丢包的现象；
• 2）如果你用了多个云商服务，用 VPN 组网，IP隧道封装的数据临界 1500，又会造成丢包、包重传问题；
• 3）最严重的情况：部分网络封杀 ICMP 协议，导致 MTU 无法自动协商。

TCP 拥塞控制优化：

拥塞窗口 CongWin 是未接收到接收端确认情况下连续发送的字节数; 。CongWin 是动态调整，取决于带宽和延迟的积，比如 100MB 的带宽 100ms 的延迟环境。

时延带宽积 = 100Mbps*100ms = (100/8)*(100/1000) = 1.25MB

理论上 CongWin 窗口可以最大化到 1.25MB。CentOS 默认CongWin = 20*MSS，在 29KB 左右，离上限 1.26MB 差太多了，默认值上调TCP的启动会更快。

TCP 快速打开 (TCP Fast Open：TFO)：

TCP 的 keepalive 下依然会有链接断掉重建的情况，TFO 是针对这种情况的优化。

TFO 的原理机制：

在我们观察中开启 TFO 机制，海外业务一个 RTT 通常时间在 100ms 以上，HTTP 请求效率提升了 12% 左右。

5、应用层的改进优化

5.1HTTP 的优化

HTTP1.1 有个 keep-alive 作用是复用 TCP 链接，减少新建的消耗，对于浏览器的业务比较适用，但对于移动端这种时间分散的请求，大部分请求还是新建连接。

HTTP1.1 的串行机制有头部阻塞的问题。

5.2SSL 层优化

尽量升级到 TLS1.3（微信的TLS1.3实践：《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》），利用 Pre-shared Key 机制，开启 ssl_early_data 可以进一步优化 “0-RTT ”，如果无法升级 TLS 版本，优化密钥算法为 ECDHE，运算速度快，握手的消息往返由 2-RTT 减少到 1-RTT，能达到与 TLS1.3 类似的效果。

TLS 版本的区别：

TLS1.3 经过优化后，一个 HTTP 请求由之前的 4 个 RTT 减少为 3 个 RTT。

5.3升级 HTTP2.0

几个重要的改进点：

• 1）分帧传输；
• 2）多路复用；
• 3）头部压缩。

多路复用：

在 HTTP/2 中，两个非常重要的概念：帧（frame）和流（stream）。帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。多路复用，就是在一个 TCP 连接中可以存在多条流。这些改进可以避免 HTTP 队头阻塞问题，提高传输性能。

头部压缩：

开发人员如果不注意对 header 内容的控制，会造成 header 内容失控的现象，客户端极容易存储一个非常大的 Cookie。

HTTP2 的分帧传输机制：

5.4边缘节点动态加速

这个是非常有效的方式。

尽可能离用户最近，利用边缘节点对路由、链路进行优化，提高动态服务的效率。相较于直连模式，使用动态加速后，P90 的接口延迟效率提升了 60%。

爱奇艺海外动态加速的效果提升（请求时间为秒）：

5.5启用兜底机制

对于失败的请求，启用兜底的协议 QUIC 或者 kcp。

客户端的失败率在 3% 左右，对这部分请求使用 UDP 协议兜底尝试，在我们的观察成功率提升了 45%。

6、传输内容的优化

6.1应用 Brotli

因为预置了字典，在同等级别的压缩率下，对比 gzip 至少提升了 17% 的压缩比，接口平均的 Content-Size 由 30KB，降至 18KB。

6.2接口由 JSON 改为 Google Protobuf

应用 Protobuf 的重要原因是解析效率比 JSON 至少高四五倍，在节点深度和数据量大的情况下更明显。

但注意 Protobuf 内部的 varint 压缩，只对小于 128 的数字进行可变长压缩。实际效果不大，生产环境如果数据量大，外层的压缩如 gzip 不可少。

PS：关于Protobuf的资料，可以进一步阅读《IM通讯协议专题学习》。

6.3图片格式升级为 WebP

在应用 WebP 的同时，降低海报图片的质量，实践看海报的 quality 设置为 85% 肉眼难以分辨，相对同质量的 JPEG 或者 PNG ，可以最大减小 45% 的体积。

应用效果明显。App 打开首页图片的加载提升肉眼可见。

7、业务层面的优化改进

7.1减少不必要请求：

一些通用内容，如导航、频道，通常由运营人员主动更新。

如下图：增加一个启动阶段请求的接口，里面放入内容更新的时间戳，与本地 cache 的时间戳有差异，则异步请求更新。

 

7.2区别用户网络，适应不同的策略

具体作法是：

• 1）对于视频，非 WiFi 默认启播码率为 360P；
• 2）对于海报，后端接口提供两种质量的 Url，WiFi 高质，4G 低质。

7.3更多的业务优化

增加请求重试、调整 HTTP 的超时时间，请求缓存等等  这些可以根据业务的需求进行调整。

8、本文小结

爱奇艺海外版APP经过一系列细节优化，用户体验持续上升。用户接口延迟、客户端失败率、视频播放成功率一系列的关键指标得到很大的改善。这也助力爱奇艺在东南亚多个国家的应用市场排名升至 TOP 1。

另外 App 优化、Server 延迟优化、产品体验的改进，这一系列只有相辅相成才可以最大化提升用户体验。

9、参考资料

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

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

[3] 新手入门一篇就够：从零开发移动端IM

[4] 现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障

[5] 全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等

[6] 美图App的移动端DNS优化实践：HTTPS请求耗时减小近半

[7] 百度APP移动端网络深度优化实践分享(一)：DNS优化篇

[8] 百度APP移动端网络深度优化实践分享(二)：网络连接优化篇

[9] 百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇

[10] 爱奇艺移动端网络优化实践分享：网络请求成功率优化篇

[11] 美团点评的移动端网络优化实践：大幅提升连接成功率、速度等

[12] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

[13] 谈谈移动端 IM 开发中登录请求的优化

[14] 移动端IM开发需要面对的技术问题（含通信协议选择）

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

[16] 微信对网络影响的技术试验及分析（论文全文）

[17] 腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）

[18] IM开发者的零基础通信技术入门(十二)：上网卡顿？网络掉线？一文即懂！

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

[20] IM通讯协议专题学习(一)：Protobuf从入门到精通，一篇就够！

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

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统，是RainbowChat的姊妹系统（RainbowChat是一套基于开源IM聊天框架 MobileIMSDK (Github地址)  的产品级移动端IM系统）。

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

[- 1 -] 一个基于长连接的安全可扩展的订阅/推送服务实现思路

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

[摘要] 本文将从如何保证连接的业务安全（禁止非业务认证的连接订阅消息）和如何扩展能够支持更多的消息和连接两点展开分析。

[- 2 -] 实践分享：如何构建一套高可用的移动端消息推送系统？

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

[摘要] 本文追溯了推送技术的发展历史，剖析了其核心原理，并对推送服务的关键技术进行深入剖析，围绕消息推送时产生的服务不稳定性，消息丢失、延迟，接入复杂性，统计缺失等问题，提供了一整套平台级的高可用消息推送解决方案。实践中，借助于该平台，不仅能提能显著提高消息到达率，还能提高研发效率，并道出了移动开发基础设施的平台化架构思路。

[- 3 -] Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)

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

[摘要] 本文内容整理自奇虎360公司的周洋在 Gopher China 2015 大会上的分享（演讲PPT下载：《Go语言构建高并发消息推送系统实践PPT(来自奇虎360)[附件下载] 》），该次分享以360海量在线的消息推送系统为例，来探讨使用Go语言构建高并发消息推送系统时所遇到的问题以及总结出的各种实践技巧。

[- 4 -]腾讯信鸽技术分享：百亿级实时消息推送的实战经验

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

[摘要] 本文整理了此次甘恒演讲的内容并以文字的方式分享给大家，希望能给技术同行带来一些技术上的启发。

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

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

[摘要] 本文作者是美拍的架构师，经历了直播弹幕从无到有，从小到大的过程，借此文为大家分享构建弹幕系统的经验，希望能为正在开发或正打算开发弹幕、消息推送、IM聊天等系统的技术同行带来一些启发。

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

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

[摘要] 我会详细的介绍下京麦实时消息推送是如何在演变中不断完善的。

[- 7 -] 了解iOS消息推送一文就够：史上最全iOS Push技术详解

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

[摘要] 本文将对iOS Push的在线push、本地push及离线（远程）push进行了详细梳理，介绍相关逻辑、测试时要注意的要点以及相关工具的使用。

[- 8 -] 基于APNs最新HTTP/2接口实现iOS的高性能消息推送(服务端篇)

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

[摘要] 本文要分享的消息推送指的是当iOS端APP被关闭或者处于后台时，还能收到消息/信息/指令的能力。

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

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

[摘要] 本文将描述“达达-京东到家”的订单即时派发系统从无到有的系统演进过程，以及方案设计的关键要点，希望能为大家在解决相关业务场景上提供一个案例参考。

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

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

[摘要] 本文主要分享的是如何从零设计开发一个中大型推送系统，因限于篇幅，文中有些键技术只能一笔带过，建议有这方面兴趣的读者可以深入研究相关知识点，从而形成横向知识体系。

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

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

[摘要] 本文分享了爱奇艺基于Netty实现WebSocket长连接实时推送网关时的实践经验总结。

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

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

[摘要] 本文分享的离线消息推送系统设计并非专门针对IM产品，但无论业务层的差别有多少，大致的技术思路上都是相通的，希望借喜马拉雅的这篇分享能给正在设计大用户量的离线消息推送的你带来些许启发。

[- 13 -] 直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路

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

[摘要] 本文将回顾微信直播聊天室单房间海量用户同时在线的消息组件技术设计和架构演进，希望能为你的直播聊天互动中的实时聊天消息架构设计带来启发。

[- 14 -] 直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践

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

[摘要] 本文主要分享的是百度直播的消息系统的架构设计实践和演进过程。

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

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

[摘要] 本文将首先从Pike的系统架构升级、工作模式升级、长稳保活机制升级等方面介绍2.0版本的技术演进，随后介绍其在直播、游戏等新业务场景下的技术特性支持，并对整个系统升级过程中的技术实践进行了总结。

[- 16 -] 揭秘vivo百亿级厂商消息推送平台的高可用技术实践

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

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

[- 17 -] 得物从零构建亿级消息推送系统的送达稳定性监控体系技术实践

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

[摘要] 本文分享的是得物针对现有的消息推送系统的消息送达耗时、实时性、稳定性等方面问题，从零到一构建完整的消息推送质量监控体系和机制的技术实践。

[- 18 -] B站千万级长连接实时消息系统的架构设计与实践

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

[摘要] 本文将介绍B站基于golang实现的千万级长连接实时消息系统的架构设计与实践，包括长连接服务的框架设计，以及针对稳定性与高吞吐做的相关优化。

👉52im社区本周新文：《IM跨平台技术学习(十一)：环信基于Electron打包Web IM桌面端的技术实践》，欢迎阅读！👈

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

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

[- 1 -] iOS的推送服务APNs详解：设计思路、技术原理及缺陷等

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

[摘要] 本文重点介绍APNs的设计思路、技术原理以及各种缺陷槽点，也希望能给自已设计推送系统的同行带来启发。

[- 2 -] 信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑

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

[摘要] 集成推送需要注意些什么？集成之后，怎样确认自己是否正确集成了远程消息推送呢？

[- 3 -] Android端消息推送总结：实现原理、心跳保活、遇到的问题等

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

[摘要] 最近研究Android推送的实现, 研究了两天一夜, 有了一点收获, 写下来既为了分享, 也为了吐槽. 需要说明的是有些东西偏底层硬件和通信行业, 我对这些一窍不通, 只能说说自己的理解.

[- 4 -] 扫盲贴：认识MQTT通信协议

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

[摘要] MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。

[- 5 -] 一个基于MQTT通信协议的完整Android推送Demo

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

[摘要] 本文主要介绍的是基于MQTT实现一个简单的Android消息推送系统。更多推送技术资料请见：http://www.52im.net/forum.php?mod=collection&action=view&ctid=11

[- 6 -] 求教android消息推送：GCM、XMPP、MQTT三种方案的优劣

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

[摘要] 对各个方案的优缺点的研究和对比，推荐使用MQTT协议的方案进行实现，主要原因是在文中。

[- 7 -] IBM技术经理访谈：MQTT协议的制定历程、发展现状等

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

[摘要] MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。

[- 8 -] 移动端实时消息推送技术浅析

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

[摘要] 本文将从移动端无线网络的特点来谈谈实时消息推送的技术原理及相关问题，希望能给你带来些许启发。

[- 9 -]  扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别

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

[摘要] 本文将从原理上谈谈两个平台上实时消息推送的区别。

[- 10 -] 绝对干货：基于Netty实现海量接入的推送服务技术要点

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

[摘要] 通过本文的案例分析和对推送服务设计要点的总结，帮助大家在实际工作中少走弯路。

[- 11 -] 移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）

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

[摘要] 本文主要内容由微信开发团队人员编写，来自 WeMobileDev

[- 12 -] 为何微信、QQ这样的IM工具不使用GCM服务推送消息？

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

[摘要] 同样是IM软件，为什么微信不使用GCM的机制而要自己开启一个Service常驻后台轮询，并且还要使用多种方式触发该Service导致无法关闭，这种机制既耗电又浪费网络资源，微信放弃成熟的GCM推送机制而使用自身后台服务的软件是否有其他自身目的性？还是说微信某些功能必须自身常驻呢？

[- 13 -] 极光推送系统大规模高并发架构的技术实践分享

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

[摘要] 2016年的双十一大促改改过去，作为国内第三方推送服务的领导者，极光（JIGUANG）采取了哪些措施来应对高并发推送服务？同时，极光基于 ICE 打造高可用云推送平台，其背后有哪些技术细节值得探索？

[- 14 -] 从HTTP到MQTT：一个基于位置服务的APP数据通信实践概述

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

[摘要] 基于以上业务场景，如此频繁的数据交互，要达到数据的实时推送级别，该选用哪种技术？HTTP短轮询还是基于TCP的实时长连接？本文给出的答案是使用MQTT协议，请继续往下阅读。

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

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

[摘要] 此文内容整理自魅族架构师于小波在“魅族技术开放日”的演讲分享，本次演讲中于小波分享了魅族在实现2500万长连接的实时消息推送系统中所遇到的坑和一些心得体会，希望对实时消息推送技术相关的技术同行有所启发和帮助。

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

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

[摘要] 本文内容来自ChinaUnix的IT名人堂对魅族系统架构师于小波的专访，于小波分享了在构建魅族海量长连接的实时消息推送系统过程中所总结出的各种心得和体会，希望对正在或即将开发消息推送系统的开发者同行带来一些启发。请往下看正文。

[- 17 -]  深入的聊聊Android消息推送这件小事

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

[摘要] 微信由于有国际版，将 GCM 作为辅助公共通道，但仅用于激活微信自己的 Push 通道，并没有通过 GCM 来传递数据，这点也是为了复用心跳的优化策略和数据处理逻辑。

[- 18 -] 基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)

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

[摘要] 本文将围绕 Hybrid App（以Cordova为例）的 WebSocket 消息推送进行一系列的实践性探索。

👉52im社区本周新文：《社交软件红包技术解密(十三)：微信团队首次揭秘微信红包算法，为何你抢到的是0.01元》，欢迎阅读！👈

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

本文由腾讯技术何金源分享，原题“不畏移山，手机QQ技术架构升级变迁史”，本文进行了排版和内容优化等。

1、引言

接上篇《总是被低估，从未被超越，揭秘QQ极致丝滑背后的硬核IM技术优化》，本文则将重点介绍手机 QQ 客户端技术架构升级背后的故事。

手机 QQ 经过20多年发展，功能不断增加，代码不断累积，架构已经变得越来越臃肿，影响到协作团队开发效率，对用户体验、质量稳定都有较大风险，因此手机 QQ 亟需技术架构的升级。但是对如此庞大的项目进行架构升级，在行业内也是少有的，手机 QQ 架构升级面临的困难和挑战都十分巨大，本文将围绕最新手机 QQ 客户端项目背景、项目历程、项目挑战、项目成果等方面进行深入介绍。

2、手机QQ的历史包袱

在过去20多年里，手机 QQ 从原来纯粹的即时通讯IM工具，成长为承载了空间、频道、短视频、超秀、增值服务等众多业务的平台。

随着业务越来越复杂，最初设计的技术架构变得越来越不适配，业务相互之间耦合越来越严重，时常会遇到改一个问题，牵扯出 N 个问题，问题改不动，代码债越积越多的情况，历史的包袱如同一座大山横在每一位手机 QQ 项目成员面前。

2020年，我们开始着手做架构升级。

鉴于手机 QQ 的业务复杂度、代码量级都非常大，评估下来架构升级的工作量大得惊人，于是我们采用分阶段、逐步演进的策略去进行架构升级。

整体回顾，手机 QQ 的架构升级时间线是这样的：

3、“解耦重构”架构设计

虽然历史包袱如同一座大山，但是手机 QQ 项目成员也有移山的意志和决心。

在2020年，手机 QQ 启动了名为“工业化实践”的技术架构升级项目，这标志着手机 QQ 工程首次系统性地进行业务边界划分、解耦和重构升级。

从上图可看出，旧架构虽然有模块化和插件化，但存在以下不足：

• 1）边界不清晰：主工程承载基础和大部分业务代码，导致基础和业务代码边界不清晰；
• 2）代码耦合紧：基础核心类持续膨胀、业务之间代码依赖不合理；
• 3）开发效率低：代码修改扩散造成 CR、解冲突、定位问题成本高，同时拖慢编译速度。

针对以上不足，对手机 QQ 工程重新设计了架构：

1）新架构按业务划分模块，业务模块之间是相互解耦的，业务模块之间通过接口和路由进行通信；

2）同时按层级设计划分，层级自上而下依赖，上层模块可依赖下层模块，但下层模块不能逆向依赖上层模块。

手 Q 客户端新架构：

新架构的主要收益：

• 1）模块更加内聚：新特性开发影响范围逐步收敛到模块内部，提升研发效率；
• 2）接口更加清晰：依赖数减少，可测性提升，更易于通过单元测试、接口测试保障代码逻辑正确性，提升产品质量。

4、“解耦重构”的实践历程

4.1概述

手机 QQ 工程各个业务之间的依赖非常严重，对它进行解耦重构不是一蹴而就的事情，需要按阶段制定目标，一步一步地优化。

通过整理，手机 QQ 工程解耦重构划分为以下三个阶段。

4.2阶段一（2020.11 - 2021.2）

基本完成约300万行核心代码的解耦，一共约30个基础模块和40个基础组件完成解耦，核心业务模块基本完成解耦。

开发新功能时，因为接口与服务实现是隔离的，通过接口依赖的代码不会再耦合严重。

4.3阶段二（2021.3 - 2021.6）

目标：业务模块继续解耦，建设防劣化机制。

成果：

• 1）API 代码占比与依赖数不增加；
• 2）完成防劣化机制搭建，在合入阶段拦住不合理修改；
• 3）完善动态化能力，优化插件与宿主间通信机制和发布效率。

4.4阶段三（2021.7 以后）

目标：进一步完善基础模块和组件化，实现子工程化。

成果：

• 1）完善基础模块和公共组件重构，建立基础模块发布组件流程；
• 2）对频道、小世界业务实现子工程化，独立编译运行。

5、“解耦重构”的技术收益

在重构基础上，梳理依赖关系，通过三个阶段改善模块化水平，提高编译速度和研发效率，流水线的编译耗时提升50%。

代码冲突方面也得到明显改善，对比重构前后数据，冲突文件数减少60%，冲突次数减少30%，大大提升开发效率。

6、手机QQ下一代架构：NT架构

在成功迈出改革的第一步之后，我们将注意力转向了手机 QQ 面临的版本碎片化问题。

不同端各自发展，形成了所谓的“烟囱式”结构，其中代码的复用率极低。这种结构带来了多端体验不一致、端内业务体验参差不齐以及每次版本更新时高昂的开发和维护成本等问题。

为了解决这些问题，并在提升用户体验、优化性能和提高研发效率方面实现突破，我们不得不深入思考。

正是这些迫切的需求和挑战促使我们启动了改革的第二步——推进手机 QQ NT 架构升级项目。

在 NT 架构设计之初，我们坚定认为不应该继续缝缝补补，而是应该采用最新且合理的技术理念，摒弃了简单的修补式方法。这次升级不仅是技术上的一次大刀阔斧的改造，更是一场深思熟虑的技术转型。

我们重视在不造成架构大规模动荡的前提下，制定了一条清晰、可行的实施路径。目标是以更少的人力投入实现更高的工作效率和成果，确保了升级过程中的高效和稳健。这种方法不仅保证了项目的顺利进行，也为未来的技术发展和迭代奠定了坚实的基础。

7、NT架构落地之难

由于手机 QQ 的历史悠久且拥有庞大的用户群，该项目在业务和用户层面都展现了巨大的复杂性。

具体来看，项目层面的挑战包括：

• 1）代码总量庞大：手机端代码近千万行，形成了一个技术上的庞然大物；
• 2）测试复杂性高：测试用例众多，功能繁杂，且存在部分文档缺失的情况；
• 3）依赖组件过时：项目中依赖了一些陈旧且缺乏维护的组件，以及大量无人维护的二进制库；
• 4）研发流程保障：在进行架构升级的同时，必须确保研发工作流程能够平稳过渡，以免影响到研发效率。

用户层面上的挑战则包括：

• 1）在长达一年以上的升级过程中，日常版本需要正常迭代；
• 2）用户本地数据量巨大，如超过 10G 的本地消息数据库；
• 3）项目需在技术优化的同时提升用户体验与活跃度，确保技术优化在用户端实现价值。

面对这些复杂度，项目的核心难点主要集中在以下三个方面。

1）海量功能项目的架构升级和统一：针对全终端、全功能和全项目团队的整体升级，确保架构升级过程中不能有任何缺失。手机 QQ 是在发展了20多年进行彻底重构，难度空前，没有资料可参考。

2）IM 全链路架构重写升级：解决陈年技术债，优化消息架构，平稳迁移用户历史数据，并提升消息性能。QQ 消息架构有陈年技术债，很多 QQ 历史版本里，没有统一的消息 ID 生成规则，没有统一的存储和索引方案，消息类型也是无序扩张。所以，既需要对IM全链路重写优化，同时在过程中，还需要平稳迁移用户历史数据，最终完成升级，保护用户数据、用户体验不受影响。

3）用户体验提升与活跃数据提升：逐步优化核心功能体验，不影响用户习惯，通过提升体验推动产品数据增长。代码的重写不能全盘一次性推倒重来。核心功能体验要保持，逐步优化，不能影响用户使用习惯。

这些挑战不仅说明了手机 QQ NT 架构升级项目的复杂性，也证明了我们在面对前所未有的技术难题时的决心。

8、NT架构设计

为了实现架构升级和统一，项目团队先用 C++ 开发了具备 QQ IM 核心功能的跨平台内核层：把 IM 核心业务逻辑（好友、群、频道等消息逻辑、资料与关系链逻辑、图片语音视频等富媒体收发逻辑、实时音视频逻辑等），QQ 通用组件（数据库、协议编解码、网络传输等），以及线程/网络/IO 等通用资源管理模块和操作系统封装部分，由原来的各平台原生语言实现，统一下沉到 C++ 跨平台层。

为了控制项目质量风险，NT 跨平台内核先接入用户量相对较少，对功能补齐紧迫度高的桌面端，完全用新架构重写桌面端。

在桌面端成功完成功能验证和质量测试之后，我们开始了向移动端的迁移工作，并顺利完成了 iOS 和安卓平台的集成。

当然，移动端的接入远远不像图中描述的这般容易，接下来将介绍其中的解决方案和主要过程。

9、 IM客户端全链路重写升级

在新的 NT 架构基础上，对 QQ 来说，最核心的技术升级，是 IM 全链路的升级。

IM 消息数据源复杂，历史包袱很重，升级过程的遇到的第一个难点就是数据转换及存量数据迁移到新版本问题。

比如：

• 1）老版本的 QQ，好友消息没有唯一标识字段，导入和去重影响大；
• 2）2012年以前的版本，群消息没有支持漫游，消息无唯一字段；
• 3）各平台消息数据格式不同，复杂度高，iOS 和 Android 分别有约200种消息类型；
• 4）富媒体（图片、视频、语音、文件）资源，存储的目录结构、命名都不同；
• 5）特殊消息，如结构化消息、Ark 消息、小灰条消息，需要做转换，完成业务的梳理和下架工作；
• 6）还有因为各种功能的变迁带来的遗留数据问题，如已经退出或者解散的群和讨论组等。

所以，首先需要做 IM 的精简。项目团队基于用户价值考虑，零基思维，完成消息格式统一，对消息和会话类型进行彻底精简，为 QQ 消息长治久安打下基础。

有了全端格式统一和类型精简的基础，开始用大小、性能、安全性综合最优方案设计跨平台统一的全新客户端 DB，然后再考虑旧 DB 的数据，如何平稳升级到新 DB。

移动端和桌面端不同，活跃用户全年在线，有些手机本地纯文本消息的 DB 文件超过10G，加上富媒体、文件等，总数据量超过100G，而且移动端又有存储空间小、功耗敏感、后台杀进程等多方面限制，需要设计出一套周密的升级策略，保护用户核心数据资产不丢失。

方案核心要点：

• 1）断点续导：移动端场景，进程随时可能被杀或退出。确保消息不丢失、不重复；
• 2）用户分级：跟进消息数据大小，用户分为三类，做不同的体验优化，减少对用户的影响；
• 3）优化发烫和耗电：限制导入速度，防止手机发烫。手机切后台后停止导入。对消息数据多的用户，引导用户设置在后台导入；
• 4）监控：做好各种导入异常上报监控，随时跟进用户反馈。

通过设计周密的升级策略，内部多轮推演，外部从百级开始放量，全方位监控，并用兜底策略保障不丢消息。最终结合监控数据和用户反馈数据，完成了全量用户的全量数据平稳迁移新 DB。

10、客户端核心功能优化提升

不仅是消息，在 NT 架构重写升级过程中，对 QQ 核心功能也一起做了更彻底的重构，手机 QQ 原生功能进行了大规模解耦，通用的部分进行优化并下沉为统一的 NT-Runtime 原生组件（NT 组件服务及框架层）。基于重构后的架构，也对性能进行全面优化。

首先是消息相关核心模块的优化。

消息逻辑下沉到 C++ 跨平台，也推动上层进行架构刷新。

以聊天窗口（AIO）为例：基于全新数据流架构 + 数据预加载 + UI 逻辑并行化的设计思路，完成单向数据流驱动与异步加载渲染，系统资源全力供给 AIO 消息列表，最终性能指标提升明显，AIO 内查看、跳转、滑动消息，顺畅丝滑。

核心技术优化方案：

• 1）采用基于单向数据流的 MVI 架构，实现业务解耦；
• 2）预加载和异步渲染，实现消息无缝滑动；
• 3）消息加载并行化，减少首屏和滑动时的加载时间；
• 4）消息动态加载、释放，优化内存占用。
• 5）200+业务组件懒加载，实现数据分层和按需加载。

其它 QQ 主场景，如消息列表页、消息与富媒体收发、图片视频查看等，也采用相同的路径进行优化，最终性能全面提升。

11、本文小结

在手机 QQ 超过20年的发展历程中，应用功能的不断扩展和代码量的持续增长积累了巨大的技术债务，给原有的客户端架构带来了沉重的负担。最新版手机QQ通过一系列的架构演变和技术升级，成功地实现了从臃肿不堪到模块化、高效、稳定的转变。

客户端架构由各端烟囱式架构逐步升级为多端跨平台复用的 NT 架构，降低多端维护人力成本，提升 QQ 全端开发效率，为 QQ 的持续发展和技术迭代打下了坚实的基础。

展望未来，QQ 将基于 NT 架构，在技术创新的道路上继续前行，不断进行架构优化和技术升级，为用户提供更加流畅稳定的产品体验。

12、相关资料

[1] 总是被低估，从未被超越，揭秘QQ极致丝滑背后的硬核IM技术优化

[2] 大型IM工程重构实践：企业微信Android端的重构之路

[3] 企业微信针对百万级组织架构的客户端性能优化实践

[4] 微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题

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

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

[7] 全面解密新QQ桌面版的Electron内存优化实践

[8] 移动端IM实践：iOS版微信界面卡顿监测方案

[9] 微信团队原创分享：Android版微信的臃肿之困与模块化实践之路

[10] 微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等

[11] 微信团队分享：微信支付代码重构带来的移动端软件架构上的思考

[12] 微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化

[13] 抖音技术分享：飞鸽IM桌面端基于Rust语言进行重构的技术选型和实践总结

[14] 阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践

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

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

1. 微信朋友圈千亿访问量背后的技术挑战和实践总结
2. 腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)
3. IM全文检索技术专题(二)：微信移动端的全文检索多音字问题解决方案
4. 微信团队分享：iOS版微信的高性能通用key-value组件技术实践
5. 微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？
6. 微信团队分享：微信Android版小视频编码填过的那些坑
7. IM全文检索技术专题(一)：微信移动端的全文检索优化之路
8. 企业微信客户端中组织架构数据的同步更新方案优化实战
9. 微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解
10. 微信“红包照片”背后的技术难题
11. 移动端IM实践：iOS版微信的多设备字体适配方案探讨
12. 腾讯信鸽技术分享：百亿级实时消息推送的实战经验
13. IPv6技术详解：基本概念、应用现状、技术实践（上篇）
14. 腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践
15. 微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅
16. 社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等
17. 社交软件红包技术解密(四)：微信红包系统是如何应对高并发的
18. 社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践
19. 微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结
20. IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现
21. 微信团队分享：微信支付代码重构带来的移动端软件架构上的思考
22. IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总
23. 微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路
24. 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等
25. IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践
26. 微信团队分享：微信后台在海量并发请求下是如何做到不崩溃的
27. 微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等
28. 微信技术分享：揭秘微信后台安全特征数据仓库的架构设计
29. IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存优化实践
30. 企业微信针对百万级组织架构的客户端性能优化实践
31. 揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链
32. 微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题
33. 微信团队分享：微信后端海量数据查询从1000ms降到100ms的技术实践
34. 大型IM工程重构实践：企业微信Android端的重构之路
35. IM技术干货：假如你来设计微信的群聊，你该怎么设计？
36. 微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗
37. 长连接网关技术专题(十一)：揭秘腾讯公网TGW网关系统的技术架构演进

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

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

[- 1 -] 高仿Android版手机QQ首页侧滑菜单源码 [附件下载]

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

[摘要] 本文分享的源码高仿了手机QQ的这个效果，希望可以为有相同需求的IM开发者同行节省点撸码时间。

[- 2 -] 开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]

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

[摘要] libco在2013年的时候作为腾讯六大开源项目首次开源，ibco支持后台敏捷的同步风格编程模式，同时提供系统的高并发能力。

[- 3 -] 分享java AMR音频文件合并源码，全网最全

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

[摘要] 分享java AMR音频文件合并源码，全网最全。

[- 4 -]微信团队原创Android资源混淆工具：AndResGuard [有源码]

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

[摘要] 本文主要是讲述资源混淆组件的用法以及性能，资源混淆组件不涉及编译过程，只需输入一个apk，可得到一个实现资源混淆后的apk

[- 5 -] 一个基于MQTT通信协议的完整Android推送Demo [附件下载]

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

[摘要] 本文主要介绍的是基于MQTT实现一个简单的Android消息推送系统。更多推送技术资料请见：http://www.52im.net/forum.php?mod=collection&action=view&ctid=11

[- 6 -] Android版高仿微信聊天界面源码 [附件下载]

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

[摘要] 微信的聊天界面是挺漂亮的，每条消息都带一个气泡，给人一种很清新的感觉，其实实现起来也不是那么的难，下面我们就来实现一下。

[- 7 -] 高仿手机QQ的Android版锁屏聊天消息提醒功能 [附件下载]

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

[摘要] 今天为大家带来的是，可以在锁屏下弹窗显示消息来提醒用户，可用于移动端IM或消息推送应用中。

[- 8 -] 高仿iOS版手机QQ录音及振幅动画完整实现 [源码下载]

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

[摘要] 高仿iOS版手机QQ聊天界面中录音及振幅动画。

[- 9 -]  Android端社交应用中的评论和回复功能实战分享[图文+源码]

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

[摘要] 页面整体采用了CoordinatorLayout来实现详情页的顶部视差效。同时，这里我采用ExpandableListView来实现多级列表，然后再解决它们的嵌套滑动问题。

[- 10 -] Android端IM应用中的@人功能实现：仿微博、QQ、微信，零入侵、高可扩展[图文+源码]

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

[摘要] 网上已经有一些文章分享了类似功能实现逻辑，但是几乎都是扩展EditText类，这种实现方式肯定不能进入我的首发阵容。你以为是因为它不符合面向对象六大原则？错，只因为它不够优雅！不够优雅！不够优雅！

[- 11 -] 仿微信的IM聊天时间显示格式(含iOS/Android/Web实现)[图文+源码]

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

[摘要] 作为移动端IM的王者，微信无疑处处是标杆，所以本次的消息时间显示格式，直接参照微信的实现逻辑准没错（随大流虽然没个性，但不至于非主流）。

[- 12 -] Android版仿微信朋友圈图片拖拽返回效果 [源码下载]

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

[摘要] 目前的app的动画效果是越来越炫了，很多主流app的图片预览返回都有类似功能，比较常见的是ios自带相册，微信朋友圈等等。自己项目中也有类似功能，最近整理了一下这个功能的代码，做个笔记记录，有兴趣的朋友可以在文末附件下载源码。

[- 13 -] 手把手教你实现网页端社交应用中的@人功能：技术原理、代码示例等

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

[摘要] 本文分享的@人功能是针对Web网页前端的，跟移动端原生代码的实现，从技术原理和实际实现上，还是有很大差异，所以如果想了解移动端IM这种社交应用中的@人实现功能，可以读一下《Android端IM应用中的@人功能实现：仿微博、QQ、微信，零入侵、高可扩展[图文+源码]》这篇文章。

[- 14 -] SpringBoot集成开源IM框架MobileIMSDK，实现即时通讯IM聊天功能

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

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

[- 15 -] 基于Netty，徒手撸IM(一)：IM系统设计篇

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

[摘要] 本篇主要是徒手撸IM系列的开篇，主要讲解的是的IM设计思路，不涉及实践编码，希望给你带来帮助。

👉52im社区本周新文：《总是被低估，从未被超越，揭秘QQ极致丝滑背后的硬核IM技术优化》，欢迎阅读！👈

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

本文由哔哩哔哩资深开发工程师黄山成分享，原题“千万长连消息系统”，本文进行了排版和内容优化等。

1、引言

在当今数字娱乐时代，弹幕已经成为直播平台上不可或缺的互动元素之一。

用户通过发送弹幕、送礼等，可以实时在直播画面上展现自己的想法、评论和互动内容，从而丰富了用户观看体验。在这个过程中，实时向终端推送互动信息，就需要用到长连接。

长连接，顾名思义，是应用存活期间和服务端一直保持的网络数据通道，能够支持全双工上下行数据传输。其和请求响应模式的短连接服务最大的差异，在于它可以提供服务端主动给用户实时推送数据的能力。

本文将介绍B站基于golang实现的千万级长连接实时消息系统的架构设计与实践，包括长连接服务的框架设计，以及针对稳定性与高吞吐做的相关优化。

2、关联文章

• 《B站基于微服务的API网关从0到1的演进之路》
• 《石墨文档单机50万WebSocket长连接架构实践》
• 《百度统一socket长连接组件从0到1的技术实践》
• 《探探的IM长连接技术实践：技术选型、架构设计、性能优化》
• 《爱奇艺WebSocket实时推送网关技术实践》
• 《LinkedIn的Web端即时通讯实践：实现单机几十万条长连接》
• 《一个基于长连接的安全可扩展的订阅/推送服务实现思路》
• 《魅族2500万长连接的实时消息推送架构的技术实践分享》
• 《专访魅族架构师：海量长连接的实时消息推送系统的心得体会》

3、架构设计

3.1概述

长连接服务是多业务方共同使用一条长连接。

因为在设计时，需要考虑到不同业务方、不同业务场景对长连接服务的诉求，同时也要考虑长连接服务的边界，避免介入业务逻辑，影响后续长连接服务的迭代和发展。

长连接服务主要分为三个方面：

• 1）长连接建立、维护、管理；
• 2）下行数据推送；
• 3）上行数据转发（目前只有心跳，还没实际业务场景需求）。

3.2整体架构

长连接服务整体构架如上图所示，整体服务包含以下几个部分。

1）控制层：建连的前置调用，主要做接入合法性校验、身份校验和路由管控。

主要职责：

• 1）用户身份鉴权；
• 2）加密组装数据，生成合法token；
• 3）动态调度分配接入节点。

2）接入层：长连接核心服务，主要做卸载证书、协议对接和长连接维护。

主要职责：

• 1）卸载证书和协议；
• 2）负责和客户端建立并维护连接，管理连接id和roomid的映射关系；
• 3）处理上下行消息。

3）逻辑层：简化接入层，主要做长连的业务功能。

主要职责：

• 1）在线人数上报记录；
• 2）记录连接ID各属性和各节点的映射关系。
• 4）消息分发层：消息推送到接入层。

主要职责：

• 1）消息封装、压缩和聚合推送给相应的边缘节点；

5）服务层：业务服务对接层，提供下行消息推送入口。

主要职责：

• 1）管控业务推送权限；
• 2）消息检测和重组装；
• 3）消息按一定策略限流，保护自身系统。

3.3核心流程

长连接主要是3个核心流程：

• 1）建立连接：由客户端发起，先通过控制层，获取该设备合法的token和接入点配置；
• 2）维持连接：主要是客户端定时发起心跳，来保证长连接活跃；
• 3）下行推送：下行推送由业务Server发起，经由服务层根据相关标识确定连接标识和接入节点，经过消息分发层，把推送到对应的接入层，写入到指定连接上，然后下发到客户端。

3.4功能列表

结合B站业务场景，下行数据推送，提供如下通用功能：

• 1）用户级消息：指定推送给某些用户（比如给某个主播发送邀请pk消息）；
• 2）设备级消息：制定推送给某些设备（比如针对未登陆的设备，推送客户端日志上报指令）；
• 3）房间级消息：给某房间内的连接推送消息（比如给直播间的所有在线用户推送弹幕消息）；
• 4）分区消息：给某分区的房间推送消息（比如给某个分区下，所有开播的房间，推送某个营收活动）；
• 5）全区消息：给全平台用户推送消息（比如给全部在线用户推送活动通知）。

4、高吞吐技术设计

随着业务发展壮大，在线用户越来越多，长连系统的压力越来越大，尤其是热门赛事直播，比如s赛期间，全平台在线人数快达到千万，消息吞吐量有上亿，长连系统消息分发平均延迟耗时在1s左右，消息到达率达到99%，下面具体分析下长连做了哪些措施。

4.1网络协议

选择合适的网络协议对于长连接系统的性能至关重要：

• 1）TCP协议：可以提供可靠的连接和数据传输，适用于对数据可靠性要求较高的场景；
• 2）UDP协议：是一个不可靠的协议，但是传输效率高，适用于对数据可靠性要求不高的场景；
• 3）WebSocket协议：也是实现双向通信而不增加太多的开销，更多的用于web端。

接入层拆分成协议模块和连接模块：

• 1）协议模块：和具体的通讯层协议交互，封装不同通讯协议的接口和逻辑差异。
• 2）连接模块：维护长连接业务连接状态，支持请求上行、下行等业务逻辑，维护连接各属性，以及和房间id的绑定关系。

针对以上第 1）点，协议模块同时给连接模块提供统一的数据接口，包括连接建立、数据读取、写入等。后续增加新协议，只要在协议模块做适配，不影响其他模块的长连业务逻辑。

优势在于：

• 1）业务逻辑和通讯协议做了隔离，方便迭代增加通讯协议，简化兼容多通讯协议的实现难度；
• 2）控制层可以根据客户端的实际情况，下发更优的通讯协议。

4.2负载均衡

采用负载均衡技术可以将请求分发到不同的服务器节点上处理，避免了单一节点的负载过高，提高了系统的扩展性和稳定性。

长连增加控制层，做负载均衡。控制层提供http短连接口，基于客户端和各边缘节点实际情况，根据就近原则，动态选择合适的接入节点。

接入层支持水平扩展，控制层可以实时增加、减少分配节点。在S赛期间，在线人数快到达千万时，平衡调度各接入节点，保障了各节点的CPU和内存都在稳定的范围内。

4.3消息队列

消息推送链路是：业务发送推送，经过服务层推到边缘节点，然后下发给客户端。

服务层实时分发到各边缘节点，如果是房间类型消息，需要推到多个边缘节点，服务层同时还要处理业务逻辑，很影响消息的吞吐量。

所以增加消息队列和消息分发层，消息分发层维护各边缘节点信息和推送消息，提高了系统的并发处理能力和稳定性，避免了因消息推送阻塞而导致的性能问题。

4.4消息聚合

当有热门赛事时，同时在线可能达到千万级别，一条弹幕消息就要扩散到千万个终端，假如在线的每个人每秒发一条，需要发送消息量就是1kw*1kw，消息量非常大，此时消息分发层和接入层，压力都会很大。

分析发现：这些消息都是同一个房间的，属于热点房间，比如s赛房间，观众数量是无法减少的，那只能在消息数上做文章。业务消息推送不能减少，又要减少扩散的消息数，就想到了消息聚合。

针对房间消息，按照一定的规则进行消息聚合，批量推送：

消息聚合上线后，消息分发层对接入层调用QPS下降60%左右，极大的降低了接入层和消息分发层的压力。

4.5压缩算法

消息聚合后，降低了消息的数量，但是增加了消息体的大小，影响了写入IO，需要减少消息体大小，就想到了消息压缩。

压缩算法，选了市面上比较常用的两个：zlib和brotli，进行比较。

抓取了线上业务推送的数据，选择最高等级的压缩等级，进过压缩验证：

由此可见，brotli相比zlib有很大的优势，最后选择了brotli压缩算法。

选择在消息分发层进行消息压缩，避免在各接入节点多次重复压缩，浪费性能。上线后提升吞吐量的同时，也降低的宽带使用成本。

5、服务保障技术设计

现在有些业务是强依赖长连推送消息，消息丢失，轻则影响用户体验，重则阻塞业务后续流程，进而影响业务流水。针对长连服务消息保障，做了如下工作。

5.1多活部署

多活部署，通过在不同地理位置部署相同的系统架构和服务，实现了系统在单一地域故障时的快速故障转移，从而提高了系统的稳定性和可用性。

长连服务部署，主要做了以下几点：

• 1）长连接在国内华东、华南、华北地域均部署了接入点，支持三大运营商；华南和华中自建机房也部署了接入点；为支持海外用户，增加了新加坡机房独立接入点；
• 2）针对业务场景不同，在云上节点和自建节点之间，实时切换，因为云上节点和自建机房的成本是不一样的，在保证服务质量的前提下，尽可能的控制成本。

目前线上运行过程中，偶尔会遇到单节点或机房的网络抖动，通过控制层，对有问题的节点，进行秒级摘流，大大减少了对业务的影响。

5.2高低消息通道

多业务消息接入长连接，但不同消息之间的重要性是不一样的，比如弹幕消息和邀请pk消息，丢失几条弹幕对用户体验不会影响很大，但如果邀请pk消息丢失，则会导致pk业务无法进行后续的流程。

针对不同等级的消息，采用了高低优消息通道。重要消息走高优通道，普通消息走低优通道。这样重要和普通消息进行了物理隔离，消息分发优先保证重要消息。

针对高优通道，做了双投递的保障，在接入层做幂等去重。首先重要消息是针对用户级别的，量不会很大，所以对接入层的压力不会增加很大。另外双投递的job是部署在多机房的，这也就降低单机房网络抖动造成的影响。

高低优通道上线后，遇到过内网出网抖动，当时内网部属的job节点推送消息异常，而云上高优job节点可正常推送，很好的保障了高优消息的到达，进而保障了高优业务不受影响。

5.3高达功能

高低优通道解决的是job到接入层的这一个环节，但消息推送联路涉及到多个环节，比如服务层到job、接入层到客户端。

针对整个链路，通过实现必达机制来确保终端的到达率，简称高达功能。

功能实现：

• 1）每条消息引入msgID，客户端收到消息后进行幂等去重和ack回执；
• 2）服务端针对msgid进行ack检测，针对未ack的，有效期内再次重试下发。

最终到达率 = (1-(1-r)^(n+1))，其中：r为广播单次到达率，n为最大重试次数。

例如：r = 97%、n=2，那么最终到达率可以达到(1-(1-0.97)^(2+1)) = 99.9973%

6、进出”房“消息的送达保证设计

有些业务场景，需要用到用户进出房消息，比如用户A进入直播间，页面会显示欢迎用户A进入房间，或者是加入在线榜单。

1）进房消息会存在丢失，需要有补偿机制。想到可以通过连接心跳来补偿进房消息，但心跳是持续不断的，连接在线期间，业务希望只收到一次进房消息，所以进房消息需要有幂等机制。

2）出房消息也会存在丢失，如果丢失了，业务无法从在线榜单剔除用户，此时也需要有补偿机制。此时就需要增加连接的状态机，通过心跳维护状态机，当心跳丢失时，认为连接断开，用户退房。

7、未来规划

统一长连接服务经历数次迭代后，目前基本功能已经趋于稳定，后续对长连接服务进行改善和优化。

主要集中在以下几个方向：

• 1）数据化：进一步完善长连接全链路网络质量数据统计和高价值消息全链路追踪的能力；
• 2）智能化：端上建联、接入点选择等能够根据实际环境进行自动化调整；
• 3）性能优化：接入层的连接模块中，处理上下行消息的携程进行共享，减少接入层的携程数，进一步提升单机性能和连接数；
• 4）功能扩展：新增离线消息功能等。

8、参考资料

[1] 手把手教你写基于TCP的Socket长连接

[2] 正确理解IM长连接、心跳及重连机制，并动手实现

[3] 万字长文：手把手教你实现一套高效的IM长连接自适应心跳保活机制

[4] 用JWT技术解决IM系统Socket长连接的身份认证痛点

[5] TCP/IP详解 - 第11章·UDP：用户数据报协议

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

[7] WebSocket从入门到精通，半小时就够！

[8] 快速理解TCP协议一篇就够

[9] 快速理解TCP和UDP的差异

[10] 一泡尿的时间，快速搞懂TCP和UDP的区别

[11] 到底什么是Socket？一文即懂！

[12] 我们在读写Socket时，究竟在读写什么？

[13] 假如你来设计TCP协议，会怎么做？

[14] 深入操作系统，一文搞懂Socket到底是什么

[15] 通俗易懂，高性能服务器到底是如何实现的

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

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

一、更新内容简介

本次更新为次要版本更新，进行了bug修复和优化升级（更新历史详见：码云 Release Notes、Github Release Notes）。

MobileIMSDK 可能是市面上唯一同时支持 UDP+TCP+WebSocket 三种协议的同类开源IM框架。轻量级、高度提炼，历经10年、久经考验。客户端支持iOS、Android、Java、H5、微信小程序、Uniapp，服务端基于Netty。

二、MobileIMSDK简介

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

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

MobileIMSDK工程始于2013年10月，历经10年，起初用作某产品的即时通讯底层实现，完全从零开发，技术自主可控！

您可能需要：查看关于MobileIMSDK的详细介绍。

三、源码托管同步更新

OsChina.net

• 源码托管： http://git.oschina.net/jackjiang/MobileIMSDK

• 项目资料： 点击查看更多资料

GitHub.com

• 源码托管： https://github.com/JackJiang2011/MobileIMSDK

• 项目资料： 点击查看更多资料

四、MobileIMSDK设计目标

让开发者专注于应用逻辑的开发，底层复杂的即时通讯算法交由SDK开发人员，从而解偶即时通讯应用开发的复杂性。

五、MobileIMSDK框架组成

整套MobileIMSDK框架由以下7部分组成：

1. Android客户端SDK：用于Android版即时通讯客户端，支持Android 4.0及以上，查看API文档；
2. iOS客户端SDK：用于开发iOS版即时通讯客户端，支持iOS 12.0及以上，查看API文档；
3. Java客户端SDK：用于开发跨平台的PC端即时通讯客户端，支持Java 16及以上，查看API文档；
4. H5客户端SDK：查看精编注释版；
5. 微信小程序端SDK：查看精编注释版；
6. Uniapp端SDK：查看精编注释版；
7. 服务端SDK：用于开发即时通讯服务端，支持Java 1.7及以上版本，查看API文档。

整套MobileIMSDK框架的架构组成：

 另外：MobileIMSDK可与姊妹工程 MobileIMSDK-Web 无缝互通，从而实现Web网页端聊天或推送等。

六、MobileIMSDK v6.5更新内容 

【重要说明】：

MobileIMSDK v6.5 为次要版本，进行了若干优化！ 查看详情 （github）

【新增重要特性】：

• 1. [Android端] 新增了Demo中当APP处于后台时，收到消息时显示系统通知的功能。

【解决的Bug】：

• 1. [服务端] 尝试解决极小几率下Android端会误把“自已”踢掉的问题。

【其它优化和提升】：

• 1. [服务端] 升级了log4j2等基础库，解决基础库低版中带来的安全漏洞风险；
• 2. [服务端] 服务端SDK和Demo工程已迁移至IDEA；
• 3. [Java端] Java桌面端的TCP和UDP两种协议的SDK和Demo工程已迁移至IDEA；
• 4. [Android端] 提升targetSdkVersion至34（即Android 14）；
• 5. [Android端] 解决了Demo中绑定前台服务在Android 14中崩溃等问题。
• 6. [iOS端] 提升最低系统支持版本为iOS 12；
• 7. [iOS端] 优化了JSON解析库中的一处过时API调用。

【最新版本源码地址】：

• Gitee：https://gitee.com/jackjiang/MobileIMSDK/releases/tag/6.5
  
• Github：https://github.com/JackJiang2011/MobileIMSDK/releases/tag/6.5

七、Demo运行演示

八、技术应用示例

8.1 示例1：基于MobileIMSDK的移动端IM RainbowChat（更多运行截图）：

8.2 示例2：基于MobileIMSDK-Web的Web端IM RainbowChat-Web（更多运行截图）：

即时通讯技术文集（第37期）：IM代码入门实践(Part1) [共16篇]

本文由腾讯技术团队peter分享，原题“腾讯网关TGW架构演进之路”，下文进行了排版和内容优化等。

1、引言

TGW全称Tencent Gateway，是一套实现多网统一接入，支持自动负载均衡的系统， 是公司有10+年历史的网关，因此TGW也被称为公司公网的桥头堡。

本文从腾讯公网TGW网关系统的应用场景、背景需求讲起，重点解析了从山海1.0架构到山海2.0架构需要解决的问题和架构规划与设计实现，以及对于未来TGW山海网关的发展和演进方向。

 

技术交流：

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

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

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

2、专题目录

本文是专题系列文章的第11篇，总目录如下：

1. 《长连接网关技术专题(一)：京东京麦的生产级TCP网关技术实践总结》
2. 《长连接网关技术专题(二)：知乎千万级并发的高性能长连接网关技术实践》
3. 《长连接网关技术专题(三)：手淘亿级移动端接入层网关的技术演进之路》
4. 《长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践》
5. 《长连接网关技术专题(五)：喜马拉雅自研亿级API网关技术实践》
6. 《长连接网关技术专题(六)：石墨文档单机50万WebSocket长连接架构实践》
7. 《长连接网关技术专题(七)：小米小爱单机120万长连接接入层的架构演进》
8. 《长连接网关技术专题(八)：B站基于微服务的API网关从0到1的演进之路》
9. 《长连接网关技术专题(九)：去哪儿网酒店高性能业务网关技术实践》
10. 《长连接网关技术专题(十)：百度基于Go的千万级统一长连接服务架构实践》
11. 《长连接网关技术专题(十一)：揭秘腾讯公网TGW网关系统的技术架构演进》（* 本文）

3、TGW网关系统的重要性

TGW全称Tencent Gateway，是一套实现多网统一接入、支持自动负载均衡的系统， 是公司有10+年历史的网关，因此TGW也被称为公司公网的桥头堡。它对外连接了各大运营商并支撑公有云上EIP、CLB等产品功能，对内提供了公网网络的接入功能，如为游戏、微信等业务提供公网接入服务。

TGW主要有两大产品：

• 1）弹性EIP（比如购买一台虚拟机CVM或是一个NAT实例后，通过EIP连通外网）；
• 2）四层CLB。

四层CLB一般分为内网CLB和外网CLB：

• 1）内网CLB是在vpc内创建一个CLB实例，把多个CVM服务挂在了内网CLB上，为后端RS提供负载均衡的能力；
• 2）外网CLB面对的是公网侧负载均衡的需求。

当在内部部署CLB集群时，可分为IPV4或者IPV6两大类，根据物理网络类型又细分为BGP和三网两类。三网指这些IP地址是静态的，不像BGP一样能够在多个运营商之间同时进行广播。

以上就是四层TGW产品及功能，山海网关在原有产品基础上做了网络架构方面的演进。

4、Region EIP的引入

具体介绍下EIP和CLB两个产品。

过去CLB和EIP使用不同的IP地址池，导致资源池上的隔离问题。使得我们无法把EIP地址绑定到公有云CLB实例上。

例如：一个创业公司最初只购买一台虚拟机并挂载一个公网EIP来提供服务。随着用户量的增长，如果想将这个EIP地址迁移到一个公网CLB实例上，在原有架构下是无法实现这种迁移的。

此外：EIP和CLB部署在每个机房，因此在每个机房都需要建立EIP出口。但是各个机房的公网出口之间缺无法相互容灾。

所以这种情形下，我们确定了产品的目标：

• 1）希望将所有公网出口整合到一到两个机房之内，以避免重复建设，节省成本；
• 2）通过将出口集中，我们可以将对应的网关服务器也进行集中，进而提高设备的利用率；
• 3）通过这样的布局可实现跨机房的容灾方案。

因此：最早的Region EIP（REIP）计划应运而生。

以北京这类大型region为例的：我们将EIP专区建设到位于两个城市的超核机房。这两个机房通常会放置物理网络的交换设备，并为各自设立了一个REIP专区。在REIP专区内部署Region EIP集群。为了实现跨AZ容灾，两个机房的集群之间借助大小网段实现互相备份容灾的能力。一旦其中一个机房的集群发生故障或出现网络问题，另一个机房的集群可以立即承担起容灾任务。

同时：因为新的Region EIP的网络架构跟原来的网络架构不一样，通过网络架构升级以及机型升级，我们能够把单台Region EIP的性能做到原有单台EIP性能的5倍。这样我们通过容量的提升进一步提升了设备利用率，在完成全量Region EIP后，设备数量会从3000+台缩减至700+台。同时原有的CLB集群还保留在各个机房不变，这些CLB集群的外网接入能力由Region EIP承担。

5、公网CLB的演进

5.1概述

公网CLB最早是有公网接入能力的。引入到Region EIP之后，当初设想是公网CLB不再演进，尽量让存量用户迁移到另外一种形式，上层是Region EIP，下层是内网CLB。用户先买一个内网CLB，如果需要对公网提供服务就再买一个弹性EIP，把EIP跟内网CLB绑定在一起，提供CLB公网的能力，替代原有的公网CLB，这是最早公网CLB的替代方案。

两个方案的区别是：原有公网CLB，用户仅看到一个CLB实例。新的模式下，用户看到的是两个实例：一个EIP+一个内网CLB，两个实例都可以独立运营管理。这就是我们最早的两层架构设想，想把公网CLB跟外网解耦。

但是，真正去跟用户或产品交流时，这个想法遇到了比较大的挑战：

1）用户体验的改变：以前公网CLB用户看到是一个实例，但是现在用户看到两个实例，必然会给用户带来一些适配工作。比如用户进行创建、管理实例时，API不一样了。以前使用通过自动化脚本创建公网CLB实例的，现在脚本还要改变去适配新的API。

2）用户习惯改变：以前用户习惯在一个实例下，点击页面，就能够查看流量、链接数等监控信息。现在EIP流量需要到REIP查看，而链接数还需在CLB产品上看。

3）存量客户无法迁移：原来客户买的公网CLB实例，是无法直接无感知迁移到内网CLB+REIP这种新形式的。

在这些挑战下，这个替代方案没能真正落地。结合用户的要求，我们最终跟产品定下的策略是：公网CLB保持不变。原有的公网CLB继续保留，同时如果用户新增的公网CLB需求，也要继续支持。

5.2公网CLB模型

那么，公网CLB到底怎么演变？

我们的初衷并不是把公网CLB这个产品摒弃掉，而是要收敛公网入口。所以我们针对这个初始需求，提出了上面这个两级架构模型。

首先：用REIP将公网流量先引进来，再将这个流量通过隧道报文的形式转发给原有的公网CLB集群，这样公网CLB不需要原有外网接入的能力，不需要再跟外网打交道，可以演变成只在机房内部的集群；同时因为公网CLB的流量都会经过REIP，REIP自然也就是公网CLB的流量入口。从而达到我们最初收敛公网入口的目的。这样的架构升级，可实现用户无感知。架构升级切换过程中，用户在访问公网CLB，不会出现卡顿或者重连的现象。

这个架构模型也有一定的局限性的。公网CLB实例只能承载公网的流量，无法像上文提到的两层RERP+CLB那样，内外网随时进行转化。REIP+CLB实例中的CLB既承载内网侧CLB的流量，又承载公网侧CLB的流量。

6、山海架构 1.0

借助这个两级架构模型，我们能够把公网CLB保留下来，并且通过REIP把公网入口收敛。

进一步思考并完善，我们提出了下面的想法：跟产品进行解耦。

以前我们一个地区上线公网CLB产品，底层就要搭建有一个公网CLB的集群去支持。用户需要内网CLB服务，就要对应搭建个内网CLB的集群。底层集群类型跟产品是强耦合，有IPv4/IPv6， 公网/内网、BGP/三网组合出的多个产品形态。

这种模式在小地域部署，因为产品业务的流量小，集群利用率低，就会造成很大的成本压力。

为了应对这种小带宽低成本的诉求，我们将CLB+REIP的模型进一步抽象，引入山海架构：我们只建设CLB和REIP两类集群。通过这两类集群上的不同实例组合，满足多个产品形态的要求。从而实现产品形态和底层物理网络集群类型解耦。

解耦合的方式是：CLB和REIP通过不同的实例类型，组合出不同的产品形态。

山海架构在TGW内部做闭环，不涉及到产品侧和用户侧的改动。整个过程升级，对产品侧不做任何接口上的更新。因为产品侧的API接口保持不变，对用户侧就可以做到完全无感知。在产品侧保持不变，就需要我们在内部管控，识别接入用户实例是哪种形态的产品，拆分成不同形式的CLB和REIP的实例。其他的相关功能的比如流量统计、限速等模块也都要适配不同的产品形态，通过模块的适配，做到山海架构对上层产品侧应用的透明。

山海架构1.0归纳起来有两个重点：收敛公网入口和集群类型归一。

1）REIP：部署在城核机房，同时承载的是CLB和REIP两类产品的公网流量。之前EIP，在物理网络上有BGP+三网、v4/v6等多种集群类型。REIP借助vlan的隔离支持，把所有的网络类型都集中到一种REIP集群上来，我们称之为全通集群。在物理网络层面实现网络类型的归一， 然后再通过软件层的适配，实现REIP支持多通类型的网络接入能力。

2）CLB：在山海两级架构下，REIP集群处理公网侧的各种场景组合，CLB集群通过隧道与REIP处理公网流量。之前一个机房如果要把所有的产品能力支持起来，大概有7种集群类型。现在CLB集群可以用一种集群类型来支持所有的产品的公网CLB产品，以及内网CLB产品的能力。我们把三网+BGP以及内外网还有V4V6等集群类型都用一种类型来支持，山海架构完全落地后，开区的最小服务器数量可以降低到8台服务器，来承载所有的EIP和CLB产品需求。

归纳起来一句话：对于用户来说，产品形态没有改变，用户使用习惯也没有改变。而在底层，我们把集群类型收敛到一个CLB集群和一个REIP集群上。

7、山海架构1.0限速技术

在山海架构演进中，有许多技术点，本文选取限速技术进行分享。

首先Region EIP支持三网。以前BGP跟三网分开独立支持，山海网关统一用Region EIP支持。Region EIP本身的网络架构分成两个机房，每个机房放4台TGW设备，每个EIP只会走左边或者右边。一个EIP进来的流量经过上面这层交换机时，经过了ECMP分流，然后分到了4台设备上。这样对每个EIP其实是采用了分布式限速。

限速有两个要求：

• 1）精确性，限速上下浮动要小，要限得准；
• 2）要有容灾能力。

限速最极端的精准就是把它放到单点上去做限速，但是单点限速就会面临单点故障和容灾的问题。在X86服务器上，使用的是分布式限速，一个EIP均分到4台服务器上，每五秒钟做一次流量的的汇总统计，通过流量比例计算将这个EIP的带宽配额，重新分配并分发到4台设备上，以此来实现集群上的限速。在单台设备上，也是没隔一段时间，就重新计算配额并分配到每个CPU核上，我们目前用的是300毫秒周期。

需要说明的是：在限速的实现上，业务有多重实现方式，我们了解到有的实现的是静态分配，比如120兆的带宽，4台设备，我们每台设备分40M(三分之一)的带宽。1/3而不是1/4的带宽，目的是防止某一台设备断了之后，用户总带宽不达标，影响用户体验。在单台设备上限速，也有另外一种实现方式，大小桶。比如限速1M的带宽，那么每个核第一次取回100K或者200K配额。后续报文处理时候，先消耗上次取回的配额，如果带宽配额消耗光了，再重新取。周期调整跟大小桶这两种实现方式各有优缺点。从资源消耗来说，300毫秒周期的资源消耗相对会更少一些，两者大概有10%左右的性能偏差。

限速上另一诉求：小带宽的限速的精准限速。

大带宽比如100兆，分到每个核上相对富裕。小带宽如一M带宽，一秒钟100k字节等，分到四台机器再分到几十个核上，每个核都可能不到一个大报，这时候再去做精准限速就会非常困难，因为既然要提前分配资源，资源那么少，分配到单核上，可能一个包都过不去，但凡有一个报文过去了，又可能超了。所以在小带宽限速时，我们把它退化成类似于单点限速的模式。由于入方向带宽最小也是100兆，因此保持原有的分布式限速不变。只对出方向小带宽，使用单点限速。方案是这样的：

每台REIP有自己一个独享的内网地址，只有这台服务器故障时候，这个地址的流量才被分发到其他三台服务器。

入方向流量被分到四台REIP服务器后，REIP处理完通过tunnel转发给母机。隧道的外层源地址，只使用其中一台REIP服务器的独享的IP地址。每个外网IP地址在挂载到集群下管理时候，就确定下来了。

母机在接受到网关发过去的流量，解析外层报文地址，并记录在本地会话表里，我们称之为母机的自学习能力。当母机侧转发出方向报文时，就只会使用本地学习并记录的外层地址去封装隧道。这样出方向的流量，就回到单台TGW设备上，实现了单点限速。

独享的内网地址本身是有容灾能力：

• 1）当其服务器故障了，流量就被分散到集群其他服务器，放弃单点限速；
• 2）当服务器被修复上线后，又可以重新变成精准的单点限速。

这样保证小带宽精准限速的同时，又避免了单点故障。

在限速过程中，还有一个问题，因为CLB集群原来的限速是在CLB集群上自己做的，引入山海之后，REIP上有限速能力，那么公网CLB的限速要不要挪到REIP上？

我们经过多次讨论， 最终还是维持**这个限速在公网CLB上不变。

这里有几种场景考量：

1）内外网攻击：如果我们把它放到REIP上，这里可以扛住外网的攻击，但同时内网的攻击我们是防不住的，因为公网CLB上没有限速后，流量内网的攻击就会先把CLB上压过载，导致丢包，影响业务的稳定性。

2）有效流量的准确统计：原有架构下，从公网流量首先到达CLB，我们需要检查公网CLB上与port对应的服务是否已配置规则并启用。如果没有启用，则将报文直接丢弃且不记录为公网CLB的带宽使用量。山海架构下，如果先经过Region EIP限速，这类无服务访问流量（如恶意攻击和垃圾流量）也将占用限速资源。尽管这部分限速流量会送达至CLB集群，但由于缺乏相应服务支持，它们最终还是将被丢弃。结果导致用户带宽不及预期。比如用户购买10M带宽，实际有效运行的仅有8M流量，而其余2M被无服务流量占用了。

3）多重限速的影响：还有一个这个场景中，当Region EIP实施带宽限速后，这些流量最终可能进入公网CLB。然而，由于CLB的规格限制，例如新建连接数或并发连接数已达到上限，部分数据包可能会被丢弃。这些丢失的数据包已经消耗了购买的公网带宽，从而导致用户观察到的公网CLB流量带宽未达到预期。因此，我们保留公网CLB限速功能不变，仅进行引流调整。

8、山海架构1.0的优势

CLB产品及REIP产品，在使用山海1.0之后的几点优势。

1）CLB产品本身支持热迁移，扩容到山海热迁移，不会引起用户的断流，有助于运维做用户产品升级迭代。这方面有个典型案例，比如某台设备坏了或者发现某台设备上有问题，需要把流量迁走的时候，我们可以不用中断用户的流量的。我们了解到，以前有的竞品，因为热迁移做的不是特别完善，在设备出现问题或者是需要升级版本的时候，常选择低峰期做升级。

2）EIP在做限速的时候，在出方向时是小带宽，可以做到比较精准的限速。好处是用户做压测或测试的时，带宽不会抖动影响自己的业务的稳定性。

3）高低优先级限速。用户买一些比较小的比如10M带宽或者5M带宽，用来服务本身业务，同时也会ssh或者远程桌面登录EIP；因为一起我们是做无差别的限速丢包的话，这样会造成它本身的控制流量，如远程桌面的流量也会被丢包，造成登录的卡顿。用户需要在不超限速的前提下，优先保证远程桌面不卡，然后再提供其他的下载服务。我们把流量根据端口进行区分，比如22端口或者是远程桌面的3389端口的流量，标记为高优先级。在做限速时，只要高优先流量不超限速，就全部放行。当高优先级流量再叠加上低优先级的流量超限速时，把低优先级的流量丢掉，这样ssh访问服务器的时候能够非常顺畅。

4）山海架构上线后，基于vip粒度的调度，可以让调度更加灵活。比如原来一个集群为了节省路由条目，我们按照一个网段发路由，不是每个VIP都发路由的。山海两级架构之后，没有了这个限制，就可以按照VIP，把CLB实例调度到不同CLB集群。这样如果用户需要一个特别大规格的VIP的时候，我们可用一个集群的能力去扛用户一个VIP，从而满足超大规格实例的诉求。当然真实使用产品时，很少有客户把上百G的流量用一个VIP来承载。用户出于容灾考虑，通常不会把所有的鸡蛋放到一个篮子里。

9、山海架构 2.0

9.1概述

如前所述：山海 1.0 主要目标是整合公共网络并将所有公网出口集中在城市核心机房内。至于剩余的 CLB 群集，我们会继续将其保存在原有各机房的专区里。这是因为网关设备有其与服务器不同的网络诉求，例如普通服务器不能提供发布动态路由，并通过动态路由引流处理业务流量。

再比如：网关专区的收敛比1:1，而服务器虽然带宽也是100G， 但其收敛比率往往小于1：1。

在这种情况下，我们不能简单地将 CLB 网关群集群平移放置到服务器区。因此，CLB 网关群集通常在构建每个机房时，预先规划并预留相应的网关专区。机房建设起来后，如业务量小，又会因预留资源空置造成浪费。目前专区闲置机位也是一笔较大的费用。

同时，还有一种临时扩容的需求场景，例如VIP大客户，临时会有大流量的转发需求，这时常态运营水位没法满足需要，需要调配设备做集群扩容。如果本机房的设备不够还需要跨机房搬迁，搬迁周期比较长，对我们运营压力会很大。

所以，我们希望通过山海2.0能把专区建设的空置率降下来，同时提升弹性，能够低成本的快速扩缩容。

9.2引流交换机

在山海 2.0里，我们采用了“引流交换机”。在每个机房的建设时，我们可以放置两组共四台引流交换机。

考虑到单个交换机的容量可以达到 1 T 以上，有四台交换机工作，一个机房能够承受大约 4T~ 6T 的流量峰值。这意味着后续无需再额外扩容，一次性的建设和布局就可以满足长期的需求。相比于 CLB 群集占用的机位空间，四台交换机所需的机位显著减少。

我们把原来CLB集群对外声明路由的能力放到了引流交换机上，把CLB服务器用用通用服务器区的设备来代替。考虑收敛比和容灾，不会把一个集群放到一两个机架上，会相对分散些，更不会把整个机架全部再用成CLB集群。这样CLB集群不再单独建设网关专区，引流交换机把路由声明发出去，通过隧道跟CLB设备转发流量。

9.3山海2.0的变化

我们以内网CLB为例，原来一台虚拟机访问CLB集群，CLB集群把它的流量转到对应的RS。

引入交换机之后，其进出两个方向都会有变化：入方向（访问LB方向），虚拟机的流量先被引流到了引流交换机，交换机把报文做一次封装，然后发送给对应的服务器，进行负载均衡转换。最后处理后的结果，被转发给真正的RS。原来的两跳访问变成了现在的三跳。同样反方向流量返回时，RS的流量先回到引流交换机，然后被分发到对应的LD设备上。LD处理完之后，再把报文直接转到client虚拟机上。借助引流交换机的中转，我们就能够让负载均衡的专区设备的放到普通的服务器区里。

另外：这里的CLB服务器，可以跟其他的网关包括母机复用一些相同机型的服务器，当需要扩容时，就可以使用通用服务器。而不像以前CLB既有自己独立的机型，又对服务器的物理位置有要求。有了引流交换机跟LD之间是做隧道传输，LD具体的物理位置就没有像原来一样有硬性的要求。这样CLB可以通过通用服务器区域，调配服务器。

最后一项是：原有跟REIP类似的，CLB设备做路由通告时，也是按照网段通告，有引流交换机之后，我们可以在引流交换机上去做细粒度的调度，一个VIP或是几个vip放到一个集群。还可以在引流交换机上做更细粒度的调度，如IP+port这样的五元组的粒度的调度。

10、未来展望

目前网关设备最重要也是最大的一个方向就是做高性能、硬件卸载。依赖硬件来实现高性能的转发。

网关设备分为有状态和无状态两种：

• 1）无状态设备就像IP转换一样，只要依据规则，任何时刻来了报文，转换出来的形式都是固定的；
• 2）有状态设备是需要记录TCP、 UDP状态，记录转发到后端设备，当不同的时间转发即使相同的类型的流量，它转发的目的地也不一样，转换的格式也可能不一样。

硬件卸载在有状态和无状态时，基本上用到的设备都是DPU和交换机，用到的介质几乎都是FPGA。

FPGA和ASIC本质上是一个东西，无论友商还是我们自己内部研发，更多的是FPGA上做功能，并小规模的灰度上线验证，一旦稳定下来，就转化成批量的ASIC，以此来降低成本。

DPU和交换机在无状态设备上，交换机相对更有优势，因为无状态设备对容量的要求相对小些，像EIP网关以及内部无状态的网关大多用交换机形态实现。DPU目前更多的用在母机侧，做有状态类的网络处理。当然， 采用DPU不仅仅局限网络诉求，还有存储安全等其他需求。去年英特尔宣布已不再进行交换机tf芯片的演进迭代，大家对交换机的质疑会增大。

所以，也衍化了另一种方案：在一台额外的服务器中插入 DPU 网卡以实现卸载功能。

但不同方案有不同的优缺点：

1）使用交换机的最大优势在于其强大的交换性能（可达 1T或几个T及更高），可支持很大的接入容量。但是，交换机仅能是一个底座，若要扩展容量仍需依赖 FPGA 技术。

2） DPU 的优点则包括成熟的产业链、庞大的产量以及稳定的供应保障；此外，由于 DPU 在母机侧已被广泛验证和采用，许多功能的实现都相对固定。

这是两种方案各自的优缺点。

在两个产品运用负载均衡状态的交换上，业内不同的厂家也有不同的玩法，有的是交换机，有的是DPU。当前，无论是交换机还是 DPU，都依赖FPGA(ASIC)来做大容量的会话管理，同时越来越多的设备或多或少的支持P4。在 X86 上进行编程时，通常选择 DPDK。

相较之下：使用 P4 进行编程的门槛较低。P4 编写一般功能需求的代码非常简单快捷，只需一两周时间即可完成，甚至对于熟练者来说，可以在几个小时就开发出一个小功能。虽然充分发挥硬件的性能，P4类芯片还需要进行很深入细节的研究，但P4还是大大降低了数据面编程的门槛，特别是在高性能转发的需求方面。

另一个特点是：小型化。大家过去比较关注数据中心和海量数据的优化问题，随着业务发展，逐步转向降低运营成本和提高效率的场景，开设小型站点。这类小型站点，是典型的“麻雀虽小，五脏俱全”，希望用尽量少的设备成本来满足各种功能需求。所以我们将设备设计为具有较小规格的产品系列，并在易用性上进行改进，通过集群合并、虚拟机等承担更多的任务负载。这样在业务规模和流量不大，也能以较少的资源应对较高的功能性需求。一旦业务规模扩大，我们可将这些小型站点升级为传统的数据中心级物理设备。

以上未来网关两个主要的方向。

11、相关资料

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

[2] 网络编程入门从未如此简单(三)：什么是IPv6？漫画式图文，一篇即懂！

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

[4] 脑残式网络编程入门(六)：什么是公网IP和内网IP？NAT转换又是什么鬼？

[5] 脑残式网络编程入门(七)：面视必备，史上最通俗计算机网络分层详解

[6] 以网游服务端的网络接入层设计为例，理解实时通信的技术挑战

[7] 百度统一socket长连接组件从0到1的技术实践

[8] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

[9] 百度APP移动端网络深度优化实践分享(二)：网络连接优化篇

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

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

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

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

[-1-] 跟着源码学IM(一)：手把手教你用Netty实现心跳机制、断线重连机制

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

[摘要] 说到用Netty来开发IM或推送系统，以一个生产级产品的标准来说，最基本的心跳机制、断线重连机制肯定得有吧？好，如果你还不清楚这些，那就看看本文吧！

[-2-] 跟着源码学IM(二)：自已开发IM很难？手把手教你撸一个Andriod版IM

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

[摘要] 本文适合没有任何即时通讯（IM）开发经验的小白开发者阅读，文章将教你从零开始，围绕一个典型即时通讯（IM）系统的方方面面，手把手为你展示如何基于Netty+TCP+Protobuf来开发出这样的系统。非常适合从零入门的Android开发者。

[-3-] 跟着源码学IM(三)：基于Netty，从零开发一个IM服务端

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

[摘要] “文适合IM新手阅读，但最好有一定的网络编程经验，必竟实践性的代码上手就是网络编程。如果你对网络编程，以及IM的一些理论知识知之甚少，请务必首先阅读：《新手入门一篇就够：从零开发移动端IM》，该文为IM小白分类整理了详尽的理论资料，请按需补充相关知识。

[-4-] 跟着源码学IM(四)：拿起键盘就是干，教你徒手开发一套分布式IM系统

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

[摘要] 本文记录了我开发的一款面向IM学习者的 IM系统——CIM（全称：CROSS-IM），同时提供了一些组件帮助开发者构建一款属于自己可水平扩展的 IM。

[-5-] 跟着源码学IM(五)：正确理解IM长连接、心跳及重连机制，并动手实现

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

[摘要] 本文正好借着在CIM系统中有这样两个需求（CIM是本文作者从零开发的一个学习性质的IM系统，详见《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》），正好来聊一聊我是如何理解IM长连接的心跳及重连机制，以及又是怎么踩坑已及填坑的。

[-6 -] 跟着源码学IM(六)：手把手教你用Go快速搭建高性能、可扩展的IM系统

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

[摘要] 本文适合有一定网络通信技术基础的IM新手阅读。如果你对网络编程，以及IM的一些理论知识知之甚少，请务必首先阅读：《新手入门一篇就够：从零开发移动端IM》，按需补充相关知识。

[-7-] 跟着源码学IM(七)：手把手教你用WebSocket打造Web端IM聊天

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

[摘要] 本文将基于Tomcat和Spring框架实现一个逻辑简单的入门级IM应用，对于即时通讯初学者来说，能找到一个简单直接且能顺利跑通的实例代码，显然意义更大，本文正是如此。希望能给你的IM开发和学习带来启发。

[-8-] 跟着源码学IM(八)：万字长文，手把手教你用Netty打造IM聊天

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

[摘要] 上篇《跟着源码学IM(七)：手把手教你用WebSocket打造Web端IM聊天》中，我们使用 WebSocket 实现了一个简单的 IM 功能，支持身份认证、私聊消息、群聊消息。然后就有人发私信，希望使用纯 Netty 实现一个类似的功能，因此就有了本文。

[-9 -]  跟着源码学IM(九)：基于Netty实现一套分布式IM系统

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

[摘要] 接下来的内容，我会为你介绍如何开发一个IM的方方面面，包括系统架构、通信协议、单聊群聊、表情发送、UI事件驱动等，以及全套的实践源码让你可以上手学习。

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

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

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

[-11 -] 跟着源码学IM(十一)：一套基于Netty的分布式高可用IM详细设计与实现(有源码)

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

[摘要] 本文将要分享的是如何从零实现一套基于Netty框架的分布式高可用IM系统，它将支持长连接网关管理、单聊、群聊、聊天记录查询、离线消息存储、消息推送、心跳、分布式唯一ID、红包、消息同步等功能，并且还支持集群部署。

[-12 -] 跟着源码学IM(十二)：基于Netty打造一款高性能的IM即时通讯程序

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

[摘要] 原本打算做个多人斗地主练习程序，但那需要织入过多的业务逻辑，因此一方面会带来不必要的理解难度，让案例更为复杂化，另一方面代码量也会偏多，所以最终依旧选择实现基本的IM聊天程序，既简单，又能加深对Netty的理解。

👉52im社区本周新文：《微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗》《移动端IM产品RainbowChat[专业版] iOS端 v9.0版已发布！》，欢迎阅读！👈

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

本文由微信技术团队分享，原题“十年前的微信消息收发架构长啥样？”，下文进行了排版和内容优化等。

1、引言

2023 年，微信及 WeChat 的 DAU（月活用户）达到 13.4 亿，微信已经是很多人工作、生活中不可或缺的一个环节。从 2011 年 1 月 21 日上线至今，微信已经走过了 13 个年头，其背后的技术基座与架构也发生了巨大的变化。这些变化背后，所折射的也正是中国互联网高速发展的黄金年代。

好的架构是迭代出来的，却也少不了良好的设计，本文将带大家回顾微信背后最初的也是最核心的IM消息收发技术架构，愿各位读者能从中获得启发。

2、微信技术起步

微信诞生于 QQMail 团队，初始的整个微信后台架构都带着浓重的邮箱气息，消息收发架构作为微信最为核心的部分，同样是基于邮箱的存储转发机制演变而来。

微信定位为即时通讯IM软件，对消息的收发有2个基本的要求：

• 1）消息尽可能的实时送达；
• 2）不丢消息。

在邮箱的存储转发机制上做了改良后，微信的消息收发实现了以上2个基本要求。

3、消息发送架构

首先通过手机 A 给手机 B 发送一条微信消息来看消息发送的整体架构是怎样的（如下图所示）。

微信消息发送在整体架构上可以分为2个部分。

第一部分：手机A发送消息到服务器（上图中1、2、3部分）：

• 1）1 - 手机A发送发消息请求到接入层 ConnnectSvr；
• 2）2 - 接入层收到请求后，将请求转到逻辑层 SendSvr 进行处理；
• 3）3 - 逻辑层处理完各种逻辑（如反垃圾，黑名单等等）之后，将消息存入存储层 MsgStore。

第二部分：服务器发送通知到手机B（上图中4、5.1、5.2、6、7部分）：

1）4 - 逻辑层 SendSvr 将给手机 B 的新消息到达通知发送到通知处理服务器 PushSvr。

2）5.1 - PushSvr 查询手机 B 在接入层所在长连接的 ConnectSvr，并将通知发给该 ConnectSvr。

3）5.2 - PushSvr 发送一个 Push tips 给手机操作系统自建的第三方 Push 系统（如苹果的 APNsPush，微软的 WPPush，黑莓的 BBPush 等）。像苹果的 IOS 系统，在 APP 退出到后台10分钟后就会释放掉该 APP 所持有的所有资源（如 CPU，网络，内存等），导致之前建立的长连接通道也会一并断掉，此时通过5.1的方式进行通知是不可达的，所以还需要依赖与苹果自身的 apns 通道来达到实时通知的目的。

4）6 - 接入层 ConnnectSvr 通过手机 B 建立的长连接通道将新消息达到通知发送给手机 B。

5）7 - 第三方 Push 服务器通过自建的 Push 通过发送 Push tips 到手机 B。

4、消息接收架构

手机 B 在收到新消息到达通知后进行消息收取的整体架构如下图所示：

 

消息收取的流程主要分为3个步骤：

• 1）手机 B 发起收取消息的请求到接入层服务器 ConnnectSvr；
• 2）接入层服务器 ConnnectSvr 接到请求后转给逻辑层服务器 ReceiveSvr 进行处理；
• 3）ReceiveSvr 从存储层 MsgStore 中获取到需要下发的消息。

5、消息收发架构小结

在上述第4、5两节中分享的消息收发架构保障之下，微信可以保证手机 A 在发出消息 100ms 级别内让手机 B 收取到该条消息。

当然，对于退出后台的苹果 iOS 的微信用户，在苹果的 APNs 服务器正常的情况下，也可以保证在秒级别内通知到手机 B 点开 APP 进入前台来收取消息。

6、消息防丢失机制

虽然消息收发架构保证了消息收发双方能够及时收发消息，但该架构不能保证消息在传输过程中不发生丢弃。

当然为了达到任意一条消息都不丢的状态，最简单的方案是手机端对收到的每条消息都给服务器进行一次 ack 确认，但该方案在手机端和服务器之间的交互过多，并且也会遇到在弱网络情况下 ack 丢失等问题。

为了完美的做到消息不丢，微信消息系统对消息收发引入了 sequence 机制。

PS：感兴趣的话，以下是更多与IM消息送达保证有关的文章，可以一并阅读：

1. 理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨
2. 融云技术分享：全面揭秘亿级IM消息的可靠投递机制
3. 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制
4. IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

7、消息防丢失机制技术实现

7.1sequence 机制

• 1）每个用户都有42亿的 sequence 空间（从1到 UINT_MAX），从小到大连续分配；
• 2）每个用户的每条消息都需要分配一个 sequence；
• 3）服务器存储有每个用户已经分配到的最大 sequence；
• 4）手机端存储有已收取消息的最大 sequence。

PS：微信sequence序列号生成的具体算法和实现详见《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》。

7.2消息收取sequnece确认机制

当服务器和手机端都拥有了一个 sequence 之后，服务器和手机端之间就可以根据两者 sequence 的差异来收取消息，同时保证手机端未收取下去的消息最终能够收取下去。

具体流程如下图表示：

1）根据服务器和手机端之间 sequence 的差异，可以很轻松的实现增量下发手机端未收取下去的消息。

2）对于在弱网络环境差的情况，丢包情况发生概率是比较高的，此时经常会出现服务器的回包不能到达手机端的现象。由于手机端只会在确切的收取到消息后才会更新本地的 sequence，所以即使服务器的回包丢了，手机端等待超时后重新拿旧的 sequence 上服务器收取消息，同样是可以正确的收取未下发的消息。

3）由于手机端存储的 sequence 是确认收到消息的最大 sequence，所以对于手机端每次到服务器来收取消息也可以认为是对上一次收取消息的确认。一个帐号在多个手机端轮流登录的情况下，只要服务器存储手机端已确认的 sequence，那就可以简单的实现已确认下发的消息不会重复下发，不同手机端之间轮流登录不会收到其他手机端已经收取到的消息。

如上图4所示：假如手机 A 拿 Seq_cli = 100 上服务器收取消息，此时服务器的 Seq_svr =  150，那手机 A 可以将 sequence 为[101 - 150]的消息收取下去，同时手机 A 会将本地的 Seq_cli 置为150。

如上图5所示：手机 A 在下一次再次上来服务器收取消息，此时 Seq_cli = 150，服务器的 Seq_svr = 200，那手机 A 可以将 sequence为[151 - 200]的消息收取下去。

如上图6所示：假如原手机 A 用户换到手机 B 登录，并使用 Seq_cli = 120 上服务器收取消息，由于服务器已经确认 sequence <= 150 的消息已经被手机收取下去了，故不会再返回 sequence 为[121 - 150]的消息给手机 B，而是将 sequence 为[151 - 200]的消息下发给手机 B。

这里虽然 sequence 为[151 - 200]的消息有可能是被手机 A 和手机 B 都收取到，但由于手机 A 在收到 sequence 为[151 - 200]的消息时并没有给服务器进行确认或者这些消息手机 A 压根就没有收取到，所以为了防止消息丢失，sequence 为[的消息也是需要下发给手机 B 的。

8、本文小结

以上简单文字描述的就是微信最初的IM消息收发的架构。

该架构实现了即时通讯软件对消息收发所需的两个基本要求：

• 1）消息尽可能的实时送达 ；
• 2）不丢消息。

以上：是 2014 年微信古早时期的消息收发架构的基本介绍，时过境迁，微信的消息收发架构已经发生了巨大的变化，但我们还是可以从中看到技术演变的价值与力量。

程序员最大的成就与幸福，或许就是自己的代码跑在千万人的设备上，默默支撑着海量的需求。

9、参考资料

[1] iOS的推送服务APNs详解：设计思路、技术原理及缺陷等

[2] 了解iOS消息推送一文就够：史上最全iOS Push技术详解

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

[4] 微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）

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

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

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

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

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

[10] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[11] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

[12] IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总

[13] 零基础IM开发入门(一)：什么是IM系统？

[14] 理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨

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

10、微信团队的其它文章

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

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

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

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

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

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

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

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

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

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

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

《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》

《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》

《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》

《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》

《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》

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

《IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践》

《微信团队分享：微信后台在海量并发请求下是如何做到不崩溃的》

《微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等》

《微信技术分享：揭秘微信后台安全特征数据仓库的架构设计》

《IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存优化实践》

《企业微信针对百万级组织架构的客户端性能优化实践》

《揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链》

《微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题》

《微信团队分享：微信后端海量数据查询从1000ms降到100ms的技术实践》

《大型IM工程重构实践：企业微信Android端的重构之路》

《IM技术干货：假如你来设计微信的群聊，你该怎么设计？》

（本文已同步发布于：http://www.52im.net/thread-4636-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 实现）。

v9.0 版更新内容

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

• 1）[新增] 新增“@”功能；
• 2）[新增] 新增消息引用功能（支持引用全部消息类型）；
• 3）[bug] 解决显示Android端发起的的音视频呼叫记录时，显示的是JSON文本的问题；
• 4）[bug] 解决了消息转发时，“最近消息”列表中的表情内容没有被转义成表情图标的问题；
• 5）[bug] 聊天界面中对新发的图片消息等长按时不显示弹出菜单的问题（直到表格被刷新后才会正常）；
• 6）[优化] 首页消息列表中的语音消息将显示语音时长（跟新版微信一样）；
• 7）[优化] 其它优化及bug修复。

新增功能运行截图（更多截图点此查看）：

本文由微信技术团队仇弈彬分享，原题“微信海量数据查询如何从1000ms降到100ms？”，本文进行了内容修订和排版优化。

1、引言

微信的多维指标监控平台，具备自定义维度、指标的监控能力，主要服务于用户自定义监控。作为框架级监控的补充，它承载着聚合前 45亿/min、4万亿/天的数据量。

当前，针对数据层的查询请求也达到了峰值 40万/min，3亿/天。较大的查询请求使得数据查询遇到了性能瓶颈：查询平均耗时 > 1000ms，失败率居高不下。

针对大数据量带来的查询性能问题，微信团队对数据层查询接口进行了针对性的优化，将平均查询速度从1000ms+优化到了100ms级别。本文为各位分享优化过程，希望对你有用！

2、技术背景

微信多维指标监控平台（以下简称多维监控），是具备灵活的数据上报方式、提供维度交叉分析的实时监控平台。

在这里，最核心的概念是“协议”、“维度”与“指标”。

例如：如果想要对某个【省份】、【城市】、【运营商】的接口【错误码】进行监控，监控目标是统计接口的【平均耗时】和【上报量】。在这里，省份、城市、运营商、错误码，这些描述监控目标属性的可枚举字段称之为“维度”，而【上报量】、【平均耗时】等依赖“聚合计算”结果的数据值，称之为“指标”。而承载这些指标和维度的数据表，叫做“协议”。

多维监控对外提供 2 种 API：

1）维度枚举查询：用于查询某一段时间内，一个或多个维度的排列组合以及其对应的指标值。它反映的是各维度分布“总量”的概念，可以“聚合”，也可以“展开”，或者固定维度对其它维度进行“下钻”。数据可以直接生成柱状图、饼图等。

2）时间序列查询：用于查询某些维度条件在某个时间范围的指标值序列。可以展示为一个时序曲线图，横坐标为时间，纵坐标为指标值。

然而，不管是用户还是团队自己使用多维监控平台的时候，都能感受到明显的卡顿。主要表现在看监控图像或者是查看监控曲线，都会经过长时间的数据加载。

团队意识到：这是数据量上升必然带来的瓶颈。

目前：多维监控平台已经接入了数千张协议表，每张表的特点都不同。维度组合、指标量、上报量也不同。针对大量数据的实时聚合以及 OLAP 分析，数据层的性能瓶颈越发明显，严重影响了用户体验。

于是这让团队人员不由得开始思考：难道要一直放任它慢下去吗？答案当然是否定的。因此，微信团队针对数据层的查询进行了优化。

3、优化分析1：用户查询行为分析

要优化，首先需要了解用户的查询习惯，这里的用户包含了页面用户和异常检测服务。

于是微信团队尽可能多地上报用户使用多维监控平台的习惯，包括但不限于：常用的查询类型、每个协议表的查询维度和查询指标、查询量、失败量、耗时数据等。

在分析了用户的查询习惯后，有了以下发现：

1）时间序列查询占比 99% 以上：

出现如此悬殊的比例可能是因为：调用一次维度枚举，即可获取所关心的各个维度。

但是针对每个维度组合值，无论是页面还是异常检测都会在查询维度对应的多条时间序列曲线中，从而出现「时间序列查询」比例远远高于「维度枚举查询」。

2）针对1天前的查询占比约 90%：

出现这个现象可能是因为每个页面数据都会带上几天前的数据对比来展示。异常检测模块每次会对比大约 7 天数据的曲线，造成了对大量的非实时数据进行查询。

4、优化分析2：数据层架构

分析完用户习惯，再看下目前的数据层架构。

多维监控底层的数据存储/查询引擎选择了 Apache-Druid 作为数据聚合、存储的引擎，Druid 是一个非常优秀的分布式 OLAP 数据存储引擎，它的特点主要在于出色的预聚合能力和高效的并发查询能力。

它的大致架构如图：

具体解释就是：

5、优化分析3：为什么查询会慢

查询慢的核心原因，经微信团队分析如下：

1）协议数据分片存储的数据片段为 2-4h 的数据，每个 Peon 节点消费回来的数据会存储在一个独立分片。

2）假设异常检测获取 7 * 24h 的数据，协议一共有 3 个 Peon 节点负责消费，数据分片量级为 12*3*7 = 252，意味着将会产生 252次 数据分片 I/O。

3）在时间跨度较大时、MiddleManager、Historical 处理查询容易超时，Broker 内存消耗较高。

4）部分协议维度字段非常复杂，维度排列组合极大（>100w），在处理此类协议的查询时，性能就会很差。

6、优化实践1：拆分子查询请求

根据上面的分析，团队确定了初步的优化方向：

• 1）减少单 Broker 的大跨度时间查询；
• 2）减少 Druid 的 Segments I/O 次数；
• 3）减少 Segments 的大小。

在这个方案中，每个查询都会被拆解为更细粒度的“子查询”请求。例如连续查询 7 天的时间序列，会被自动拆解为 7 个 1天的时间序列查询，分发到多个 Broker，此时可以利用多个 Broker 来进行并发查询，减少单个 Broker 的查询负载，提升整体性能。

但是这个方案并没有解决 Segments I/O 过多的问题，所以需要在这里引入一层缓存。

7、优化实践2：拆分子查询请求+Redis Cache

7.1概述

这个方案相较于 v1，增加了为每个子查询请求维护了一个结果缓存，存储在 Redis 中（如下图所示）。

假设获取 7*24h 的数据，Peon 节点个数为 3，如果命中缓存，只会产生 3 次 Druid 的 Segments I/O （最近的 30min）数据，相较几百次 Segments I/O 会大幅减少。

接下来看下具体方法。

7.2时间序列子查询设计

针对时间序列的子查询，子查询按照「天」来分解，整个子查询的缓存也是按照天来聚合的。

以一个查询为例：

{

    "biz_id": 1, // 查询协议表ID：1

    "formula": "avg_cost_time", // 查询公式：求平均

    "keys": [

        // 查询条件：维度xxx_id=3

        {"field": "xxx_id", "relation": "eq", "value": "3"}

    ],

    "start_time": "2020-04-15 13:23", // 查询起始时间

    "end_time": "2020-04-17 12:00"// 查询结束时间

}

其中 biz_id、 formula,、keys 了每个查询的基本条件。但每个查询各不相同，不是这次讨论的重点。

本次优化的重点是基于查询时间范围的子查询分解，而对于时间序列子查询分解的方案则是按照「天」来分解，每个查询都会得到当天的全部数据，由业务逻辑层来进行合并。

举个例子：04-15 13:23 ～ 04-17 08:20 的查询，会被分解为 04-15、04-16、04-17 三个子查询，每个查询都会得到当天的全部数据，在业务逻辑层找到基于用户查询时间的偏移量，处理结果并返回给用户。

每个子查询都会先尝试获取缓存中的数据，此时有两种结果：

经过上述分析不难看出：对于距离现在超过一天的查询，只需要查询一次，之后就无需访问 DruidBroker 了，可以直接从缓存中获取。

而对于一些实时热数据，其实只是查询了cache_update_time-threshold_time 到 end_time 这一小段的时间。在实际应用里，这段查询时间的跨度基本上在 20min 内，而 15min 内的数据由 Druid 实时节点提供。

7.3维度组合子查询设计

维度枚举查询和时间序列查询不一样的是：每一分钟，每个维度的量都不一样。

而维度枚举拿到的是各个维度组合在任意时间的总量，因此基于上述时间序列的缓存方法无法使用。在这里，核心思路依然是打散查询和缓存。

对此，微信团队使用了如下方案。

缓存的设计采用了多级冗余模式，即每天的数据会根据不同时间粒度：天级、4小时级、1 小时级存多份，从而适应各种粒度的查询，也同时尽量减少和 Redis 的 IO 次数。

每个查询都会被分解为 N 个子查询，跨度不同时间，这个过程的粗略示意图如下：

举个例子：例如 04-15 13:23 ～ 04-17 08:20 的查询，会被分解为以下 10 个子查询：

04-15 13:23 ～ 04-15 14:00

04-15 14:00 ～ 04-15 15:00

04-15 15:00 ～ 04-15 16:00

04-15 16:00 ～ 04-15 20:00

04-15 20:00 ～ 04-16 00:00

04-16 00:00 ～ 04-17 00:00

04-17 00:00 ～ 04-17 04:00

04-17 00:00 ～ 04-17 04:00

04-17 04:00 ～ 04-17 08:00

04-17 08:00 ～ 04-17 08:20

这里可以发现：查询 1 和查询 10，绝对不可能出现在缓存中。因此这两个查询一定会被转发到 Druid 去进行。2～9 查询，则是先尝试访问缓存。如果缓存中不存在，才会访问 DruidBroker，在完成一次访问后将数据异步回写到 Redis 中。

维度枚举查询和时间序列一样，同时也用了 update_time 作为数据可信度的保障。因为最细粒度为小时，在理想状况下一个时间跨越很长的请求，实际上访问 Druid 的最多只有跨越 2h 内的两个首尾部查询而已。

8、优化实践3：更进一步（子维度表）

通过子查询缓存方案，我们已经限制了 I/O 次数，并且保障 90% 的请求都来自于缓存。但是维度组合复杂的协议，即 Segments 过大的协议，仍然会消耗大量时间用于检索数据。

所以核心问题在于：能否进一步降低 Segments 大小？

维度爆炸问题在业界都没有很好的解决方案，大家要做的也只能是尽可能规避它，因此这里，团队在查询层实现了子维度表的拆分以尽可能解决这个问题，用空间换时间。

具体做法为：

• 1） 对于维度复杂的协议，抽离命中率高的低基数维度，建立子维度表，实时消费并入库数据；
• 2） 查询层支持按照用户请求中的查询维度，匹配最小的子维度表。

9、优化成果

9.1缓存命中率>85%

在做完所有改造后，最重要的一点便是缓存命中率。因为大部分的请求来自于1天前的历史数据，这为缓存命中率提供了保障。

具体是：

• 1）子查询缓存完全命中率（无需查询Druid）：86%；
• 2）子查询缓存部分命中率（秩序查询增量数据）：98.8%。

9.2查询耗时优化至 100ms

在整体优化过后，查询性能指标有了很大的提升：

平均耗时 1000+ms -> 140ms；P95：5000+ms -> 220ms。

10、相关文章

[1] 微信后台基于时间序的海量数据冷热分级架构设计实践

[2] IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议

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

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

[5] 陌陌技术分享：陌陌IM在后端KV缓存架构上的技术实践

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

[7] 微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]

[8] 腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享

[9] IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践

[10] 微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等

[11] 微信技术分享：揭秘微信后台安全特征数据仓库的架构设计

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

11、微信团队的其它文章

《Android版微信安装包“减肥”实战记录》

《iOS版微信安装包“减肥”实战记录》

《移动端IM实践：iOS版微信界面卡顿监测方案》

《微信“红包照片”背后的技术难题》

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

《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》

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

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

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

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

《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》

《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》

《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》

《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》

《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》

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

《微信团队分享：微信后台在海量并发请求下是如何做到不崩溃的》

《IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存优化实践》

《企业微信针对百万级组织架构的客户端性能优化实践》

《揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链》

《微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题》

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

本文由冀浩东分享，原题“单核QPS近6000S，陌陌基于OceanBase的持久化缓存探索与实践”，为了阅读便利，本文进行了排版和内容优化等。

1、引言

挚文集团于 2011 年 8 月推出了陌陌，这款立足地理位置服务的开放式移动视频IM应用在中国社交平台领域内独树一帜。陌陌和探探作为陌生人社交领域的主流IM应用，涵盖了多种核心业务模块，包括直播服务、附近动态功能、即时通讯（IM）业务以及增值服务等，每个业务场景都具有其独特性和挑战。

在本文中，陌陌数据库负责人冀浩东将聚焦探讨陌陌的 KV 系统架构选型思路，深入解析如何进行此类系统的甄选决策，同时进一步分享陌陌团队在采用 OceanBase（OBKV）过程中所经历的探索与实践经验。

2、关于作者

冀浩东：陌陌（现挚文集团）数据库负责人。目前负责陌陌和探探两个数据库团队建设以及集团数据库存储运营工作。在大规模数据源稳定性建设 、团队建设、成本优化、机房迁移等方面等领域积累了深厚的专业经验与实战心得。

3、陌陌的主要IM业务场景特点

1）直播业务：在陌陌众多业务场景中，直播业务占据了显著位置，其特点就在于随时可能出现的流量突发场景。由于低延时和高并发的需求，直播场景对数据库系统的实时处理能力提出了较高要求。平台需要确保在大量用户同时在线观看和互动时，数据能够被及时、准确地处理和分发。

2）附近动态：此功能则涉及到用户的地理位置信息、活动轨迹以及社交关系等复杂数据。这类数据会迅速积累，并随着时间的推移形成大规模的数据集。数据具有明显的冷热分层特性，即某些数据在某一时刻可能会成为热点，如当某用户发布的帖子引发热议并成为热门话题时。这要求系统能够有效管理并快速响应热点数据的访问需求。

3）IM 业务：此场景的核心特点是低延迟和高并发通信。信息的送达时间必须精确，对实时性有极高的要求。为了保证用户体验，应用程序需要确保消息能够即时、可靠地在用户之间传递。

4）增值服务：则主要侧重于数据的一致性和实时性。在处理用户购买、赠送虚拟物品或享受会员特权等操作时，系统需要确保数据的准确性并及时更新用户账户状态。同时，为了提供优质的增值服务，实时性也是不可或缺的因素，例如实时计算用户的积分、等级或者权益等。

陌陌和探探在运营这些业务场景时，都需要强大的数据处理和管理系统来应对各种特性和挑战，以确保为用户提供高效、稳定且满足个性化需求的社交体验。

针对以上的业务场景，我们应该如何选择 KV 系统呢？

4、陌陌后端KV缓存架构的演进阶段

在公司的成长过程中，存储选型通常会经历四个阶段。

4.1初始阶段

公司的主要目标是能够运行起来。

在创业初期，基于新开发的 App 进行运营工作时，由于业务能力可能还未成熟，为了应对快速迭代的业务需求，对系统的期望不会过高。只需要确保技术层面能够满足基本的业务需求并逐步演进即可。在这个阶段，常见的架构选择包括 Redis 主从架构和 Redis Cluster 等原生架构。

Redis 主从集群架构的优势在于可以迅速构建主从集群或分片集群，并且许多设计可以直接在客户端操作。然而，这种简单的操作方式可能导致设计与客户端业务代码的高度耦合，不利于后期的弹性扩容。

相比之下，Redis Cluster 集群架构支持动态扩容和高可用性。

然而，使用 Redis Cluster 时，业务依赖客户端感知节点变更。如果客户端未能正确处理节点变更，可能会导致服务中断或业务性能下降，因此对于对错误敏感的业务，Redis Cluster 可能会引入额外的复杂性。尽管 Redis Cluster 具有去中心化、组件少、提供 Smart Client 以及支持水平扩展等优点，但也存在批处理功能不友好和缺乏有效流控机制等问题。

4.2第二阶段

进入第二阶段，随着公司的发展和用户数量的增长，需要架构具备快速扩展的能力。

这一阶段的代表性架构例如 Codis、Twemproxy 等基础性 Redis分片架构。

其中，Codis提供了服务端分片方案、中心化管理、故障自动转移、节点水平扩展（1024 槽位）、动态扩缩容，以及支持 pipeline 和批处理等功能。

然而，Codis的当前版本较为陈旧，官方仅提供 3.2.9 版本，更新版本需要自行修复和适配，且由于组件多、资源消耗大。

4.3第三阶段

随着业务的进一步发展和公司进入相对稳定期，可能会发现先前急于扩张时遗留了一些问题。

例如：是否过度使用内存，数据是否可以冷热分层等。这些问题需要重新检验和优化。这个优化过程是第三阶段的重点。

在这个阶段，常见的持久化架构选择包括 oneStore-Pika、Tendis 和 Pika 等。

4.4第四阶段

最后，在第四阶段，公司业务和技术可能已经进入了深度复杂的领域，简单的优化调整可能无法带来显著的收益，甚至可能出现无法进一步优化的情况。

这时，可以通过引入更稳定的架构或者采用新的解决思路来应对挑战。

我们个人推荐考虑多模态架构，它能够适应多种数据类型和工作负载，提供更大的灵活性和优化空间。

总的来说，公司在不同发展阶段的存储选型应根据业务需求、技术成熟度、成本效益以及未来的扩展性和优化空间等因素进行综合考虑和决策。随着公司的发展和业务复杂性的增加，存储架构也需要不断进化和优化，以确保系统的稳定、高效和可持续发展。

5、陌陌自研的KV缓存“oneStore”

针对当前公司的业务状况，陌陌面临的最显著挑战在于集群规模的不断增长。

当单集群分片数量超过 1000 个，数据量超过 10TB，以及 QPS 超过 100 万时，现有的 Codis 架构和 Redis Cluster 架构已然无法满足需求，达到了其承载能力的极限。

为了解决这一瓶颈问题，公司自主研发了一款名为 oneStore 的存储产品（如下图所示）。

这一架构经过了分阶段的优化和改进过程，旨在突破原有的限制，以适应更高的分片数量、更大的数据量以及更密集的查询请求。通过 oneStore 架构，陌陌力求实现业务扩展的无缝对接和性能的大幅提升。

1）第一阶段：提供服务端 Proxy 方案，并通过自主研发的 oneStore Watcher 哨兵组件进行架构精简。这样一来，只需要部署一套哨兵集群，就能有效地管理一个业务区域。

2）第二阶段：提供客户端 SDK 方案。虽然服务端 Proxy 方案表现优秀，但随着业务的稳定，公司着眼于降本增效。直接使用客户端 SDK 方案，感知集群拓扑变化，并且通过 SDK 直连后端 Redis 地址，这样可以去除服务端 Proxy 组件，节省技术资源开销。然而，我们并没有完全摒弃服务端 Proxy 方案。因为目前陌陌的客户端 SDK 方案仅支持 Java 和 C++，对于 PHP、Python 等其他语言的用户，仍需要通过服务端 Proxy 访问数据源。这两种方案的成功运用，帮助我们统一了公司层面 Redis 的接入方式，并显著提升了机房迁移的效率。

随着业务的进一步稳定，陌陌开始从成本角度进行优化，选择 Pika 替代部分请求量不高的 Redis 集群，再提升架构的持久化能力（如下图所示）的同时降低存储成本。

然而现阶段 Pika 主要用来存储一些相对较冷数据，对于热数据的处理性能仍有待提高，后续团队也会持续关注并努力提升这一方面的性能。

总的来说，目前陌陌还面临一些需要解决和优化的场景：

1）单机多实例之间互相影响的问题：陌陌迫切需要解决单机多实例之间相互影响的问题，以确保各个实例的稳定运行和高效协作。这涉及到系统的整体稳定性和协同性，需要有针对性的优化和调整。

2）数据持久化支持：陌陌计划增强数据持久化的支持能力，以实现完整的数据持久化解决方案，以保障数据的完整性和可靠性。不仅仅局限于冷数据，而是要覆盖更广泛的数据类型，以确保数据的完整性和可靠性。这将是系统长期稳定性的一个重要保障。

所以，陌陌需要通过一个简单可靠可扩展的 KV 系统来解决以上问题。

6、陌陌的分布式KV缓存选型

6.1OceanBase

OBKV 是 OceanBase 数据库提供的通过 API 接口访问 Table 模型 Hbase 模型的能力。

有关OceanBase 数据库的来历，详见：《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路 。

之所以选择 OceanBase（OBKV），主要看中其两大优势：

• 1）性能更好；
• 2）稳定性高。

6.2关于性能

OceanBase（OBKV）基于 Table 模型构建，与 Redis 数据结构持久化方案这个典型的表模型匹配，且性能比传统持久化存储更强 ，能构建更丰富的数据结构。

下图是OceanBase（OBKV）在大量写数据的场景（TPS 17000），由于不同阶段都有任务在写数据，可以看出 TPS 非常陡峭，并且响应延时在 2 毫秒以下，事务的响应时间明细与预期是相对应的。

下图为 CPU 监控图：可以看到 CPU 使用率在 10% 以下，相对稳定。MemStore 的使用比例也是正常的，在 24% 以内，波动范围非常小，符合预期。

整体来看：OceanBase（OBKV） 生产环境波动小，资源占用稳定。

6.3关于稳定性

OceanBase（OBKV）基于 OceanBase ，存储引擎经过丰富的大规模 TP 场景验证，能提供高并发、低延时的能力。

从下图OceanBase（OBKV） 的多租户功能可见其稳定性。黑色线代表OceanBase（OBKV）租户，蓝色线的租户是 MySQL 租户。在 11:30 左右发起压测以后，OceanBase（OBKV） 租户的响应正常， MySQL 租户也没有受到影响。从服务器层面来看，CPU 负载是因为压测而上升的，而 MySQL 租户并不受影响。

因此可以得出：多租户功能能够有效解决单机多实例的相互影响问题。下图展示了是线上 MySQL 生产租户的表现，TPS 为 5000时，整体表现非常稳定。CPU 和内存使用波动较小，符合预期。

此外：能够便捷地通过 KV 接口将数据存入数据库，并运用 SQL 进行数据查询。OceanBase（OBKV）进一步增强了这一便捷性，支持二级索引以及服务端TTL功能，这有助于显著简化上层服务架构的设计。

尽管如此，OceanBase（OBKV）也存在一定的局限性，如仅提供单机事务处理能力；若要开启分布式事务支持，则可能会影响到系统在高并发环境下的性能表现和低延时响应能力。但鉴于当前陌陌业务的需求，我们认为OceanBase（OBKV）的单机事务能力完全符合要求，并因此共同构建了结合OceanBase（OBKV）- Redis 储存方案。

7、陌陌的分布式KV集群架构改进

陌陌与 OceanBase 开源团队共同打造了一个内部代号为 modis 的项目。

该项目整体架构涵盖了接入层、数据结构层、缓冲层、存储层以及管理平面等多个层次（具体可参考下图）。

值得注意的是：缓冲层在未来的规划中将用于有效解决热点读取及大 KEY 问题的挑战。而在存储层方面，陌陌将对其进行标准化抽象设计，构建出标准的 Storage 结构，以便能够灵活接入包括但不限于OceanBase（OBKV）在内的多种存储解决方案。

在测试评估过程中，将 Pika 数据（总计 158GB）成功迁移到 OceanBase（OBKV）-Redis 集群后，存储占用空间显著减少至 95GB，这一举措带来了存储成本的显著优化，总体上节约了大约 40% 的存储成本。

为了评估性能表现，特意构建了一个专门的测试环境（具体规格参见下图），并在该环境中模拟了不同并发线程场景以观测其峰值性能情况。

基于多租户管理的思路，不会对单一租户分配过多资源，而是优先观察各个租户在使用过程中哪个率先达到性能瓶颈，并据此计算单核的 QPS。当前，陌陌提供的标准规格为 12C40G 内存。未来，为了更好地适应业务需求的变化，可能会推出更小规格的配置方案，例如 4C8G 或 8C16G 等规格，这些决策将完全取决于实际业务的具体需要。

下图展示了 128 个线程数  QPS 70000 情况下 OceanBase（OBKV）-Redis 的性能表现。

具体是：

• 1）P90 响应延迟为 1.9 ms；
• 2）P95 响应延迟为 2.2 ms；
• 3）P99响应延迟为6.3 ms；

平均计算下来，单核读写比例是 4:1，此时单核能力接近 6000 QPS。

此外：在运维管理方面，深入对比了 OceanBase（OBKV）、Pika 以及 TiKV 在日常运维操作中的特性差异。目前，只有 OceanBase（OBKV）提供了原生的多租户支持功能，这一优势有效地解决了在单机部署多实例时所面临的相互干扰的问题。值得一提的是，OceanBase（OBKV）凭借完备的图形化界面管理工具和参数变更即刻生效的特点，对于数据库运维工作来说，无疑是极其贴心且高效的解决方案。

总的来说，OceanBase（OBKV）-Redis 实现了性能的显著提升、更少的磁盘使用以及运维管理的极大简化。

这主要得益于 OceanBase（OBKV）-Redis 的几个优势：

• 1）多租户隔离，解决单机多实例互相影响的困境；
• 2）存储成本更低。通过 Encoding 框架 + 通用压缩 ，进行表模型存储；
• 3）性能更高。将请求过滤直接下压存储，不用序列化以及反序列化，支持服务端 TTL。

8、相关文章

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

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

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

[4] 腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享

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

[6] 微信技术分享：揭秘微信后台安全特征数据仓库的架构设计

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

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

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

[10] 阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践

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

[12] IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！

[13] 小红书万亿级社交网络关系下的图存储系统的架构设计与实践

[14] IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议

[15] 微信后台基于时间序的海量数据冷热分级架构设计实践

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

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

​[- 1 -] 直播系统聊天技术(一)：百万在线的美拍直播弹幕系统的实时推送技术实践之路

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

[摘要] 本文作者是美拍的架构师，经历了直播弹幕从无到有，从小到大的过程，借此文为大家分享构建弹幕系统的经验，希望能为正在开发或正打算开发弹幕、消息推送、IM聊天等系统的技术同行带来一些启发。

[- 2 -] 直播系统聊天技术(二)阿里电商IM消息平台，在群聊、直播场景下的技术实践

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

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

[- 3 -] 直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路

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

[摘要] 本文将回顾微信直播聊天室单房间海量用户同时在线的消息组件技术设计和架构演进，希望能为你的直播聊天互动中的实时聊天消息架构设计带来启发。

[- 4 -] 直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践

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

[摘要] 本文主要分享的是百度直播的消息系统的架构设计实践和演进过程。

[- 5 -] 直播系统聊天技术(七)：直播间海量聊天消息的架构设计难点实践

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

[摘要] 本文将主要从高可用、弹性扩缩容、用户管理、消息分发、客户端优化等角度，分享直播间海量聊天消息的架构设计技术难点的实践经验。

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

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

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

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

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

[摘要] 本文基于网易云信针对TFBOYS某场线上演唱会的技术支持，为你分享千万级在线用户量的直播系统中实时弹幕功能的技术实践，希望能带给你启发。

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

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

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

[- 9 -]  融云IM技术分享：万人群聊消息投递方案的思考和实践

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

[摘要] 本文根据融云技术团队的实践经验，总结了万人群聊消息投递方案的一些思考和实践，希望能给你带来启发。

[- 10 -] 实时社群技术专题(一)：支持百万人超级群聊，一文读懂社群产品Discord

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

[摘要] 本文为系列文章的首篇，文章内容不讨论Discord具体的技术实现，仅从其产品定义的角度上对Discord软件进行详尽和具体的介绍，希望能帮助你对Discord从产品形态上有较为完整的认知，也方便你阅读本系列文章的后续篇章。

[- 11 -] 实时社群技术专题(二)：百万级成员实时社群技术实现（消息系统篇）

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

[摘要] 本文是序列文章的第2篇，将要分享的是云信的实时社群产品“圈组”（“圈组”是云信的类Discord产品实现方案）的消息系统技术设计实践。

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

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

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

👉52im社区本周新文：《陌陌技术分享：陌陌IM在后端KV缓存架构上的技术实践》，欢迎阅读！👈

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

本文由ELab团队公众号授权发布，原题《Rust语言在IM客户端的实践》，来自抖音电商前端团队的分享，本文有修订和改动。

1、引言

本文将介绍飞鸽IM前端团队如何结合Rust对飞鸽客户端接待能力进行的技术提升，一步步从概念验证、路径分解到分工开发，再到最后上线收益论证，并分享了其中遇到的技术挑战与经验总结等。

本项目是一个长周期的复杂项目，相信本项目落地的经验对其他同学及团队能有所借鉴。

2、技术背景

飞鸽是在抖音电商业务上面向商家和用户的聊天工具，其拉通售前、售中、售后渠道，为商家履约提供重要支撑。

对于飞鸽桌面端IM而言，我们会面临很多基础挑战，比如做好会话稳定性、操作流畅性、冷启动速度等，而在满足98%以上的用户需求且业务趋于稳定后，一些在冲刺后遗留的性能天花板问题暴露在我们面前，其中 高并发接待 & 多开是两个重要的挑战，是旧账与难啃的硬骨头。

为何持续会有这些挑战存在？

1）历史技术选型，包含者成本、人力、效率等考量，飞鸽客户端使用的技术栈是react + electron：

* im sdk与业务渲染代码都由 js 编写，im sdk同时是cpu密集型 & io 密集型的组件，在高并发场景下，渲染频率也比较高，业务与sdk相互抢占cpu资源与io资源，导致收发消息慢、操作卡顿（高并发限制）。

* 由于im sdk运行在webview中，所以收发消息依赖webview存活，故多开账号 = 多个webview，内存成本线性增长。

2）im页面在web层面多次优化后已接近架构上限，无法基于现有架构做更多天花板的突破。

对于以上这些挑战，我们给出的解法是：对现有架构进行调整，使用Rust语言对im sdk进行重写，彻底解除这一块的性能瓶颈！

3、为什么选Rust语言？

飞鸽im sdk是一个对运行稳定性要求高的组件，其工程量大、逻辑复杂，对于异步特性使用非常频繁，其对于内存安全、 线程安全有着比较严格的要求。

假如使用C++，作为新手并没有把握能够将复杂的IM SDK少bug的编写下来（团队限制）。

Rust学习曲线虽然陡峭，但是其为安全设计的各类语言特性、强大的编译器，能够将新人编写代码的问题数降到最低（逻辑问题除外）。

并且飞书团队提供了客户端的rust生态库，帮助我们解决很多的基建问题，所以这里使用Rust是相当合适的。

Rust学习成长曲线：

4、飞鸽IM客户端历史架构的问题

如背景中所描述，历史架构存在这两个问题：

• 1）IM SDK 与 业务JS代码共用Weview资源，接待密集的时候，sdk与业务，互相抢占cpu与io资源，导致容易卡顿、消息延迟；
• 2）多开的账号必须依赖IM Webview存活（否则无法收到消息），内存线性增长。

5、飞鸽IM客户端新架构与预期目标

具体是：

• 1）Rust独立进程承担所有的im sdk的计算压力，可以大幅减轻js线程压力，可提升压力场景接待体验；
• 2）Rust im SDK 解除浏览器中的IO限制（如同域名并发数限制）；
• 3）解除Webview存活依赖，依靠rust进程也可收消息，为更多账号的多开能力提供了铺垫。

6、先用Rust进行技术可行性验证

为了验证推测切实可行，我们提前做了完备的POC验证。

在POC中，我们针对“单进程单线程模型”、“多进程模型”、“多线程模型”，这三种模型搭建了mvp demo，即简易的客服聊天模型，并进行压力测试，并监测其内存、cpu等指标。

通过POC，我们得出的结论是：

具体就是：

• 1）rust 整体优于 js，计算占比越重，优势越明显（高压时cpu差别能到达3倍以上）；
• 2）架构选型上，rust进程独立是最好的方案，稳定性更优、性能损耗相差较小。

7、新架构开始实施

路要一步步走，整个项目粗估下来会有上百的工作日，作为业务团队，我们无法在短期内投入大量的资源去做这个项目，所以需要一步一步拆解、验证、拿收益。

团队内native开发资源有限，这件事情的进行也需要团队进行学习、成长。下面我们将详细分享这个过程 。

8、新架构实施阶段1：Rust SDK工程基建

造房子先得有一个地基 —— Rust工程的基础建设，是Native业务的前置条件！

桌面端同学牵头搭建了整个RustSDK地基，地基解决的问题如下图所示：

需要做的工作：

• 1）业务容器：有规律的组织代码结构，进行业务隔离、资源隔离；
• 2）跨进程调用封装：降低业务调用难度；
• 3）建设日志系统、日志回捞：降低排查问题的难度；
• 4）构建跨平台异步执行环境：简化异步代码编写，底层封装，便于跨平台代码迁移；
• 5）跨平台编译，跨平台集成；
• 6）... ...

9、新架构实施阶段2：IM基础能力夯实

在拥有一部分地基后，我们开始针对IM SDK的基础能力进行实现和验证。

因为只有完成基础能力验证之后，我们才会有信心在新的架构上叠加更多的功能。

这阶段我们关注以下指标（ 希望其存在优化，至少不劣化）：

• 1）长链在线率；
• 2）消息发送成功率；
• 3）卡顿率；
• 4）Rust进程崩溃率、无响应率。

仅实现长链能力下沉，验证&提升其稳定：

本阶段论证结果如下：

• 1）Rust Crash率， 达成预期；
• 2）Rust无响应率 - 未达预期，可优化；
• 3）长链在线率 - 达成预期，但是存在优化空间；
• 4）卡顿率 - 不劣化 达成预期；
• 5）消息发送成功率 - 不劣化，达成预期。

这阶段的工作是考验耐心的，因为这个阶段并不能带来实质性的用户体验提升、也无法拿到明显的提升数据，只是作为中间阶段，它有存在的必要性。

这阶段后，在稳定性治理、基础能力验证、 Rust 语言经验、指标制定合理性这几方面，我们踩上了一个更结实的台阶，更有信心去进行更复杂的下一阶段。

10、 新架构实施阶段3：使用Rust实现IM SDK全部能力

夯实基础后，我们开始发力冲刺，大刀阔斧的对IM SDK进行重新设计、实现、联调以及上线。

此阶段要实现im sdk的全部能力、 并对线上运行的js im sdk进行替换。

由于飞鸽im对于通信模块的稳定程度要求是很高的，替换过程就像是在高速行驶的车辆上替换轮胎，如果出现问题也容易导致大量的客服负面反馈。

因此，新rust sdk的稳定性、异常问题时的兜底方案、灰度时的监控观察、对新增反馈的留意都很重要，放量过程会存在一定精神压力。

工作内容大致如下。

1）多实例的Rust IM SDK设计（商家单聊、群聊、平台客服）、Js -> Rust IMSDK跨端调用协议设计：

• a）分析、拆解所有Js Im SDK至今具有的能力，并以贴合Rust的方式重新设计；
• b）需要在协议设计中，尽可能的合并 & 简化 Js -> Rust的调用，以减少IPC通信成本。

2）开发：

• a）Rust IM SDK核心实现；
• b）Rust\Js适配同学紧密合作，根据协议进行业务实现、业务适配；
• c）密切沟通，发现问题及时纠偏；
• d）编写单测；

3）测试：

• a）各类IM场景回归测试；
• b）性能进行验证。

4）异常兜底方案实现：

设计数据冗余，当Rust进程出现崩溃、无响应、不可恢复的网络错误时，识别并fallback到 web版本，使用冗余数据快速恢复im sdk正常运行状态，确保用户体验。

5）稳妥的上线方案 & 稳定性治理。

6）调用&适配优化，结合Native能力进一步性能优化。

7）结果回收。

8）其中各个步骤都会存在一些挑战，在后后面的内容会提到。

调用简化模型：

IM Core简化模型：

11、新架构实施阶段4：基于稳定的RustIM SDK实现形态升级

最后的阶段，我们基于完善的Rust IM SDK的能力进行形态的升级。

本阶段正在进行中，完成后会做更多的分享。

1）多窗口改造：销毁后台的多开账号，让多开账号数量突破到25个。

2）消息提醒、通知流程改造。

3）消息本地化能力：加快消息上屏。

12、技术挑战与实践总结

12.1编程语言 & IM领域知识突破

一个有战斗力的团队，一定是持续学习、进步的。

比如：

• 1）获取学习的纯粹快乐：当沉浸在学习中，并感受到自己在进步的时候，会是一个快乐的状态；
• 2）逐步克服小挑战，及时获得正反馈；
• 3）在同事中找到伙伴和老师，询问与探讨：建立团队中的学习氛围。

12.2长周期技术项目，如何持续保持信心 ？

比如 ：

• 1）Leader与同事认可与支持 — 团队基础、价值观鼓励；
• 2）关注长期收益，训练自己延迟满足感；
• 3）做好阶段性分解与验证，缩短单个周期（如本文的一二阶段拆解，可逐步累积信心）；
• 4）增强自身实力，做好问题把控，及时发现&解决问题。

12.3高效合作

团队Native开发同学少，且各自并行业务需求，需合理的安排开发路线，减少总开发时长。

• 1）合理的设计开发并行路线，减少串行依赖
• 2）协议与接口先行；
• 3）各同学负责其相近&擅长的部分；
• 4）联调时缩短彼此距离，高效沟通。

12.4保障用户体验的灰度上线

1）编写模块的健康自检，检测到异常时用最小的代价切换备用老方案。

2）完善业务监控&技术指标监控：crash率、无响应率、长链在线率、发消息成功率、请求成功率、卡顿率等。

3）对真实用户使用体验进行跟踪：

• a）书反馈群组维护，及时获得用户反馈；
• b）与商家客服保持线下联系，获取一手体验情况。

4）放量节奏的把控：

• a）大型改动可以先给白名单用户试用，收集反馈；
• b）放出能够识别问题的量，解决问题后再继续放量；
• c）放量期间主动查询用户实时反馈数据，有问题及时解决。

12.5如何减少IPC通信成本带来的开销

频率过高的IPC通信可能使得CPU优化适得其反，因为老版本都运行在Js中，所以调用频率是没有节制的（循环读取数据也经常出现），必须要在设计上降低下来——降低业务JS线程的压力。

以下措施可以将本场景通信成本降低90%以上。

1）更高效的数据协议 protobuf：相较于json，数据更小、解析和序列化性能更高、跨语言生成代码工具。

2）Rust push to js：使用数据收集去重 + debounce批量更新的策略，合并多个数据回调接口，减少通信频率。

3）Js call rust（单次基础耗时4ms）：

• a）适当缓存数据，不用每次都回源查询；
• b）需要频繁调用的逻辑下沉Rust，Rust逻辑自完善。

12.6结果回收：极端场景下的优化大盘数据体现不明显

针对某种场景做的优化工作不容易在大盘数据中得到体现（尤其在灰度阶段），我们应该针对特殊场景建立新指标。

即编写策略，识别并收集极端场景下的数据：为了衡量极端场景的的卡顿优化，建立了忙碌与卡顿指标，可以衡量出用户接待忙碌程度与卡顿率的关系，并且通过此指标将优化清晰的衡量出来。

12.7Rust SDK的问题治理

具体是：

• 1）前期的问题不稳定，需更多信息辅助排查，日志尽量完整；
• 2）与真实用户群体保持联系，可加快问题验证、问题发现的过程；
• 3）需要建设便捷的日志回捞 & 日志分析工具（帮助快速找到日志还原现场）。

13、新架构带来的收益

压力评测：

数据表现：

解读一下：

• 1）客服发送消息，大盘端到端耗时降低 40%；
• 2）消息发送成功率三个9 -> 四个9；
• 3）im页面大盘卡顿率降低 15%；
• 4）密集接待场景，卡顿率降低 50%。

全量至今，再无大量进线导致卡顿的反馈。回访历史反馈用户，皆无因大量接待导致的卡顿现象

14、相关文章

[1] 阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践

[2] IM开发干货分享：有赞移动端IM的组件化SDK架构设计实践

[3] IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的

[4] 如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源

[5] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[6] IM开发干货分享：IM客户端不同版本兼容运行的技术思路和实践总结

[7] IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践

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

[9] IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存优化实践

[10] IM跨平台技术学习(五)：融云基于Electron的IM跨平台SDK改造实践总结

[11] 抖音技术分享：抖音Android端手机功耗问题的全面分析和详细优化实践

[12] 社交软件红包技术解密(十二)：解密抖音春节红包背后的技术设计与实践

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

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

[- 1 -] 快速裂变：见证微信强大后台架构从0到1的演进历程（一）

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

[摘要] 2个月的开发时间，微信后台系统经历了从0到1的过程。从小步慢跑到快速成长，经历了平台化到走出国门，微信交出的这份优异答卷，解题思路是怎样的？

[- 2 -] 如何保证IM实时消息的“时序性”与“一致性”？

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

[摘要] 实时消息时序和一致性是分布式系统架构设计中非常难的问题（尤其IM应用这种以消息为中心的应用形态），困难在哪？有什么常见优化实践？这就是本文要讨论的内容。

[- 3 -] IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？

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

[摘要] “用户在线状态的一致性”（单聊好友在线状态、群聊用户在线状态）是IM应用领域比较难解决的一个技术问题，如何精准实时的获得好友、群友的在线状态，是今天将要探讨的话题。

[- 4 -]IM群聊消息如此复杂，如何保证不丢不重？

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

[摘要] 由于“消息风暴扩散系数”的存在（概念详见《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》），群消息的复杂度要远高于一对一的单聊消息。群消息的实时性、可达性、离线消息是今天将要讨论的核心话题。

[- 5 -] 微信后台团队：微信后台异步消息队列的优化升级实践分享

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

[摘要] 本文分享了该组件2.0版本的功能特点及优化实践，希望能为类似业务（比如移动端IM系统等）的消息队列设计提供一定的参考。

[- 6 -] 移动端IM中大规模群消息的推送如何保证效率、实时性？

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

[摘要] 当然，实际在生产环境下，群消息的发送都会想尽办法进行压缩，并开展各种改善性能的处理办法，而不是像上述举例里的直接扩散写（即2000人群里，一条消息被简单地复制为2000条一对一的消息投递）。具体有哪些优先策略？本文或许可以带给你一些启发。

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

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

[摘要] 本文内容主要涉及IM系统中的消息系统架构，探讨一种适用于大用户量的消息同步以及存储系统的架构实现，能够支持消息系统中的高级特性『多端同步』以及『消息漫游』。在性能和规模上，能够做到全量消息云端存储，百万TPS以及毫秒级延迟的消息同步能力。

[- 8 -] 关于IM即时通讯群聊消息的乱序问题讨论

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

[摘要] 问题描述：客户端A、B、C，服务端S，例如：A发三条群消息，B、C收到的消息都是乱序，目前问题：A发第一条消息失败之后排到队列，这时服务端还在持续发消息，那么第二条消息送达到B、C，然后客户端最先显示的就不是第一条消息，导致乱序出现。

[- 9 -]  IM群聊消息的已读回执功能该怎么实现？

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

[摘要] 那么群聊消息的收发流程、消息的送达保证、已读回执机制，到底该怎么实现呢？这就是今天要讨论的话题。

[- 10 -] IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？

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

[摘要] 任何技术方案，都不是天才般灵感乍现想到的，一定是一个演进迭代，逐步优化的过程。今天就聊一聊，IM群聊消息，为啥只需要存一份。

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

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

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

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

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

[摘要] 听到这个问题，全厂的人都炸了。要知道一个微信群最多只能有500人啊，QQ群也只有2000而已。当你有机会加入一个2000人QQ群的时候，你就已经感受到“信息爆炸”的可怕……

[- 13 -] IM群聊机制，除了循环去发消息还有什么方式？如何优化？

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

[摘要] 目前我是用循环来获取群成员，然后获取群成员ID去循环调用senddata()方法，想不用循环或者用其他什么方式来优化群聊循环发送这个机制，各位大佬有什么办法没？

[- 14 -] 网易云信技术分享：IM中的万人群聊技术方案实践总结

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

[摘要] 本文内容是网易云信团队为了响应万人群聊功能需求，在设计实现万人群聊技术方案中总结的技术实践，借此机会分享给各IM开发者同行。

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

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

[摘要] 本文适合有一定IM后端架构设计经验的开发者阅读，或许出于商业产品技术秘密的考虑，分享者在本次所分享的内容上有所保留，鉴于阿里对于钉钉在技术上的内容分享做的非常少，所以本文虽然内容不够全面，但仍然值得一读。

👉52im社区本周新文：《抖音技术分享：飞鸽IM桌面端基于Rust语言进行重构的技术选型和实践总结》，欢迎阅读！👈

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

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

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

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

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

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

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

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

[- 3 -] 阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践

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

[摘要] 本篇将要分享的是闲鱼IM系统中在线和离线聊天消息数据的同步机制上所遇到的一些问题，以及实践性的解决方案。

[- 4 -] 探探的IM长连接技术实践：技术选型、架构设计、性能优化

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

[摘要] 本文将要分享的是陌生人社交应用探探的IM长连接模块从技术选型到架构设计，再到性能优化的整个技术实践过程和经验总结。

[- 5 -] IM开发干货分享：浅谈IM系统中离线消息、历史消息的最佳实践

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

[摘要] 本文将基于IM消息系统的技术实践，分享关于离线消息和历史消息的正确理解，以及具体的技术配合和实践，希望能为你的离线消息和历史消息技术设计带来最佳实践灵感。

[- 6 -] IM开发干货分享：IM客户端不同版本兼容运行的技术思路和实践总结

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

[摘要] 本文将基于笔者的IM产品开发和运营实践，为你分享如何实现不同APP客户端版本与服务端通信的兼容性处理方案。

[- 7 -] 字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8

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

[摘要] 字符编码是计算机技术的基石，对于程序员来说尤其重要，字符编码的知识是必须要懂的。

[- 8 -] IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质

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

[摘要] 对于乱码这个看似不起眼，但并不是一两话能讲清楚的问题，是很有必要从根源了解字符集和编码原理，知其然知其所以然显然是一个优秀码农的基本素养，所以，便有了本文，希望能帮助到你。

[- 9 -]  史诗级计算机字符编码知识分享，万字长文，一文即懂！

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

[摘要] 前一阵跟同事碰到了字符乱码的问题，了解后发现这个问题存在两年了，我们程序员每天都在跟编码打交道，但大家对字符编码都是一知半解：“天天吃猪肉却很少见过猪跑”，今天我就把它彻底讲透！

[- 10 -] 百度统一socket长连接组件从0到1的技术实践

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

[摘要] 本文旨在探讨socket长连接技术在移动端的实践，并以iOS端为例，重点分享了百度在实现统一socket长连接组件过程中的技术选型和整体架构设计逻辑。并结合IM即时通讯聊天应用案例，展示长连接组件是如何在移动应用领域为类似业务场景提供解决方案的。

[- 11 -] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

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

[摘要] 本文将介绍淘宝 APP 统一网络库演进的过程，讲述如何围绕体验持续构建南北向从监测到加速一体化的终端网络架构，通过构建 NPM 弱网诊断感知能力，落地原生多通道技术/多协议择优调度手段，贴合厂商附能网络请求加速，实现去 SPDY 及规模化 IPv6/H3 协议簇的平滑过渡，为用户提供弱网更好、好网更优的 APP 加载浏览体验，支撑业务创造更多的可能性。

[- 12 -] 揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链

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

[摘要] 本文将摘取企业微信的其中一个技术分支——IM体系之下的“关系链”内核要素，为你揭秘企业微信是如何支持超大规模IM组织架构的。

👉52im社区本周新文：《长连接网关技术专题(九)：去哪儿网酒店高性能业务网关技术实践》，欢迎阅读！👈

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

本文由去哪儿网技术团队田文琦分享，本文有修订和改动。

1、引言

本文针对去哪儿网酒店业务网关的吞吐率下降、响应时间上升等问题，进行全流程异步化、服务编排方案等措施，进行了高性能网关的技术优化实践。

技术交流：

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

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

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

2、作者介绍

田文琦：2021年9月加入去哪儿网机票目的地事业群，担任软件研发工程师，现负责国内酒店主站技术团队。主要关注高并发、高性能、高可用相关技术和系统架构。主导的酒店业务网关优化项目，荣获22年去哪儿网技术中心TC项目三等奖。

3、专题目录

本文是专题系列文章的第9篇，总目录如下：

1. 《长连接网关技术专题(一)：京东京麦的生产级TCP网关技术实践总结》
2. 《长连接网关技术专题(二)：知乎千万级并发的高性能长连接网关技术实践》
3. 《长连接网关技术专题(三)：手淘亿级移动端接入层网关的技术演进之路》
4. 《长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践》
5. 《长连接网关技术专题(五)：喜马拉雅自研亿级API网关技术实践》
6. 《长连接网关技术专题(六)：石墨文档单机50万WebSocket长连接架构实践》
7. 《长连接网关技术专题(七)：小米小爱单机120万长连接接入层的架构演进》
8. 《长连接网关技术专题(八)：B站基于微服务的API网关从0到1的演进之路》
9. 《长连接网关技术专题(九)：去哪儿网酒店高性能业务网关技术实践》（* 本文）

4、技术背景

近来，Qunar 酒店的整体技术架构在基于 DDD 指导思想下，一直在进行调整。其中最主要的一个调整就是包含核心领域的团队交出各自的“应用层”，统一交给下游网关团队，组成统一的应用层。

这种由多个网关合并成大前台(酒店业务网关)的融合，带来的好处是核心系统边界清晰了，但是对酒店业务网关来说，也带来了不小的困扰。

系统面临的压力主要来自两方面：

• 1）首先，一次性新增了几十万行大量硬编码、临时兼容、聚合业务规则的复杂代码且代码风格迥异，有些甚至是跨语言的代码迁移；
• 2）其次，后续的复杂多变的应用层业务需求，之前分散在各个子网关中，现在在源源不断地汇总叠加到酒店业务网关。

这就导致了一系列的问题：

• 1）业务网关吞吐性能变差：应对流量尖峰时期的单机最大吞吐量与合并之前相比，下降了20%
• 2）内部业务逻辑处理速度变差：主流程业务逻辑的处理时间与合并之前相比，上涨了10%。
• 3）代码难以维护、开发效率低：主站内部各个模块之间严重耦合，边界不清，修改扩散问题非常明显，给后续的迭代增加了维护成本，开发新需求的效率也不高。

酒店业务网关作为直接面对用户的系统，出现任何问题都会被放大百倍，上述这些问题亟待解决。

5、吞吐量下降问题分析

现有系统虽然业务处理部分是异步化的，但是并不是全链路异步化（如下图所示）。

同步 servlet 容器，servlet 线程与业务逻辑线程是同一个，高峰期流量上涨或者尤其是遇到流量尖峰的时候，servlet 容器线程被阻塞的时候，我们服务的吞吐量就会明显下降。

业务处理虽然使用了线程池确实能实现异步调用的效果，也能压缩同步等待的时间，但是也有一些缺陷。

比如：

• 1）CPU 资源大量浪费在阻塞等待上，导致 CPU 资源利用率低；
• 2）为了增加并发度，会引入更多额外的线程池，随着 CPU 调度线程数的增加，会导致更严重的资源争用，上下文切换占用 CPU 资源；
• 3）线程池中的线程都是阻塞的，硬件资源无法充分利用，系统吞吐量容易达到瓶颈。

6、响应时间上涨问题分析

前期为了快速落地酒店 DDD 架构，合并大前台的重构中，并没有做到一步到位的设计。

为了保证项目质量，将整个过程切分为了迁移+重构两个步骤。迁移之后，整个酒店业务网关的内部代码结构是割裂、混乱的。

总结如下：

我们最核心的一个接口会调用70多个上游接口，上述问题：边界不清、不内聚、各种重复调用、依赖阻塞等问题导致了核心接口的响应时间有明显上涨。

7、 解决方案Part1：全流程异步化提升吞吐量

全流程异步化方案，我们主要采用的是 Spring WebFlux。

7.1选择的理由

1）响应式编程模型：Spring WebFlux 基于响应式编程模型，使用异步非阻塞式 I/O，可以更高效地处理并发请求，提高应用程序的吞吐量和响应速度。同时，响应式编程模型能够更好地处理高负载情况下的请求，降低系统的资源消耗。

2）高性能：Spring WebFlux 使用 Reactor 库实现响应式编程模型，可以处理大量的并发请求，具有出色的性能表现。与传统的 Spring MVC 框架相比，Spring WebFlux 可以更好地利用多核 CPU 和内存资源，以实现更高的性能和吞吐量。

3）可扩展性：Spring WebFlux 不仅可以使用 Tomcat、Jetty 等常规 Web 服务器，还可以使用 Netty 或 Undertow 等基于 NIO 的 Web 服务器实现，与其它非阻塞式 I/O 的框架结合使用，可以更容易地构建可扩展的应用程序。

4）支持函数式编程：Spring WebFlux 支持函数式编程，使用函数式编程可以更好地处理复杂的业务逻辑，并提高代码的可读性和可维护性。

5）50与 Spring 生态系统无缝集成：Spring WebFlux 可以与 Spring Boot、Spring Security、Spring Data 等 Spring 生态系统的组件无缝集成，提供了完整的 Web 应用程序开发体验。

7.2实现原理和异步化过程

上图中从下到上每个组件的作用：

• 1）Web Server：适配各种 Web 服务， 监听客户端请求，并将其转发到 HttpHandler 处理；
• 2）HttpHandler：以非阻塞的方式处理响应式 http 请求的最底层处理器，不同的处理器处理的请求都会归一到 httpHandler 来处理，并返回响应；
• 3）DispatcherHandler：调度程序处理程序用于异步处理 HTTP 请求和响应，封装了HandlerMapping、HandlerAdapter、HandlerResultHandler 的调用，实际实现了HttpHandler的处理逻辑；
• 4）HandlerMapping：根据路由处理函数 (RouterFunction) 将 http 请求路由到相应的handler。WebFlux 中可以有多个 handler，每个 handler 都有自己的路由；
• 5）HandlerAdapter：使用给定的 handler 处理 http 请求，必要时还包括使用异常处理handler 处理异常；
• 6）HandlerResultHandler：处理返回结果，将 response 写到输出流中；
• 7）Reactive Streams：Reactive Streams 是一个规范，用于处理异步数据流。Spring WebFlux 实现了 Reactor 库，该库基于响应式流规范，处理异步数据流。

在整个过程中 Spring WebFlux 实现了响应式编程模型，构建了高吞吐量、高并发的 Web 应用程序，同时也具有响应快速、可扩展性好、资源利用率高等优点。

下面我们来看下 webFlux 是如何将 Servlet 请求异步化的：

1）ServletHttpHandlerAdapter 展示了使用 Servlet 异步支持和 Servlet 3.1非阻塞I/O，将 HttpHandler 适配为 HttpServlet。

2）第10行：request.startAsync()开启异步模式，然后将原始 request 和 response 封装成 ServletServerHttpRequest 和 ServletServerHttpResponse。

3）第36行：httpHandler.handle(httpRequest, httpResponse) 返回一个 Mono 对象(即Publisher)，对 Request 和 Response 的所有具体处理都在 Mono 对象中定义。

所有的操作只有在 subscribe 订阅的那一刻才开始进行，HandlerResultSubscriber 是 Reactive Streams 规范中标准的 subscriber，在它的 onComplete 事件触发时，会结束 servlet 的异步模式。

对 Servlet 返回结果的异步写入，以 DispatcherHandler 为例说明：

1）第2行：exchange 是对 ServletServerHttpRequest 和 ServletServerHttpResponse 的封装。

2）第10-15行：在系统预加载的 handlerMappings 中根据 exchange 找到对应的 handler，然后利用 handler 处理 exchange 执行相关业务逻辑，最终结果由 result 将 ServletServerHttpResponse 写入到输出流中。

最后：除了 Servlet 的异步化，作为业务网关，要实现全链路异步化还需要在远程调用方面要支持异步化。在 RPC 调用方式下，我们采用的异步 Dubbo，在 HTTP 调用方式下，我们采用的是 WebClient。

WebClient 默认使用的是 Netty 的 IO 线程进行发送请求，调用线程通过订阅一些事件例如：doOnRequest、doOnResponse 等进行回调处理。异步化的客户端，避免了业务线程池的阻塞，提高了系统的吞吐量。

在使用 WebClient 这种异步 http 客户端的时候，我们也遇到了一些问题：

1）首先：为了避免默认的 NettyIO 线程池可能会执行比较耗时的 IO 操作导致 Channel 阻塞，建议替换成其他线程池，替换方法是 Mono.publishOn(reactor.core.scheduler.Schedulers.newParallel("biz_scheduler", 300))。

2）其次：因为线程发生了切换，无法兼容 Qtracer (Qunar内部的分布式全链路跟踪系统)，所以在初始化 WebClient 客户端的时候，需要在 filter 里插入对 Request 的修改，记录前一个线程保存的 Qtracer 的上下文。WebClient.Builder wcb = WebClient.builder().filter(new QTraceRequestFilter())。

8、解决方案Part2：服务编排降低响应时间

Spring WebFlux 并不是银弹，它并不能保证一定能降低接口响应时间，除了全流程异步化，我们还利用 Spring WebFlux 提供的响应式编程模型，对业务流程进行服务编排，降低依赖之间的阻塞。

8.1服务编排解决方案

在介绍服务编排之前，我们先来了解一下 Spring WebFlux 提供的响应式编程模型 Reactor。

它有最重要的两个响应式类 Flux 和 Mono：

• 1）一个 Flux 对象表明一个包含0..N 个元素的响应式序列；
• 2）一个 Mono 对象表明一个包含零或者一个（0..1）元素的结果。

不管是 Flux 还是 Mono，它的处理过程分三步：

• 1）首先声明整个执行过程(operator)；
• 2）然后连通主过程，触发执行；
• 3）最后执行主过程，触发并执行子过程、生成结果。

每个执行过程连通输入流和输出流，子过程之间可以是并行的，也可以是串行的这个取决于实际的业务逻辑。我们的服务编排就是完成输入和输出流的编排，即在第一步声明执行过程（包括子过程），第二步和第三步完全交给 Reactor。

下面是我们服务编排的总体设计：

如上图所示：

1）service：是最小的业务编排单元，对 invoker 和 handler 进行了封装，并将结果写回到上下文中。主流程中，一般是由多个 service 进行并行/串行地编排。

2）Invoker：是对第三方的异步非阻塞调用，对返回结果作 format，不包含业务逻辑。相当于子过程，一个 service 内部根据实际业务场景可以编排0个或多个 Invoker。

3）handler：纯内存计算，封装共用和内聚的业务逻辑。在实际的业务开发过程中，对上下文中的任一变量，只有一个 handler 有写权限，避免了修改扩散问题。也相当于子过程，根据实际需要编排进 service 中。

4）上下文：为每个接口都设计了独立的请求/处理/响应上下文，方便监控定位每个模块的处理正确性。

上下文设计举例：

在复杂的 service 中我们会根据实际业务需求组装 invoker 和 handler，例如：日历房售卖信息展示 service 组装了酒店报价、辅营权益等第三方调用 invoker，优惠明细计算、过滤报价规则等共用的逻辑处理 handler。

在实际优化过程中我们抽象了100多个 service，180多个 invoker，120多个 handler。他们都是小而独立的类，一般都不会超过200行，减轻了开发同学尤其是新同学对代码的认知负担。边界清晰，逻辑内聚，代码的不可知问题也得到了解决。

每个 service 都是由一个或多个 Invoker、handler 组装编排的业务单元，内部处理都是全异步并行处理的。

如下图所示：ListPreAsyncReqService 中编排了多个 invoker，在基类 MonoGroupInvokeService 中，会通过 Mono.zip(list, s -> this.getClass() + " succ")将多个流合并成为一个流输出。

在 controller 层就负责处理一件事，即对 service 进行编排（如下图所示）。

我们利用 flatMap 方法可以方便地将多个 service 按照业务逻辑要求，进行多次地并行/串行编排。

1）并行编排示例：第12、14行是两个并行处理的输入流 afterAdapterValidMono、preRankSecMono ，二者并行执行各自 service 的处理。

2）并行处理后的流合并：第16行，搜索结果流 rankMono 和不依赖搜索的其他结果流preRankAsyncMono，使用 Mono.zip 操作将两者合并为一个输出流 afterRankMergeMono。

3）串行编排举例：第16、20、22行，afterRankMergeMono 结果流作为输入流执行 service14 后转换成 resultAdaptMono，又串行执行 service15 后，输出流 cacheResolveMono。

以上是酒店业务网关的整体服务编排设计。

8.2编排示例

下面来介绍一下，我们是如何进行流程编排，发挥网关优势，在系统内和系统间达到响应时间全局最优的。

8.2.1）系统内：

上图示例中的左侧方案总耗时是300ms。

这300ms 来自最长路径 Service1的200ms 加上 Service3 的100ms：

• 1）Service1 包含2个并行 invoker 分别耗时100ms、200ms，最长路径200ms；
• 2）Service3 包含2个并行invoker 分别耗时50ms、100ms，最长路径100ms。

而右图是将 Service1 的200ms 的 invoker 迁移至与 Service1 并行的 Service0 里。

此时，整个处理的最长路径就变成了200ms：

• 1）Service0 的最长路径是200ms；
• 2）Service1+service3 的最长路径是100ms+100ms=200ms。

通过系统内 invoker 的最优编排，整体接口的响应时间就会从300ms 降低到200ms。

8.2.2）系统间：

举例来说：优化前业务网关会并行调用 UGC 点评（接口耗时100ms）和 HCS 住客秀（接口耗时50ms）两个接口，在 UGC 点评系统内部还会串行重复调用 HCS 住客秀接口（接口耗时50ms）。

发挥业务网关优势，UGC 无需再串行调用 HCS 接口，所需业务聚合处理（这里的业务聚合处理是纯内存操作，耗时可以忽略）移至业务网关中操作，这样 UGC 接口的耗时就会降下来。对全局来说，整体接口的耗时就会从原来的100ms 降为50ms。

还有一种情况：假设业务网关是串行调用 UGC 点评接口和 HCS 住客秀接口的话，那么也可以在业务网关调用 HCS 住客秀接口后，将结果通过入参在调用 UGC 点评接口的时候传递过去，也可以省去 UGC 点评调用 HCS 住客秀接口的耗时。

基于对整个酒店主流程业务调用链路充分且清晰的了解基础之上，我们才能找到系统间的最优解决方案。

9、优化后的效果

9.1页面打开速度明显加快

优化后最直接的效果就是在用户体感上，页面的打开速度明显加快了。

以详情页为例：

9.2接口响应时间下降50%

列表、详情、订单等主流程各个核心接口的P50响应时间都有明显的降幅，平均下降了50%。

以详情页的 A、B 两个接口为例，A接口在优化前的 P50 为366ms：

A 接口优化后的 P50 为36ms：

B 接口的 P50 响应时间，从660ms 降到了410ms：

9.3单机吞吐量性能上限提升100%，资源成本下降一半

单机可支持 QPS 上限从100提升至200，吞吐量性能上限提升100%，平稳应对七节两月等常规流量高峰。

在考试、演出、临时政策变化、竞对故障等异常突发事件情况下，会产生瞬时的流量尖峰。在某次实战的情况下，瞬时流量高峰达到过二十万 QPS 以上，酒店业务网关系统经受住了考验，能够轻松应对。

单机性能的提升，我们的机器资源成本也下降了一半。

9.4圈复杂度降低38%，研发效率提升30%

具体就是：

• 1）优化后酒店业务网关的有效代码行数减少了6万行；
• 2）代码圈复杂度从19518减少至12084，降低了38%；
• 3）网关优化后，业务模块更加内聚、边界清晰，日常需求的开发、联调时间均有明显减少，研发效率也提升了30%。

10、本文小结与下一步规划

1）通过采用 Spring WebFlux 架构和系统内/系统间的服务编排，本次酒店业务网关的优化取得了不错的效果，单机吞吐量提升了100%，整体接口的响应时间下降了50%，为同类型业务网关提供一套行之有效的优化方案。

2）在此基础上，为了保持优化后的效果，我们除了建立监控日常做好预警外，还开发了接口响应时长变化的归因工具，自动分析变化的原因，可以高效排查问题作好持续优化。

3）当前我们在服务编排的时候，只能根据上游接口在稳定期的响应时间，来做到最优编排。当某些上游接口响应时间存在波动较大的情况时，目前的编排功能还无法做到动态自动最优，这部分是我们未来需要优化的方向。

11、相关文章