Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 473, comments - 13, trackbacks - 0, articles - 1

导航

公告


    ① 即时通讯开发社区
    地址: 52im.net
    专业的资料、社区

    ② 关注我的公众号:

    让技术不再封闭

    ③ 我的Github
    地址: 点此进入
    好代码,与大家分享
<2023年5月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

常用链接

留言簿(272)

随笔档案

文章档案

搜索

  •  

最新评论

阅读排行榜

评论排行榜

60天内阅读排行

2023年5月18日

相关链接:

一、理论知识准备

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

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

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

鸿蒙Next的WebSocket文档和手册:

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

二、开发工具准备

1)DevEco-Studio:

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

2)一站式下载地址:鸿蒙官网下载地址 点此进入。(需要注册成为开发者才能下载哟!

3)DevEco-Studio效果预览:

三、SDK 文件用途说明

3.1文件概览

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

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

大致的目录说明:

3.2详细说明

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

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

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

1)ClientCoreSDK.getInstance().loginHasInit:

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

2)ClientCoreSDK.getInstance().connectedToServer:

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

3)ClientCoreSDK.getInstance().currentLoginInfo:

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

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

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

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

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

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

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

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

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

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

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

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

10)SocketEvent.SOCKET_EVENT_ON_RECIEVE_MESSAGE事件通知:

11)SocketEvent.SOCKET_EVENT_ON_LOGIN_RESPONSE事件通知:

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

12)SocketEvent.SOCKET_EVENT_ON_LINK_CLOSE事件通知:

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

13)SocketEvent.SOCKET_EVENT_PING事件通知:

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

14)SocketEvent.SOCKET_EVENT_PONG事件通知:

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

15)SocketEvent.SOCKET_EVENT_KICKOUT事件通知:

16)SocketEvent.SOCKET_EVENT_ON_ERROR_RESPONSE事件通知:

17)SocketEvent.SOCKET_EVENT_RECONNECT_ATTEMPT事件通知:

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

18)SocketEvent.SOCKET_EVENT_MESSAGE_LOST事件通知:

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

19)SocketEvent.SOCKET_EVENT_MESSAGE_BE_RECIEVED事件通知:

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

五、如何引入SDK库文件

5.1方法一:源码形式

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

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

 

5.2方法二:.har包形式

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

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

六、如何调用SDK代码

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

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

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

6.2第二步:初始化SDK

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

6.3第三步:注册框架事件

注册MobileIMSDK框架级的事件监听(示例详见Demo中的 IMClientManager.ets 文件):

6.4第四步:调用登录方法(框架内部会自动启动connect全过程)

调用登录方法(示例详见Demo中的 LoginPage.ets 文件):

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

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

八、Demo运行方法

8.1重要说明

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

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

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

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

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

8.3启动模拟器

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

 

▲ 点击绿色箭头,立即启动模拟器!

8.4一键运行

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

8.5运行效果

1)Demo的登陆界面运行截图:

2)Demo的主界面运行截图:

3)Demo运行的同时,可以查看详细的log输出(方便调试):

九、引用资料

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

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

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

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

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

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

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

posted @ 2024-12-30 12:08 Jack Jiang 阅读(25) | 评论 (0)编辑 收藏

一、基本介绍

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

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

二、与MobileIMSDK的关系

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

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

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

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

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

三、设计目标

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

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

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

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

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

四、技术亮点

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

五、文件组成

完整工程文件概览:

 

SDK代码文件用途说明:

精编注释级的源码:

六、Demo功能说明

点击可看大图 ▲

七、实际运行效果

1)Demo 的登陆界面运行截图(点击可看大图 ▼

2)Demo 的主界面运行截图(点击可看大图 ▼):

3)Demo 运行的同时,可以查看详细的 log 输出(方便调试

八、详尽开发者手册

① 开发者手册网页版):点此进入 

② 开发者手册PDF精编版):点此进入 * 推荐

九、相关资料

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

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

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

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

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

posted @ 2024-12-23 11:31 Jack Jiang 阅读(36) | 评论 (0)编辑 收藏

     摘要: 本文由小白debug分享,原题“能 ping 通,TCP 就一定能连通吗?”,下文进行了排版和内容优化。1、引言平时,我们想要知道,自己的机器到目的机器之间,网络通不通,一般会执行ping命令。一般对于状况良好的网络来说,你能看到它对应的loss丢包率为0%,也就是所谓的能ping通。如果看到丢包率100%,也就是ping不通。▲ ping正常▲ p...  阅读全文

posted @ 2024-12-19 11:29 Jack Jiang 阅读(43) | 评论 (0)编辑 收藏

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

1、引言

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

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

 
 

2、系列文章

本文是系列文章中的第16篇,本系列文章的大纲如下:

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

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

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

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

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

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

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

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

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

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

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

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

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

网络编程懒人入门(十四):到底什么是Socket?一文即懂!

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

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

3、Wireshak的安装和基本使用

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

使用:

如上图所示:

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

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

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

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

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

4、快速理解Wireshak的过滤器

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

4.1捕获过滤器

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

需要在开始捕获之前设置,相对简单:

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

例如:

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

4.2显示过滤器

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

功能更加强大和复杂:

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

例如:

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

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

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

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

6、什么是HTTPS

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

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

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

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

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

7、HTTPS的SSL/TLS握手过程

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

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

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

1)C:ClientHello

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

2)S:ServerHello

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

3)S:Certificate

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

4)S:ServerKey Exchange

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

5)S:ServerHello Done

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

6)C:ClientKey Exchange

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

7)C:ChangeCipher Spec

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

8)C:Finished

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

9)S:Change Cipher Spec

10)S:Finished

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

8、解密HTTPS报文

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

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

如下:

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

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

9、参考资料

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

posted @ 2024-12-12 11:24 Jack Jiang 阅读(62) | 评论 (0)编辑 收藏

     摘要: 本文由转转技术团队刘筱雨分享,原题“一文读懂浏览器本地存储:Web Storage”,下文进行了排版和内容优化。1、引言鉴于目前浏览器技术的进步(主要是HTML5的普及),在Web网页端IM聊天应用的技术选型阶段,很多开发者都会纠结到底该不该像原生移动端IM那样将聊天记录缓存在浏览器的本地,还是像传统Web端即时通讯那样继续存储在服务端?本文将为你简洁明了地讲清楚浏览器本地...  阅读全文

posted @ 2024-11-28 11:00 Jack Jiang 阅读(73) | 评论 (0)编辑 收藏

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

[-1-]  微信朋友圈千亿访问量背后的技术挑战和实践总结

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

[摘要] 朋友圈的数据是永远存储的,而且随着业务的快速发展,存储容量、带宽和设备的消耗大量增加,尤其重大节日带来的使用量增长,更加剧了消耗,也给运维人员的保障带来了巨大压力。


[-2-] 腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)

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

[摘要] 本次文章跟大家分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。


[-3-] 腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

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

[摘要] 本文接上篇《腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》,继续腾讯公司分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。


[-4-] IM全文检索技术专题(二):微信移动端的全文检索多音字问题解决方案

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

[摘要] 本文重点讲述微信安卓客户端在SQLite FTS5的基础上,多音字问题的解决方案。


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

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

[摘要] 对于Android应用来说,内存向来是比较重要的性能指标。内存占用过高,会影响应用的流畅度,甚至引发OOM,非常影响用户体验。因此,内存优化也向来是行业内的重点工作项和难点工作项。


[--] 微信团队分享:iOS版微信的高性能通用key-value组件技术实践

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

[摘要] 本文要分享的是iOS版微信内部正在推广和使用的一个高性能通用key-value 组件的技术实践过程,该组件在微信内部被命名为MMKV(以下简称MMKV)。


[-7-] 微信团队分享:iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的?

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

[摘要] 一般来说,特殊字符闪退是系统漏洞引起,只要更新系统就行。但大部分用户不愿意更新系统,而苹果也不一定第一时间解决问题。另外后台可以拦截恶意文本传递,但对于本地已下发的消息,后台没有办法让它删除。所以客户端还是要做些保护预防特殊字符闪退。


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

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

[摘要] 本文将详细介绍Android版手Q中这套线程卡死监控系统设计思路以及技术实践总结。


[-9 -]  微信团队原创分享:iOS版微信的内存监控系统技术实践

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

[摘要] 二期版本以Instruments的Allocations为参考,着重四个方面优化,分别是数据收集、存储、上报及展现。


[-10-] 让互联网更快:新一代QUIC协议在腾讯的技术实践分享

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

[摘要] 本文主要介绍 QUIC 协议在腾讯内部及腾讯云上的实践和性能优化,新一代的互联网协议需要大家一起努力推动,你准备好了吗?


[-11 -] iOS后台唤醒实战:微信收款到账语音提醒技术总结

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

[摘要] 本文借此总结了iOS平台上的APP后台唤醒和语音合成、播放等一系列技术开发过程中遇到的坑和小技巧,希望与您分享。


[-12 -] 腾讯技术分享:社交网络图片的带宽压缩技术演进之路

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

[摘要] 为了进一步降低运营带宽成本,减小用户访问流量及提升页面加载速度,社交网络 CDN运维紧跟行业图片优化趋势,创新引入WebP、SharpP、自适应分辨率、Guetzli等图像压缩技术到现网,经过三年多的多部门联合攻关,已逐渐形成一套覆盖全图片类型(JPEG、JPG、PNG、WebP、GIF)多场景的图片压缩运营体系,适用于各类型终端,每年节约外网带宽几百G。


[-13 -] 微信团队分享:视频图像的超分辨率技术原理和应用场景

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

[摘要] 本文试着讲述超分辨率技术的正确打开方式,浅谈视频图像的超分辨率技术的基本概念和应用场景等问题。


[-14 -] 微信团队分享:微信每日亿次实时音视频聊天背后的技术解密

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

[摘要] 本文将为大家介绍微信实时音视频聊天在不同发展阶段的各个关键视频技术环节采用的方案,同时分享在实时音视频聊天中的视频编码器研发的方法和经验。


👉52im社区本周新文:《Web端IM聊天消息该不该用浏览器本地存储?一文即懂!》,欢迎阅读!👈

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

posted @ 2024-11-27 11:06 Jack Jiang 阅读(63) | 评论 (0)编辑 收藏

     摘要: 本文由得物技术WWQ分享,原题“基于IM场景下的Wasm初探:提升Web应用性能”,下文进行了排版和内容优化。1、什么是WasmWasm,全称 WebAssembly,官网描述是一种用于基于堆栈的虚拟机的二进制指令格式。Wasm被设计为一个可移植的目标,用于编译C/C++/Rust等高级语言,支持在Web上部署客户端和服务器应用程序。简单的来说,Wasm就是使用C...  阅读全文

posted @ 2024-11-21 12:56 Jack Jiang 阅读(73) | 评论 (0)编辑 收藏

为了更好地分类阅读 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/

posted @ 2024-11-20 11:34 Jack Jiang 阅读(80) | 评论 (0)编辑 收藏

     摘要: 本文由携程技术团队Aaron分享,原题“干货 | 携程弱网识别技术探索”,下文进行了排版和内容优化。1、引言网络优化一直是移动互联网时代的热议话题,弱网识别作为移动端弱网优化的第一步,受到的关注和讨论也是最多的。本文从方案设计、代码开发到技术落地,详尽的分享了携程在移动端弱网识别方面的实践经验,如果你也有类似需求,这篇文章会是一个不错的实操指南。技术交流:- 移动端IM开发...  阅读全文

posted @ 2024-11-14 11:14 Jack Jiang 阅读(75) | 评论 (0)编辑 收藏

为了更好地分类阅读 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等做了全流程的优化,确保在限带宽、丢包、时延、抖动,无论单项还是复杂网络,都有非常不错的实际体验。


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

[链接] 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 实现问题所选择的解决方案。


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

[链接] 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/

posted @ 2024-11-13 11:58 Jack Jiang 阅读(72) | 评论 (0)编辑 收藏

     摘要: 本文由微信后台Astra项目团队分享,原题“Ray在微信AI计算中的大规模实践”,下文进行了排版和内容优化。1、引言微信存在大量AI计算的应用场景,主要分为三种:流量分发、产品运营和内容创作。流量分发场景中的 AI 计算主要用于搜索、广告、推荐场景的核心特征生产,产品运营相关的 AI 计算主要用于产品功能相关和内容运营相关(低质、优质、生态建设),由于大模型的兴起,AIGC...  阅读全文

posted @ 2024-11-07 11:07 Jack Jiang 阅读(85) | 评论 (0)编辑 收藏

     摘要: 本文来自微信团队工程师张文瑞的技术分享,由InfoQ编辑发布,下文有修订和改动。原文地址:infoq.cn/article/1-billion-bonus-from-the-clouds,感谢原作者的分享。一、引言与传统意义上的红包相比,手机端的红包似乎更符合现在年轻一代的习惯。这其中,以春节发红包最为流行。以微信为例,除夕全天微信用户红包总发送量可以达到百亿个,红包峰值收发量为比百万个/秒。本文...  阅读全文

posted @ 2024-11-06 11:52 Jack Jiang 阅读(69) | 评论 (0)编辑 收藏

     摘要: 本文由LearnLHC分享,原始出处:blog.csdn.net/LearnLHC/article/details/115268028,本文进行了排版和内容优化。1、引言熟悉网络编程的(尤其搞实时音视频聊天技术的)同学们都有个约定俗成的主观论调,一提起UDP和TCP,马上想到的是UDP没有TCP可靠,但UDP肯定比TCP高效。说到UDP比TCP高效,理由是什么呢?事实真是这样吗?跟着本文咱们一探究...  阅读全文

posted @ 2024-10-30 11:31 Jack Jiang 阅读(71) | 评论 (0)编辑 收藏

关于MobileIMSDK

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

工程开源地址是:

关于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)[优化] 优化了首页“消息”列表中同一好友和陌生人会话不能自动合并的问题。

部分功能运行截图(更多截图点此查看):

posted @ 2024-10-29 12:23 Jack Jiang 阅读(65) | 评论 (0)编辑 收藏

     摘要: 1、引言当你在浏览器输入 qq.com 按下回车键,到页面呈现在你面前,整个过程发生了什么?我以前思考过这个问题,从最前面的浏览器到最后的 db 都梳理的一遍,触发了一次技术顿悟,将很多散落的知识点贯通起来了。本文将抛弃千篇一律的计网知识理论,从现实的互联网技术实践角度,一步步为你分享一次网络请求背后的技术秘密。 技术交流:- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端I...  阅读全文

posted @ 2024-10-24 11:34 Jack Jiang 阅读(113) | 评论 (0)编辑 收藏

一、关于RainbowChat-Web

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

二、v7.2 版更新内容

此版更新内容更多历史更新日志):

  • 1)[bug] [前端]      - 解决了加载首页聊天记录时,存在极小概率出现消息重复的问题;
  • 2)[bug] [前端]      - 解决了Firefox浏览器中右键无法复制文本消息的问题;
  • 3)[bug] [服务端]   - 升级了MobileIMSDK-Web库,解决了服务端QoS机制C2S消息路径时去重逻辑未起效的问题;
  • 4)[优化] [前端]     - 解决了引用的名片消息不会显示默认头像的问题;
  • 5)[优化] [前端]     - 重构了相关的类名、文件名等;
  • 6)[优化] [服务端]  - 优化了离线消息处理效率(异步化、无锁队列、批量处理、事务合并);
  • 7)[优化] [服务端]  - 优化了聊天记录处理效率(异步化、无锁队列、批量处理、事务合并);
  • 8)[优化] [服务端]  - 优化了“接口1008-26-8”,使按时间戳加载的消息在客户端不发生重复;
  • 9)[优化] [服务端]  - 修改了离线消息、聊天记录异步定时器实现,使之运行更健壮;
  • 10)[重构] [服务端] - 重构了通用http服务端工程、MQ工程目录名等;

三、主要功能特性截图

主要功能特性截图(更多运行截图运行视频

posted @ 2024-10-21 14:20 Jack Jiang 阅读(45) | 评论 (0)编辑 收藏

     摘要: 本文由陆业聪分享,原题“一文掌握直播技术:实时音视频采集、编码、传输与播放”,本文进行了排版和内容优化。1、引言从游戏、教育、电商到娱乐,直播技术的应用场景无处不在。随着移动端的网速越来越快,直播技术的普及和发展将更加迅速。本文详细介绍了Android端直播技术的全貌,涵盖了从实时音视频采集、编码、传输到解码与播放的各个环节。文章还探讨了直播中音视频同步、编解码器选择、传输...  阅读全文

posted @ 2024-10-17 11:10 Jack Jiang 阅读(64) | 评论 (0)编辑 收藏

关于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编写。

工程开源地址:

v11.7 版更新内容

此版更新内容更多历史更新日志):

(1)Android端主要更新内容:

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

(2)服务端主要更新内容:

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

部分功能运行截图更多截图点此查看):

posted @ 2024-10-16 10:16 Jack Jiang 阅读(56) | 评论 (0)编辑 收藏

     摘要: 本文由百度技术团队分享,引用自百度Geek说,原题“百度Android IM SDK组件能力建设及应用”,本文进行了排版和内容优化。1、引言移动互联网时代,随着社交媒体、移动支付、线上购物等行业的快速发展,对即时通讯功能的需求不断增加。对于各APP而言,接入IM SDK(即时通讯软件开发工具包)能够大大降低开发成本、提高开发效率,快速构建自己的IM系统。本文主要介绍了百度公...  阅读全文

posted @ 2024-10-10 12:35 Jack Jiang 阅读(74) | 评论 (0)编辑 收藏

     摘要: 本文来自微信团队工程师张文瑞的技术分享,由“极客邦科技Geekbang”编辑发布,下文有修订和改动。一、开场白谢谢大家!我是来自腾讯WXG技术架构部的张文瑞,今天下午跟大家分享的主题是:微信团队是如何从0到1实现“有把握”的微信春晚摇一摇红包系统的。回忆一下春晚的活动,有什么样的活动形式呢?当时我们是直接复用客户端摇一摇入口,专门给春晚摇一摇定制了一...  阅读全文

posted @ 2024-10-10 10:18 Jack Jiang 阅读(133) | 评论 (0)编辑 收藏

     摘要: 1、前言在猴年新春的时候,腾讯当时推出了新春广告片(点击观看视频),作为《弹指间 心无间》的延续。片中通过春节期间发送QQ红包让家人打车回家团聚,让我们感受到了“最温暖的红包,给最爱的人”那种弹指间的感动。而就在这弹指一挥间,此次腾讯新春广告片距离2011年腾讯发布《弹指间 心无间》“亲情篇”已经好几年过去了。在这几年的时间里,腾讯QQ从音频、视频、...  阅读全文

posted @ 2024-09-29 12:18 Jack Jiang 阅读(90) | 评论 (0)编辑 收藏

本文由萤火架构分享,原题“localhost和127.0.0.1的区别是什么?”,原文链接“juejin.cn/post/7321049446443417638”,下文进行了排版和内容优化。

1、引言

继《你真的了解127.0.0.1和0.0.0.0的区别?》、《深入操作系统,彻底搞懂127.0.0.1本机网络通信》之后,这是整理收录的第3篇有关本机网络的网络编程基础文章。以下是正文内容。

今天在网上逛的时候看到一个问题,没想到大家讨论的很热烈,就是标题中这个:

前端同学本地调试的时候,应该没少和localhost打交道吧,只需要执行 npm run 就能在浏览器中打开你的页面窗口,地址栏显示的就是这个 http://localhost:xxx/index.html。

可能大家只是用,也没有去想过这个问题。联想到我之前合作过的一些开发同学对它们俩的区别也没什么概念,所以我觉得有必要普及下。

 
 

2、系列文章

本文是该系列文章中的第 4 篇:

网络编程入门如此简单(一):假如你来设计网络,会怎么做?

网络编程入门如此简单(二):假如你来设计TCP协议,会怎么做?

网络编程入门如此简单(三):什么是IPv6?漫画式图文,一篇即懂!

网络编程入门如此简单(四):一文搞懂localhost和127.0.0.1》(* 本文)

3、localhost是什么呢?

localhost是一个域名,和大家上网使用的域名没有什么本质区别,就是方便记忆。

只是这个localhost的有效范围只有本机,看名字也能知道:local就是本地的意思。

张三和李四都可以在各自的机器上使用localhost,但获取到的也是各自的页面内容,不会相互打架。

4、从域名到程序

要想真正的认清楚localhost,我们还得从用户是如何通过域名访问到程序说起。

以访问百度为例。

1)当我们在浏览器输入 baidu.com 之后,浏览器首先去DNS中查询 baidu.com 的IP地址。

为什么需要IP地址呢?打个比方,有个人要寄快递到你的公司,快递单上会填写:公司的通讯地址、公司名称、收件人等信息,实际运输时快递会根据通信地址进行层层转发,最终送到收件人的手中。网络通讯也是类似的,其中域名就像公司名称,IP地址就像通信地址,在网络的世界中只有通过IP地址才能找到对应的程序。(请详读《什么是公网IP和内网IP?NAT转换又是什么鬼?》)

DNS就像一个公司黄页,其中记录着每个域名对应的IP地址,当然也有一些域名可能没做登记,就找不到对应的IP地址,还有一些域名可能会对应多个IP地址,DNS会按照规则自动返回一个。我们购买了域名之后,一般域名服务商会提供一个域名解析的功能,就是把域名和对应的IP地址登记到DNS中。(请详读《理论联系实际,全方位深入理解DNS》)

这里的IP地址从哪里获取呢?每台上网的电脑都会有1个IP地址,但是个人电脑的IP地址一般是不行的,个人电脑的IP地址只适合内网定位,就像你公司内部的第几栋第几层,公司内部人明白,但是直接发给别人,别人是找不到你的。

如果你要对外部提供服务,比如百度这种,你就得有公网的IP地址,这个IP地址一般由网络服务运营商提供,比如你们公司使用联通上网,那就可以让联通给你分配一个公网IP地址,绑定到你们公司的网关服务器上,网关服务器就像电话总机,公司内部的所有网络通信都要通过它,然后再在网关上设置转发规则,将网络请求转发到提供网络服务的机器上。

2)有了IP地址之后,浏览器就会向这个IP地址发起请求,通过操作系统打包成IP请求包,然后发送到网络上。

网络传输有一套完整的路由协议,它会根据你提供的IP地址,经过路由器的层层转发,最终抵达绑定该IP的计算机。

3)计算机上可能部署了多个网络应用程序,这个请求应该发给哪个程序呢?

这里有一个端口的概念,每个网络应用程序启动的时候可以绑定一个或多个端口,不同的网络应用程序绑定的端口不能重复,再次绑定时会提示端口被占用。

通过在请求中指定端口,就可以将消息发送到正确的网络处理程序。但是我们访问百度的时候没有输入端口啊?这是因为默认不输入就使用80和443端口,http使用80,https使用443。我们在启动网络程序的时候一定要绑定一个端口的,当然有些框架会自动选择一个计算机上未使用的端口。

5、localhost和127.0.0.1的区别是什么?

有了前面的知识储备,我们就可以很轻松的搞懂这个问题了。

localhost是域名,上文已经说过了。

127.0.0.1 呢?是IP地址,当前机器的本地IP地址,且只能在本机使用,你的计算机不联网也可以用这个IP地址,就是为了方便开发测试网络程序的。

我们调试时启动的程序就是绑定到这个IP地址的。

这里简单说下,我们经常看到的IP地址一般都是类似 X.X.X.X 的格式,用"."分成四段。其实它是一个32位的二进制数,分成四段后,每一段是8位,然后每一段再转换为10进制的数进行显示。

那localhost是怎么解析到127.0.0.1的呢?经过DNS了吗?没有。每台计算机都可以使用localhost和127.0.0.1,这没办法让DNS来做解析。

那就让每台计算机自己解决了。每台计算机上都有一个host文件,其中写死了一些DNS解析规则,就包括 localhost 到 127.0.0.1 的解析规则,这是一个约定俗成的规则。

如果你不想用localhost,那也可以,随便起个名字,比如 wodehost,也解析到 127.0.0.1 就行了。

甚至你想使用 baidu.com 也完全可以,只是只能自己自嗨,对别人完全没有影响。

PS:以下两篇可以深入进行阅读:

  1. 你真的了解127.0.0.1和0.0.0.0的区别?
  2. 深入操作系统,彻底搞懂127.0.0.1本机网络通信

6、域名的等级划分

localhost不太像我们平常使用的域名,比如 www.juejin.cn 、baidu.com、csdn.net, 这里边的 www、cn、com、net都是什么意思?localhost为什么不需要?

域名其实是分等级的,按照等级可以划分为顶级域名、二级域名和三级域名...

1)顶级域名(TLD):

顶级域名是域名系统中最高级别的域名。它位于域名的最右边,通常由几个字母组成。顶级域名分为两种类型:通用顶级域名和国家顶级域名。常见的通用顶级域名包括表示工商企业的.com、表示网络提供商的.net、表示非盈利组织的.org等,而国家顶级域名则代表特定的国家或地区,如.cn代表中国、.uk代表英国等。

2)二级域名(SLD):

二级域名是在顶级域名之下的一级域名。它是由注册人自行选择和注册的,可以是个性化的、易于记忆的名称。例如,juejin.cn 就是二级域名。我们平常能够申请到的也是这种。目前来说申请 xxx.com、xxx.net、xxx.cn等等域名,其实大家不太关心其顶级域名com\net\cn代表的含义,看着简短好记是主要诉求。

3)三级域名(3LD):

三级域名是在二级域名之下的一级域名。它通常用于指向特定的服务器或子网。例如,在blog.example.com中,blog就是三级域名。www是最常见的三级域名,用于代表网站的主页或主站点,不过这只是某种流行习惯,目前很多网站都推荐直接使用二级域名访问了。

域名级别还可以进一步细分,大家可以看看企业微信开放平台这个域名:developer.work.weixin.qq.com,com代表商业,qq代表腾讯,weixin代表微信,work代表企业微信,developer代表开发者。这种逐层递进的方式有利于域名的分配管理。

按照上边的等级定义,我们可以说localhost是一个顶级域名,只不过它是保留的顶级域,其唯一目的是用于访问当前计算机。

7、多网站共用一个IP和端口

上边我们说不同的网络程序不能使用相同的端口,其实是有办法突破的。

以前个人博客比较火的时候,大家都喜欢买个虚拟主机,然后部署个开源的博客程序,抒发一下自己的感情。为了挣钱,虚拟主机的服务商会在一台计算机上分配N多个虚拟主机,大家使用各自的域名和默认的80端口进行访问,也都相安无事。这是怎么做到的呢?

如果你有使用Nginx、Apache或者IIS等Web服务器的相关经验,你可能会接触到主机头这个概念。主机头其实就是一个域名,通过设置主机头,我们的程序就可以共用1个网络端口。

首先在Nginx等Web程序中部署网站时,我们会进行一些配置,此时在主机头中写入网站要使用的域名。

然后Nginx等Web服务器启动的时候,会把80端口占为己有。

然后当某个网站的请求到达Nginx的80端口时,它会根据请求中携带的域名找到配置了对应主机头的网络程序。

然后再转发到这个网络程序,如果网络程序还没有启动,Nginx会把它拉起来。

8、私有IP地址

除了127.0.0.1,其实还有很多私有IP地址,比如常见的 192.168.x.x。

这些私有IP地址大部分都是为了在局域网内使用而预留的,因为给每台计算机都分配一个独立的IP不太够用,所以只要局域网内不冲突,大家就可劲的用吧。你公司可以用 192.168.1.1,我公司也可以用192.168.1.1。

但是如果你要访问我,就得通过公网IP进行转发。

大家常用的IPv4私有IP地址段分为三类:

  • 1)A类:从10.0.0.0至10.255.255.255;
  • 2)B类:从172.16.0.0至172.31.255.255;
  • 3)C类:从192.168.0.0至192.168.255.255。

这些私有IP地址仅供局域网内部使用,不能在公网上使用。

除了上述三个私有的IPv4地址段外,还有一些保留的IPv4地址段:

1)用于本地回环测试的127.0.0.0至127.255.255.255地址段,其中就包括题目中的127.0.0.1,如果你喜欢也可以给自己分配一个127.0.0.2的IP地址,效果和127.0.0.1一样。

2)用于局域网内部的169.254.0.0至169.254.255.255地址段,这个很少接触到,如果你的电脑连局域网都上不去,可能会看到这个IP地址,它是临时分配的一个局域网地址。

这些地址段也都不能在公网上使用。

近年来,还有一个现象,就是你家里或者公司里上网时,光猫或者路由器对外的IPv4地址也不是公网IP了,这时候获得的可能是一个类似 100.64.x.x 的地址,这是因为随着宽带的普及,运营商手里的公网IP也不够了,所以运营商又加了一层局域网,而100.64.0.0 这个网段是专门分给运营商做局域网用的。

如果你使用阿里云等公有云,一些云产品的IP地址也可能是这个,这是为了将客户的私有网段和公有云厂商的私有网段进行有效的区分。

其实还有一些不常见的专用IPv4地址段,完整的IP地址段定义可以看这里:www.iana.org/assignments

9、IPv6  

你可能也听说过IPv6,因为IPv4可分配的地址太少了,不够用,使用IPv6甚至可以为地球上的每一粒沙子分配一个IP。只是喊了很多年,大家还是喜欢用IPv4,这里边原因很多,这里就不多谈了。

IPv6地址类似于:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX。

它是128位的,用":"分成8段,每个X是一个16进制数(取值范围:0-F),IPv6地址空间相对于IPv4地址有了极大的扩充。比如:2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b 就是一个有效的IPv6地址。(请详读《什么是IPv6?漫画式图文,一篇即懂!》)

10、参考资料  

[1] 你真的了解127.0.0.1和0.0.0.0的区别?

[2] 深入操作系统,彻底搞懂127.0.0.1本机网络通信

[3] 什么是IPv6?漫画式图文,一篇即懂!

[4] 一文读懂什么是IPv6

[5] IPv6技术详解:基本概念、应用现状、技术实践(上篇)

[6] 什么是公网IP和内网IP?NAT转换又是什么鬼?

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

[8] 面视必备,史上最通俗计算机网络分层详解

[9] 通俗讲解,有了IP地址,为何还要用MAC地址?

[10] 理论联系实际,全方位深入理解DNS


(本文已同步发布于:http://www.52im.net/thread-4702-1-1.html

posted @ 2024-09-26 10:23 Jack Jiang 阅读(84) | 评论 (0)编辑 收藏

     摘要: 1、前言微信——腾讯战略级产品,创造移动互联网增速记录,10个月5000万手机用户,433天之内完成用户数从零到一亿的增长过程,千万级用户同时在线,摇一摇每天次数过亿...在技术架构上,微信是如何做到的?日前,在腾讯大讲堂在中山大学校园宣讲活动上,腾讯广研助理总经理、微信技术总监周颢在两小时的演讲中揭开了微信背后的秘密。周颢把微信的成功归结于腾讯式的“三位一体&...  阅读全文

posted @ 2024-09-25 11:17 Jack Jiang 阅读(135) | 评论 (0)编辑 收藏

► 相关链接:

一、技术准备

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

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

WebSocket标准文档、API手册:

二、开发工具准备

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从入门到精通,半小时就够!

posted @ 2024-09-19 13:14 Jack Jiang 阅读(70) | 评论 (0)编辑 收藏

一、基本介绍

MobileIMSDK的H5端是一套纯JS编写的基于标准WebSocket的即时通讯库:
  • 1)超轻量级、极少依赖;
  • 2)纯JS编写、高度提炼,简单易用;
  • 3)基于标准WebSocket协议,客户端兼容性好;
  • 4)支持运行于iOS、Android等移动端浏览器和各种PC端浏览器;
  • 5)能与 MobileIMSDKGithub托管链接)的各种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:new:(暂未开源);
  • 5)服务端基于Netty,性能卓越、易于扩展;
  • 6)可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等;
  • 7)可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。

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

三、与MobileIMSDK-Web的关系

MobileIMSDK-Web也是一套纯JS编写的Web端即时通讯框架(含服务端)。

MobileIMSDK-Web框架与MobileIMSDK-H5端的相同点:
  • 1)都是Web端即时通讯框架;
  • 2)都是纯JS编写;
  • 3)都可以运行在手机、pc端的浏览器或web容器内。
MobileIMSDK-Web框架与MobileIMSDK-H5端的不同点:
  • 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方依赖。

四、设计目标

直接使用原生的WebSocket有以下问题和劣势:
  • 1)功能有限:没有提供心跳保活、断线重连、送达保证(重传和去重)等即时通讯关键算法和逻辑;
  • 2)API 简陋:在如此有限的标准API下,能逻辑清晰和健壮地实现并组合心跳保活、断线重连、送达保证等算法,需要相当高的技术掌控力
  • 3)逻辑耦合:经验欠缺的开发人员,会将WebSocket通信代码与前端UI界面代码混在一起,使得UI界面的编写、维护、改版都非常困难。
针对以上问题,而MobileIMSDK-H5端库将让开发者专注于UI应用层的开发,网络通信层的专业代码交由SDK开发人员,从而解偶UI前端和通信层的逻辑耦合性,大大降低技术复杂性。

总结一下,MobileIMSDK-H5端库的设计目标是为您的Web端IM带来以下便利:
  • 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运行效果截图

1)Demo在PC端浏览器运行效果:

 

2)Demo在手机端浏览器运行效果(点击可看大图 ▼):

3)Demo在PC端主流浏览器的运行效果(点击可看大图 ▼):

十、详尽开发者手册

① MobileIMSDK-H5端的详细介绍:点此查看 👈
② MobileIMSDK-H5端的开发手册(网页版):点此查看 👈
 MobileIMSDK-H5端的开发手册(精编PDF版):点此查看 👈 (* 推荐
④ MobileIMSDK-开源框架的详细介绍:https://gitee.com/jackjiang/MobileIMSDK (Github托管链接)👈

十一、相关资料

[1] HTML5 WebSocket API 文档
[2] MobileIMSDK开源框架的API文档
[3] MobileIMSDK开源IM框架源码Github地址点此
[4] MobileIMSDK-Web框架基础介绍

posted @ 2024-09-18 10:36 Jack Jiang 阅读(68) | 评论 (0)编辑 收藏

     摘要: 本文由得物技术厉飞雨、GavinX分享,原题“得物App白屏优化系列|网络篇”,下文进行了排版和内容优化。1、引言图片加载作为重中之重的App体验指标,端侧的白屏问题则是其中最为严重、也是最为常见的问题之一。想象一下如果你在浏览交易商品、社区帖子等核心场景下,图片无法完成加载是多么糟糕的体验。如上图所示,通过线上白屏问题归因,我们看到网络问题导致比例最高,占比达81.97%...  阅读全文

posted @ 2024-09-12 11:02 Jack Jiang 阅读(78) | 评论 (0)编辑 收藏

     摘要: 【来源申明】本文引用了微信公众号“鲜枣课堂”的《老司机揭秘手机定位技术,这下彻底明白啦!》文章内容。为了更好的内容呈现,下文在引用和收录时内容有改动,转载时请注明原文来源信息,尊重原作者的劳动。1、系列文章引言1.1适合谁来阅读?本系列文章尽量使用最浅显易懂的文字、图片来组织内容,力求通信技术零基础的人群也能看懂。但个人建议,至少稍微了解过网络通信方面的知识后再看,会更有收...  阅读全文

posted @ 2024-09-11 12:07 Jack Jiang 阅读(88) | 评论 (0)编辑 收藏

     摘要: 【来源申明】本文引用了微信公众号“鲜枣课堂”的《坐高铁手机没信号?原因远比你想的要复杂!》文章内容。为了更好的内容呈现,本文在引用和收录时内容有改动,转载时请注明原文来源信息,尊重原作者的劳动。1、系列文章引言1.1适合谁来阅读?本系列文章尽量使用最浅显易懂的文字、图片来组织内容,力求通信技术零基础的人群也能看懂。但个人建议,至少稍微了解过网络通信方面的知识后再看,会更有收...  阅读全文

posted @ 2024-09-06 12:02 Jack Jiang 阅读(85) | 评论 (0)编辑 收藏

本文由携程技术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

posted @ 2024-08-29 15:45 Jack Jiang 阅读(82) | 评论 (0)编辑 收藏

     摘要: 【来源申明】本文引用了微信公众号“网优雇佣军”的《是谁偷走了我家的手机信号?》文章内容。为了更好的内容呈现,下文在引用和收录时内容有改动,转载时请注明原文来源信息,尊重原作者的劳动。1、系列文章引言1.1适合谁来阅读?本系列文章尽量使用最浅显易懂的文字、图片来组织内容,力求通信技术零基础的人群也能看懂。但个人建议,至少稍微了解过网络通信方面的知识后再看,会更有收获。如果您大...  阅读全文

posted @ 2024-08-21 17:53 Jack Jiang 阅读(89) | 评论 (0)编辑 收藏

     摘要: 本文由得物技术厉飞雨分享,原题“得物App弱网诊断探索之路”,下文进行了排版和内容优化。1、引言随着得物用户规模和业务复杂度不断提升,端上网络体验优化已逐步进入深水区。为了更好地保障处于弱网状态下得物App用户的使用体验,我们在已有的网络体验大盘、网络诊断工具的基础上研发了弱网诊断能力。该工具能够高效实时诊断用户真实网络环境,同时给出精确网络质量分级,为后续App各业务场景...  阅读全文

posted @ 2024-08-15 11:08 Jack Jiang 阅读(103) | 评论 (0)编辑 收藏

     摘要: 本文来自腾讯手Q基础架构团队杨萧玉、邱少雄、张自蹊、王褚重天、姚伟斌的分享,原题“QQ 客户端性能稳定性防劣化系统 Hodor 技术方案”,下文进行了排版和内容优化。1、引言接上篇《首次公开,最新手机QQ客户端架构的技术演进实践》。防劣化是比较经典的技术话题,手 Q 的防劣化系统从 2021 年 10 月开始投入研发,从 0 到 1 迭代了将近三年的时间,已经达到了业界先进...  阅读全文

posted @ 2024-08-02 10:38 Jack Jiang 阅读(58) | 评论 (0)编辑 收藏

关于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编写。

工程开源地址是:

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”增加了“消息发送者昵称”内容的返回;

部分功能运行截图更多截图点此查看):

posted @ 2024-07-26 12:57 Jack Jiang 阅读(94) | 评论 (0)编辑 收藏

一、关于RainbowChat-Web

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

二、v7.1 版更新内容

此版更新内容更多历史更新日志):

  • 1)[bug] [前端]   - 解决了转发语音消息后,语音消息ui气泡css样式问题;
  • 2)[bug] [前端]   - 解决了登陆后首次打开对应聊天界面前收到的新消息和历史消息显示顺序问题;
  • 3)[bug] [前端]   - 解决了删除聊天后,没有自动清除聊天界面上的“加载更多”功能按钮;
  • 4)[bug] [前端]   - 解决了引用陌生人消息时,显示的是uid而不是对方昵称的问题;
  • 5)[bug] [前端]   - 解决了群主撤回群员消息时,系统通知中显示的是uid而不是对方昵称的问题;
  • 6)[优化] [前端]   - 优化了引用的消息内容中表情图标导致引用的文字不能垂直居中显示的ui问题;
  • 7)[优化] [前端]   - 优化了群聊中消息发送者昵称的显示;
  • 8)[优化] [服务端] - 为“接口1008-26-8”增加了“消息发送者昵称”内容的返回;

三、主要功能特性截图

主要功能特性截图(更多运行截图运行视频

posted @ 2024-07-26 11:42 Jack Jiang 阅读(76) | 评论 (0)编辑 收藏

     摘要:      本文由京东技术王泽知分享,原题“基于Web的跨平台桌面应用开发”,下文进行了排版和内容优化。1、引言近些年来,跨平台跨端一直是比较热门的话题,Write once, run anywhere一直是开发者所期望的,跨平台方案的优势十分明显。对于开发者而言,可以做到一次开发、多端复用,一套代码就能够运行在不同设备上,这在很大程度上能够降低...  阅读全文

posted @ 2024-07-25 11:08 Jack Jiang 阅读(108) | 评论 (0)编辑 收藏

为了更好地分类阅读 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/

posted @ 2024-07-11 12:38 Jack Jiang 阅读(105) | 评论 (0)编辑 收藏

     摘要: 本文由QQ音视频团队贺坤分享原题“Linux QQ能打语音视频了!一文详解背后技术实现!”,下文进行了排版和内容优化等。1、引言2024年6月6日,QQ For Linux 3.2.9 正式支持了音视频通话功能,这是 QQ Linux 版本的又一个里程碑事件。 2024 年,QQ 音视频正式推出 NTRTC,全平台(iOS/Android/MacOS/Windows/Lin...  阅读全文

posted @ 2024-07-04 11:31 Jack Jiang 阅读(91) | 评论 (0)编辑 收藏

本文由爱奇艺技术团队分享,作者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

posted @ 2024-06-27 11:51 Jack Jiang 阅读(88) | 评论 (0)编辑 收藏

一、关于RainbowChat-Web

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

二、v7.0 版更新内容

此版更新内容更多历史更新日志):

  • 1)[bug] [前端]    - 解决了断网重连后,首页“消息”列表中的item选中状态会消失的问题;
  • 2)[bug] [前端]    - 解决了“清屏”功能不能清除群聊缓存的问题;
  • 3)[bug]  [服务端] - 解决了消息撤回时,被引用消息的历史记录没有被正确处理;
  • 4)[新增] [前端]    - 新增“@”功能;
  • 5)[新增] [前端]    - 新增消息引用功能(支持引用全部消息类型);
  • 6)[新增] [前端]    - 启用了新的“加载更多”功能,支持动态分页加载,提升大量历史聊天记录下的用户体验;
  • 7)[优化] [前端]    - 首页消息列表中的语音消息将显示时长(跟新版微信一样);
  • 8)[优化] [前端]    - 优化了聊天消息中的网址链接显示(自动解析超链接);
  • 9)[优化] [前端]    - 大幅提升聊天界面中加载大量消息时的ui渲染性能;
  • 10)[优化] [前端]   - 其它ui和体验的小细节优化;
  • 11)[优化] [服务端] - 为“接口1008-26-7”增加了“at_me”字段的返回;
  • 12)[优化] [服务端] - 优化了“接口1008-26-8”,使聊天记录支持按时间戳的分页加载方案;
  • 13)[优化] [服务端] - 升级了包括log4j2等在内的一些基础库版本。

三、v7.0 版新增主要特性截图

“@”功能功能运行截图查看演示视频更多运行截图):

“消息引用”功能(查看演示视频更多运行截图):

 

posted @ 2024-06-24 13:25 Jack Jiang 阅读(49) | 评论 (0)编辑 收藏

     摘要: 本文由腾讯技术kernel分享,原题“TCP经典异常问题探讨与解决”,下文进行了排版和内容优化等。1、引言TCP的经典异常问题无非就是丢包和连接中断,在这里我打算与各位聊一聊TCP的RST到底是什么?现网中的RST问题有哪些模样?我们如何去应对和解决?本文将从TCP的RST技术原理、排查手段、现网痛难点案例三个方面,自上而下、循序渐进地给读者带来一套完整的分析方法和解决思路...  阅读全文

posted @ 2024-06-20 12:49 Jack Jiang 阅读(89) | 评论 (0)编辑 收藏

     摘要: 本文由环信技术黄飞鹏分享,原题“实战|如何利用 Electron 快速开发一个桌面端应用”,本文进行了排版和内容优化等。1、引言早就听说利用Electron可以非常便捷的将网页端快速打包成桌面应用,并且利用 Electron 提供的 API 调用可以使用原生桌面 API 一些高级功能。于是这次借着论证 Web IM端 SDK 是否可以在 Electron 生成的桌面端正常稳...  阅读全文

posted @ 2024-06-13 11:53 Jack Jiang 阅读(67) | 评论 (0)编辑 收藏

为了更好地分类阅读 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聊天等系统的技术同行带来一些启发。


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

[链接] 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/

posted @ 2024-06-12 14:54 Jack Jiang 阅读(55) | 评论 (0)编辑 收藏

     摘要: 本文由腾讯梁中原分享,原题“红包算法揭秘!哪段代码让你只抢了0.01元?”,下文进行了排版和内容优化等。1、引言在上一篇《来看看微信十年前的IM消息收发架构,你做到了吗》的文章中,有用户提到想了解自己每次微信红包只能抽中 0.01 元的反向手气最佳是怎么在技术上实现的,于是就有了本篇文章的诞生。其实,微信红包最初在产品设计上有过很多思路,最初曾以多档次、按比例分配的方式,但...  阅读全文

posted @ 2024-06-06 12:45 Jack Jiang 阅读(56) | 评论 (0)编辑 收藏

为了更好地分类阅读 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/

posted @ 2024-06-05 11:56 Jack Jiang 阅读(16) | 评论 (0)编辑 收藏

本文由腾讯技术何金源分享,原题“不畏移山,手机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

posted @ 2024-05-30 10:24 Jack Jiang 阅读(70) | 评论 (0)编辑 收藏

     摘要: 本文由腾讯云开发者张曌、毕磊分享,原题“QQ 9“傻快傻快”的?!带你看看背后的技术秘密”,本文进行了排版和内容优化等。1、引言最新发布的 QQ 9 自上线以来,流畅度方面收获了众多用户好评,不少用户戏称 QQ 9 “傻快傻快”的,快到“有点不习惯了都”。作为庞大量级的IM应用,QQ 9 从哪些方面做了...  阅读全文

posted @ 2024-05-23 14:20 Jack Jiang 阅读(98) | 评论 (0)编辑 收藏

为了更好地分类阅读 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聊天界面中录音及振幅动画。


[- -]  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/

posted @ 2024-05-22 13:53 Jack Jiang 阅读(73) | 评论 (0)编辑 收藏

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

1、引言

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

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

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

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

 
 
 技术交流:

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

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

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

2、关联文章

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

posted @ 2024-05-16 11:44 Jack Jiang 阅读(92) | 评论 (0)编辑 收藏

一、更新内容简介

本次更新为次要版本更新,进行了bug修复和优化升级(更新历史详见:码云 Release NotesGithub Release Notes)。

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

二、MobileIMSDK简介

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

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

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

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

三、源码托管同步更新

OsChina.net

GitHub.com

四、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调用。

【最新版本源码地址】:

七、Demo运行演示

八、技术应用示例

8.1 示例1:基于MobileIMSDK的移动端IM RainbowChat更多运行截图):

 

8.2 示例2:基于MobileIMSDK-Web的Web端IM RainbowChat-Web更多运行截图):

 

posted @ 2024-05-09 11:34 Jack Jiang 阅读(84) | 评论 (0)编辑 收藏

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

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

[- 1 -] 一种Android端IM智能心跳算法的设计与实现探讨(含样例代码)

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

[摘要] 本文将与大家一起探讨一种更加简单易行和实用的心跳算法,不一定适合所有人,但希望能需要的同行带来一些启发。


[- 2 -] 详解Netty的安全性:原理介绍、代码演示(上篇)

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

[摘要] 作为一个高性能的NIO通信框架,基于Netty的行业应用非常广泛,不同的行业、不同的应用场景,面临的安全挑战也不同,下面我们根据Netty的典型应用场景,分析下Netty面临的安全挑战。


[- 3 -] 详解Netty的安全性:原理介绍、代码演示(下篇)

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

[摘要] 接上篇《详解Netty的安全性:原理介绍、代码演示(上篇)》。


[- 4 -] Java NIO基础视频教程、MINA视频教程、Netty快速入门视频 [有源码]

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

[摘要] 本次分享的是自己收藏的Java nio、mima、netty的视频教程,现分享给各位,希望对大家有帮助。


[- -] 轻量级即时通讯框架MobileIMSDK的源码

[链接]http://git.oschina.net/jackjiang/MobileIMSDK

https://github.com/JackJiang2011/MobileIMSDK

[摘要] 如Github下载慢,请往:https://gitee.com/jackjiang/MobileIMSDK,代码完全同步,请放心下载 


[- 6 -] 开源IM工程“蘑菇街TeamTalk”2015年5月前未删减版完整代码 [附件下载]

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

[摘要] 本次分享的源码来自即时通讯群群友的个人分享,因可能涉及网易泡泡源码版权纠纷,请开发者保证仅用于个人学习和研究之用,切勿用于商业用途。


[- 7 -]  NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战 [附件下载]

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

[摘要] 本文中,服务端将分别用MINA2和Netty4进行实现,但在你实际的项目中服务端实现只需选其一就行了。


[- 8 -] NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战 [附件下载]

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

[摘要] 本文将演示一个iOS客户端程序,通过UDP协议与两个典型的NIO框架服务端,实现跨平台双向通信的完整Demo。


[- 9 -] NIO框架入门(二):服务端基于MINA2的UDP双向通信Demo演示 [附件下载]

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

[摘要] 本文将演示的是一个基于MINA2的UDP服务端和一个标准UDP客户端(Java实现)双向通信的完整例子。


[- 10 -] NIO框架入门(一):服务端基于Netty4的UDP双向通信Demo演示 [附件下载]

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

[摘要] 本文将演示的是一个基于Netty4的UDP服务端和一个标准UDP客户端(Java实现)双向通信的完整例子。


[- 11 -] 用于IM中图片压缩的Android工具类源码,效果可媲美微信 [附件下载]

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

[摘要] 本文要分享的工具类源码来自IM产品 RainbowChat,压缩效果可媲美微信,详情请参见源码。


[- 12 -] 高仿Android版手机QQ可拖拽未读数小气泡源码 [附件下载]

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

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


[- 13 -] 一个WebSocket实时聊天室Demo:基于node.js+socket.io [附件下载]

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

[摘要] 本文将基于HTML5规范中的WebSocket技术,使用Node.js和Socket.io(关于Socket.io介绍,请参见《Socket.IO介绍:支持WebSocket、用于WEB端的即时通讯的框架》)来实现一个可用于Web端的简易实时聊天室,源码可从文末附件中下载到。


[- 14 -] Android聊天界面源码:实现了聊天气泡、表情图标(可翻页) [附件下载]

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

[摘要] Android聊天界面源码:实现了聊天气泡、表情图标。


👉52im社区本周新文:《即时通讯安全篇(十四):网络端口的安全防护技术实践》,欢迎阅读!👈

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

posted @ 2024-05-08 12:24 Jack Jiang 阅读(79) | 评论 (0)编辑 收藏

     摘要: 本文由vivo互联网技术Peng Qiankun分享,原题“vivo 网络端口安全建设技术实践”,本文进行了排版和内容优化等。1、引言随着互联网业务的快速发展,网络攻击的频率和威胁性也在不断增加,端口是互联网络通信中的门户,它是数据进出的必经之路,因此端口安全也逐渐成为了企业内网的重要防线之一。然而网络端口因其数量庞大、端口开放和关闭的影响评估难度大,业务影响程度高、以及异...  阅读全文

posted @ 2024-05-06 12:35 Jack Jiang 阅读(78) | 评论 (0)编辑 收藏

本文由腾讯技术团队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

posted @ 2024-04-18 11:06 Jack Jiang 阅读(90) | 评论 (0)编辑 收藏

关于MobileIMSDK

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

工程开源地址是:

关于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 端,请:点此查看

v11.5 版更新内容

此版更新内容更多历史更新日志):

(1)Android端主要更新内容:

  • 1)[bug] 解决了“@”提醒在客户端新消息时未持久化的问题;
  • 2)[bug] 解决了首页“一键已读”功能不清除“@”提醒标记的问题;
  • 3)[bug] 解决了消息转发时,“最近消息”列表中的表情内容没有被转义成表情图标的问题;
  • 4)[bug] 解决了查看iOS端发的引用的文件消息时,无法跳转到文件下载界面的问题;
  • 5)[bug] 解决了查看iOS端发的引用的短视频消息时,无法跳转到短视频下载界面的问题;
  • 6)[升级] 提升targetSdkVersion至34,全面兼容Android 14;
  • 7)[升级] 解决了绑定前台服务在Android 14中崩溃的问题;
  • 8)[升级] 升级权限管理框架XXPermissions至18.62,全面兼容Android 14;
  • 9)[升级] 其它基础库升级等。

(2)服务端主要更新内容:

  • 1)[bug] 修复一处跟RainbowChat-Web产品联合部署时,Web端无法成功加载历史记录的问题;
  • 2)[升级] 升级了包括log4j2等在内的一些基础库版本;
  • 3)[升级] 优化了iOS离线推送时苹果手机端的桌面未读数角标显示;

部分功能运行截图更多截图点此查看):

 

posted @ 2024-04-17 11:51 Jack Jiang 阅读(102) | 评论 (0)编辑 收藏

为了更好地分类阅读 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长连接的心跳及重连机制,以及又是怎么踩坑已及填坑的。


[--] 跟着源码学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 实现一个类似的功能,因此就有了本文。


[--]  跟着源码学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/

posted @ 2024-04-12 12:06 Jack Jiang 阅读(73) | 评论 (0)编辑 收藏

本文由微信技术团队分享,原题“十年前的微信消息收发架构长啥样?”,下文进行了排版和内容优化等。

1、引言

2023 年,微信及 WeChat 的 DAU(月活用户)达到 13.4 亿,微信已经是很多人工作、生活中不可或缺的一个环节。从 2011 年 1 月 21 日上线至今,微信已经走过了 13 个年头,其背后的技术基座与架构也发生了巨大的变化。这些变化背后,所折射的也正是中国互联网高速发展的黄金年代。

好的架构是迭代出来的,却也少不了良好的设计,本文将带大家回顾微信背后最初的也是最核心的IM消息收发技术架构,愿各位读者能从中获得启发。

 
 

技术交流:

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

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

(本文已同步发布于:http://www.52im.net/thread-4636-1-1.html

2、微信技术起步

微信诞生于 QQMail 团队,初始的整个微信后台架构都带着浓重的邮箱气息,消息收发架构作为微信最为核心的部分,同样是基于邮箱的存储转发机制演变而来

微信定位为即时通讯IM软件,对消息的收发有2个基本的要求:

  • 1)消息尽可能的实时送达;
  • 2)不丢消息。

在邮箱的存储转发机制上做了改良后,微信的消息收发实现了以上2个基本要求。

3、消息发送架构

首先通过手机 A 给手机 B 发送一条微信消息来看消息发送的整体架构是怎样的(如下图所示)。

微信消息发送在整体架构上可以分为2个部分。

第一部分:手机A发送消息到服务器(上图中1、2、3部分):

  • 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

posted @ 2024-04-11 11:05 Jack Jiang 阅读(84) | 评论 (0)编辑 收藏

关于MobileIMSDK

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

工程开源地址是:

关于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修复。

新增功能运行截图(更多截图点此查看):

posted @ 2024-04-07 12:18 Jack Jiang 阅读(520) | 评论 (0)编辑 收藏

     摘要: 本文由苏三说技术分享,原题“微信群聊功能,原来是这样设计的!”,下文进行了排版和内容优化等。1、引言当我那天拿着手机,正在和朋友们的微信群里畅聊着八卦新闻和即将到来的周末计划时,忽然一条带着喜意的消息扑面而来,消息正中间写着八个大字:恭喜发财,大吉大利。抢红包!!相信大部分人对此都不陌生,微信的这个群聊系统可以方便地聊天、分享图片和表情,还有那个神奇的红包功能。微信作为 1...  阅读全文

posted @ 2024-04-03 10:25 Jack Jiang 阅读(98) | 评论 (0)编辑 收藏

     摘要: 本文由腾讯技术yeconglu分享,原题“企业微信大型Android系统重构之路”,下文进行了排版和内容优化等。1、引言企业微信本地部署版(下文简称为本地版)是从2017年起,脱胎于企业微信的一款产品。本地版的后台服务能独立部署在政府或者大型企业的本地服务器上。在一个已经迭代了7年的大型Android端工程中,企业微信本地版不可避免地会暴露出一些遗留系统的特点。本文将探讨我...  阅读全文

posted @ 2024-03-28 11:21 Jack Jiang 阅读(118) | 评论 (0)编辑 收藏

本文由微信技术团队仇弈彬分享,原题“微信海量数据查询如何从1000ms降到100ms?”,本文进行了内容修订和排版优化。

1、引言

微信的多维指标监控平台,具备自定义维度、指标的监控能力,主要服务于用户自定义监控。作为框架级监控的补充,它承载着聚合前 45亿/min、4万亿/天的数据量。

当前,针对数据层的查询请求也达到了峰值 40万/min,3亿/天。较大的查询请求使得数据查询遇到了性能瓶颈:查询平均耗时 > 1000ms,失败率居高不下。

针对大数据量带来的查询性能问题,微信团队对数据层查询接口进行了针对性的优化,将平均查询速度从1000ms+优化到了100ms级别。本文为各位分享优化过程,希望对你有用!

 
 

技术交流:

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

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

(本文已同步发布于:http://www.52im.net/thread-4629-1-1.html

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

posted @ 2024-03-21 13:25 Jack Jiang 阅读(92) | 评论 (0)编辑 收藏

本文由冀浩东分享,原题“单核QPS近6000S,陌陌基于OceanBase的持久化缓存探索与实践”,为了阅读便利,本文进行了排版和内容优化等。

1、引言

挚文集团于 2011 年 8 月推出了陌陌,这款立足地理位置服务的开放式移动视频IM应用在中国社交平台领域内独树一帜。陌陌和探探作为陌生人社交领域的主流IM应用,涵盖了多种核心业务模块,包括直播服务、附近动态功能、即时通讯(IM)业务以及增值服务等,每个业务场景都具有其独特性和挑战。

在本文中,陌陌数据库负责人冀浩东将聚焦探讨陌陌的 KV 系统架构选型思路,深入解析如何进行此类系统的甄选决策,同时进一步分享陌陌团队在采用 OceanBase(OBKV)过程中所经历的探索与实践经验。

技术交流:

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

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

(本文已同步发布于:http://www.52im.net/thread-4627-1-1.html)

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

posted @ 2024-03-14 12:09 Jack Jiang 阅读(22) | 评论 (0)编辑 收藏

为了更好地分类阅读 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

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

[- -] 直播系统聊天技术(八):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消息系统。

[- -]  融云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/

posted @ 2024-03-13 14:00 Jack Jiang 阅读(61) | 评论 (0)编辑 收藏

     摘要: 本文由百度技术团队分享,引用自百度Geek说,原题“千万级高性能长连接Go服务架构实践”,为了阅读便利,本文进行了排版优化等。1、引言移动互联网时代,长连接服务成为了提升应用实时性和互动性的基础服务。本文将介绍百度基于golang实现的统一长连接服务,从统一长连接功能实现和性能优化等角度,描述了其在设计、开发和维护过程中面临的问题和挑战,并重点介绍了解决相关问题和挑战的方案...  阅读全文

posted @ 2024-03-07 10:59 Jack Jiang 阅读(107) | 评论 (0)编辑 收藏

本文由ELab团队公众号授权发布,原题《Rust语言在IM客户端的实践》,来自抖音电商前端团队的分享,本文有修订和改动。

1、引言

本文将介绍飞鸽IM前端团队如何结合Rust对飞鸽客户端接待能力进行的技术提升,一步步从概念验证、路径分解到分工开发,再到最后上线收益论证,并分享了其中遇到的技术挑战与经验总结等。

本项目是一个长周期的复杂项目,相信本项目落地的经验对其他同学及团队能有所借鉴。

 
 

技术交流:

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

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

(本文已同步发布于:http://www.52im.net/thread-4620-1-1.html

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

posted @ 2024-02-29 10:26 Jack Jiang 阅读(76) | 评论 (0)编辑 收藏

为了更好地分类阅读 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系统等)的消息队列设计提供一定的参考。


[- -] 移动端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/

posted @ 2024-02-28 13:19 Jack Jiang 阅读(107) | 评论 (0)编辑 收藏

为了更好地分类阅读 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

[摘要] 对于乱码这个看似不起眼,但并不是一两话能讲清楚的问题,是很有必要从根源了解字符集和编码原理,知其然知其所以然显然是一个优秀码农的基本素养,所以,便有了本文,希望能帮助到你。


[- -]  史诗级计算机字符编码知识分享,万字长文,一文即懂!

[链接] 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/

posted @ 2024-02-22 12:13 Jack Jiang 阅读(107) | 评论 (0)编辑 收藏

本文由去哪儿网技术团队田文琦分享,本文有修订和改动。

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、相关文章

[1] 从C10K到C10M高性能网络应用的理论探索

[2] 一文读懂高性能网络编程中的I/O模型

[3] 一文读懂高性能网络编程中的线程模型

[4] 以网游服务端的网络接入层设计为例,理解实时通信的技术挑战

[5] 手淘亿级移动端接入层网关的技术演进之路

[6] 喜马拉雅自研亿级API网关技术实践

[7] B站基于微服务的API网关从0到1的演进之路

[8] 深入操作系统,彻底理解I/O多路复用

[9] 深入操作系统,彻底理解同步与异步

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

[11] 百度统一socket长连接组件从0到1的技术实践

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

[13] 百度基于金融场景构建高实时、高可用的分布式数据传输系统的技术实践


(本文已同步发布于:http://www.52im.net/thread-4618-1-1.html

posted @ 2024-02-21 10:20 Jack Jiang 阅读(90) | 评论 (0)编辑 收藏

本文由得物技术暖树分享,有修订和改动。

1、引言

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

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4614-1-1.html

2、消息推送的作用

2.1 什么是消息推送

消息推送每天都在我们的手机上发生,如下图所示,除非你的手机没有安装App或关闭了通知栏权限。

2.2 消息推送的价值

从用户的生命周期来看,消息推送对于提高App活跃度、提升用户粘性和用户留存率都起到了重要作用。

比如:

  • 1)提升新用户次日留存,低成本促活,对平台的短期留存率影响显著;
  • 2)提升老用户活跃度,push可以通过外部提醒起到拉活的作用;
  • 3)流失用户召回,当用户流失后,若push权限未关闭,通过消息推送的方式,有可能重新唤醒用户。

对于第 2)点,很多内容平台类App的用户push首次启动占比可达 10%以上,因此push对DAU的增量贡献不容小觑。

3、业务背景和技术痛点

消息中心为得物App提供了强大,高效的用户触达渠道。其中push对于得物DAU的贡献有可观的占比,这也就意味着每一条推送消息都是一次与用户沟通的宝贵机会。所以推送的稳定性成为我们关注的首要问题。

那么我们遇到的以下痛点就亟待解决:

1)消息中心没有明确消息推送的耗时标准,业务和技术之间存在gap,业务方对于推送的消息什么时候到达没有明确的心理预期。

2)从技术上来讲消息推送各个节点的耗时不明确,无法对各个节点的耗时做针对性的优化,这也就需要我们针对消息推送的节点耗时进行监控。

3)消息推送的稳定性依赖于第三方的推送通道,而三方通道对于我们来讲就是个黑盒子,如何做到三方通道异常及时发现并止损也是需要考虑的问题。

4)在我们正常的迭代过程中有时候不可避免的会出现些异常或者有坏味道的代码,这些问题能不能及时发现、及时止损,能不能及时告警出来。

4、稳定性监控体系

SLA(Service-Level Agreement),也就是服务等级协议,指的是系统服务提供者(Provider)对客户(Customer)的一个服务承诺。这是衡量一个大型分布式系统是否“健康”的常见方法。

在开发设计系统服务的时候,无论面对的客户是公司外部的个人、商业用户,还是公司内的不同业务部门,我们都应该对自己所设计的系统服务有一个定义好的SLA。因为SLA是一种服务承诺,所以指标可以多种多样。

最常见的四个SLA指标:

  • 1)可用性;
  • 2)准确性;
  • 3)系统容量;
  • 4)延迟。

 

对于消息推送而言,我们主要关注的是消息能否及时可靠的送达给用户,也就是SLA中关注的时效性和稳定性的问题。

目前消息中心针对实效性和稳定性的开发已经完成并初显成效。

系统架构图:

下面主要针对时效性和稳定性的监控做一些介绍。

5、时效性监控的技术实现

5.1 节点的拆分

如何做到时效性的无死角监控,那么我们就要对消息推送的整个流程进行拆分,把整个流程拆分成若干个独立且无依赖的可监控节点。

从消息系统流转图中可以看到:整个推送流程是清晰明了的,消息的的推送主要会经历推送鉴权、用户查询、防疲劳过滤、防重复过滤等的逻辑处理,考虑到每个业务逻辑的处理是相互独立且无依赖的,那我们就可以根据具体的业务处理逻辑进行节点的拆分,这样就可以做到拆分无遗漏,监控无死角。

拆分后的具体节点如下:

5.2 节点耗时的计算

具体的节点拆分逻辑和耗时逻辑的计算如下图:

 

节点耗时的计算:记录节点消息推送到达的时间,并计算节点推送耗时,例如:防疲劳耗时 = T7(antiFatigueConsumeTime) - T6(checkrepeatConsumeTime)。

节点阻塞量的计算:记录节点消息推送的瞬时阻塞量, 例如:防疲劳节点阻塞量 = 防疲劳的总量 - 防疲劳已经处理的量。

5.3 节点指标的制定

既然需要监控的节点已经拆分明确了,那针对这些节点我们监控哪些指标才是有意义的呢。

1)目前消息推送高峰耗时较长,各业务域对于消息的到达时间也没有明确的心理一个预期,另外消息中心也无法感知推送在整个链路各个节点的耗时情况,无法针对节点耗时做到有针对性的优化,所以节点的推送量和推送耗时就是我们需要重点关注的指标。

2)节点的阻塞量可以让我们及时感知到推送中存在的积压问题,在大促期间,消息的推送量也会达到一个高峰,消息目前是否有堆积,处理的速度是否跟的上,是否需要临时扩容,那么节点的阻塞量就成了一个比较有意义的参考指标。

考虑到消息推送是有优先级的并且区分单推和批量推,所以我们要针对不同的优先级和推送方式设置不同的标准。

消息推送耗时的具体标准如下:

5.4 技术方案的实现

为了能感知到消息推送中发生的异常和耗时情况,这就需要我们标准化监控指标和监控的节点。

其中耗时指标可以感知节点的耗时和代码的坏味道,阻塞量可以监控到节点的堆积情况,推送成功率可以感知节点的推送异常等。

另外节点拆分后我们可以很快定位到异常发生的具体位置,经过拆分监控的主要节点包括鉴权、风控、用户查询、防疲劳、防重复、厂商调用等。

另外消息中心每天推送大量消息给得物用户,SLA监控任何一个操作嵌入主流程中都可能导致消息推送的延迟。这也就要求监控和主流程进行隔离,主流程的归主流程,SLA 的归 SLA,SLA 监控代码从主流程逻辑中剥离出来,彻底避免SLA代码对主流程代码的污染,这也就要求SLA逻辑计算需要独立于推送业务的主流程进行异步计算,防止SLA监控拖垮整个主流程,那么Spring AOP+Spring Event就是最好的实现方式 。

5.5 成果

消息推送实效性监控做完之后,对服务节点耗时异常可以及时感知,同时也完成了关键节点耗时的指标化。

可以明确的看到所有节点在各个时间的耗时情况,同时也对消息推送针对各个节点的的优化起到了指导作用。

时效性节点监控:

时效性节点告警:

6、厂商推送监控的技术实现

6.1 监控指标制定

消息推送接入的有多个推送通道,如何做到对这些通道做到无死角的监控,及时感知呢。

1)在做厂商监控之前,我们就已经遇到了厂商通道推送跌零的情况,这种情况下整个推送通道都挂掉了,我们要及时通知厂商进行修复,所以厂商推送跌零告警和厂商余量监控是必须的。

2)从现有数据来看,厂商的推送成功率、回执成功率、点击率都稳定在一定的的区间。如果厂商推送的指标数据偏离这个区间则说明推送有异常,所以推送成功率、回执成功率、点击率的监控是必须的。

3)另外从业务请求发送的用户数来看,每天的消息推送基本是稳定的,相对应的厂商的回执数量和点击数量也是稳定的,那么对厂商推送成功的数量,回执的数量和点击的数量监控也有一定的参考意义。

业务侧请求发送的用户数:

厂商监控告警:

6.2 技术方案实现

厂商每天有数亿的消息推送,这也就意味着厂商的监控不能嵌在主流程中处理。厂商的监控代码要从主流程逻辑中剥离出来,避免监控拖垮主流程,同样避免监控异常影响到推送的主流程。

针对厂商推送的监控,目前使用的是有界内存队列实现:

6.3 成果

消息推送厂商监控上线之后,可以及时感知到厂商推送的异常信息,对于厂商推送的异常和厂商规则的更改等可以做到及时的感知。

 

7、 稳定性监控体系带来的收益

7.1 异常的及时发现

监控上线后及时发现了发现了厂商推送线程关闭失败,厂商推送跌零、厂商营销消息规则更改、厂商通道偶发不可用等问题,并做到了及时的止损。

1)在时效性监控上线之后,发现了因厂商推送线程创建关闭失败导致线程数逐渐上升问题,避免了线上故障的发生。

2)厂商异常导致推送跌零,监控发现后及时通知到厂商并止损。

3)发现厂商营销消息规则更改的异常,并及时经梳理各大厂商文档后发现除了多个厂商通道在未来一个月内也会有规则的更改,消息平台及时适应了厂商规则,接入厂商系统通道,做到了及时止损。

7.2 服务性能的提升

时效性监控上线后发现了多个服务可以优化的点,其中多个厂商和推送节点在高峰推送时耗时较高,很明显节点耗时和厂商推送 SDK 连接池和连接时间参数需要优化。优化后消息推送整体的吞吐量实现了翻倍的提升。

8、 展望未来

由于时间问题,目前消息监控只做了时效性和厂商推送稳定性相关的监控,但是监控上线后带来的收益还是比较可观的,可以预见的是监控的构建在未来必将带给我们更大的收益,后续我们可以从以下点丰富现有监控。

1)考虑到业务预的推送量和推送时间是稳定的,那么我们可以针对业务维度添加推送数据的监控,及时感知上游推送数据的变化。

2)其次我们可以针对各个节点的推送异常、漏斗转化率、服务性能等做监控,进一步丰富消息平台的监控体系。

3)对于消息推送来讲也要考虑推送的转化率问题,那么卸载、屏蔽等指标也是我们需要监控的点,通过这些业务指标及时感知推送的效果,做到精细化的管控。

9、本文小结

消息平台监控上线后带来的收益还是比较可观的,包括多次异常的及时发现和止损,还有发现多个个可以优化的性能点,实现了服务高峰吞吐量的翻倍。

同时也解决了我们现在遇到的以下痛点:

1)时效性明确的给到了不同优先级的耗时标准,避免了业务和技术之间的gap,业务方对于推送的耗时也有了明确的心理预期。

2)时效性使得节点耗时的性能问题可以一目了然,通过对现有节点耗时问题的优化,消息服务的吞吐量实现了翻倍的提升。

3)厂商稳定性监控使得厂商异常可以及时感知,其中厂商稳定性监控上线后发现多起厂商推送的异常,并做到了及时的解决和止损。

4)SLA时效性和厂商稳定性上线后,消息中心可以及时感觉到推送链路的异常和代码的坏味道,特别是对于新上线的代码,如果存在异常可以及时感知。

10、相关文章

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

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

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

[4] 实践分享:如何构建一套高可用的移动端消息推送系统?

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

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

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

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

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

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

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

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

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

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

11、 得物分享的其它文章

IM跨平台技术学习(七):得物基于Electron开发客服IM桌面端的技术实践

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

得物自研客服IM中收发聊天消息背后的技术逻辑和思考实现

(本文已同步发布于:http://www.52im.net/thread-4614-1-1.html

posted @ 2024-01-25 11:27 Jack Jiang 阅读(312) | 评论 (0)编辑 收藏

关于MobileIMSDK

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

工程开源地址是:

关于RainbowChat

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

 

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

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

v11.0 版更新内容

此版更新内容更多历史更新日志):

(1)Android端主要更新内容新增“@”功能、消息引用功能等】:

  • 1)[新增] 新增“@”功能;
  • 2)[新增] 新增消息引用功能(支持引用全部消息类型);
  • 3)[bug] 解决了转发的是收到的短视频消息时,发送者这边不从网络加载预览图的问题;
  • 4)[bug] 解决了离线好友消息在首页“消息”列表上显示的时间不是最后一条消息的发送时间问题;
  • 5)[优化] 首页消息列表中的语音消息将显示语音时长(跟新版微信一样);
  • 6)[优化] 其它优化及bug修复。

(2)服务端主要更新内容:

  • 1)[新增] 增加了“@”功能相关数据字段和代码逻辑的实现;
  • 2)[新增] 增加了消息引用功能相关数据字段和代码逻辑的实现;
  • 3)[优化] 更新了消息推送特权接口,支持陌生人、好友、群聊3种消息的推送,且增加了主机ip检查(提高安全性);

此版新增功能运行截图更多截图点此查看):

posted @ 2024-01-24 12:44 Jack Jiang 阅读(58) | 评论 (0)编辑 收藏

本文由百度搜索技术平台研发部分享,本文有修订和改动。

1、引言

分布式数据传输系统是一种用于在多个计算节点之间高效传输大量数据的系统,诣在高效的解决大规模数据迁移、备份、跨地域复制等问题。其广泛应用在实时数据流传输、跨数据中心数据迁移、多媒体传输等场景,在大多数企业中的日志管理、业务数据建库等场景中也都会使用到。

众所周知,数据的高效传输往往直接影响着企业对市场先机的把握,对企业发展有重要意义,特别是在金融领域,如证券行业,它对分布式数据传输系统的设计提出了更高的要求,证券领域数据变化飞快,一个高时效、稳定的数据流传输系统不仅能有效的提升用户体验,更能提供用户一手的投资信息,有助于用户的投资决策,进而拉进企业与用户的距离。

本文将通过一个百度搜索旗下的金融场景案例来分享构建高实时、高可用的分布式数据传输系统的技术实践。

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4602-1-1.html

2、业务背景

作为百度搜索场景下时效性要求较高的业务,金融承载着每天数千万次的用户搜索请求。

而在2021年以前,金融业务的数据一直都是采用传统的互联网引入方式,该方式的特点是接入成本较低,但受公网等不可控因素影响,数据时效性较差,且数据断流、错误等问题频出,随即而来的就是业务维护成本较高,十分不利于产品迭代。

我们基于此发起了一个证券数据直连项目,诣在通过接驳全球各大证券交易所数据中心来构建一个高时效、高可用的分布式传输系统,从而有效的解决传统数据引入方式(公网抓取、推送)所带来的时效性、稳定性、正确性等问题,进而满足全国乃至全球用户的金融需求。

3、设计目标

3.1业务目标

接驳全球各大证券交易所Level-1行情数据,来覆盖全量上市公司股票、外汇、期货、ETF、涡轮牛熊等证券业务来满足用户需求,时效性追平金融行业竞品,为打造强大的金融生态做数据基建储备。

Level-1行情简称LV1行情:是交易所根据交易规则发布的即时行情信息,数据格式包括基于FIX/FAST协议的接口和TXT文件、二进制数据流等,行情通过交易所信息技术公司的高速地面网和宽带广播卫星系统发布或上证所信息网络有限公司的互联网和专线传输。

3.2技术目标

1)基础设施建设:协同交易所、运营商完成物理专线的链路部署,通过物理专线接入的方式在百度云机房接入上海、深圳、香港、纳斯达克证券交易所数据中心,适配交易所单、组播协议将二进制流/文本数据引入到百度内部,再分别完成华南、华北、华东、香港(支持海外访问)地域的数据存储与转发,同时支持负载和流量调度来支撑各地域的用户请求。(注:这里的物理专线特指光缆)

2)时效性和稳定性提升:行情数据检索99分位耗时不超过200ms,数据稳定性从99%提升至99.99%以上,数据灾备能力从1主0备升级至1主2备。

3)数据安全:基于百度安全能力,构建类似的防火墙策略来严格控制每一个机房、每一个集群的出入权限,并且配置好相应的安全组策略。

4、关键思路

从功能和网络拓扑上来看,一个高时效、高可用的金融数据传输系统至少需要包含以下几个部分,我们逐个来进行解读。

4.1接入层

适配全球各大交易所单、组播传输协议,确保数据能在专线物理网络正常传输。

接入主要有2种方式:

  • 1)一种是走互联网;
  • 2)一种是走物理专线。

前者相对比较灵活:各类数据协议基本都可以支持,有直接走HTTP(GET/POST),或者是走消息队列的发布订阅等等,接入成本较低,属立即接入那种,但受公网的不可控因素影响,在传输效率和安全性上相对后者会有比较大的差距,我们一般会把互联网的方式当做一个灾备能力存在。

专线方式的特点:是仅点对点传输,由于用的是独立的光缆,在有限带宽内理论可以做到无争用状态,不受公网影响,属可靠传输,传输协议私有化,增加了更多的认证机制。因此也更安全,区分不同应用场景,像证券类数据传输,一般交易所采用的是单播、组播方式,当下用的多的是组播。另外专线中也有主备的概念,一般会预留1-2条线路做灾备,整体下来,专线的费用要更昂贵一些,接入的周期也更长,往往长达几个月。

4.2网络层

完成华南、华北、华东百度云机房虚拟网络架构建设,包括子网、路由、网关等。

虚拟网络的核心组成部分主要是子网、路由、网关、虚拟机,其中每个子网关联着一个虚拟机集群,我们把整个组成部分(域)统称为一个VPC(Virtual private Cloud),路由又区分为TGW路由和对等连接。

这里主要关注对等连接,它是为用户提供了VPC级别的网络互联服务,使用户实现在不同虚拟网络之间的流量互通,实现同区域/跨区域,同用户/不同用户之间稳定高速的虚拟网络互联,其核心是基于对路由表的操作,对等连接也支持配置地域级的DNS同步。

网关又分为NAT网关和专线网关:

1)一个对外:比如设置SNAT和DNAT规则用于统一网段的外网出口;

2)一个对内:对内其实就是确保能够走专线和内部网络打通。

4.3传输层

完成各机房内的数据解析、存储、同步、转发等。

对于接入层获取到的数据我们分为三个级别:

1)像交易所主要是二进制流、文本为一级数据,我们需要保留近一段时间的原始数据落在本地(一级数据管理集群),以便用作应急回放。

2)而解码后的数据为二级数据,落在二级数据管理集群上,主要用于跨地域同步。

3)最后,对解码后的数据进行计算&加工,作为三级数据,落在三级数据管理集群用于承接应用服务。同时,按协议解码后的数据按照使用场景区分为实时流(如分时)、延时流(如K线),延时流经过实时流计算得来,实时流同步进内存用于提升IO效率,延迟流通过实时流的计算后异步进DB,DB维护在三级数据管理集群上。

4.4应用层

负载/流量调度、监控能力等建设。

应用层的设计,主要有两个方面的考虑:

1)一方面是对于接入层的负载和流量调度,如通过部署websocket/http服务来支撑百度用户流量,使用BLB(Baidu Load Balance)将同一区域的多台百度智能云服务器虚拟成一个组,设置一个内网或外网的服务地址,将前端并发访问转发给后台多台云服务器(BCC),实现应用程序的流量均衡,性能上实现业务水平扩展。

负载均衡还通过故障自动切换及时地消除服务的单点故障,提升服务的可用性,支持服务器调度权重策略配置,并支持TCP、HTTP等协议。

2)一方面是对监控的应用,如请求/数据传输日志落盘、统计、分析以及流量和sla监控等。

4.5小结

将以上四层能力建设后,此时单机房内的网络拓扑应该如下图所示。

注:DCC/BBC/BCC都是百度云范畴的机器类型,更多细节可以参考百度智能云私有网络:https://cloud.baidu.com/doc/VPC/s/Vjwvytu2v

5、核心难点1

公网和私有网络方式下如何在云上完成多协议适配,尤其是在私有网络中适配单播、组播协议以及如何做组播转单播。

5.1公网&私有网络接入介绍

对于一个数据传输系统来说,最重要的一点其实就是能支持多协议的数据适配来提升系统的灵活性,证券交易所一般提供的接入方式有公网接入和私有网络接入,公网接入的成本较低,一般周粒度就可完成,没有复杂协议约束。

而私有网络往往会有更高的要求,协议上大部分都要求具备单播介入能力,少部分像纳斯达克和深圳交易所会要求下游支持组播接入。绝大多数的云厂商是无法直接在虚拟机上适配的,传统券商基本都是完全使用昂贵的物理机资源来承载,虽然物理机插拔更方便也更稳定,但运维管理成本也更高。

两种方式在效果和成本上也有本质的区别:

1)公网接入:公网比较常见的数据接入方式主要是HTTP/HTTPS方式,当然也会有RPC/FTP,只是用的相对少一些。

为了提升数据传输安全,双方可以在调用前协商好数据加密算法和密钥。优点是接入成本较低,能快速应用,尤其在跨洋传输上会有体现。缺点是走的公共线路,网络不可靠,且数据易被截获,当攻击者捕获两端的数据包后,哪怕不能完全解析,也可以实施一些流量攻击手段以影响服务稳定性。总的来说,一般不会对于安全性、时效性要求较高的数据采用该方式接入,更多是只是一种备用方式(特殊场景除外,如跨洋传输)。

2)私有网络接入:公司内网其实就属于一个私有网络,但是对于跨公司传输数据的场景,要想构建私有网络,一般会走物理专线接入的方式。

这种点对点传输方式的显著优点是专网专用且安全性较高,基本不受公共网络影响(自然灾害等不可抗力除外),在带宽范围内基本可以做到无网络争用状态(数据即发即达),由于是私有网络(双端内网传输),基本不用担心数据安全问题,而且往往还会增加额外的数据校验手段,尤其在金融场景,会有严格的token(硬/软)认证,该方式的缺点是成本相比公网传输接入成本更高,一般要持续数月,费用更昂贵,一般在上百万元,依赖选取的传输介质(一般选择光纤)和带宽。

5.2私有网络中单播、组播协议接入方案

私有网络有单播、广播、组播之分。

1)单播:相对比较好适配一些,走静态路由的方式在同一个VLANID下分别配置云端和IDC端的IP段作为IPV4专线互联地址即可。

2)广播:一般是对于服务端而言,比如证券交易所下游对接着全球范围的所有券商,数据源是相同的,一般会采用广播的机制把数据推送给所有下游。

3)组播:一般是要求下游需要适配,现如今大部分业务都已经上公有云,在云上常用虚拟化技术来完成服务器集群的部署。

对于虚拟机来说,更多的支持单播传输,不支持组播传输,往往需要在专门的物理设备(组播路由器、或特定的组播软件)上配置转发组播报文的路由,路由表关联着具体的路由协议(如PIM),再用IGMPV3协议来完成组播成员和报文的管理,通过动态BGP维护邻居关系(现在的云厂商上对BGP的可能是固定分配AS号,如果有AS的要求还是需要在物理机上单独做),我们可以圈出一部分物理资源专门承载组播数据传输,通过配置IGMP Snooping(可以将组播报文转发到二层数据链路层,实现组转单,注意版本需要是3,否则无法转发IGMPV3报文)+ AP完成组播转单播配置,再通过双网卡(WAN口+LAN口)形式实现专线网络数据接入&同步到百度内网,物理机通过三层交换机来关联,构造出类似下面的网络拓扑(如下图所示)。

6、核心难点2

6.1概述

数据管理&跨地域同步,数据灾备能力、时效性提升。

数据的分层管理主要是应对单机房内的场景,而对于跨机房或者说跨地域的主要难点是数据同步,后者需要更多的考虑跨机房数据传输效率和灾备管理,核心是网络设计。

6.2数据管理

按使用场景的不同,将数据分交易所二进制流数据(原始数据流)、文本数据、业务数据/日志等。

1)原始数据流:主要应对单机房、跨机房传输场景,当出现下游业务服务异常导致的数据展现错误时,存储的原始数据流可以很好的对数据进行回放,以便快速恢复业务,尤其是应对金融证券数据传输场景,证券交易所一般不会推送重复数据,如果下游业务服务异常导致存储的业务数据全部失效或为脏数据,那可能只能通过refresh主动请求上游来重新获取。

但这样做可能会出现核心数据丢失,由于这种方式的效率较低,还会扩大业务受损的影响面,因此一般会先存储交易所下发的原始数据流,业务可以自定义存储方式和周期,当出现问题时,可以通过『重播』原始数据流来止损。

另外原始数据流还能用于在对等网络中的跨机房恢复业务数据。

2)业务数据流:主要应对单机房传输的场景,根据模块分工的不同,分证券的实时行情、历史行情等等,对于单机房数据集群的管理我们有很多方式,对于自研的DB,在调度上可以用一些标准的分布式管理手段(如zk),数据同步的手段一般需要自定义,对于传统的DB如Mysql、Redis、Mongo等,一般有标准化的数据同步方式和调度模式。

6.3跨地域同步

跨机房地域同步的前提是多个机房之间需要有直接或间接关联关系的专用物理网络,即确保网络是可达的,然后再结合虚拟网络完成子网及路由配置。

对于具有直接网络关联关系的2个机房来说,我们的对等网络(Peer Connection)设计稍微简单一些。

现在各个云厂商也基本都支持直接配置了,其原理是首先在同一个VPC下划分好子网并规划好集群规模,其次通过配置路由表的方式完成本端和对端的下一跳关联,这样就完成了2个直接对端的对等网络建设。

接着再配置和内网专线的路由,就能做到云机房->内网机房的网络互通。

但如果2个机房没有直接关联关系,而又需要完成本端和对端数据同步怎么办呢,比如有A B C三个机房,只有A-B B-C有直接关联关系,而我们想要让A-C关联,这时候不可能说再建立一条物理链路,我们可以采用类似桥接的方式(或者叫隧道),同时关联A-B-C三个机房,其中B作为一个"网桥",再通过NAT技术完成IP地址转换,确保C可以识别从A过来的路由,而A-B B-C 正常采用对等网络的方式完成基础网络配置,这样就可以胯多个机房进行通信,由于是物理网络传输,机房间的耗时不会有很大差别(30ms内)。

由于网络细节的篇幅较多,我们不做详细的赘述,这里我们看看跨地域同步的网络架构(如下图所示)。

 

注:图中网段可以根据不同场景做划分,这里只做简单介绍。

6.4数据灾备能力、时效性提升

数据灾备:我们一般选择离各个证券交易所就近的一个接入点,比如上证选择在上海机房接入,深证选择在广州接入,纳斯达克在香港接入,每个接入点配置2条专线用做物理链路的主备,同时扩展一条互联网通路(注意这里的互联网也是直接和交易所对接,已经不是传统数据引入渠道)做次备,链路默认都是活跃状态,有专们的物理设备会根据专线的健康状况(自定义逻辑)自动切换。

最后,再根据上面提到的跨地域同步的原理,在云机房关联各条物理链路,在每条物理链路上抽象出独立的VPC,通过构建网络拓扑实现跨机房数据复制及灾备。

时效性:物理专线(光缆)接入方式天然的优势就是数据"即发即达",因为在固定带宽内基本不存在网络争用,而且现在大部分线路都会配置中继,其损耗带来的影响相对可控,因此接入方式就决定了数据传输的时效性。

相比传统互联网接入方式,单从数据上来看,专线接入SLA超过5个9(互联网接入2个9),当然也会配置上重传机制来进一步提升数据到达的可靠性。

交易所下发数据的数据频率按市场划分,A股一般3s/笔,港美股没有特殊限制,即有成交即下发,除去光损耗带来的影响,最快可以到3ms/笔,由于频率越高,对机器要求也越高,为此我们特殊做了一些限频操作,整体的数据时效性基本会在60ms(99.99+分位)内。

7、核心难点3

7.1概述

集群管理&单地域、跨地域流量调度。

流量调度生效在应用层,主要是找到一种高效的调度/负载方式来对内/外的业务提供数据支撑,从协议上/应用场景划分主要有TCP/HTTP,策略上因业务而异,主要还是基于对流量分配中权重的定义。

比如有基于RS健康检查的分配,每隔一段时间探测一下下游集群的健康状况来动态调整流量配比,也可以根据下游机器的连接数来分配,还可以基于对资源访问的热度来分配,区分单地域和跨地域场景如下面所述。

7.2单地域场景

现在各个云厂商都有相应的流量调度产品支撑,比如百度云上有BLB(Baidu Load Balance),可以很轻松构建一个调度规则出来,在BLB下可以设置调度集群的协议(TCP/HTTP),然后关联对应的服务器集群,最后给不同的服务器集群配置权重策略。

当流量进来时,BLB会帮我们完成自动分配,在某一个集群出现问题时,可以手动调整集群权重来干预流量配比,即所谓的切流。

7.3多地域场景

多个机房间的流量调度策略是在云上一般是隔离开的,当然我们可以在多个机房的最上层再抽象出一个专门的调度集群,对外暴露一个VIP。

在这个VIP上配置多个地域之间的调度关系,互联网公司基本上也都是这么做的,更多的是针对超大集群规模的场景,而且VIP的选取也是有条件/成本的。

但如果想低成本快速在云上创建一个能支持多地域同时访问且具备自动化流量调度的应用,且云上又不支持多地域共享VIP的功能时,我们可以尽可能多的基于云上已有的功能自己完成,在每个机房内部单独抽出一个类似nginx的集群,每个集群上维护着不同于本地域的调度关系,它们的下游就是不同于本机房的BLB,同时互相检查对方的健康状况并上报监控系统,这样当出现异常时,除了能针对性的在本机房内完成BLB级的流量调度,还能做到多机房间的流量切换,以提升机房间的灾备能力。当然,也需要有足够的容量。

 

8、总体设计

上图各个模块的作用如下(各模块均采用多路复用):

1)源数据接入集群:适配2种方式(互联网/物理专线)+各类协议(互联网、单播、组播)的数据源接入;

2)源数据转发集群:确保各机房源数据的一致性,降低由于业务服务本身带来的数据不一致问题;

3)数据解析集群:公共模块,主要是针对源数据进行统一的处理,以便转发给下游各业务;

4)业务数据集群(实时/延时流):负责将数据解析集群下发的内容转换成业务详细数据,也就是B端或C端用户看到的数据;

5)网关集群:负责承载用户访问流量;

6)监控集群:负责收集各个集群上报的日志情况,并作为稳定性管理手段之一。

可以看到:机房B相比其他机房,少了接入层配置,这主是基于成本和性能上考虑,把机房B当做数据传输枢纽,不仅能保证本机房数据传输,也能支持跨机房的数据同步&复制。该分布式传输系统从数据接入到监控集群,整体机器规模不大(100左右),但可支撑超过10亿的流量。

9、本文小结

一个良好的产品体验及产品矩阵,其背后一定离不开一个高可用、高时效的数据支撑,尤其是在金融领域,用户只可能会为一手的信息、完善的产品功能买单。

自21年完成数据通路建设以来,金融的稳定性和业务规模都有了质的飞跃,证券数据时效性问题从季度数十个降低到年度1个以内,99分位耗时更是从过去的分钟级降低到60ms以内,数据SLA从2个9左右提升至5个9以上,产品覆盖股票、外汇、基金、期货等诸多领域,也是第一个在搜索领域支持行情长连接的业务,基于搜索生态也孵化出来了像百度股市通PC站、app等多个独立端产品,目前正在结合AI能力进行持续优化,期望从完善用户体验->帮助用户决策进阶,也让金融投资变得更智能,更简单。

本文主要结合一个金融数据接入案例对分布式数据传输系统做了一个简单的介绍,包括传输系统中的一些核心节点的设计,如数据接入层的多协议适配、数据的分层管理以及跨地域的数据同步对应的网络拓扑等,通过实验得出结论,该方案能很好的应用在各种规模的分布式数据传输系统设计中。当然,由于篇幅问题,也省略了很多实现上的细节,读者有任何问题可以留言,可以一起探讨,也会尽量答复。

10、相关文章

[1] 技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解

[2] 以网游服务端的网络接入层设计为例,理解实时通信的技术挑战

[3] 知乎千万级并发的高性能长连接网关技术实践

[4] 手淘亿级移动端接入层网关的技术演进之路

[5] 喜马拉雅自研亿级API网关技术实践

[6] 石墨文档单机50万WebSocket长连接架构实践

[7] 小米小爱单机120万长连接接入层的架构演进

[8] B站基于微服务的API网关从0到1的演进之路

[9] 百度统一socket长连接组件从0到1的技术实践

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

11、其它百度技术分享

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

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

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

全面了解移动端DNS域名劫持等杂症:原理、根源、HttpDNS解决方案等

深入了解百度开源的分布式RPC框架brpc的方方面面

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

IM消息ID技术专题(五):开源分布式ID生成器UidGenerator的技术实现

百度统一socket长连接组件从0到1的技术实践

百度网盘千万节点的P2P架构设计(PPT) [附件下载]

即时通讯音视频开发(二十):一文读懂视频的颜色模型转换和色域转换

揭秘百度IM消息中台的全量用户消息推送技术改造实践

百度基于金融场景构建高实时、高可用的分布式数据传输系统的技术实践


(本文已同步发布于:http://www.52im.net/thread-4602-1-1.html

posted @ 2024-01-18 11:22 Jack Jiang 阅读(61) | 评论 (0)编辑 收藏

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

[- 1 -] IM开发干货分享:如何优雅的实现大量离线消息的可靠投递

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

[摘要] 本文作者将以自已IM开发过程中的真实总结,分享针对大量离线聊天消息,在确保用户端体验不降级的前提下,保证离线消息的可靠投递。


[- 2 -] IM开发干货分享:有赞移动端IM的组件化SDK架构设计实践

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

[摘要] 本文主要以Android客户端为例,记录了有赞旗下 App 中使用自研 IM,并将IM提炼成组件化SDK的设计思路。


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

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

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


[- 4 -] IM扫码登录技术专题(一):微信的扫码登录功能技术原理调试分析

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

[摘要] 本文将以轻松活泼的语言形式,为你分析和讲解微信手机扫码登录的技术原理,希望在你的IM中开发此功能时有所启发。


[- 5 -] IM扫码登录技术专题(二):市面主流的扫码登录技术原理调试分析

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

[摘要] 本文将简要的介绍扫码登录功能的技术实现逻辑,并实际结合淘宝、微信的扫码登录功能,学习和研究大厂主流应用的技术实现思路。


[- 6 -] IM扫码登录技术专题(三):通俗易懂,IM扫码登录功能详细原理一篇就够

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

[摘要] 最近刚好看到一个二维码的技术原理讲解视频,正好借此机会将扫码登录的详细技术原理梳理并总结一下,方便自已回顾,也希望能帮助到想在IM里开发类似功能的同行们。


[- 7 -] IM扫码登录技术专题(四):你真的了解二维码吗?刨根问底、一文掌握!

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

[摘要] 二维码技术使用起来很简单,本系列的前三篇文章也专门针对IM扫码登录这个功能做了详细的分享,但本着学习技术不留死角的习惯,我认为有必要单独学习一下到底什么是二维码。


[- 8 -] 理解IM消息“可靠性”和“一致性”问题,以及解决方案探讨

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

[摘要] 本文内容仅供参考,具体的解决方案请务结合自已的系统构架和实现情况,多阅读几篇即时通讯网上有关这个技术话题的文章,取其精华,找到适合自已的技术方案和思路才是最明智的。


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

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

[摘要] 本文总结了阿里闲鱼技术团队使用Flutter在对闲鱼IM进行移动端跨端改造过程中的技术实践等,文中对比了传统Native与现在大热的Flutter跨端方案在一些主要技术实现上的差异,以及针对Flutter技术特点的具体技术实现,值得同样准备使用Flutter开发IM的技术同行们借鉴和参考。


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

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

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


[- 11 -] IM全文检索技术专题(三):网易云信Web端IM的聊天消息全文检索技术实践

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

[摘要] 本文将具体来聊聊网易云信是如何实现IM客户端全文检索能力的,希望能带给你启发。


[- 12 -]  IM开发干货分享:万字长文,详解IM“消息“列表卡顿优化实践

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

[摘要] 本文将要分享是融云IM技术团队基于对自有产品“消息”列表卡顿问题的分析和实践(本文以Andriod端为例),为你展示一款IM在解决类似问题时的分析思路和解决方案,希望能带给你启发。


👉52im社区本周新文:《百度基于金融场景构建高实时、高可用的分布式数据传输系统的技术实践》,欢迎阅读!👈

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

posted @ 2024-01-17 12:01 Jack Jiang 阅读(50) | 评论 (0)编辑 收藏

本文由21CTO万能的大雄分享,本文有修订和改动。

1、引言

在当今快速发展的技术环境中,对跨平台桌面应用程序的需求正在不断激增。

开发人员面临着选择正确框架之挑战,以便可以高效构建可在 Windows、macOS 和 Linux 上无缝运行的应用程序。

在本文中,我们将比较五种流行的桌面应用程序开发框架:ElectronFlutterTauriReact Native  Qt,希望可以帮助你根据项目需求做出明智的技术选型决策。

 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4598-1-1.html

2、系列文章

本文是系列文章中的第10篇,本系列总目录如下:

IM跨平台技术学习(一):快速了解新一代跨平台桌面技术——Electron

IM跨平台技术学习(二):Electron初体验(快速开始、跨进程通信、打包、踩坑等)

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

IM跨平台技术学习(四):蘑菇街基于Electron开发IM客户端的技术实践

IM跨平台技术学习(五):融云基于Electron的IM跨平台SDK改造实践总结

IM跨平台技术学习(六):网易云信基于Electron的IM消息全文检索技术实践

IM跨平台技术学习(七):得物基于Electron开发客服IM桌面端的技术实践

IM跨平台技术学习(八):新QQ桌面版为何选择Electron作为跨端框架

IM跨平台技术学习(九):全面解密新QQ桌面版的Electron内存占用优化

IM跨平台技术学习(十):快速选型跨平台框架Electron、Flutter、Tauri、React Native等》(* 本文)

3、初识框架

1)Electron:

* 技术背景:Electron 由 GitHub 开发,因其使用 HTML、CSS 和 JavaScript 等 Web 技术构建跨平台桌面应用程序的能力而广受欢迎。

* 主要功能:Electron 通过其 Node.js 集成提供对本机 API 的轻松访问,使开发人员能够创建功能丰富的应用程序。它还支持用 C++ 编写的本机插件,尽管构建这些插件可能更复杂且容易出错。

2)Flutter:

* 技术背景:Flutter 由 Google 创建,以其在移动应用程序开发中的使用而闻名,但也可用于桌面应用程序。

* 主要特点:Flutter 提供了一组丰富的可定制 UI 小部件,其 Dart 代码被编译为本机机器代码,从而实现快速执行并减少开销。它采用独特的“基于小部件”架构,提供丰富的可定制 UI 小部件。

3)Tauri:

* 技术背景:Tauri 是一个较新的框架,旨在创建安全且轻量级的桌面应用程序。它旨在弥合 Rust 和 Web 技术之间的差距。

* 主要功能:Tauri 支持使用 Rust 或 C 构建本机插件,从而可以访问 Web 平台中不可用的本机 API 和功能。

4)React Native:

* 技术背景:React Native,同样来自 Facebook,主要以移动应用程序开发而闻名,但也有桌面应用程序开发的扩展。

* 主要功能:React Native 提供了一种访问本机 API 和功能的方法,但与其他框架相比,它可能需要更多的努力。它支持无缝集成第三方库。

5)Qt:

* 技术背景:Qt 是一个 C++ 框架,绑定了多种语言,包括 Python 和 JavaScript。这是一个历史悠久、历史悠久的框架。

* 主要功能:Qt 提供出色的本机集成功能,允许开发人员访问本机 API 和功能。它提供了一套用于构建跨平台桌面应用程序的全面工具,并强调本机外观和感觉。

4、跨平台能力

在跨平台功能方面,Electron、Flutter、Tauri 和 Qt 足以在多个操作系统上运行应用程序。它们为 Windows、macOS 和 Linux 提供广泛的支持,使其成为需要广泛兼容性的项目的合适选择。

React Native 虽然主要是为移动设备设计的,但可以扩展以创建桌面应用程序。然而,它的跨平台支持可能不像其他框架那样无缝,并且可能需要额外的努力才能在所有平台上实现一致的性能和 UI。

5、性能表现

性能是桌面应用程序开发的关键因素。

以下是这些框架的性能特征:

  • 1)Electron:以其较高的资源使用率而闻名,Electron 应用程序可能会占用更多内存和 CPU,从而影响较旧或功能较弱的计算机的性能;
  • 2)Flutter:Flutter 的性能值得称赞,这要归功于它的编译代码和 GPU 加速。它提供快速的启动时间和流畅的动画;
  • 3)Tauri:Tauri 因其轻量级特性和低资源消耗而脱颖而出。它是构建快速且响应灵敏的桌面应用程序的绝佳选择;
  • 4)React Native:React Native 桌面应用程序可以节省资源,但跨平台优化性能可能需要额外的工作;
  • 5)Qt:Qt 的性能非常出色,提供类似本机的速度和响应能力。它是资源密集型应用程序的首选。

6、用户界面

创建丰富且响应迅速的用户界面是桌面应用程序开发的一个重要指标。

以下是这些框架在 UI 功能方面的比较:

  • 1)Electron:Electron 提供了大量预构建的 UI 组件和广泛的主题选项。开发人员可以轻松创建具有视觉吸引力的应用程序;
  • 2)Flutter:Flutter 基于小部件的方法允许高度可定制且具有视觉吸引力的用户界面。它提供了广泛的开箱即用的小部件;
  • 3)Tauri:Tauri 不像其他框架那样提供那么多的 UI 组件,但允许对用户界面进行严格控制,这有利于创建独特的设计;
  • 4)React Native:通过React Native,开发人员可以使用第三方库和组件进行UI设计。可能需要额外的工作才能实现完全定制的外观;
  • 5)Qt:Qt 擅长提供与目标平台无缝集成的类似本机的 UI 元素。它是需要精美原生外观的应用程序的首选。

7、开发经验

流畅的开发工作流程对于生产力至关重要。

以下是这些框架在开发经验方面的比较:

  • 1)Electron:Electron 提供了一套广泛的开发工具和一个活跃的社区。调试和热重载得到良好支持;
  • 2)Flutter:由于其基于 widget 的架构和强大的文档,Flutter 的开发体验得到了简化。热重载是一个突出的功能;
  • 3)Tauri:Tauri 仍然相对较新,但使用 Rust 和 JavaScript 提供了简化的开发过程。它强调快速发展;
  • 4)React Native:React Native 为 Web 和移动开发人员提供了熟悉的开发体验。然而,过渡到桌面可能需要一个学习曲线;
  • 5)Qt:Qt 提供了一个成熟的开发环境,具有广泛的 IDE 和工具。它以其稳定性和全面的文档而闻名。

8、原生集成

访问本机平台功能和 API 对于许多桌面应用程序至关重要。

让我们看看这些框架如何处理本机集成:

  • 1)Electron:Electron 通过 Node.js 集成提供对本机 API 的轻松访问。它还支持用 C++ 编写的本机插件,尽管构建这些插件可能更复杂且容易出错;
  • 2)Flutter:Flutter 的 Dart 代码被编译为本机机器代码,从而实现快速执行并减少开销。它采用了一种称为“基于小部件”架构的独特方法,提供了一组丰富的可定制 UI 小部件;
  • 3)Tauri:Tauri 支持使用 Rust 或 C 构建原生插件,可用于访问 Web 平台中不可用的原生 API 和功能;
  • 4)React Native:React Native 提供了一种访问本机 API 和功能的方法,但与其他框架相比可能需要更多的努力。它支持无缝集成第三方库;
  • 5)Qt:Qt 提供出色的本机集成功能。它是一个 C++ 框架,绑定了多种语言,包括 Python 和 JavaScript,可用于访问本机 API 和功能。

9、社区与生态系统

开发人员社区的规模和活跃度,可以显着影响框架的成功和第三方库的可用性。

这些框架的表现如下:

  • 1)Electron:Electron 拥有一个庞大而活跃的社区,提供大量可用的插件和扩展;
  • 2)Flutter:Flutter 拥有不断增长的社区和越来越多的软件包,主要专注于移动开发,但也有桌面扩展;
  • 3)Tauri:Tauri 仍在成长,但其社区充满热情并致力于其发展。其生态系统正在稳步扩展;
  • 4)React Native:React Native 拥有完善的社区,主要专注于移动开发。桌面扩展社区规模较小,但正在不断增长;
  • 5)Qt:Qt 拥有悠久的历史和强大的生态系统,拥有庞大的工具、小部件和扩展库。

10、 框架们的成功案例

让我们探索一些现实世界的用例和使用这些框架构建的应用程序示例,以更好地了解它们在不同场景中的优点和缺点。

以下是具体的场景举例:

  • 1)Electron:广泛用于构建跨平台桌面应用程序,包括代码编辑器(VSCode)、通信工具(Slack)和娱乐应用程序(Spotify);
  • 2)Flutter:Flutter 逐渐成为富媒体应用程序的选择,已用于 Google Ads、阿里巴巴和 Reflectly 等应用程序;
  • 3)Tauri:Tauri 正在获得轻量级、安全应用程序的青睐,包括密码管理器 (LosePass) 和通信工具 (Mailspring);
  • 4)React Native:虽然主要是一个移动框架,但 React Native 已扩展到 Discord 和 Microsoft Teams 等应用程序中的桌面使用;
  • 5)Qt:Qt 是一种多功能选择,可用于从工业软件到游戏和汽车信息娱乐系统的广泛应用。

11、开发时的挑战

虽然每个框架都有其优点,但必须意识到潜在的挑战和限制。

比如这些:

  • 1)Electron:Electron 应用程序可能会占用大量资源,可能会导致旧硬件上出现性能问题;
  • 2)Flutter:如果您主要是移动开发人员,那么使用 Flutter 进行桌面开发可能会涉及一个学习曲线;
  • 3)Tauri:作为一个相对较新的框架,与更成熟的选项相比,Tauri 可能拥有较小的社区和较少的第三方库;
  • 4)React Native:将 React Native 转换到桌面可能需要额外的努力,并且某些特定于平台的功能可能更难访问;
  • 5)Qt:Qt 的学习曲线,特别是对于刚接触 C++ 的开发人员来说,可能是一个挑战。

12、本文小结

为桌面应用程序开发选择正确的框架很大程度上取决于项目的具体要求,例如目标平台、性能预期、UI 需求和所需的开发体验。

如果正在寻找一个允许你利用 Web 技术的框架,Electron和React Native是不错的选择。Electron 拥有庞大的社区和广泛的预构建组件,而 React Native 提供强大的组件系统,并允许在移动和桌面平台之间重用代码。

如果性能和小包大小是优先考虑的,请考虑Flutter或Tauri。Flutter 提供快速的启动时间和流畅的动画,而 Tauri 则以其轻量级和低资源消耗而闻名。

如果你需要一个具有出色本机集成和本机外观的框架,Qt是一个可靠的选择。

如果你正在开发需要丰富的、可定制的用户界面的复杂应用程序,Flutter可能是最佳选择,因为它基于 widget 的开发方法。

还请各位开发者要记住,请考虑与每个框架相关的学习曲线,特别是如果你或团队尚不熟悉所涉及的技术。比如,Tauri 需要 Rust 或 C 的前置知识,而 Flutter 使用 Dart 做为预备知识。

13、相关资料

[1] Electron官方开发者手册

[2] Flutter官方手册

[3] Tauri官方手册

[4] React Native开发指南

[5] QT官方文档和手册

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

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

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

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

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

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


(本文已同步发布于:http://www.52im.net/thread-4598-1-1.html

posted @ 2024-01-11 10:58 Jack Jiang 阅读(421) | 评论 (0)编辑 收藏

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

​[- 1 -] IM消息ID技术专题(一):微信的海量IM聊天消息序列号生成实践(算法原理篇)

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

[摘要] 如何优雅地解决“消息序列号只要保证顺序性而不需要兼顾唯一性”的问题呢?这就是本文所要分享的内容,强烈建议深入理解和阅读。


[- 2 -] IM消息ID技术专题(二):微信的海量IM聊天消息序列号生成实践(容灾方案篇)

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

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


[- 3 -] IM消息ID技术专题(三):解密融云IM产品的聊天消息ID生成策略

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

[摘要] 本文要分享的是融云即时通讯云产品中的聊天消息ID生成算法和策略,一个19字节的ID就能包含:时间戳、消息类型、会话ID、序列号,小ID、大用途,值得借鉴!


[- 4 -]IM消息ID技术专题(四):深度解密美团的分布式ID生成算法

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

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


[- 5 -] IM消息ID技术专题(五):开源分布式ID生成器UidGenerator的技术实现

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

[摘要] 本文是专题系列文章的第5篇,专门介绍百度开源的分布式消息ID生成器UidGenerator的算法逻辑、实现思路、重点源码解读等,或许能带给你更多的启发。


[- -] IM消息ID技术专题(六):深度解密滴滴的高性能ID生成器(Tinyid)

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

[摘要] 本文将要分享的是滴滴开源的分布式ID生成器Tinyid的技术原理、使用方法等等,希望能进一步为你打开这方面的技术视野。


[- 7 -] IM消息ID技术专题(七):深度解密vivo的自研分布式ID服务(鲁班)

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

[摘要] 本文通过对分布式ID的3种应用场景、实现难点以及9种分布式ID的实现方式进行介绍,并对结合vivo业务场景特性下自研的鲁班分布式ID服务从系统架构、ID生成规则与部分实现源码进行分享,希望为本文的阅读者在分布式ID的方案选型或技术自研提供参考。


[- 8 -] IM开发宝典:史上最全,微信各种功能参数和逻辑规则资料汇总

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

[摘要] 本文将根据微信官方目前已公开的资料,将它的一些常用功能参数和逻辑规则资料进行了汇总整理,希望能助力你的IM开发!


[- -]  IM开发干货分享:我是如何解决大量离线消息导致客户端卡顿的

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

[摘要] 今天这篇不是原理性文章,而是为大家分享一下由笔者主导开发实施的IM即时通讯聊天系统,针对大量离线消息(包括消息漫游)导致的用户体验问题的升级改造全过程。


[- 10 -] 零基础IM开发入门(一):什么是IM系统?

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

[摘要] 本系列文章将尽量从理论概念入手,通俗易懂的梳理IM中的基础技术概念和热门技术点,希望能帮你理清看似一团乱麻的IM知识体系,助你找到清晰的IM技术学习方向。


[- 11 -] 零基础IM开发入门(二):什么是IM系统的实时性?

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

[摘要] 对于技术门外汉来说,到底什么是IM的“实时性”?该如何理解它?这就是本文想要讨论的主题。


[- 12 -] 零基础IM开发入门(三):什么是IM系统的可靠性?

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

[摘要] 本篇主要讲解IM系统中的“可靠性”这个话题,内容尽量做到只讲原理不深入展开,避开深层次的技术性探讨,确保通俗易懂。


[- 13 -] 零基础IM开发入门(四):什么是IM系统的消息时序一致性?

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

[摘要] 本文尽量以通俗简显的文字为你讲解IM消息时序一致性问题的产品意义、发生原因、解决思路等。


👉52im社区本周新文:《IM跨平台技术学习(十):快速对比跨平台框架Electron、Flutter、Tauri、React Native等》,欢迎阅读!👈

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

posted @ 2024-01-10 13:24 Jack Jiang 阅读(60) | 评论 (0)编辑 收藏

本文由字节跳动技术团队李晨光、匡建鑫、陈鉴平分享,本文有修订和改动。

1、引言

新媒体互动直播已成为了广大网民最重要的休闲娱乐方式之一。丰富的传统文化、新闻、竞技体育、法律、知识共享等内容,通过移动端互动直播的形式得以更加高效的展现传播,既让优质的直播内容可以实现爆发式传播扩散,又可以让用户有更多的机会感受,学习甚至主动参与直播互动。超低延时视频直播技术正在走上一条全新的发展之路。

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

 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4587-1-1.html

2、系列文章

本文是系列文章中的第 11 篇,本系列总目录如下:

3、低延时直播技术的作用

网络基础设施升级、音视频传输技术迭代、WebRTC 开源等因素,驱动音视频服务时延逐渐降低, 使超低延时直播技术成为炙手可热的研究方向。实时音视频业务在消费互联网领域蓬勃发展, 并逐渐向产业互联网领域加速渗透。经历了行业第一轮的红利爆发期,我国实时音视频行业的场景效能逐渐深化,步入到理性增长阶段。

延时的指标选择很大程度上取决于用户与内容制作方的交互耦合程度,场景丰富多样。

在这些极端场景下,延时在用户侧希望越小越好,接近于实时通信的低延迟模式可以最大化地激发用户的参与感,无缝地与内容生产方产生互动效应,调动用户所见即所得的积极性。比如在主播秀场的PK、送礼、工会冲榜、打赏的活动关键环节,竞争双方的储值大户都希望实时地观察到自身主播在礼物刷榜后的反应,为后台运营决策团队或者后续活动策略提供第一时间的信息反馈。

下图体现了从技术/产品/运营的三方角度来综合思考低延时直播技术的作用;从外部-内部综合因素考虑技术的变迁对整个生态正向循环的影响。

4、传统直播技术中RTMP协议的延迟问题

RTMP 协议是最传统的直播协议,主播端采用 RTMP 协议推送 H.264/5 和 AAC 编码的视音频数据到云厂商 CDN 服务器进行转封装分发,端到端延迟一般控制在 3 到 7 秒。

问题是 RTMP 的可扩展性存在缺陷,同时对于延迟的进一步下探存在一定的技术困难。

RTMP 协议情况下:为了满足延时降低必然压缩播放器的下载缓冲区,这样会引发显著的卡顿问题,使得播放的观感产生不舒适的感受(延时下探至 2 秒以下)。

5、传统直播技术在实时互动场景中的不足

1)视频延时和弹幕交互的延时存在显著差异,问题聊天内容互动与视频传输图像节奏不匹配:

2)观众与主播互动形式单一,是单向内容传导无法做到双向(在 RTC 技术引入之前无法显著解决)。

3)单向传导的局限第一个方面表现在:观众端拉流传输无法做到根据网络情况自适应调节。用户只能以固定的码率进行流媒体传输无法做到动态感知,在网络情况实时变化的场景(比如弱网,移动基站切换等)固定单向码率传输有较大概率造成丢帧卡顿等因素影响观播体验。另一方面在网络条件更好时,固定码率传输无法动态提升视频传输码率(更高的画质带来更加舒适的体验)

4)在直播和连麦场景共存的互动直播场景下,主播采用传统RTMP推流在遇到连麦PK场景时,会产生推流/本地连麦合流/服务器连麦合流的切换问题,这种场景变换的切换会使得观众端产生瞬间的卡顿问题。如果采用基于webRTC直播技术的超低延时直播方案,这种推流--连麦逻辑的合流切换问题可以得到比较友好的解决(只需要改变服务器转发-订阅流通道的分发逻辑,不涉及推流媒体数据流的旁路调度切换)。

6、 超低延时直播与标准直播的区别

6.1超低延时直播

超低延时直播是近年来新兴起的一类应用。

如电商直播、赛事直播等场景,兼具高并发与低延时的特性,传统直播 3-20s 的时延难以满足其需求,但对实时互动的要求又不及视频会议等典型的实时音视频应用,无需将时延降低至 400ms 以下。

为此,超低延时直播融合了传统直播与实时音视频的技术架构,通过取长补短的方式实现了介于二者之间的端到端时延。

尽管针对超低延时直播厂商尚无一套标准的技术路径,但大体可以归纳为拉流协议、网络架构和推流协议三个方面的改造, 在实际应用过程中,厂商会平衡成本及性能指标等因素,在不同的协议和网络架构之间进行选择。

6.2传输层协议的差异

基于 UDP 协议的可靠性优化,为弱网对抗策略提供依据。

传统直播 FLV/RTMP 等采用的是 TCP 协议(或者 QUIC 协议)TCP 是牺牲传输实时性来换取数据完整性的可靠传输协议。

弱网环境下,其在数据传输前的“三次 握手”连接会带来较大延时。

而 UDP 作为不可靠的传输协议,其最大的优点为高实时性,但不保证数据的到达和排序。

实时音视频 产品(如 RTM 超低延时直播)往往采用 UDP 协议,并在此之上进行协议层与算法层的优化,来提高传输的可靠性与逻辑性。

相关文章可阅读:

  1. 网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势
  2. 技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解
  3. 不为人知的网络编程(六):深入地理解UDP协议并用好它
  4. 不为人知的网络编程(七):如何让不可靠的UDP变的可靠?

6.3UDP 协议的优化

UDP 协议往往和 RTP/RTCP 协议一起在实际应用中出现。

RTP 负责数据传输,其协议头中的序列号、 端口类型、时间戳等字段,可为数据包的分组、组装、排序提供逻辑依据。

RTCP 作为 RTP 的控制协议,负责对 RTP 的传输质量进行统计反馈,并为弱网对抗策略提供控制参数。

7、RTM 协议本身的演进历程

a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp"

a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime"

a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range

a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type

a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp

a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-config

RTP 使用 RTP 私有扩展头携带 DTS/CTS 值,每一帧 RTP 数据包通过 RFC5285-Header-Extension 扩展头携带该帧的 DTS 值,每一帧首个 RTP 包和 VPS/SPS/PPS 包通过 RFC5285-Header-Extension 扩展头携带该帧的 CTS 值,通过 PTS = DTS + CTS 计算当前帧的时间戳。用于启播快速音画同步和播放器播控逻辑精准音画同步。

扩展头携带帧的起始/结束序号:如果首帧的前几个包丢失,那么可根据起始序号快速发起重传加快首帧;如果当前帧的后几个包丢失,那么可根据该帧的结束序号快速发起重传,降低延时,减少卡顿。

扩展头携带帧的类型:如果携带并解析了正确的帧类型,客户端可以不用解析 metadata ;同时在弱网情形,客户端可以跳过 B 帧直接解码 P 帧,加速出帧并减少潜在卡顿。

扩展头携带 P 帧的参考帧信息:如果发生弱网情形,那么客户端可以依照扩展头指定的参考帧关系及其对应时间戳,跳过 B 帧解码 ,减少卡顿发生。

为了加速信令交互的速度,CDN 可以在某些条件下不去查询媒体信息,直接向客户端返回支持的音视频能力;此时 SDP 的媒体描述中将不包含有具体的音视频配置详细信息。在音频层面,此时AnswerSDP 中不包含 aac 解码所需的头信息;此时我们需要采取 RTP 扩展头模式携带 AAC-Config 供客户端在 RTP 收包时刻自行解析处理完成解码动作,作用是减少信令交互时间,提升拉流成功率。

miniSDP 信令标准实现部分(抖音)。

CDN 信令异步回源。

RTP 携带扩展头组成部分。

8、WebRTC 协议在直播播放器的移植

RTM 低延时直播基于 WebRTC 技术衍生,基于 WebRTC 标准构建点到点传输一般有如下几个步骤:

  • 1)通信双方要进行媒体协商,会话详细规范即 SDP(Session Description Protocol) 交互;
  • 2)随后进行交互式网络地址协商(查询对端真实 IP 地址)准备构建媒体传输通道;
  • 3)当上述条件准备完毕即进入最终的 Peer to Peer 点对点媒体数据传输。

信令部分客户端-服务器单独开发,利用了 SDP 标准报文模式。媒体传输部分采用开源的 WebRTC 框架和字节自研的实时音视频媒体引擎进行媒体传输。

9、RTC 信令协议的改造升级

MiniSDP压缩协议:https://github.com/zhzane/mini_sdp

标准 SDP 比较冗长(5-10KB 左右),不利于快速高效传输。在直播场景下,会尤其影响首帧时间。

MiniSDP 对标准 SDP 文本协议进行高效能压缩,将原生 SDP 转换成更小的二进制格式,使其能够通过一个 UDP 包来传输。

降低信令交互时间,提高网络传输效能,降低直播拉流首帧渲染时间,提高拉流秒开率/成功率等 QoS 统计指标。

10、CDN对RTM 信令的异步回源优化

降低 RTM 信令交互时间,降低 RTM 拉流首帧渲染时间。

原来的流程在服务端缓存不命中时需要等待回源拿到数据,才能返回带有 AacConfig 信息的 AnswerSDP。客户端收到 AnswerSDP 后发送 STUN,而服务端只能在收到 STUN 才能开始下发数据。

如下图左:当异步回源情况下,服务端不再等待回源结果直接返回 AnswerSDP,之后回源和WebRTC 建连流程同步进行。

如上图右:等到 WebRTC 建连成功且回源拿到数据立即下发 RTP 数据。

11、视频渲染卡顿的优化(百秒卡顿平均降低4秒)

改善人均看播时长,改变 RTC 引擎的组帧/解码策略;禁止 RTC 在低延时模式下的丢帧,改善直播的视频渲染卡顿。

传统的 RTC 场景优先保时延,全链路会触发各种丢帧(包括但不限于解码模块,网络模块),FLV 直播场景会优先保证观播体验(不丢帧,良好的音画同步效果)。

RTM 要想减少卡顿,取得 qoe 的收益,播控策略需进行定制化,定制逻辑修改点:

1)确保不会由于软解的解码耗时或者硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer ,内核层有一层强制的音画同步逻辑,可以确保音视频的播放体验;

2)同时上层在监控网络模块和解码模块的缓存长度,有相应的兜底逻辑:

  • a. 判断硬解确实解不过来,dec_cache_frames 过多,上报错误,会降级到软解;
  • b. jitterbuffer 异常,缓存的 frame_list 过多,触发播放器异常逻辑,上报错误,重新拉流。

12、RTM播控逻辑的优化

改善移动端看播渗透,RTC 统一内核方案天生存在缺陷( MediaCodec 硬件解码器初始化耗时久)。将 RTM 视频解码模块从 RTC 内核中迁移至 TTMP 播放内核,复用了 FLV 的视频解码模块( MediaCodec 避免重新初始化)。显著的降低了安卓平台的首帧渲染时间,提升了拉流的成功率。

RTC 内核通用逻辑:

改进的 RTM 内核播控逻辑:

13、相关文章

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

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

[3] 零基础入门:基于开源WebRTC,从0到1实现实时音视频聊天功能

[4] 实时音视频入门学习:开源工程WebRTC的技术原理和使用浅析

[5] 零基础快速入门WebRTC:基本概念、关键技术、与WebSocket的区别等

[6] 学习RFC3550:RTP/RTCP实时传输协议基础知识

[7] 基于RTMP数据传输协议的实时流媒体技术研究(论文全文)

[8] 技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解

[9] 让互联网更快:新一代QUIC协议在腾讯的技术实践分享

[10] 实时音视频面视必备:快速掌握11个视频技术相关的基础概念

[11] 实时音视频开发理论必备:如何省流量?视频高度压缩背后的预测技术

[12] 移动端实时音视频直播技术详解(一):开篇

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

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

[15] 视频直播技术干货:一文读懂主流视频直播系统的推拉流架构、传输协议等

(本文已同步发布于:http://www.52im.net/thread-4587-1-1.html

posted @ 2024-01-04 11:45 Jack Jiang 阅读(123) | 评论 (0)编辑 收藏

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

​[- 1 -] 全面掌握移动端主流图片格式的特点、性能、调优等

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

[摘要] 本文我们一起全面分析学习目前主流和新兴的几种图片格式的特点、性能、调优等,以及相关开源库的选择,希望能为您的移动端应用(包括本社区主要讨论的即时通讯应用)中的图片优化带来一些启发。


[- 2 -] 最火移动端跨平台方案盘点:React Native、weex、Flutter

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

[摘要] 本篇主要以react-native、weex、flutter,深入聊聊当前最火的这3种跨平台移动开发方案的实现原理、现状与未来。至于为什么只讲它们,因为对比ionic、phoneGap,它们更于 “naive” (˶ ⁻̫ ˵)。看完本篇,相信你会对于当下跨平台移动开发的现状、实现原理、框架的选择等有更深入的理解。


[- 3 -] 子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践

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

[摘要] 本文内容来自对网易云信首席架构师周梁伟的采访,采访内容主要围绕网易云信这种海量用户IM云平台的关键技术难点以及对应的技术实践。


[- 4 -] IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列

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

[摘要] 消息是互联网信息的一种表现形式,是人利用计算机进行信息传递的有效载体,比如即时通讯网坛友最熟悉的即时通讯消息就是其具体的表现形式之一。


[- 5 -] 微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)

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

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


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

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

[摘要] 阿里数据库事业部研究员张瑞,将为你讲述双11数据库技术不为人知的故事。


[- 7 -] 自已开发IM有那么难吗?手把手教你自撸一个Andriod版简易IM (有源码)

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

[摘要] 本文不是一篇即时通讯理论文章,文章内容全部由实战代码组织而成。


[- 8 -] 融云技术分享:解密融云IM产品的聊天消息ID生成策略

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

[摘要] 本文要分享的是融云即时通讯云产品中的聊天消息ID生成算法和策略,一个19字节的ID就能包含:时间戳、消息类型、会话ID、序列号,小ID、大用途,值得借鉴!


[- -]  IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!

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

[摘要] 本文将分析传统数据库(即SQL数据库)存在的一些问题,以及盘点目前市面上几大类 NoSQL 特性、优缺点等,希望给大家提供一些在不同业务场景下存储技术选型方面的参考。


[- 10 -] 适合新手:从零开发一个IM服务端(基于Netty,有完整源码)

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

[摘要] 本文写的比较浅显但不太易懂,建议结合代码一起来读,文章配套的完整源码请从本文文末 “11、完整源码下载” 处下载!


[- 11 -] 拿起键盘就是干:跟我一起徒手开发一套分布式IM系统

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

[摘要] 本文记录了我开发的一款面向IM学习者的 IM系统——CIM(全称:CROSS-IM),同时提供了一些组件帮助开发者构建一款属于自己可水平扩展的 IM。


[- 12 -] 适合新手:手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)

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

[摘要] 本文适合有一定网络通信技术基础的IM新手阅读。如果你对网络编程,以及IM的一些理论知识知之甚少,请务必首先阅读:《新手入门一篇就够:从零开发移动端IM》,按需补充相关知识。


[- 13 -] IM里“附近的人”功能实现原理是什么?如何高效率地实现它?

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

[摘要] 本文将简要的为你讲解“附近的人”的基本理论原理,并以Redis的GEO系列地理位置操作指令为例,理论联系实际地为你讲解它们是如何被高效实现的。


[- 14 -] IM开发基础知识补课(七):主流移动端账号登录方式的原理及设计思路

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

[摘要] 本文将分享几种典型的移动端账号登陆方式的技术原理,以及设计思路,理解后,完全可以快速实施于你的各种应用系统(并不限于IM系统)中。


[- 15 -] IM“扫一扫”功能很好做?看看微信“扫一扫识物”的完整技术实现

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

[摘要] 本文将详细为你解密微信“扫一扫识物”功能背后的技术秘密。


[- 16 -] IM要做手机扫码登录?先看看微信的扫码登录功能技术原理

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

[摘要] 本文将以轻松活泼的语言形式,为你分析和讲解微信手机扫码登录的技术原理,希望在你的IM中开发此功能时有所启发。


👉52im社区本周新文:《视频直播技术干货(十一):超低延时视频直播技术的演进之路》,欢迎阅读!👈

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

posted @ 2024-01-03 11:57 Jack Jiang 阅读(19) | 评论 (0)编辑 收藏

     摘要: 本文由字节跳动技术团队杨晨曦分享,本文有修订和改动。1、引言本文将带你一起初步认识Thrift的序列化协议,包括Binary协议、Compact协议(类似于Protobuf)、JSON协议,希望能为你的通信协议格式选型带来参考。  技术交流:- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》- 开源IM框架源码:https://github.com/JackJ...  阅读全文

posted @ 2023-12-28 10:52 Jack Jiang 阅读(61) | 评论 (0)编辑 收藏

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

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

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

[摘要] 到底是“登陆”还是“登录”?这是很多处女坐开发者纠结的问题,不过它不是本文本讨伦的内容。本文将针对移动端IM的登陆功能给出相应的优化建议。


[- 2 -] 移动端IM登录时拉取数据如何作到省流量?

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

[摘要] 移动网络时代,手机的流量是个很昂贵的资源(至少暂时是这样)。一个典型的移动端IM在登录后,往往要向服务器同步非常多的数据,如果处理的不好是很费流量的,那么从技术上来讲,有没有节省流量的方法呢?这就是本文要讨论的话题。


[- 3 -] 浅谈移动端IM的多点登录和消息漫游原理

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

[摘要] 本文将展开聊聊移动端IM“多点登陆”与“消息漫游”的原理。


[- 4 -] 完全自已开发的IM该如何设计“失败重试”机制?

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

[摘要] 如何设计好这个失败重试的机制,使得客户端能做好失败重试,服务器有能够排除这种重复消息,但是排重处理不太复杂?


[- 5 -] 通俗易懂:基于集群的移动端IM接入层负载均衡方案分享

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

[摘要] 本文将以基于TCP数据传输协议的移动端IM为例,通过循序渐进地方式,分享如何构建一个基于分布式集群的移动端IM接入层的设计和实现。


[- -] 微信对网络影响的技术试验及分析(论文全文)

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

[摘要] 本文来自论文《微信对网络影响的技术试验及分析》,文中研究了微信对现今移动网络的影响,对于即时通讯开发人员来说,文中的某些数据和研究结果,对于实现类似的技术,有一定的参考和借鉴意义。即时通讯网(52im.net)现全文收录之。


[- 7 -] 即时通讯系统的原理、技术和应用(技术论文)

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

[摘要] 首先,介绍即时通信的概念、特点和技术原理,较为全面地剖析了实现即时通信系统涉及的关键技术,包括即时通信传输协议、相关安全技术和音/视频编解码技术等;其次,简要概述了即时通信系统在我校的应用情况;最后,说明当前即时通信工具存在的问题及其发展趋势。


[- 8 -] 开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀

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

[摘要] 本文将简要介绍TeamTalk开源的过去和现在,为打算研究和采用TeamTalk的同行提供一定程度的参考。文中所涉及内容如有不妥,还请各位看官见谅。


[- -]  QQ音乐团队分享:Android中的图片压缩技术详解(上篇)

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

[摘要] 实际在生产环境下,群消息的发送都会想尽办法进行压缩,并开展各种改善性能的处理办法,而不是像上述举例里的直接扩散写(即2000人群里,一条消息被简单地复制为2000条一对一的消息投递)。具体有哪些优先策略?本文或许可以带给你一些启发。


[- 10 -] QQ音乐团队分享:Android中的图片压缩技术详解(下篇)

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

[摘要] 关于压缩图片在诸如即时通讯应用场景下的好处,我们就不再赘述,不言自明。本篇将承接上篇《QQ音乐团队分享:Android中的图片压缩技术详解(上篇)》,继续讨论图片的尺寸压缩和常用的几种尺寸压缩算法。


[- 11 -] 腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率

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

[摘要] 本文内容是由腾讯TMQ专项测试团队针对手机QQ图片上传速度和成功率问题,在各种复杂移动网络环境下的优化实践总结和整理而成。文章虽是针对手机QQ图片上传这一特定业务功能,但内容中大量涉及复杂移动网络环境下无线网络的特性、特点以及相关第一手测试数据,都是非常珍贵的,尤其值得移动端IM开发、消息推送这种深度依赖移动网络的应用开发者借鉴和参考。


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

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

[摘要] 本文将给读者们一个一年多以前为公司的某产品成功优化网络流量的案例。速度、成功率与流量正好是 Apps 网络优化的几大重点,希望本文我们分享的思路能够给诸位正在开展或将来会开展此类工作的读者们一些启发。


[- 13 -] 腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(下篇)

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

[摘要] 本篇中将详细介绍我们的具体分析方法和实践优化思路,以及在优化过程中总结出来的法则等。


[- 14 -] 如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源

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

[摘要] 本文正文内容引用了微信开发团队的资料。


[- 15 -] 基于社交网络的Yelp是如何实现海量用户图片的无损压缩的?

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

[摘要] 研究Yelp的极致图片压缩技术,或许能给即时通讯开发者同行带来一定的借鉴意义,而这也是此文的意义所在。


[- 16 -] 腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)

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

[摘要] 本次文章跟大家分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。


[- 17 -] 腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

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

[摘要] 本文接上篇《腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》,继续腾讯公司分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。


[- 18 -] 为什么说即时通讯社交APP创业就是一个坑?

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

[摘要] 所以今天,我将尽量试着以用户的眼光,去描述这样一种现实:什么拳打QQ、脚踩微信,自嗨式的创业就像浮云一样......


👉52im社区本周新文:《IM通讯协议专题学习(十):初识 Thrift 序列化协议》,欢迎阅读!👈

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

posted @ 2023-12-27 15:23 Jack Jiang 阅读(57) | 评论 (0)编辑 收藏

本文由冰河分享,作者博客 binghe.gitcode.host,原题“这套分布式IM即时通讯系统如何写到简历上?我给你整理好了!”,本文有修订和改动。

1、引言

分布式IM即时通讯系统本质上就是对线上聊天和用户的管理。

针对聊天本身来说,最核心的需求就是:发送文字、图片、文件、语音、视频、消息缓存、消息存储、消息未读、已读、撤回,离线消息、历史消息、单聊、群聊,多端同步,以及其他一些需求。

对用户管理来说,存在的需求包含:添加好友、查看好友列表、删除好友、查看好友信息、创建群聊、加入群聊、查看群成员信息、退出群聊、修改群昵称、拉人进群、踢人出群、解散群聊、填写群公告、修改群备注以及其他用户相关的需求等。

为了更好的理解分布式IM即时通讯系统的设计,我站在架构师的角度,在充分了解系统需求、业务流程和技术流程后,从全局视角为系统设定方案目标,对技术方案进行选型,对系统进行总体架构设计和分层架构设计,并梳理清楚发送消息的交互链路、单聊和群聊的交互链路。希望对你有帮助。

 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4564-1-1.html

2、方案目标

在进行技术选型与总体架构设计之前,需要明确一个事项,就是系统无论采用哪种方案,采用哪种架构设计都需要明确这种方案的业务目标、技术目标和架构目标,并在研发过程中不断评估系统的总体性能表现,发现系统瓶颈并不断进行优化。

总体上,我们搭建和开发的分布式IM即时通讯系统,需要满足如下方案目标。

具体是:

  • 1)业务目标:满足需求设计篇章中的各类需求场景;
  • 2)技术目标:支持无限扩容,百万用户同时在线聊天;
  • 3)架构目标:高并发、高性能、高可用、可监控、可预警、可伸缩,支持无限扩展。

3、技术选型

在技术选型上,除了采用SpringBoot等基础框架外,也会采用容器化方案。

同时,考虑到为了尽量降低技术门槛,在整个分布式IM即时通讯系统的技术选型中,主要采用市面上比较流行的技术框架和方案。

具体选型如下所示:

  • 1)开发框架:SpringBoot、SpringCloud、SpringCloud Alibaba、Dubbo;
  • 2)缓存:Redis分布式缓存+Guava本地缓存;
  • 3)数据库:MySQL、TiDB、HBase;
  • 4)流量网关:OpenResty+Lua;
  • 5)业务网关:SpringCloud Gateway + Sentinel;
  • 6)持久层框架:MyBatis、Mybatis-Plus;
  • 7)服务配置、服务注册与发现:Nacos;
  • 8)消息中间件:RocketMQ;
  • 9)网络通信Netty
  • 10)文件存储:Minio;
  • 11)日志可视化治理:ELK;
  • 12)容器化管理:Swarm、Portainer;
  • 13)监控:Prometheus、Grafana;
  • 14)前端:Vue;
  • 15)单元测试:Junit;
  • 16)基准测试:JMH;
  • 17)压力测试:JMeter。

4、初步架构设计

对于IM即时通讯系统来说,涵盖了即时通讯后端服务、大后端平台、SDK接入服务、OpenAI接入服务、大前端UI,我相信不少小伙伴多多少少能够画出IM即时通讯系统的架构图,大致如下图所示。

 

其实,这种这种架构设计也比较常见,在这种架构设计中,Kong/Openresty/Nginx只做负载均衡和反向代理,研发人员更多的是关注业务层和基础层的开发,流量比较小时,这种架构设计一般不会有什么问题。但是一旦流量比较大,用户调用后端平台的接口发送消息时,即时通讯SDK同步调用即时通讯服务的接口就会出现性能问题。

因为每个终端同时只能与一个IM即时通讯服务实例建立连接,如果大量的用户终端恰好都与一个IM即时通讯服务建立连接,那即时通讯SDK频繁同步调用同一个IM即时通讯服务的接口就会出现性能瓶颈。此时,出现性能瓶颈时,不仅仅会影响到IM即时通讯服务,也会对后端平台接收请求的业务造成一定的影响。

5、架构设计优化

既然上节图中所示的架构设计存在性能瓶颈,那我们如何进行优化呢?

为此我们在前图基础上进行了优化,优化后的架构如下图所示。

对比两图可以看出,在屏蔽掉技术实现细节的前提下,我们将对业务的校验和流量管控进行前置化,放大Kong/OpenResty/Nginx的职责,使得这些软件不仅具备反向代理和负载均衡的功能,还能实现限流、黑白名单、流量管控、业务校验等功能。

也就是说,在这种架构模式下,我们充分发挥了整个分布式IM即时通讯系统的入口职责,充分利用Kong/OpenResty/Nginx的高并发、高吞吐量的能力,尽量将大部分无效请求挡在整个系统之外。例如,用户在没登录系统的前提下,就尝试调用发送消息、添加好友、添加群组等等接口。这样会大大减轻后台平台的业务压力。

除了在Kong/OpenResty/Nginx中实现限流、黑白名单、流量管控、业务校验等功能外,我们还引入了业务网关集群,实现限流、降级、熔断、流控、校验、鉴权等功能,进一步保证下游系统的稳定性和安全。

为了解决大量用户终端恰好连接到同一个IM即时通讯服务实例,IM即时通讯SDK频繁调用同一个IM即时通讯服务实例的接口造成的性能问题。我们在IM即时通讯服务SDK与IM即时通讯服务之间引入了RocketMQ集群。

IM即时通讯服务集群中的每一个IM即时通讯服务实例在集群中都有一个唯一的ID,并且每个IM即时通讯服务实例在启动后,只会监听RocketMQ中与自身ID相关的Topic。这样每个IM即时通讯服务只会收到与自身ID相关的Topic中的消息,不会接收所有的消息。

当用户登录系统后,就会与IM即时通讯服务建立长连接,并且会以用户ID和终端为Key,以IM即时通讯服务的ID为value,将其存储到分布式缓存中。同时,会以用户ID和终端为Key,以用户终端与IM即时通讯服务建立的长连接为value,将其存储到IM即时通讯服务本地内存中。

当用户调用后端平台的接口发消息时,会带上目标用户的ID,并且在IM即时通讯SDK中会指定用户登录的终端设备,最终会通过IM即时通讯SDK向RocketMQ发送消息。

此时IM即时通讯SDK会根据目标用户ID和终端从分布式缓存中获取目标用户连接的IM即时通讯服务的ID,并向此ID相关的Topic发送消息。此时与目标用户建立长连接的IM即时通讯服务就会接收到RocketMQ中的消息,随后根据用户ID和终端从本地缓存中获取到与用户终端建立的长连接,并基于此长连接向用户推送消息。

另外,在实际实现中,为了避免大量用户同时只连接IM即时通讯服务集群中的某一个服务实例,会对用户连接的IP、浏览器指纹、手机设备等做Hash和取模运算,使其尽量均匀分布到集群中的每一个服务实例上。

那么问题来了,这种架构设计还有进一步优化的空间吗?

6、容器化架构设计

为进一步增强分布式IM即时通讯系统的性能、可用性和弹性伸缩能力,我们可以对分布式IM即时通讯系统进行容器化架构设计,如下图所示。

可以看到,我们对分布式IM即时通讯系统的架构设计进行了进一步优化,采用了容器化架构设计。在原有架构的基础上,我们进行了如下改进和优化。

1)基础支撑服务:基础支撑服务会由各种基础中间件、数据存储服务、以及监控服务实现,包含:MySQL数据库、TiDB数据库、HBase、Redis缓存、RocketMQ消息队列、Prometheus监控和Portainer容器管理等基础中间件实现,基础支撑服务会对整个分布式IM即时通讯系统提供最基础的数据、传输、监控和容器管理等服务。

2)容器化:在容器化层面,会通过Docker、Swarm和Portainer实现,其中,会基于Swarm和Portainer对容器化进行管理。

3)其他基础性功能实现:除了上述分层架构外,对于建设分布式IM即时通讯系统来说,还要考虑异常监控、服务注册与发现、可视化、服务降级与兜底数据、服务限流、服务容灾、容量规划与扩缩容和全链路压测等。

7、DDD分层业务架构设计

在分布式IM即时通讯系统中,不管是大后端平台,还是IM即时通讯服务,我们都会对业务层的代码采用分层业务架构。

这里,可以借鉴DDD的分层架构思想,将代码总体上分成展示层、应用层、领域层和基础设施层四个层次。

但是,考虑到分布式IM即时通讯系统的特殊性,又不会严格按照DDD的原则来设计代码分层,具体按照如下图所示。

可以看到,分布式IM即时通讯系统会借鉴DDD的设计思想,但是不会完全按照DDD的方式进行设计。

1)展示层:展示层,也叫做用户UI层,是DDD设计的最上层,对外提供API接口,接收客户端请求,解析参数,返回结果数据,并对异常进行处理。

2)应用层:应用层,也叫做Application层,应用层主要处理容易变化的业务场景,可对相关的事件、调度和其他聚合操作进行相关的处理。

3)领域层:领域层,也叫做Domain层,领域层可以说是DDD设计的精髓所在,它是将业务系统中相对不变的部分抽象出来封装成领域模型。在分布式IM即时通讯系统的设计中,领域层基本不会依赖其他层,也不会依赖基础设施层,这里是与DDD设计存在区别的地方。

4)基础设施层:基础设施层,也叫做Infrastructure层,基础设施层会对其他各层提供通用的基础能力,在分布式IM即时通讯系统中,就包括了缓存、通用工具类、消息、系统的持久化机制等。

8、总体IM消息交互链路

在分布式IM即时通讯系统中,我们忽略掉其他一些细节信息,重点关注下发送消息的交互链路逻辑。不管是单聊还是群聊,最终都需要通过IM即时通讯服务将消息推送给用户的终端。此时发送消息的流程如下图所示。

可以看到:用户在分布式IM即时通讯系统发送消息时,不管是单聊还是群聊,最终的消息都会推送到用户登录的终端设备上。假设此时用户A给用户B发送消息,或者用户A和用户B在同一个群组,用户A向群组发送消息,用户B接收消息的主要流程如下。

具体是:

  • 1)用户A调用后端平台的接口向用户B发送消息,并且发送的消息中会带有用户B的ID以及终端信息;
  • 2)后端平台将消息缓存起来,并且会将消息异步写入消息库;
  • 3)后端平台从Redis中获取用户B连接的IM即时通讯服务的ID;
  • 4)后端平台获取到用户B连接的IM即时通讯服务的ID后,会向RocketMQ中用户B连接的IM即时通讯服务ID对应的Topic发送消息;
  • 5)IM即时通讯服务会监听自身服务ID对应的RocketMQ中Topic的消息,此时,用户B连接的IM即时通讯服务会接收到消息;
  • 6)IM即时通讯服务接收到消息后,会根据用户B的ID以及终端信息从缓存中获取用户B与IM即时通讯服务建立的连接,并且通过这个连接向用户B推送消息。

要实现如上发送消息的流程,前提是要满足如下条件:

  • 1)后端平台满足分布式条件,可随时横向扩展;
  • 2)IM即时通讯服务满足分布式条件,可随时横向扩展;
  • 3)每个启动的IM即时通讯服务实例在集群中都有一个唯一的ID;
  • 4)每个IM即时通讯服务,都只监听自身ID对应的RocketMQ中Topic的消息;
  • 5)用户登录分布式IM即时通讯系统后,会与IM即时通讯服务建立长连接,并且会根据用户ID和所在的终端缓存长连接,同时会根据用户ID和所在的终端将连接的IM即时通讯服务的ID缓存到Redis;
  • 6)用户发送消息时,会根据目标用户的ID和终端从Redis中获取IM即时通讯服务的ID,进而向当前IM即时通讯服务的ID对应的RocketMQ的Topic发送消息;
  • 7)对应的IM即时通讯服务监听并接收到RocketMQ消息后,会根据目标用户的ID和终端从缓存中获取到用户的连接信息,向目标用户推送消息。

9、IM单聊交互链路

单聊就是在分布式IM即时通讯系统中,一个用户直接与另外一个用户聊天,也就是一对一的聊天。在这种场景下,很有可能单聊的两个用户中,出现用户不在线的情况。

例如:用户A给用户B发送消息时,用户B可能不在线。

此时,我们就需要将用户A向用户B发送的消息存储起来。

其实,在我们实现的分布式IM即时通讯系统中,无论把用户B是否在线,都会存储消息记录。当用户B登录系统后,将消息同步给用户B,如下图所示。

可以看到,用户A向用户B发送消息时:

  • 1)如果用户B在线,就可以按照发送消息的交互链路向用户B发送消息了;
  • 2)如果用户B不在线,此时就无法向用户B正常推送消息。当用户B登录分布式IM即时通讯系统后,就会调用后端平台的接口拉取所有未读消息,并通过用户B在线流程向用户B推送消息。

10、IM群聊交互链路

群聊就是在分布式IM即时通讯系统中,多个用户在同一个群组中进行聊天。

此时在发送消息时,我们可以通过群组ID找出群内所有在线的用户,将消息即时发送给在线的用户。

那些未在线的用户就按照单聊未在线的用户进行处理,如下图所示。

可以看到,群聊的交互链路流程如下所示:

  • 1)用户调用后端平台的接口向群组发送消息;
  • 2)后端平台将消息缓存并异步写入消息库;
  • 3)由于是向群组发送消息,群里有多个用户,此时就会从Redis中获取所有用户连接的IM即时通讯服务ID列表;
  • 4)对用户按照服务ID分组,将相同服务ID下的用户分在同一个逻辑分组里,方便后续推送消息,并且会记录未在线的用户列表;
  • 5)循环向每个服务ID对应的RocketMQ中的Topic发送消息;
  • 6)广播处理未在线用户的未读消息ID;
  • 7)IM即时通讯服务会监听自身服务ID对应的Topic,会随时接收推送到自身服务的消息;
  • 8)当IM即时通讯服务接收到消息后,此时用户掉线,或者用户不在线,向用户推送消息就会失败,或者未查询到用户与IM即时通讯服务建立的连接,就不会向用户推送消息;
  • 9)当用户登录分布式IM即时通讯系统后,会从后端平台拉取历史(离线)消息,并通过用户在线的流程,向用户推送消息;

好了,看到这里,你明白如何设计一个高度可扩展的分布式IM即时通讯系统了吗?

11、相关资料

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

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

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

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

[5] 移动端IM中大规模群消息的推送如何保证效率、实时性?

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

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

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

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

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

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

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

[13] 跟着源码学IM(十):基于Netty,搭建高性能IM集群(含技术思路+源码)

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

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

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

[17] 史上最通俗Netty入门长文:基本介绍、环境搭建、动手实战

[18] 新手入门:目前为止最透彻的的Netty高性能原理和框架架构解析

[19] 写给初学者:Java高性能NIO框架Netty的学习方法和进阶策略

[20] 手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制

[21] 史上最强Java NIO入门:担心从入门到放弃的,请读这篇!

(本文已同步发布于:http://www.52im.net/thread-4564-1-1.html

posted @ 2023-12-21 11:29 Jack Jiang 阅读(118) | 评论 (0)编辑 收藏

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

[- 1 -] 新手入门一篇就够:从零开发移动端IM

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

[摘要] 本文将以新手的视角引导你阅读相关文章,便于你从零开发一个移动端IM做好方方面面的知识准备:包括但不限于网络编程基础、通信协议的选型、IM的架构设计等等。文笔有限,如有不妥之处还请批评指正,希望对你有用。

[- 2 -] 移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

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

[摘要] 本文的目的,就是希望以通俗易懂的语言,帮助移动端IM开发者更好地理解移动网络的各种特性,使得开发出的功能能更好地适应移动网络,给用户带来更好的使用体验。

[- 3 -] 移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

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

[摘要] 本文将针对上篇中提到的特性,结合我们的实践经验,总结了四个方法来追求极致的“爽快”:快链路、轻往复、强监控、多异步,从理论讲到实践、从技术讲到产品,理论联系实际,举一反三,希望给您带来启发。

[- 4 -] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

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

[摘要] 这篇文章和大家聊下从移动端客户端的角度所关注的IM消息可靠性和送达机制

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

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

[摘要] 本文整理的有关内容,对于移动端即时通讯IM应用来说,同样具有启发意义

[- 6 -] 腾讯技术分享:社交网络图片的带宽压缩技术演进之路

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

[摘要] 为了进一步降低运营带宽成本,减小用户访问流量及提升页面加载速度,社交网络 CDN运维紧跟行业图片优化趋势,创新引入WebP、SharpP、自适应分辨率、Guetzli等图像压缩技术到现网,经过三年多的多部门联合攻关,已逐渐形成一套覆盖全图片类型(JPEG、JPG、PNG、WebP、GIF)多场景的图片压缩运营体系,适用于各类型终端,每年节约外网带宽几百G。

[- 7 -] 小白必读:闲话HTTP短连接中的Session和Token

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

[摘要] 本文的写作目的是以最白话地方式,通俗易懂的为你讲清HTTP协议中的Session和Token等概念,希望读完全文,您仍能满怀信心,继续义无反顾地跳入程序员这个职业深坑 ^_^。更深入的技术细节,请阅读《IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token》。

[- 8 -] IM开发基础知识补课:正确理解前置HTTP SSO单点登录接口的原理

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

[摘要] 针对上述主流移动IM系统中“长”、“短”连接的分工方式,其中最为重要也是用户最先接触到的——就是基于Http的SSO单点登陆接口(有的系统里可能并不叫SSO接口,本文讨论的是其广义:即实现身份认证功能的http接口),那么这个SSO接口工作原理是什么?可以怎么来实现?有无最佳实践建议?

[- -]  移动端IM中大规模群消息的推送如何保证效率、实时性?

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

[摘要] 实际在生产环境下,群消息的发送都会想尽办法进行压缩,并开展各种改善性能的处理办法,而不是像上述举例里的直接扩散写(即2000人群里,一条消息被简单地复制为2000条一对一的消息投递)。具体有哪些优先策略?本文或许可以带给你一些启发。

[- 10 -] 移动端IM开发需要面对的技术问题

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

[摘要] 这两年多一直从事网易云信 iOS 端 IM SDK的开发,期间不断有兄弟部门的同事和合作伙伴过来问各种技术细节,干脆统一介绍下一个IM APP的方方面面,包括技术选型(包括通讯方式,网络连接方式,协议选择)和常见问题。

[- 11 -] 开发IM是自己设计协议用字节流好还是字符流好?

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

[摘要] 自己设计协议的话,协议用字节流好还是字符流好? 各有什么优缺点?

[- 12 -] 请问有人知道语音留言聊天的主流实现方式吗?

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

[摘要] 请问有人知道语音聊天的主流实现方式吗?就是类似微信那种,按住说话,录一段,发送那种。这语音文件录好之后是直接转成二进制发送。还是说当成一个文件上传到服务器,然后发送一个消息给对方,对方收到后下载?

[- 13 -] IM消息送达保证机制实现(一):保证在线实时消息的可靠投递

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

[摘要] 本文将要讨论的是即时IM应用中极其重要但也不被用户感知的消息送达保证机制(即QoS机制),文中将给出目前主流的参考实现思路。

[- 14 -] IM消息送达保证机制实现(二):保证离线消息的可靠投递

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

[摘要] 实时在线投递针对的是消息收发双方都在线的情况(如当发送方用户A发送消息给接收方用户B时,用户B是在线的),那如果消息的接收方用户B不在线,系统是如何保证消息的可达性的呢?这就是本文要讨论的问题。

[- 15 -] 如何保证IM实时消息的“时序性”与“一致性”?

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

[摘要] 实时消息时序和一致性是分布式系统架构设计中非常难的问题(尤其IM应用这种以消息为中心的应用形态),困难在哪?有什么常见优化实践?这就是本文要讨论的内容。

[- 16 -] 一个低成本确保IM消息时序的方法探讨

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

[摘要] IM类系统中,都需要考虑消息时序问题,如果后发送的消息先显示,可能严重扰乱聊天消息所要表达的意义。

[- 17 -] IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?

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

[摘要] “用户在线状态的一致性”(单聊好友在线状态、群聊用户在线状态)是IM应用领域比较难解决的一个技术问题,如何精准实时的获得好友、群友的在线状态,是今天将要探讨的话题。

[- 18 -] IM群聊消息如此复杂,如何保证不丢不重?

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

[摘要] 由于“消息风暴扩散系数”的存在(概念详见《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?》),群消息的复杂度要远高于一对一的单聊消息。群消息的实时性、可达性、离线消息是今天将要讨论的核心话题。

👉52im社区本周新文:《一套分布式IM即时通讯系统的技术选型和架构设计》,欢迎阅读!👈

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

posted @ 2023-12-21 10:30 Jack Jiang 阅读(57) | 评论 (0)编辑 收藏

本文由NetworkFox分享,来源于华三通信,原题“什么是国密算法?”,本文有修订和改动。

1、引言

最近几年经常能听到IM应用的开发者讨论国产信创方面的技术问题,在某些场景下,国密算法是硬性要求,所以学习一下国密算法还是很有必要的。

国密算法是指由中国国家密码管理局发布的密码算法标准,旨在保障国家信息安全。目前,国家密码管理局已发布了一系列国产商用密码标准算法,包括SM1(SCB2)、SM2、SM3、SM4、SM7、SM9以及祖冲之密码算法(ZUC)等。通过在金融、电子政务及安防等领域广泛应用国密算法,在对敏感数据进行机密性、完整性和可用性保护的同时,减少对外部密码产品的依赖,提升国家信息安全水平。

本文将尽量以通俗易懂的文字,为你分享国密算法的种类、技术原理和应用场景等。

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4552-1-1.html

2、系列文章

本文是IM通讯安全知识系列文章中的第12篇,此系列总目录如下:

即时通讯安全篇(一):正确地理解和使用Android端加密算法

即时通讯安全篇(二):探讨组合加密算法在IM中的应用

即时通讯安全篇(三):常用加解密算法与通讯安全讲解

即时通讯安全篇(四):实例分析Android中密钥硬编码的风险

即时通讯安全篇(五):对称加密技术在Android平台上的应用实践

即时通讯安全篇(六):非对称加密技术的原理与应用实践

即时通讯安全篇(七):用JWT技术解决IM系统Socket长连接的身份认证痛点

即时通讯安全篇(八):如果这样来理解HTTPS原理,一篇就够了

即时通讯安全篇(九):你知道,HTTPS用的是对称加密还是非对称加密?

即时通讯安全篇(十):为什么要用HTTPS?深入浅出,探密短连接的安全性

即时通讯安全篇(十一):IM聊天系统安全手段之通信连接层加密技术

即时通讯安全篇(十二):IM聊天系统安全手段之传输内容端到端加密技术

即时通讯安全篇(十三):信创必学,一文读懂什么是国密算法》(* 本文)

3、为什么需要国密算法?

3.1国密算法的产生背景

在网络信息传输和存储过程中,数据的保密性和安全性是一项重要的需求。

传统的国际标准加密算法虽然安全可靠,但由于无法保证源代码的安全性,因此存在着源代码被外部恶意攻击者渗透或篡改的风险。为了构建安全的行业网络环境并增强国家行业信息系统的“安全可控”能力,中国积极开展了针对信息安全需求的研究和探索。

自2007年开始,中国制定了国密算法标准,并于2010年正式发布。

经过多年的发展、改进和完善,国密算法已成为中国自主研发的密码算法标准,并在各行业得到广泛应用。它的诞生不仅显著提升了中国在密码技术领域的核心竞争力,还为国家信息安全建设作出了重要贡献。

3.2国密算法的特点

国密算法具备如下特点:

1)安全性高:国密算法采用了严密的密码学原理和复杂的运算方式,具有较高的安全性。它在加密、数字签名和哈希等功能上都能提供可靠的保护,抵抗了各种传统和现代密码攻击手段。

2)高效性与灵活性:国密算法在保证安全性的同时,注重算法的效率。它的加密速度和运行效率相对较高,同时也能适应不同的密码长度和密钥长度,以满足不同场景的需求。

3)标准化广泛:国密算法已被国家标准化机构认可和采用。它符合国际密码学标准的基本要求,具备与国际算法相媲美的能力。同时,国密算法也在国内推广和应用广泛,成为中国信息安全领域的基础核心算法之一。

4)自主创新:国密算法是中国自主研发的密码算法,所以对于算法的实现和推广都具有独立的掌控能力。这意味着中国可以更好地保护自己的国家信息安全,减少对外依赖,提高自主抵抗能力。

5)面向多领域应用:国密算法不仅局限于某个特定领域的应用,它适用于金融业、电子商务、通信、物联网、区块链等不同领域的信息安全保护。它的广泛应用范围使得国密算法可以满足不同行业的安全需求。

4、国密算法应用概述

国密算法包括SM1(SCB2)、SM2、SM3、SM4、SM7、SM9以及祖冲之密码算法(ZUC)等。

其中:

  • 1)SM1、SM4、SM7、祖冲之密码(ZUC)属于对称算法;
  • 2)SM2、SM9属于非对称算法;
  • 3)SM3属于杂凑算法。

下文将主要介绍国密算法中的常用算法SM1、SM2、SM3和SM4的实现和应用。

5、SM1算法的原理和应用场景

SM1算法是国密算法中的一种对称加密算法,其特点是加解密使用相同密钥。利用SM1对称加密算法加解密数据的过程。

SM1算法未公开,仅以IP核(Intellectual Property Core,一种预先做好的集成电路功能模块)的形式存在于芯片中。

SM1算法主要用于小数据量的加密保护,因此被广泛用于研制智能IC卡、智能密码钥匙、门禁卡、加密卡等安全产品。

6、SM2算法的实现和应用场景

6.1概述

SM2算法是基于ECC(Elliptic Curve Cryptography)椭圆曲线的非对称加密算法,包括了SM2-1椭圆曲线数字签名算法、SM2-2椭圆曲线密钥交换协议和SM2-3椭圆曲线公钥加密算法,分别用于实现数字签名、密钥协商和数据加密等功能。

SM2算法在许多领域都有广泛的应用。

在电子商务领域:SM2算法被用于保护用户个人信息的安全传输,确保用户在网上交易过程中的隐私和财产的安全。

在互联网金融领域:SM2算法被用于数字支付、电子银行等场景,实现用户身份认证和交易的安全性。

此外,SM2算法还适用于物联网领域,保护物联网设备之间的通信安全,确保数据的可靠传输。

6.2数据加密

在非对称加密算法中,可对外公布的密钥称为“公钥”,只有持有者所知的密钥称为“私钥”。发送者使用接收者的公钥来加密消息,接收者用自己的私钥解密和读取该消息。

利用SM2非对称加密算法加解密数据的过程:

6.3密钥协商

由于椭圆曲线的计算复杂性高,破解难度大,因此SM2算法在密钥协商技术领域也起着关键作用。

利用SM2算法进行密钥协商的过程:

  • 1)会话双方生成自己的私钥(随机数);
  • 2)会话双方由私钥、ECC椭圆曲线参数G各自计算出公钥;
  • 3)会话双方将自己的公钥传递给对方,传递过程公开。由于椭圆曲线的计算复杂性高,破解难度大,因此攻击者难以通过公钥和椭圆曲线参数G反推出私钥;
  • 4) 双方将自己的私钥与对方的公钥进行运算,最终得到相同的会话密钥,该会话密钥可作为共享密钥用于对称加密(例如SM4算法)通信。

6.4数字签名

数字签名是一种用于验证信息完整性、真实性和来源的技术手段。它通常用于确保数据在传输或存储过程中没有被篡改,并且可以追溯到特定的发送方。

发送方使用自己的私钥对消息进行加密,生成数字签名。接收方使用发送方的公钥对签名进行解密和验证,以验证消息的完整性和真实性。

在数字签名应用中,SM2算法通常与SM3摘要算法一起使用。

7、SM3算法的实现和应用场景

SM3杂凑(Hashing)算法是国密算法中的一种摘要算法。

SM3算法通过哈希函数将任意长度的消息压缩成固定长度的摘要。摘要具有唯一性,即不同信息生成的摘要不同,且无法由摘要恢复出原始信息,更无法伪造信息获得相同摘要,因此SM3算法被广泛用于实现数字签名、数据完整性检测及消息验证等功能。

基于SM3算法的特点,在信息安全领域,SM3算法被用于保护密码学协议、数字证书和电子签名等数据的完整性。在区块链领域,SM3算法被用于加密货币的区块生成和链上交易的校验,确保区块链的安全性。

此外,SM3算法还可以应用于密码学随机数的生成和伪随机序列的校验等领域,增加了数据的安全性和可靠性。

利用SM2算法和SM3算法对用户数据进行数字签名认证及完整性校验的过程:

  • 1) 用户A发送的数据A经过SM3哈希算法运算生成摘要A。
  • 2) 摘要A经过用户A的私钥加密生成数字签名。
  • 3) 用户A的明文数据和数字签名经加密算法(SM1/SM2/SM4)加密成密文后发送给用户B。加密算法以非对称加密算法SM2为例,即加解密使用不同密钥。
  • 4)密文到达用户B处,经加密算法(SM1/SM2/SM4)解密后,还原成明文数据和数字签名。
  • 5)用户B使用用户A的公钥解密数据包中的数字签名:
  •      解密成功,数据来源合法,得到摘要A;
  •      解密失败,数据来源非用户A,丢弃本次数据。
  • 6)收到的数据包中的明文数据经过SM3哈希运算生成摘要A’。对比摘要A和摘要A’:
  •      摘要A’=摘要A,数据完整;
  •      摘要A’≠摘要A,数据被篡改,丢弃本次数据。

8、SM4算法的实现和应用

8.1概述

与SM1算法分类相同,SM4算法同样为分组对称加密算法,但SM4算法实现公开。

分组加密算法是将明文数据按固定长度进行分组,用同一密钥逐组加密,密文解密时同样使用相同密钥逐组解密。

SM4算法实现简单,因此加解密速度较快,消耗资源少,主要用于大数据量的加密和解密,例如静态储存或数据信号传输通道中数据的加解密。

在网络安全领域,SM4算法被用于保护网络传输和存储的敏感数据,如银行卡信息、密码等。在物联网领域,SM4算法被用于物联网设备之间的通信和数据加密,确保物联网数据的隐私安全。

此外,SM4算法还可以应用于区块链领域,保护加密货币的交易安全等领域,为相关系统和数据的安全提供了保障。

SM4算法支持ECB、CBC、CFB等多种分组模式,下文将介绍ECB和CBC两种基础模式。

8.2加解密模式:ECB模式

SM4算法基于ECB模式对数据加解密的过程:

  • 1)发送端将明文按固定长度分组,对每个明文分组分别使用相同的密钥进行加密生成密文分组。完整的密文由所有密文分组按序排列组合而成;
  • 2)接收端将密文按固定长度分组,对每个密文分组分别使用相同的密钥进行解密生成明文分组。所有明文分组按序排列组合而成完整的明文数据。

ECB模式实现简单,各段数据间互不影响,有利于并行运算,但相同的明文块会被加密成相同的密文块,不能提供严格的数据保密性。

8.3加解密模式:CBC模式

SM4算法基于CBC模式对明文加密的过程:

  • 1)将明文按固定长度分组;
  • 2)明文分组1与初始向量IV进行异或运算,异或运算的结果经密钥加密后得到密文分组1;
  • 3)剩余的明文分组依次与前一个密文分组进行异或运算后再加密,得到对应的密文分组;
  • 4)完整的密文由所有密文分组按序排列组合而成。

SM4算法基于CBC模式对密文解密的过程:

  • 1)将密文按固定长度分组后,对密文分组进行倒序处理;
  • 2)对密文分组n先使用密钥进行解密,密文分组n解密后的数据与密文分组n-1进行逻辑逆运算,得到明文分组n;
  • 3) 同理,剩余的密文分组解密后再与前一个密文分组进行逻辑逆运算,得到对应的明文分组;
  • 4)最后,密文分组1用密钥解密后的数据是与初始向量进行逻辑逆运算,然后得到明文分组1;
  • 5)完整的明文由所有明文分组按序排列组合而成。

CBC模式安全性高于ECB,但明文块不能并行计算,且误差会传递下去。

9、国密算法与国际标准算法的对比

国密算法和国际标准算法都是现代密码学中常用的加密算法,但在技术和优劣方面存在一些区别。

常见国密算法与国际标准算法各参数性能的对比如下:

 

10、国密算法的典型应用场景有哪些?

10.1AD-WAN纵向IP/MPLS组网

国密算法可以与AD-WAN技术结合,应用于IP/MPLS纵向网场景。

通过AD-WAN智能运维平台,实现国密配置一键下发,在网络中构建国密数据加密通道,实现基于国密的端到端的IPsec隧道保护。

国密算法在端到端的IPsec隧道中的工作原理如下:

1)在IKE密钥协商阶段,使用IKE协议进行密钥协商过程中,采用SM2算法生成会话密钥。

2)在身份认证阶段,本端使用SM2和SM3算法生成身份信息的数字签名,并使用SM1或SM4算法和会话密钥对身份信息和数字签名进行加密;对端收到加密的身份信息后,使用相同的会话密钥解密,然后通过SM2和SM3算法进行身份认证。

3)在数据传输阶段,本端使用SM2和SM3算法生成用户数据的数字签名,并使用SM1或SM4算法以及会话密钥对用户数据和数字签名进行加密;对端收到加密的用户数据后,使用相同的会话密钥解密,然后通过SM2和SM3算法进行数据完整性检查。

10.24G/5G VPDN业务组网

4G/5G VPDN(Virtual Private Dialup Network,虚拟专有拨号网络)业务是在4G/5G无线网络中采用拨号方式实现的一种虚拟专有网络业务。它利用L2TP技术为客户构建与互联网隔离的隧道,以满足客户分支和总部内网通信的需求。VPDN组网同时支持将L2TP和IPsec技术结合,通过L2TP完成用户认证确保接入安全,并利用IPsec保障通信数据安全。

1)4G/5G VPDN组网中分支网关由4G/5G路由设备担任,通过拨号接入运营商网络。

2)运营商对4G/5G路由设备的APN(Access Point Name,接入点名称)、账户、SIM/USIM卡信息进行认证。

3)4G/5G路由设备认证通过后被运营商判断是VPDN用户,同时由运营商AAA服务器向LAC(L2TP Access Concentrator,L2TP访问集中器)设备下发L2TP隧道属性,LAC设备将基于下发的L2TP隧道属性信息向该VPDN用户所属总部的LNS(L2TP Network Server,L2TP网络服务器)设备发起隧道建立请求。

4)L2TP隧道建立后,LAC设备会通过此隧道向LNS设备透传用户的认证信息。LNS设备向总部内网的AAA服务器发起对VPDN用户的二次认证,认证通过后为VPDN用户分配一个企业内网IP地址。分支终端用户和总部可以开始通信。

5)分支网关与总部网关设备上均安装有国密板卡,通过IPsec协商建立起端到端的IPsec隧道,使用国密算法对传输的数据报文进行加密保护和数据完整性检查。

6)经IPsec加密后的数据报文在LAC设备处进行L2TP封装后,通过L2TP隧道传输到LNS。

7)LNS收到数据报文后首先对L2TP报文进行解封装,然后经过IPsec解密还原出数据报文,根据报文目的IP地址转发报文。

11、相关文章

[1] 常用加解密算法与通讯安全讲解

[2] 非对称加密技术的原理与应用实践

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

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

[5] 通俗易懂:一篇掌握即时通讯的消息传输安全原理

[6] 基于Netty的IM聊天加密技术学习:一文理清常见的加密概念、术语等

[7] 理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)

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

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


(本文已同步发布于:http://www.52im.net/thread-4552-1-1.html

posted @ 2023-12-14 11:06 Jack Jiang 阅读(68) | 评论 (0)编辑 收藏

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

[- 1 -] 专访微信视频技术负责人:微信实时视频聊天技术的演进

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

[摘要] 本次专访是对谷沉沉老师在即将到来的 2017ArchSummit 全球架构师峰会上,以《数亿微信视频通话背后的视频技术二三事》为题发表演讲的一次预热。


[- 2 -] 腾讯音视频实验室:使用AI黑科技实现超低码率的高清实时视频聊天

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

[摘要] 腾讯音视频实验室和优图实验室X-lab的戴宇榮老师的团队联合开发的基于神经网络的实时视频超分辨率技术,在极小的神经网络模型大小的条件下,在手机实时视频通话上实现了基于机器学习的超分辨率技术,起到了主观上提升一档分辨率的效果。此技术即将应用在手机QQ 7.3.5的iOS版本上的实时视频聊天。


[- 3 -] 微信团队分享:微信每日亿次实时音视频聊天背后的技术解密

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

[摘要] 本文将为大家介绍微信实时音视频聊天在不同发展阶段的各个关键视频技术环节采用的方案,同时分享在实时音视频聊天中的视频编码器研发的方法和经验。


[- 4 -]福利贴:最全实时音视频开发要用到的开源工程汇总

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

[摘要] 本文汇总了一些能帮助到正在学习或进行实时音视频开发的同行们的开源工程,这些工程分为几类:音视频编解码类、视频前后处理、服务端类等,希望能加速您的学习或研究过程。


[- 5 -] 实时音视频聊天中超低延迟架构的思考与技术实践

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

[摘要] 从直播在线上抓娃娃,不断变化的是玩法的创新,始终不变的是对超低延迟的苛求。实时架构是超低延迟的基石,如何在信源编码、信道编码和实时传输整个链条来构建实时架构?在实时架构的基础之上,如果通过优化采集、编码、传输、解码和渲染中的关键环节来降低延迟?本文将会介绍即构在这方面的思考与实践。


[- 6 -] 理解实时音视频聊天中的延时问题一篇就够

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

[摘要] 音视频实时通讯的应用场景已经随处可见,从“吃鸡”的语音对讲、直播连麦、直播答题组队开黑,再到银行视频开户等。对于开发者来讲,除了关注如何能快速实现不同应用场景重点额音视频通讯,另一个更需要关注的可能就是“低延时”。但是,到底实时音视频传输延时应该如何“低”,才能满足你的应用场景呢?


[- 7 -] 写给小白的实时音视频技术入门提纲

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

[摘要] 本文是由一篇演讲稿整理出来的文章,目标读者是对实时音视频开发感兴趣但是又不知道如何下手的初学者们,对大家有所帮助。


[- 8 -] 微信多媒体团队访谈:音视频开发的学习、微信的音视频技术和挑战等

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

[摘要] 腾讯多媒体内核中心高级研究员时永方接受了LiveVideoStack的邮件采访,谈及了个人成长中的关键时刻,学习多媒体开发的三点核心,以及在5G和高清时代下,微信多媒体团队面临的挑战。


[- 9 -]  腾讯技术分享:微信小程序音视频技术背后的故事

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

[摘要] 本文来自腾讯视频云终端技术总监rexchang(常青)的技术分享,讲述的是微信小程序中音视频技术构思、设计和实现等方方面的内容,希望能为你的音视频技术实践带来启发。


[- 10 -] 微信多媒体团队梁俊斌访谈:聊一聊我所了解的音视频技术

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

[摘要] 从华为2012实验室到腾讯,过去十余年梁俊斌一直专注在音频技术。他告诉LiveVideoStack:音频技术还有许多难点需要解决,而作为技术人也延展到应用场景,关注用户需求。本文整理了本次访谈的主要内容,仅供参阅。


[- 11 -] 新浪微博技术分享:微博短视频服务的优化实践之路

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

[摘要] 本文的短视频技术跟IM的单聊、群聊、朋友圈里的小视频是类似的东西,文中针对短视频的相关优化实践可以为您的IM小视频开发提供一定的参考和借鉴意义,希望对您有用。


[- 12 -] 以网游服务端的网络接入层设计为例,理解实时通信的技术挑战

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

[摘要] 本文将尝试从开发者角度:梳理开发网游服务端的网络接入层的过程中面临的各种技术挑战,并针对性地提供相应的实时通信网络接入层解决思路,希望对于即时通讯应用的开发者来说,可以从中得到些许启发。


[- 13 -] 腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践

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

[摘要] 本文来自腾讯视频云终端技术总监rexchang(常青)技术分享,内容分别介绍了微信小程序视音视频和WebRTC的技术特征、差异等,并针对两者的技术差异分享和总结了微信小程序视音视频和WebRTC互通的实现思路以及技术方案。希望能带给你启发。


[- 14 -] 爱奇艺技术分享:轻松诙谐,讲解视频编解码技术的过去、现在和将来

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

[摘要] 本文以轻松幽默的语气,讲解了视频编解码的一些基本常识,并以爱奇艺为例,讲述了视频编解码技术在国内的发展以及未来的一些展望。


[- 15 -] 零基础入门:实时音视频技术基础知识全面盘点

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

[摘要] 本文是作者自已根据入门实时音视频的亲身经历,对于基础知识点的认知总结。虽然很浅显,但相对小白来说,能稍微系统的了解这些概念就已经是很好的起点了。


[- 16 -] 实时音视频面视必备:快速掌握11个视频技术相关的基础概念

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

[摘要] 本文将通过通俗的文字,言简意赅地为你讲解实时音视频技术中跟视频技术在关的11个非常重要的基础知识概念,希望能为你日后从事这方面的工作起到抛砖引玉的作用。


[- 17 -] 实时音视频开发理论必备:如何省流量?视频高度压缩背后的预测技术

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

[摘要] 本文将从视频编解码技术的基础知识入手,引出视频编解码技术中非常基础且重要的预测技术,学习帧内预测和帧间预测的技术原理。


👉52im社区本周新文:《即时通讯安全篇(十三):信创必学,一文读懂什么是国密算法》,欢迎阅读!👈

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

posted @ 2023-12-13 11:57 Jack Jiang 阅读(70) | 评论 (0)编辑 收藏

一、关于RainbowChat-Web

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

二、v6.0 版更新内容

此版更新内容更多历史更新日志):

  • 1)[bug][服务端] - 解决了群成员从首页“消息”列表中删除已解散群的item时没有反应的问题;
  • 2)[新增][服务端] - 安全提升,实现了一套新的token生成、校验机制(支持对称加密和非对称加密两种模式);
  • 3)[新增][服务端] - 安全提升,启用了AppKey校验机制;
  • 4)[新增][前端]    - 优化了http接口、文件上传接口校验逻辑,提升安全性;
  • 5)[新增][前端]    - 安全提升,启用了AppKey校验机制;
  • 6)[新增][前端]    - 新增发送“群名片”消息功能;
  • 7)[新增][前端]    - 新增了消息转发功能;
  • 8)[优化][前端]    - 其它细节优化等。

三、v6.0 版新增特性截图

“群名片”功能运行截图查看演示视频更多运行截图):

“消息转发”功能(查看演示视频更多运行截图):

posted @ 2023-12-11 12:08 Jack Jiang 阅读(51) | 评论 (0)编辑 收藏

     摘要: 本文由字节跳动技术团队高原、汤中峰分享,原题“抖音功耗优化实践”,本文有修订和改动。一、引言功耗优化是应用体验优化的一个重要课题,高功耗会引发用户的电量焦虑,也会导致糟糕的发热体验,从而降低了用户的使用意愿。而功耗又是涉及整机的长时间多场景的综合性复杂指标,影响因素很多。不论是功耗的量化拆解,还是异常问题的监控,以及主动的功耗优化对于开发人员来说都是很有挑战性的。本文结合抖...  阅读全文

posted @ 2023-12-07 11:37 Jack Jiang 阅读(245) | 评论 (0)编辑 收藏

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

[- 1 -] 实时语音聊天中的音频处理与编码压缩技术简述

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

[摘要] 在视频或者音频通话过程中,一方面为了减小原始声音数据的传输码率,需要进行音频压缩,另一方面为了得到更高质量的音质,需要进行音频处理。如何处理好这两方面,保证声音传播的高真性,是个技术活儿!

[- 2 -] 网易视频云技术分享:音频处理与压缩技术快速入门

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

[摘要] 随着音频处理和压缩技术的不断发展,效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现,不断改善我们的生活。

[- 3 -] 学习RFC3550:RTP/RTCP实时传输协议基础知识

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

[摘要] 本文对这些协议进行初步归纳总结,在分析RFC3550的基础上,重点分析RTP系列协议,并以报文类型为主线分析RTCP系列协议。

[- 4 -]基于RTMP数据传输协议的实时流媒体技术研究(论文全文)

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

[摘要] 本文来自论文《基于 RTMP 协议的流媒体技术的原理与应用》,文中研究了基于 Flash 平台的流媒体系统中使用的 RTMP 协议的原理和应用,并对网络上实时流媒体的各种传输方式的优缺点进行了分析。

[- 5 -] 声网架构师谈实时音视频云的实现难点(视频采访)

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

[摘要] 孙雨润,声网 Agora.io 首席音视频架构师,负责全球音视频传输技术架构。毕业于中国科学技术大学,原 YY 后台架构师,主导 Web YY 整体后台系统架构搭建。曾任职腾讯 QQ 研究员 ,主导 QQ 空间面孔墙等项目;任职微软 Microsoft 期间,参与高性能计算产品项目。

[- 6 -] 还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!

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

[摘要] 实时语音聊天开发,对于一般的开发者来说比较神秘,很多朋友不太清楚如何全面的评估一个音频引擎。

[- 7 -] 如何用最简单的方法测试你的实时音视频方案

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

[摘要] 本文总结了一些有关实时音视频方案比较值得自测的要点,旨在没有生产环境反馈和丰富的测试资源情况下,用较低的成本来测试覆盖尽可能多的真实场景中可能遇到的网络和设备问题。

[- 8 -] 简述实时音视频聊天中端到端加密(E2EE)的工作原理

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

[摘要] 本文着重阐述端到端加密(E2EE),端到端加密是确保数据传输安全的可行方法之一。读完这篇文章,你可以了解这种加密方式的基本原理.

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

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

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

[- 10 -] IM实时音视频聊天时的回声消除技术详解

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

[摘要] 为了不让文章读起来枯燥,本文将尽量通俗易懂地为您讲解实时音视频聊天场景下的回声消除技术原因希望能带给你些许启发。

[- 11 -] 如何优化传输机制来实现实时音视频的超低延迟?

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

[摘要] 要在语音视频 SDK 中实现超低延迟,实时的语音视频传输机制是必不可少的,而 FEC 和 ARQ 的智能结合是实时语音视频传输机制的基石。

[- 12 -] 实时通信RTC技术栈之:视频编解码

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

[摘要] 本文是系列文章的第一篇:讲述视频编解码的一些基本知识。

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

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

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

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

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

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

[- 15 -] 实时音视频聊天技术分享:面向不可靠网络的抗丢包编解码器

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

[摘要] 编解码器面向直播和网络通信是不一样的,我今天想说的是面向不可靠传输网络的抗丢包编解码器。

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

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

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

👉52im社区本周新文:《抖音技术分享:抖音Android端手机功耗问题的全面分析和详细优化实践》,欢迎阅读!👈

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

posted @ 2023-12-06 12:22 Jack Jiang 阅读(75) | 评论 (0)编辑 收藏

     摘要: 本文由竹子爱熊猫分享,原题“(十一)Netty实战篇:基于Netty框架打造一款高性能的IM即时通讯程序”,本文有修订和改动。1、引言关于Netty网络框架的内容,前面已经讲了两个章节,但总归来说难以真正掌握,毕竟只是对其中一个个组件进行讲解,很难让诸位将其串起来形成一条线,所以本章中则会结合实战案例,对Netty进行更深层次的学习与掌握,实战案例也并不难,一个非常朴素的I...  阅读全文

posted @ 2023-11-30 12:28 Jack Jiang 阅读(88) | 评论 (0)编辑 收藏

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

[- 1 -] 即时通讯音视频开发(一):视频编解码之理论概述

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

[摘要] 本文主要讲解实时音视频技术中视频技术的编解码基础理论。

[- 2 -] 即时通讯音视频开发(二):视频编解码之数字视频介绍

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

[摘要] 本文主要讲解实时音视频技术中视频技术的数字视频知识。

[- 3 -] 即时通讯音视频开发(三):视频编解码之编码基础

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

[摘要] 本文主要讲解实时音视频技术中视频技术的编码理论知识。

[- 4 -] 即时通讯音视频开发(四):视频编解码之预测技术介绍

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

[摘要] 本文主要讲解实时音视频技术中视频技术的预测技术理论知识。

[- 5 -] 即时通讯音视频开发(五):认识主流视频编码技术H.264

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

[摘要] 本文主要讲解实时音视频技术中目前主流的视频编码技术H.264相关知识。

[- 6 -] 即时通讯音视频开发(六):如何开始音频编解码技术的学习

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

[摘要] 本文是一篇讲述新手如何学习音频编解码知识的文章。

[- 7 -] 即时通讯音视频开发(七):音频基础及编码原理入门

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

[摘要] 本文是一篇讲述基础音频知识和编码原理的文章。

[- 8 -]  即时通讯音视频开发(八):常见的实时语音通讯编码标准

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

[摘要] 本文是一篇讲述常用的实用音频通讯编码标准的文章。

[- 9 -] 即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述

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

[摘要] 本文是一篇介绍实时音频通讯过程中的回音问题,以及回音消除技术的介绍文章。

[- 10 -] 即时通讯音视频开发(十):实时语音通讯的回音消除技术详解

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

[摘要] 本文是一篇详细介绍实时音频通讯过程中的回音消除技术的文章,主要描述的是回音消除技术理论和算法原理等。

[- 11 -] 即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解

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

[摘要] 本文是一篇详细介绍实时语音通讯过程中的丢包补偿技术的文章。

[- 12 -] 即时通讯音视频开发(十二):多人实时音视频聊天架构探讨

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

[摘要] 虽然都是视频通讯,大部分情况下的单人视频通话可能根本不需要用到流媒体服务,而多人视频,如在线教育这些则必须用到,所以下面主要介绍多人视频中服务端架构模式,以及各自特点。

[- 13 -] 即时通讯音视频开发(十三):实时视频编码H.264的特点与优势

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

[摘要] 本文主要讲解实时音视频技术中最流行的视频编码技术H.264的特点和优势,希望能为您的技术选型提供一定的参考。

[- 14 -] 即时通讯音视频开发(十四):实时音视频数据传输协议介绍

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

[摘要] 本文将简要介绍这些主流的实时音视频数据传输协议。

[- 15 -] 即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况

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

[摘要] p2p就是点对点,两个客户端直接进行数据交互,不需要经过服务器转发(relay),这种方式能大大减轻服务端的负载,所以特别视适合大数据的传输,比如实时音视频聊天、在线视频直播、大文件传输等应用场景。

[- 16 -] 即时通讯音视频开发(十六):移动端实时音视频开发的几个建议

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

[摘要] 本文将就几个典型问题给出简要的参考建议。

[- 17 -] 即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生

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

[摘要] 本文重在为读者从技术角度讲解H.264和VP8的发展渊源以及现时所面临的问题,相信读完此文后,对于即时通讯(IM聊天应用)的实时音视频开发中视频编码的选择会有个直观的了解。

[- 18 -] 即时通讯音视频开发(十八):详解音频编解码的原理、演进和应用选型

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

[摘要] 以下就是本次为大家分享的主要内容,希望通过此次分享可以使大家对音频编解码有一个整体的认识,并在实际应用中有参考的依据。

[- 19 -] 即时通讯音视频开发(十九):零基础,史上最通俗视频编码技术入门

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

[摘要] 视频编码技术涉及的内容太过专业和庞杂,市面上的书籍或博客多数都只是枯燥的技术概念罗列,对于新手来说读完依旧蒙逼是常态,本文将借此机会,专门给大家做一个关于视频编码的零基础科普。

[- 20 -] 即时通讯音视频开发(二十):一文读懂视频的颜色模型转换和色域转换

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

[摘要] 本文将以通俗易懂的文字,引导你理解视频是如何从采集开始,历经各种步骤,最终通过颜色模型转换和不同的色域转换,让你看到赏心悦目的视频结果的。

👉52im社区本周新文:《跟着源码学IM(十二):基于Netty打造一款高性能的IM即时通讯程序》,欢迎阅读!👈

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

posted @ 2023-11-29 13:41 Jack Jiang 阅读(70) | 评论 (0)编辑 收藏

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

[- 1 -] 开源实时音视频技术WebRTC的现状

[链接] http://www.52im.net/article-126-1.html

[摘要] 作为Google开源的技术,WebRTC并不是一个可以拿来就用并且性能很好的产品,而且正如众多的其它开源技术一样,WebRTC的发展并没有期待中的快。


[- 2 -] 简述开源实时音视频技术WebRTC的优缺点

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

[摘要] 作为Google开源的技术,WebRTC并不是一个可以拿来就用并且性能很好的产品,需要工程师们对其进行较多的改善。本文主要来谈一谈WebRTC的优缺点。


[- 3 -] 访谈WebRTC标准之父:WebRTC的过去、现在和未来

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

[摘要] 首届(WebRTC)网络实时通信大会期间,InfoQ 对 WebRTC 之父 Daniel C. Burnett 进行了专访,以下是专访实录。(注:Daniel 在访谈中的观点仅代表他本人及其在 W3C 所做的工作。)


[- 4 -] 良心分享:WebRTC 零基础开发者教程(中文)[附件下载]

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

[摘要] WebRTC,名称源自网页实时通信(Web Real-Time Communication)的缩写,是一个支持网页浏览器进行实时语音通话或视频聊天的技术,是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。


[- 5 -] WebRTC实时音视频技术的整体架构介绍

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

[摘要] 虽然WebRTC的目标是实现跨平台的Web端实时音视频通讯,但因为核心层代码的Native、高品质和内聚性,开发者很容易进行除Web平台外的移殖和应用。很长一段时间内WebRTC是业界能免费得到的唯一高品质实时音视频通讯技术。


[- 6 -] 新手入门:到底什么是WebRTC服务器,以及它是如何联接通话的?

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

[摘要] 通过WebRTC的端到端通信通常被人们所误解。WebRTC并不是真正意味着你不需要服务器来协商和联接通话。它只意味着,在多数情况中,你可以直接地在浏览器之间进行通信。


[- 7 -] WebRTC实时音视频技术基础:基本架构和协议栈

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

[摘要] 本文主要介绍WebRTC的架构和协议栈。


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

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

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


[- 9 -] [观点] WebRTC应该选择H.264视频编码的四大理由

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

[摘要] 对实时音视频开发者来说,当开发一个基于WebRTC的产品时,我们应该选择什么样的视频编解码器?去年的时候,答案可能是“VP8”。几个月前,答案可能是“看情况”。现在答案是“除非必须用VP8,否则就用H.264”。


[- 10 -] 基于开源WebRTC开发实时音视频靠谱吗?第3方SDK有哪些?

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

[摘要] 利用Google开源的WebRTC来开发自已的实时音视频系统,靠不靠谱这个问题一直被问到,其实很难一两句话说清楚,因为答案不是一个靠谱或不靠谱可以回答好的,既然被反复问到,今天就系统地整理参考答案。


[- 11 -] 开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用

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

[摘要] 本文在深入研究WebRTC源代码的基础上,以Video数据的发送和接收为例,力求用简洁语言描述RTP/RTCP模块的实现细节,为进一步深入掌握WebRTC打下良好基础。


[- 12 -] 简述实时音视频聊天中端到端加密(E2EE)的工作原理

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

[摘要] 本文着重阐述端到端加密(E2EE),端到端加密是确保数据传输安全的可行方法之一。读完这篇文章,你可以了解这种加密方式的基本原理.


[- 13 -] 实时通信RTC技术栈之:视频编解码

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

[摘要] 那么 RTC 技术栈究竟包含哪些技术,我们会提供一系列文章,来解读 RTC 技术栈。本文是系列文章的第一篇:讲述视频编解码的一些基本知识。


[- 14 -] 开源实时音视频技术WebRTC在Windows下的简明编译教程

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

[摘要] WebRTC是提供了一整套处理实时音视频的开源库。它包括了音视频处理(采集,编解码,前处理,后处理,渲染),数据传输(实时传输,流控)和业务逻辑控制。可以说 WebRTC 的出现大大减少了做音视频开发的难度,所以熟练掌握好这个库对于做音视频相关的同学就显的特别重要了。


[- 15 -] 网页端实时音视频技术WebRTC:看起来很美,但离生产应用还有多少坑要填?

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

[摘要] 直到2011年,WebRTC技术的出现,并且由谷歌做推广。WebRTC带来的体验是因为免安装才受到了关注。


[- 16 -] 了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化

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

[摘要] 有人说 2017 年是 WebRTC 的转折之年,2018 年将是 WebRTC 的爆发之年,这并非没有根据。就在去年(2017年),WebRTC 1.0 标准草案出炉(实际上WebRTC标准草案的早期版本早在2011年就已经发布,WebRTC并非一夜之间就出现的技术),并将于今年正式发布。与此同时,越来越多的浏览器和厂商都开始对它进行广泛的支持,WebRTC 即将成为互联网的基础设施了,或许门槛如此之高的实时音视频技术终有白菜化的那一天。


[- 17 -] 腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践

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

[摘要] 本文来自腾讯视频云终端技术总监rexchang(常青)技术分享,内容分别介绍了微信小程序视音视频和WebRTC的技术特征、差异等,并针对两者的技术差异分享和总结了微信小程序视音视频和WebRTC互通的实现思路以及技术方案。希望能带给你启发。


[- 18 -] 融云技术分享:基于WebRTC的实时音视频首帧显示时间优化实践

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

[摘要] 本文主要通过对WebRTC接收端的音视频处理过程分析,来了解和优化视频首帧的显示时间,并进行了总结和分享。


[- 19 -] 零基础入门:基于开源WebRTC,从0到1实现实时音视频聊天功能

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

[摘要] 本文将基于笔者公司开发的在线问诊产品中WebRTC技术的实践经验,讲述的如何基于WebRTC从零开发一个实时音视频聊天功能。文章会从WebRTC的基本知识、技术原理开始,基于开源技术为你演示如何搭建一个WebRTC实时音视频聊天功能。


[- 20 -] 实时音视频入门学习:开源工程WebRTC的技术原理和使用浅析

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

[摘要] WebRTC(全称 Web Real-Time Communication),即网页即时通信。是一个支持网页浏览器进行实时语音对话或视频对话的技术方案。从前端技术开发的视角来看,是一组可调用的API标准。


👉52im社区本周新文:《哔哩哔哩从0到1自研智能客服IM系统的技术实践之路 http://www.52im.net/thread-4517-1-1.html》,欢迎阅读!👈

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

posted @ 2023-11-24 11:39 Jack Jiang 阅读(74) | 评论 (0)编辑 收藏

     摘要: 本文由B端技术中心分享,原题“从0到1:哔哩哔哩智能客服系统的设计与实现”,本文有修订和改动。1、引言本文将要分享的是哔哩哔哩从0到1自研智能客服IM系统的技术实践过程,包括整体架构设计和主要核心功能的技术实现思路等,希望带给你启发。* 推荐阅读:《得物从0到1自研客服IM系统的技术实践之路》。  技术交流:- 移动端IM开发入门文章:《新手入门一篇就够...  阅读全文

posted @ 2023-11-23 11:53 Jack Jiang 阅读(88) | 评论 (0)编辑 收藏

     摘要: 本文由微信客户端团队rhythm分享,原题“视频号直播:如何进一步降低功耗占用?”,本文有修订和改动。1、引言功耗优化一直是 app 性能优化中让人头疼的问题,尤其是在直播这种用户观看时长特别久的场景。怎样能在不影响主体验的前提下,进一步优化微信iOS端视频号直播的功耗占用,本文给出了一个不太一样的答案。  技术交流:- 移动端IM开发入门文章:《新手入...  阅读全文

posted @ 2023-11-16 11:57 Jack Jiang 阅读(65) | 评论 (0)编辑 收藏

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

[- 1 -] 理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)

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

[摘要] 本文将以理论联系实际的方式,详细讲解一套典型IM的通信协议设计的方方面面。


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

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

[摘要] 通信安全是互联网应用首要考虑的问题,有别于传统PC应用,随着移动互联网时代的到来,移动端的通信安全性要同时权衡:安全、性能、体验、数据流量等等方面,要实现一个完整而实用的通信安全解决方案并非易事。本文将详细介绍基于TLS 1.3的微信新一代通信安全协议mmtls。


[- 3 -] 来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享

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

[摘要] OpenIM是阿里巴巴推出的,集成于阿里百川项目中的移动端IM开放服务。阿里百川是阿里巴巴集团无线开放平台,为移动开发者(涵盖移动创业者)提供快速搭建APP、加速APP商业化、提升用户体验的解决方案。


[- 4 -]简述实时音视频聊天中端到端加密

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

[摘要] 本文着重阐述端到端加密(E2EE),端到端加密是确保数据传输安全的可行方法之一。读完这篇文章,你可以了解这种加密方式的基本原理.


[- 5 -] 移动端安全通信的利器——端到端加密(E2EE)技术详解

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

[摘要] 端到端加密允许数据在从源点到终点的传输过程中始终以密文形式存在。采用端到端加密(又称脱线加密或包加密)时消息在被传输时到达终点之前不进行解密,因为消息在整个传输过程中均受到保护,所以即使有节点被损坏也不会使消息泄露。


[- 6 -] Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)

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

[摘要] 本文将深入浅出为读者介绍跨站点 WebSocket 漏洞的原理、检测方法和修复方法,希望能帮助广大读者在实际工作中避免这个已知安全漏洞。


[- 7 -] 通俗易懂:一篇掌握即时通讯的消息传输安全原理

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

[摘要] 本文将通过通俗易懂的文字,引导你一步步理解为何一个即时通讯应用需要加密技术,以及需要何种方式的加密技术等,希望能为您的IM或消息推送服务的设计提供一些参考。


[- 8 -]  IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

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

[摘要] 本文讨论的使用Http短连接的话题可能并不适用于微信这样的IM,因为微信的短连接并非使用Http标准协议实现,而是基于自研的Mars网络层框架再造了一套短连接机制,从而更适用于IM这种场景(更低延迟、更省流量、更好的弱网适应算法等)


[- 9 -] 快速读懂量子通信、量子加密技术

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

[摘要] 量子通信技术是个很高端的话题,对于搞IM、推送、网络通信的程序员来说,这到底是个什么鬼?所以我们一起来了解一下!


[- 10 -] 即时通讯安全篇(七):如果这样来理解HTTPS原理,一篇就够了

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

[摘要] 本文将尝试用通俗易懂的语言,一步步还原HTTPS的设计过程,以便您能轻松理解为什么HTTPS最终会是这副模样。


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

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

[摘要] 本文只做简单的描述,力求简单明了的阐明主要内容,因为HTTPS 体系非常复杂,这么短的文字是无法做到很详细和精准的分析。想要详细了解HTTPS的方方面面,可以阅读此前即时通讯网整理的《即时通讯安全篇(七):如果这样来理解HTTPS,一篇就够了》一文。


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

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

[摘要] HTTPS(全称:Hypertext Transfer Protocol Secure,超文本传输安全协议),是以安全为目标的HTTP通道,简单讲是HTTP的安全版。本文,就来深入介绍下其原理。


[- 13 -] 基于Netty的IM聊天加密技术学习:一文理清常见的加密概念、术语等

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

[摘要] 本文正好借此机会,以Netty编写的IM聊天加密为例,为入门者理清什么是PKI体系、什么是SSL、什么是OpenSSL、以及各类证书和它们间的关系等,并在文末附上简短的Netty代码实示例,希望能助你通俗易懂地快速理解这些知识和概念!


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

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

[摘要] 本文要分享的是如何使用OpenSSL生成在基于Netty的IM中真正可用的SSL/TLS证书,内容包括:证书的创建、创建过程中的注意点,以及在Server端、Android端、iOS端、Java桌面端、H5端使用证书的代码范例。


[- 15 -] 微信技术分享:揭秘微信后台安全特征数据仓库的架构设计

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

[摘要] 本文将介绍微信的安全数据特征仓库的背景起源、技术演进、当前的架构设计和实践,以及数据质量保证系统的实现。希望给中大型IM系统的安全数据特征仓库的设计带来启发。


👉52im社区本周新文:《微信团队分享:详解iOS版微信视频号直播中因帧率异常导致的功耗问题》,欢迎阅读!👈

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

posted @ 2023-11-15 10:51 Jack Jiang 阅读(63) | 评论 (0)编辑 收藏

本文由小红书基础架构存储组空洞和刘备分享,原题“小红书如何应对万亿级社交网络关系挑战?图存储系统 REDtao 来了!”,本文有修订和改动。

1、引言

小红书是一个社区属性为主的产品,它涵盖了各个领域的生活社区,并存储海量的社交网络关系。

为了解决社交场景下超大规模数据的更新与关联读取问题,并减少数据库压力和成本,我们自研了面向超大规模社交网络的图存储系统 REDtao,大大提高了系统稳定性。该系统借鉴了 Facebook 的图存储系统设计,将缓存和底层数据库封装起来,并对外提供统一的图查询 API,实现了访问收敛,同时在缓存中实现了高效的边聚合。

本文将为你分享小红书面向超大规模社交网络的图存储系统REDtao的架构设计与技术实践过程,希望能带给你启发。

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4495-1-1.html

2、关于作者

空洞:小红书基础架构存储组,负责图存储系统 REDtao 和分布式缓存的研发。

刘备:小红书基础架构存储组负责人,负责REDkv / REDtao / REDtable / REDgraph 的整体架构和技术演进。

基础架构存储组是给小红书的业务部门提供稳定可靠的存储和数据库服务,满足业务对存储产品的功能、性能、成本和稳定性要求。目前负责自研分布式 KV、分布式缓存、图存储系统、图数据库和表格存储。

已上线的存储产品包括:

  • 1)REDkv : 分布式高性能 KV;
  • 2)REDtao :满足一跳查询的高性能图存储数据库;
  • 3) REDtable :提供 Schema 语义和二级索引的表格存储;
  • 4) REDgraph :提供两跳及以上的图语义查询数据库。

3、技术背景

小红书是以年轻人为主的生活记录、分享平台,用户可以通过短视频、图文等形式记录生活点滴,分享生活方式。

在小红书的社交领域里,我们有用户、笔记、商品等实体,这些实体之间有各种各样的关系。

例如:用户与笔记之间可能存在“拥有”(发布)、“点赞”、“收藏”等三种关系,同时还存在对应的反向关系“被点赞”,“被收藏”等。

小红书的社交图谱数据已经达到了万亿条边的规模,且增长速度非常快。当用户登陆小红书时,每个用户都会看到关注的好友、粉丝、点赞、收藏以及其他为其量身定做的内容。

这些信息高度个性化,需要实时从这些海量社交关系数据中读取用户相关信息。这是一个读为主的过程,读取压力非常大。

过去,我们将这些社交图谱数据都存储在运维成熟的 MySQL 数据库中。

然而,即使我们只有百万请求每秒的规模,MySQL 的 CPU 使用率仍然到达了 55% 。随着用户和 DAU 爆发式的增长,需要不断扩容 MySQL 数据库,这带来了巨大的成本和稳定性压力。

为了解决这些问题且考虑到没有合适的开源方案,2021 年初我们开启了从 0 到 1 自研 REDtao 的历程。

4、方案调研和API设计

4.1方案调研

我们充分调研了业内其他厂商的实现,发现有着强社交属性的公司基本上都有一个自研的图存储系统(如下图所示)。

比如:

  • 1)Facebook 实现了一个叫做 “TAO” 专门的分布式社交图谱数据库,并将其作为最核心的存储系统;
  • 2)Pinterest 和 Facebook 类似,也实现了类似的图存储系统;
  • 3)字节跳动自研了 ByteGraph 并将其用于存储核心的社交图谱数据;
  • 4)Linkedln 在 KV 之上构建了社交图谱服务。

考虑到当时我们的社交图谱数据已经存放在 MySQL 数据库上且规模巨大,而社交图谱数据服务是非常重要的服务,对稳定性的要求非常高。回溯 Facebook 当年遇到的问题和我们类似,数据存储在 Memcache 和 MySQL 中。因此,参考 Facebook 的 Tao 图存储系统更贴合我们的实际情况和已有的技术架构,风险更小。

4.2API设计

社交图谱的访问主要是边的关系查询。

我们的图模型将关系表示为一个 <key, value> 对,其中 key 是 ( FromId,  AssocType,  ToId ) 的三元组,value 是属性的  JSON 格式。

比如“用户 A ”关注“用户 B ”,映射到 REDtao 的数据存储结构为:

1<FromId:用户A的ID, AssocType:关注, ToId:用户B的ID>  ->  Value (属性的json字段)

我们对业务方的需求进行分析,封装了 25 个图语义的 API 给业务方使用,满足了其增删改查的需求,并收敛业务方的使用方式。

相比于 Facebook 的 Tao,我们还补充了社交图谱所需要的图语义,为反作弊场景提供了额外的过滤参数。

同时,在缓存层面,我们支持对不同的字段在缓存中配置局部二级索引。

下面给一些典型的使用场景。

1)场景一:获取关注了 A 的所有正常用户(并且剔除作弊用户):

1getAssocs(“被关注类型”, 用户A的ID, 分页偏移量, 最大返回值, 只返回正常用户,是否按照时间从新到旧)

2)场景二:获取 A 的粉丝个数(并且剔除作弊用户):

1getAssocCount(“被关注类型”, 用户A的ID, 只返回正常用户)

5、整体架构设计

REDtao 的架构设计考虑了下面这几个关键的要素:

整体架构分为三层:

  • 1)接入层;
  • 2)缓存层;
  • 3)持久层。

业务方通过 REDtao SDK 接入服务。

如下图:

在这个架构中:和 Facebook Tao 不一样的是,我们的缓存层是一个独立的分布式集群,和下面的持久层是解耦的。缓存层和下面的持久层可以独立的扩容缩容,缓存分片和 MySQL 分片不需要一一对应,这样带来了更好的灵活性,MySQL 集群也变成了一个可以插拔替换的持久存储。

1)读流程:客户端将读请求发送给 router,router 接收到 RPC 请求后,根据边类型选择对应的 REDtao 集群,根据三元组 ( FromId,  AssocType,  ToId ) 通过一致性 Hash 计算出分片所在的 Follower 节点,将请求转发到该节点上。Follower 节点接收到该请求,首先查询本地的图缓存,如果命中则直接返回结果。如果没有命中,则将请求转发给 Leader 节点。同样的,Leader 节点如果命中则返回,如果不命中则查询底层 MySQL 数据库。

2)写流程:客户端将写请求发送给 router,和读流程一样,会转发到对应的 Follower 节点上。Follower 节点会转发写请求给 Leader 节点,Leader 节点转发给 MySQL,当 MySQL 返回写入成功后,Leader 会清除本地图缓存对应的 Key,并同步给其他所有 Follower 清除掉该 Key,保证数据的最终一致性。

6、高可用设计

REDtao 分为独立的两层:缓存层和持久层。每一层都保证高可用性。

1)自研的分布式缓存:

我们自研了实现图语义的分布式 cache 集群,支持故障自动检测和恢复、水平扩缩容。

它是一个双层 cache,每个分片都有一个 Leader 和若干个 Follower。所有的请求都先发给外层的 Follower,再由 Follower 转发给 Leader。这样的好处是读压力大的时候只需要水平扩展 Follower,单点 Leader 写入的方式也降低了复杂度,更容易实现数据的一致性。

如果一个副本故障,系统会在秒级别内进行切换。当持久层发生故障时,分布式缓存层仍然可以对外提供读取服务。

2)高可用的MySQL集群:

MySQL 集群通过自研的中间件实现了分库分表方案,并支持 MySQL 的水平扩容。每个 MySQL 数据库有若干从库,并且与公司内部其他的 MySQL 运维方案一致,保证高可用性。

3)限流保护功能:

为防止缓存击穿导致 MySQL 突发大量请求,从而导致 MySQL 宕机,我们通过限制每个主节点最大 MySQL 并发请求数来实现限流保护 MySQL。达到最大并发请求限制之后的请求会被挂起等待,直到已有请求被处理返回,或者达到等待超时请求被拒绝不会被继续请求到 MySQL 。限流阈值在线可调,根据 MySQL 集群规模调整对应限制。

为防止爬虫或者作弊用户频繁刷同一条数据,我们利用 REDtaoQueue 顺序执行对写入或者点查同一条边的请求,队列长度会被限制,控制同一时间大量相同的请求执行。相比于单个全局的队列控制所有请求的方式,基于每个请求的队列可以很好地限制单个同一请求,而不影响其他正常请求。

7、高性能设计

数据结构的设计是 REDtao 高性能的重要保证。

我们采用了三层嵌套 HashTable 的设计, 通过根据某个起点 from_id 从第一级 HashTable 中查找到 REDtaoGraph,记录了所有 type 下对应的所有的出边信息。

接着,在第二级 HashTable 中,根据某个 type_id 查找到 AssocType 对应某个 type 下边所有出边的计数、索引以及其他元数据。

最终在最后一级 HashTable ,通过 AssocType 的某个 to_id 查找到最终边信息。

我们记录了创建时间、更新时间、版本、数据以及 REDtaoQueue,time_index 则对应根据创建时间排序列表。

最后一级 HashTable 以及索引限制存储最新的 1000 个边信息,以限制超级点占据过多内存,同时集中提高最新热数据的查询命中率以及效率。REDtaoQueue 用于排队当前某个关系的读写,只记录了当前最后一个请求的元数据。

每次查询或写入时,首先查询 REDtaoAssoc:

  • 1)若缓存不存在,则会首先创建只包含 REDtaoQueue 的对象;
  • 2)若缓存已存在,则会更新队列元数据,将自己设置为队列的最后一个请求,并挂起等待被执行。

通过这种多层 hash+ 跳表的设计,我们能高效地组织点、边、索引、时间序链表之间的关系。内存的申请、释放在同一个线程上完成。

在线上环境中,我们的系统可以在一台 16 核的云厂商虚拟机上跑到 150w 查询请求/s,同时 CPU 利用率仅有 22.5% 。下方是线上集群的一个监控图,单机的 QPS 到达 3w ,每个 RPC 请求聚合了 50 个查询。

 

8、易用性设计

1)丰富的图语义 API :

我们在 REDtao 中封装了 25 个图语义的 API 给业务方使用,满足了业务方的增删改查的需求。业务方无需自行编写 SQL 语句即可实现相应操作,使用方式更加简单和收敛。

2)统一的访问 URL :

由于社区后端数据太大,我们按照不同的服务和优先级拆分成了几个 REDtao 集群。

为了让业务方不感知后端的集群拆分逻辑,我们实现了统一的接入层。

不同的业务方只需使用同一个服务 URL ,通过 SDK 将请求发送到接入层。接入层会接收到不同业务方的图语义的请求,并根据边的类型路由到不同的 REDtao 集群。它通过订阅配置中心,能够实时感知到边的路由关系,从而实现统一的访问 URL,方便业务方使用。

9、数据一致性设计

作为社交图谱数据,数据的一致性至关重要。我们需要严格保证数据的最终一致性以及一定场景下的强一致性。为此,我们采取了以下措施:

1)缓存更新冲突的解决:

REDtao 为每个写入请求生成一个全局递增的唯一版本号。在使用 MySQL 数据更新本地缓存时,需要比较版本号,如果版本号比缓存的数据版本低,则会拒绝此更新请求,以避免冲突。

2)写后读的一致性:

Proxy 会将同一个 fromId 的点或边请求路由到同一个读 cache 节点上,以保证读取数据一致性。

3)主节点异常场景:

Leader 节点收到更新请求后,会将更新请求变为 invalidate cache 请求异步的发送给其他 follower,以保证 follower 上的数据最终一致。在异常情况下,如果 Leader 发送的队列已满导致 invalidate cache 请求丢失,那么会将其他的 follower cache 全部清除掉。

如果 Leader 故障,新选举的 Leader 也会通知其他 follower 将 cache 清除。

此外,Leader 会对访问 MySQL 的请求进行限流,从而保证即使个别分片的cache被清除掉也不会将 MySQL 打崩。

4)少量强一致的请求:

由于 MySQL 的从库也提供读服务,对于少量要求强一致的读请求,客户端可以将请求染上特殊标志,REDtao 会透传该标志,数据库 Proxy 层会根据该标志将读请求转发到 MySQL 主库上,从而保证数据的强一致。

10、 跨云多活设计

跨云多活是公司的重要战略,也是 REDtao 支持的一个重要特性。

REDtao 的跨云多活架构整体如下:

这里不同于 Facebook Tao 的跨云多活实现,Facebook Tao 的跨云多活实现如下图所示。

Facebook 的方案依赖于底层的 MySQL 的主从复制都通过 DTS Replication 来做。而 MySQL 原生的主从复制是自身功能,DTS 服务并不包含 MySQL 的主从复制。该方案需要对 MySQL 和 DTS 做一定的改造。前面说到,我们的缓存和持久层是解藕的,在架构上不一样。

因此,REDtao 的跨云多活架构是我们结合自身场景下的设计,它在不改动现有 MySQL 功能的前提下实现了跨云多活功能。

1)持久层我们通过 MySQL 原生的主从 binlog 同步将数据复制到其他云的从库上。其他云上的写请求和少量要求强一致读将被转发到主库上。正常的读请求将读取本区的 MySQL 数据库,满足读请求对时延的要求。

2)缓存层的数据一致性是通过 MySQL DTS 订阅服务实现的,将 binlog 转换为 invalidate cache 请求,以清理掉本区 REDtao cache 层的 stale 数据。由于读请求会随机读取本区的任何一个 MySQL 数据库,因此 DTS 订阅使用了一个延迟订阅的功能,保证从 binlog 同步最慢的节点中读取日志,避免 DTS 的 invalidate cache 请求和本区 read cache miss 的请求发生冲突从而导致数据不一致。

11、云原生实现

REDtao 的云原生特性重点体现在弹性伸缩、支持多 AZ 和 Region 数据分布、产品可以实现在不同的云厂商间迁移等几个方面。REDtao 在设计之初就考虑到支持弹性扩缩容、故障自动检测及恢复。

随着 Kubernetes 云原生技术越来越成熟,我们也在思考如何利用 k8s 的能力将部署和虚拟机解绑,进一步云原生化,方便在不同的云厂商之间部署和迁移。

REDtao 实现了一个运行在 Kubernetes 集群上的 Operator,以实现更快的部署、扩容和坏机替换。

为了让 k8s 能感知集群分片的分配并且控制同一分片下的 Pods 调度在不同宿主机上,集群分组分片分配由 k8s Operator 渲染并控制创建 DuplicateSet (小红书自研 k8s 资源对象)。

REDtao 则会创建主从并根据 Operator 渲染出来的分片信息创建集群,单个 Pod 故障重启会重新加入集群,无需重新创建整个集群。集群升级时,Operator 通过感知主从分配控制先从后主的顺序,按照分片分配的顺序滚动升级以减少升级期间线上影响。

12、老服务的平滑升级实践

但凡变革,皆属不易。实现全新的 REDtao 只是完成了相对容易的那部分工作。

小红书的社交图谱数据服务已经在 MySQL 上运行多年,有很多不同的业务跑在上面,任何小的问题都会影响到小红书的在线用户。因此,如何保证不停服的情况下让现有业务无感知地迁移到 REDtao 上成为一个非常大的挑战。

我们的迁移工作关键有两点:

1)将老的大 MySQL 集群按优先级拆分成了四个 REDtao 集群。这样,我们可以先将优先级最低的服务迁移到一个 REDtao 集群,充分灰度后再迁移高优先级的集群;

2)专门开发了一个 Tao Proxy SDK,支持对原来的 MySQL 集群和 REDtao 集群进行双写双读,数据校验比对。

迁移时:我们首先将低优先级的数据从 MySQL 通过 DTS 服务迁移到了一个 REDtao 集群,并升级好业务方的 SDK 。DTS 服务一直对增量数据进行同步。业务方 SDK 会订阅配置中心的配置变更,我们修改配置让 Tao Proxy SDK 同时读写 MySQL 集群和 REDtao 集群,并关闭 DTS 服务。此时会使用 MySQL 集群的结果返回给用户。

在停止 DTS 服务时:有可能会有新的 MySQL 数据通过 DTS 同步过来,造成了 REDtao 集群新写的数据被同步过来的老数据覆盖。因此,在关闭 DTS 服务后,我们会通过工具读取开双写之后到关闭 DTS 服务这个时间段的 binlog 对数据进行校验和修复。

修复完成之后:Tao Proxy SDK 的双读会展示两边不一致的数据量,并过滤掉因为双写时延不一致导致数据不一致的请求。灰度一段时间后观察到 diff 的数目基本为 0,将 Tao Proxy SDK 的配置改为只读写新的 REDtao 集群。

最终:我们在 22 年初完成小红书所有核心社交图谱万亿边级别数据的迁移和正确性校验,并做到了整个迁移服务无感知,迁移过程没有发生一起故障。

13、新图存储系统带来的结果和收益

我们的社交图谱数据访问中,90% 以上的请求都是读请求,并且社交图谱的数据有非常强的时间局部性(即最近更新的数据最容易被访问)。REDtao 上线后,获得 90% 以上的 cache 命中率, 对MySQL 的 QPS 降低了 70%+ ,大大降低了 MySQL 的 CPU 使用率。在缩容 MySQL 的副本数目后,整体成本降低了21.3%。‍

业务的访问方式都全部收敛到 REDtao 提供的 API 接口上,在迁移过程中,我们还治理了一些老的不合理访问 MySQL 数据库的方式,以及自定义某些字段赋予特殊含义的不合理做法,通过 REDtao 规范了数据访问。

对比 2022 年初和 2023 年初,随着 DAU 的增长,社交图谱的请求增长了 250% 以上,如果是之前 MySQL 的老架构,扩容资源基本上和请求增长速度成正比,至少需要扩容 1 倍的资源成本(数万核)。

而得益于 REDtao 系统的存在,因其 90% 的缓存命中率,实际上整体成本只增加了 14.7%(数千核)就能扛下 2.5 倍的请求增长。在成本和稳定性上有了较大的提升。

14、未来展望

在较短的时间,我们自研了图存储系统 REDtao ,解决了社交图谱关系数据快速增长的问题。

REDtao 借鉴了 FaceBook Tao 的论文,并对整体架构、跨云多活做了较多的改进,全新实现了一个高性能的分布式图缓存,更加贴合我们自身的业务特点和提供了更好的弹性。同时,利用 k8s 能力进一步实现了云原生化。

随着 DAU 的持续增长,万亿的数据规模也在继续增长,我们也面临着更多的技术挑战。

目前公司内部的 OLTP 图场景主要分为三块:

1)社交图谱数据服务:通过自研图存储系统 REDtao 满足了社交场景超大规模数据的更新与关联读取问题。目前已经存储了万亿规模的关系;

2)风控场景:通过自研图数据库 REDgraph,满足多跳的实时在线查询。目前存储了千亿点和边的关系,满足 2 跳以及 2 跳以上的查询;

3)社交推荐:这块主要是两跳的查询。每天通过 Hive 批量地导入全量的数据,通过 DTS 服务近实时的写入更新数据。因为是在线场景,对时延的要求非常高,当前的 REDgraph 还无法满足这么高的要求,因此业务方主要是用 REDkv 来存储。

针对以上场景:为了快速满足业务需求,我们使用了三套不同的自研存储系统:REDtao 、REDgraph 和 REDkv 。

显然相对于 3 套存储系统,用一个统一的架构和系统去解决这几个图相关的场景是更加合适的。

未来:我们会将 REDgraph 和 REDtao 融合成一个统一的数据库产品,打造业内顶尖的图技术,对公司内部更多的场景进行赋能。

15、相关资料

[1] 以微博类应用场景为例,总结海量社交系统的架构设计步骤

[2] 腾讯技术分享:社交网络图片的带宽压缩技术演进之路

[3] 基于社交网络的Yelp是如何实现海量用户图片的无损压缩的?

[4] 社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等

[5] 社交软件红包技术解密(六):微信红包系统的存储层架构演进实践

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

[7] 渐行渐远的人人网:十年亲历者的互联网社交产品复盘和反思

[8] 中国互联网社交二十年:全民见证的互联网创业演义

[9] 盘点移动互联网时代的社交产品进化史(上篇):谁主沉浮

[10] 盘点移动互联网时代的社交产品进化史(下篇):大浪淘沙


(本文已同步发布于:http://www.52im.net/thread-4495-1-1.html

posted @ 2023-11-09 11:21 Jack Jiang 阅读(110) | 评论 (0)编辑 收藏

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

[- 1 -] 即时通讯安全篇(一):正确地理解和使用Android端加密算法

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

[摘要] 本文主要讨论针对Android这样的移动端应用开发时,如何正确的理解目前常用的加密算法,为诸如即时通讯应用的实战开发,如何在合适的场景下选择适合的算法,提供一些参考。


[- 2 -] 即时通讯安全篇(二):探讨组合加密算法在IM中的应用

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

[摘要] 本文深入分析了即时通信(IM)系统中所面临的各种安全问题,综合利用对称加密算法(DES算法)、公开密钥算法(RSA算法)和Hash算法(MD5)的优点,探讨组合加密算法在即时通信中的应用。


[- 3 -] 即时通讯安全篇(三):常用加解密算法与通讯安全讲解

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

[摘要] 本次着重整理了常见的通讯安全问题和加解密算法知识与即时通讯(IM)开发同行们一起分享和学习。


[- 4 -] 即时通讯安全篇(四):实例分析Android中密钥硬编码的风险

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

[摘要] 本文主要借用乌云上已公布的几个APP漏洞来讲讲这其中的潜在风险和危害。


[- 5 -] 即时通讯安全篇(五):对称加密技术在Android平台上的应用实践

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

[摘要] 本文将重点分享对称加解密技术在Android平台上的实践应用。对于即时通讯社区里的IM、推送技术的开发者同行而言,是不可多得的第一手实践资料,希望对你有用。


[- 6 -] 即时通讯安全篇(六):非对称加密技术的原理与应用实践

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

[摘要] 本文将要分享的是非对称加密技术在当前互联网场景下的应用情况。


[- 7 -] 即时通讯安全篇(七):用JWT技术解决IM系统Socket长连接的身份认证痛点

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

[摘要] 本次分享正是基于此次解决Socket长连接身份安全认证的实践总结而来,方案可能并不完美,但愿能起到抛砖引玉的作用,希望能给您的IM系统开发带来启发。


[- 8 -]  即时通讯安全篇(八):你知道,HTTPS用的是对称加密还是非对称加密?

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

[摘要] 本文将带你了解HTTPS到底用的是对称加密还是非对称加密,以及具体又是怎么使用的。


[- 9 -] 即时通讯安全篇(九):为什么要用HTTPS?深入浅出,探密短连接的安全性

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

[摘要] 今天就借此机会,跟大家一起深入学习一下HTTPS的相关知识,包括HTTP的发展历程、HTTP遇到的问题、对称与非对称加密算法、数字签名、第三方证书颁发机构等概念。


[- 10 -] 即时通讯安全篇(十):IM聊天系统安全手段之通信连接层加密技术

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

[摘要] 本篇文章将围绕IM通信连接层的安全问题及实现方案,聚焦IM网络“链路安全”,希望能带给你启发 。


[- 11 -] 即时通讯安全篇(十一):IM聊天系统安全手段之传输内容端到端加密技术

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

[摘要] 本篇将围绕IM传输内容的安全问题,以实践为基础,为你分享即时通讯应用中的“端到端”加密技术。


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

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

[摘要] 本文将简要介绍Java平台的SSL/TLS实现并以Demo示例的方式予以讲解。


[- 13 -] 理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)

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

[摘要] 本文将以理论联系实际的方式,详细讲解一套典型IM的通信协议设计的方方面面。


👉52im社区本周新文:《小红书万亿级社交网络关系下的图存储系统的架构设计与实践http://www.52im.net/thread-4495-1-1.html》,欢迎阅读!👈

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

posted @ 2023-11-06 13:45 Jack Jiang 阅读(51) | 评论 (0)编辑 收藏

     摘要: 本文由得物技术WWQ分享,原题“客服发送一条消息背后的技术和思”,本文有修订和改动。1、引言在企业IM客服场景中,客服发送一条消息的背后,需要考虑网络通信、前端展示、后端存储以及安全性等多个方面的技术支持。单从前端层面来说,就需要考虑到消息的显示、状态更新、稳定传输以及极限操作消息不卡顿等场景。随着IM系统的不断更新迭代,已经实现了从外采到自研再到一站式全场景工作台的搭建,...  阅读全文

posted @ 2023-11-02 11:02 Jack Jiang 阅读(152) | 评论 (0)编辑 收藏

关于MobileIMSDK

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

工程开源地址是:


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


v8.0 版更新内容

此版更新内容更多历史更新日志):

  • 1)[新增] 新增了“群名片”功能;
  • 2)[新增] 新增了消息转发功能;
  • 3)[新增] 安全提升,启用了AppKey校验机制;
  • 4)[优化] 安全提升,优化了http接口、文件上传接口、socket长连接的token校验逻辑;
  • 5)[优化] 更换了新的高德地图websevice key;
  • 6)[优化] 其它ui细节和bug优化等。

此版新增功能运行截图(更多截图点此查看):

posted @ 2023-11-01 11:46 Jack Jiang 阅读(57) | 评论 (0)编辑 收藏

     摘要: 本文由序员先生分享,原题“技术解读企业微信之四维关系链”,本文有修订和改动。1、引言3年疫情后的中国社会,最大的永久性变化之一,就是大多数的企业、教育机构或者政务机构,都用上了综合性的SaaS在线办公系统。而这其中,企业微信的覆盖率非常高,而且其占比还在不断增长。越来越多的人因此好奇,开始想要更深度的了解企业微信,自然也就有越来越多的人开始解读企业微信。而解读的角度,五花八...  阅读全文

posted @ 2023-10-26 10:36 Jack Jiang 阅读(77) | 评论 (0)编辑 收藏

     摘要: 本文由大淘宝终端平台技术团队沈良炜(沛轩)分享,本文有修订和改动。1、引言自 2013 年 ALLIN 无线到今天,已经走过 10 个年头,淘宝终端统一网络库 AWCN (Ali Wireless Connection Network) 从淘内孵化,一路过来伴随着淘宝业务的发展,经历集团 IPv6 战役、协议升级演进等,逐步沉淀为阿里集团终端网络通用解决方案,是兼具高性能、多协议、可容灾、可观测的...  阅读全文

posted @ 2023-10-19 14:10 Jack Jiang 阅读(132) | 评论 (0)编辑 收藏

本文由百度技术王伟分享,原题“视频中为什么需要这么多的颜色空间?”,本文收录时有修订和改动。

1、引言

在视频处理中,我们经常会用到不同的色彩空间:非线性RGB,线性 RGB,YUV,XYZ……为什么需要这么多的色彩空间呢?为什么在 FFMpeg 中会有 color_space,color_transfer,color_primaries 等一系列的颜色属性呢?这些术语之间究竟隐藏着什么秘密?

本文将以通俗易懂的文字,引导你理解视频是如何从采集开始,历经各种步骤,最终通过颜色模型转换和不同的色域转换,让你看到赏心悦目的视频结果的。

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4467-1-1.html

2、系列文章

本文是系列文章中的第20篇,本系列文章的大纲如下:

即时通讯音视频开发(一):视频编解码之理论概述

即时通讯音视频开发(二):视频编解码之数字视频介绍

即时通讯音视频开发(三):视频编解码之编码基础

即时通讯音视频开发(四):视频编解码之预测技术介绍

即时通讯音视频开发(五):认识主流视频编码技术H.264

即时通讯音视频开发(六):如何开始音频编解码技术的学习

即时通讯音视频开发(七):音频基础及编码原理入门

即时通讯音视频开发(八):常见的实时语音通讯编码标准

即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述

即时通讯音视频开发(十):实时语音通讯的回音消除技术详解

即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解

即时通讯音视频开发(十二):多人实时音视频聊天架构探讨

即时通讯音视频开发(十三):实时视频编码H.264的特点与优势

即时通讯音视频开发(十四):实时音视频数据传输协议介绍

即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况

即时通讯音视频开发(十六):移动端实时音视频开发的几个建议

即时通讯音视频开发(十七):视频编码H.264、V8的前世今生

即时通讯音视频开发(十八):详解音频编解码的原理、演进和应用选型

即时通讯音视频开发(十九):零基础,史上最通俗视频编码技术入门

即时通讯音视频开发(二十):一文读懂视频的颜色模型转换和色域转换》(* 本文

3、视频采集

如上图所示,在相机系统中,外部世界的光信息(光子,photons)通过透镜或其他光学器件聚焦之后达到相机的图像传感器(CCD 或者 CMOS)。

过程是这样的:

  • 1)图像传感器可以将一个入射光子(photon)转换为对应的一个电子(electron);
  • 2)在曝光时间内,图像传感器对转换的电子进行电荷积累;
  • 3)然后,图像传感器会将积累的电荷信号转换成对应的电压信号;
  • 4)最后,利用 ADC 把电信号转换成数字信号,而转换后的数字信号则为某个范围内的整数值。

ADC 数字信号的取值范围 :

[pquote]ADC 转换之后的数字信号的取值范围受限于 ADC 设备。对于 8-bits 的 ADC 而言,数字信号的取值范围为 [0, 2^8-1],因此,对于每一个像素而言,会用 [0, 255] 之间的整数来进行编码。[/pquote]

ADC 转换的数字信号的数值是一个线性编码的过程,这意味着如果将图像传感器上的光量增加 1 倍,则 ADC 转换之后对应的数值也会增加 1 倍。

这是一个非常有用的特性:无论是增加物理世界的光量,还是增加 ADC 转换之后的数值,对图片而言,都会带来相同的效果。线性编码意味着我们所处理的数据和光发射的强度成正比关系。

由数码相机中的 CMOS 传感器产生并写入原始文件(Raw File)的数据是线性的。与普通照片相比,线性数据通常看起来非常暗且对比度较低。

在 iPhone 手机中,可以通过设置相机来拍摄 Apple ProRAW 格式的照片。

4、探索视频伽马校正

研究表明:人类视觉系统是以对数函数的方式来感知光亮度。这意味着:人眼会提高暗部的敏感度,降低高光部分的敏感度。

从数学角度看,感知光强度和测量光强度之间存在一个*似的*方关系,具体如下式所示。

由于人类视觉感知系统不是以线性方式工作的,因此必须使用非线性曲线来对 ADC 生成的的线性数据进行变换,从而使得拍摄的图像色调与我们的视觉系统的工作方式相匹配。这个过程也就是我们所说的 伽马校正。

因此:在从线性 RGB 空间转换到非线性 RGB 空间时,需要 γ 作为转换参数。相机中的 ISP 模块负责对图像传感器的线性 RGB 进行伽马校正进而产生对应的符合人眼感知的非线性 RGB 数据。

RGB 的设备依赖性 :

不同显示设备支持的色域空间不同,因此对于不同的显示设备而言,伽马校正之后的 RGB 数值也不同。从这个角度讲,RGB 是设备依赖型的色彩空间。

5、视频压缩

根据如上的信息,我们知道:相机系统经过 ISP 处理之后,最终会得到非线性的 RGB 信息。对于视频而言,如果以 RGB 存储每帧的信息,则需要消耗大量的存储空间。

人类视觉系统对颜色信息的敏感度要弱于亮度信息。利用这一特点,通常相机会将捕获的 RGB 信息转换为 YUV 格式,然后对 YUV 格式进行色度信息采样(例如,YUV420)以便压缩图像空间。

RGB->YUV,不同标准有不同要求,一般常用的标准有:

  • 1)BT. 601(SD: Standard-Definition);
  • 2)BT. 709(HD: High-Definition);
  • 3)BT. 2020(UHD: Ultra-High-Definition)。

注意 :

标准中,不但会规定 RGB->YUV 的转换系数,同时还会规定从线性 RGB 到非线性 RGB 转换的 gamma 系数。

将 RGB颜色模型,转换成 YUV 模型后,接下来会采用某种视频编解码算法(例如,H265, VP9)对获取的数据进行视频编码,最终得到视频文件(此处忽略了音频的采集编码以及合流的操作)。

6、视频转码

出于各种原因,例如:

  • 1)终端用户的带宽受限;
  • 2)终端用户支持的视频编解码算法和相机压缩视频的编解码算法不一致;
  • 3)……

一般不会直接把相机产出的视频文件分发给用户去消费。媒体服务商会对相机生成的视频文件进行转码,然后选择合适的转码后的视频分发给终端消费用户。

在视频转码阶段,如果我们希望对原视频进行色域的变换,例如从 BT. 601 转码为 BT. 709,则需要在不同色域的 RGB 数值之间进行转换。

在不同的色域空间进行 RGB 数据的转换,这也就是我们所说的 色彩管理。色彩管理会对图像进行色彩管理以适配当前环境下的颜色效果,从而保证同一张图片在不同输入、输出上都呈现出最好的颜色。

色彩转换需要在某个线性空间下进行操作,并且操作过程需要保持设备的独立性。因此,不同的 RGB 色域空间是不能直接进行转换的,需要一个设备无关、线性的颜色模型作为中转才能实现其转换。

而 XYZ(CIE 1931 XYZ color space)具备设备无关、线性操作的特性。

在 FFMpeg 中,主要使用 colorspace 滤镜 来完成不同色域空间的转换。

根据 colorspace 的实现可知,在 FFMpeg 中,BT. 601->BT. 709 的转换过程如下所示:

在如上的变换中,涉及到 3 个颜色空间的转换,分别是:

  • 1)YUV 和 RGB 之间的转换;
  • 2)线性 RGB 和非线性 RGB 之间的转换;
  • 3)线性 RGB 和 XYZ 之间的转换。

在 FFMpeg 中,所有的这些转换参数都保存在 AVFrame 结构中:

  • 1)AVFrame->colorspace 中保存了 YUV/RGB 的转换矩阵;
  • 2)AVFrame->color_trc 中保存了线性 RGB 和非线性 RGB 之间的转换函数(transformation characteristics);
  • 3)AVFrame->color_primaries 中保存了 RGB/XYZ 的转换矩阵;

如果用 ffprobe 命令解析视频文件,则:

  • 1)color_space 字段对应 YUV/RGB 的转换矩阵;
  • 2)color_transfer 字段对应线性 RGB 和非线性 RGB 之间的转换函数;
  • 3)color_primaries 字段对应 RGB/XYZ 的转换矩阵。

$ ffprobe -select_streams v:0 -show_entries stream=color_space,color_transfer,color_primaries test.mp4

 

[STREAM]

color_space=bt2020nc

color_transfer=arib-std-b67

color_primaries=bt2020

[/STREAM]

在如上的例子中,arib-std-b67 也就是我们所熟悉的 HLG。

在 MediaInfo 中:

  • 1)Matrix coefficients 字段对应 YUV/RGB 的转换矩阵;
  • 2)Transfer characteristic 字段对应线性 RGB 和非线性 RGB 之间的转换函数;
  • 3)Color primaries 字段对应 RGB/XYZ 的转换矩阵。

除了如上的参数外,AVFrame->range 还用来存储视频中对应像素的每个分量的取值范围。

在 vf_setparams.c 中也作了相关的定义说明:

{"limited", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  0, 0, FLAGS, "range"},

{"tv",      NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  0, 0, FLAGS, "range"},

{"mpeg",    NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  0, 0, FLAGS, "range"},

{"full",    NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  0, 0, FLAGS, "range"},

{"pc",      NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  0, 0, FLAGS, "range"},

{"jpeg",    NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  0, 0, FLAGS, "range"},

7、视频解码&播放

7.1基本

转码之后的视频,可以通过各种渠道分发到终端用户进行消费。

对于大部分显示设备,例如CRT显示器、LCD、OLED,屏幕上的每个像素都是通过驱动三个非常靠*但仍然分开的小型 RGB 光源而构建的。

因此:显示屏(监视器、电视机、屏幕等等)仅使用 RGB 模型,并以不同的方式来组织,并显示最终的图像。

如前所述:不同的显示设备采用的 RGB 的色域并不一定相同,因此,RGB 是一种设备依赖型的颜色模型。在 Mac 电脑上,可以通过显示器配置来选择显示器支持不同的 RGB 色域。

7.2显示设备和相机的色域一致

如果编码视频和播放视频的显示器采用的 RGB 色域是一致的,比如都是 sRGB,此时的播放过程相对比较简单。

视频解码之后:得到 YUV 数据,然后根据标准将 YUV 数据转换成非线性的 sRGB 数据,然后显示器根据 sRGB 数据显示图像即可。

7.3显示设备和相机的色域不一致

当显示设备支持的色域从 sRGB 变为 Rec. 2020 时,如果直接显示 sRGB 色域下的数据,则会导致比较严重的颜色失真。

和转码阶段的色域转换类似,此时,也需要在不同的色域空间进行 RGB 数据的转换(色彩管理)以保证相同的视频在不同输入、输出、显示设备上都呈现出最好的颜色。

对于显示设备而言,sRGB->RGB(Rec. 2020)的转换过程如下所示:

因此:对于拍摄设备和显示设备的色域不同时,视频的播放增加了颜色管理的过程。

8、视频观看

虽然视频信息的采集和最终终端播放采用的都是 RGB 的颜色模型,但是对人眼而言,RGB 其实并不直观,比如我们很难马上反应出天青色的 RGB 色值?

为了能够更直观的表示颜色,又引入了 HSL 色彩模型。

HSL 比 RGB 更加直观,比如:想从黄色过度到红色,只需要调整色相即可,饱和度和亮度保持不变。因此,HSL 一般更适合人的色彩感知,而 RGB 更适合显示领域。

为了让作品可以呈现出期望的效果,提升用户的视觉体验,在摄影后期,使用 HSL 对作品进行调整是最方便的一种方式。利用 HSL 对作品进行调整,简单几步就可以让灰暗的「马路随拍」秒变「街头大片」。

FFMpeg 的 signalstats 滤镜可以分析获取视频的色调、饱和度、亮度信息。但是该滤镜获取的色调、饱和度和 HSL 中的计算 是不一致的。

signalstats 计算色调、饱和度的算法如下所示:

如果需要得到视频的标准 HSL 信息,可以使用作者开发的 vf_hsl 滤镜。

9、本文小结

虽然颜色还是那个颜色,但是不同的颜色空间的适用范围并不相同。

具体是:

  • 1)RGB:面向采集和显示设备;
  • 2)YUV:面向存储;
  • 3)HSL:面向人类视觉感知;
  • 4)XYZ:RGB之间的转换桥梁。

从视频采集到视频消费的整个过程,涉及到不同的设备和标准,而不同的设备和标准所支持的色域空间又不相同。

正是通过不同的颜色模型转换和不同的色域转换,才得以让我们实现:在不同输入、输出、显示设备上都呈现出最好的颜色,并以*似相同的观看体验来消费视频。

10、参考文献

[1] CMOS Image Sensor原理简述

[2] 数字视频导论

[3] 用HSL调色=简单、快速、超出片

[4] 零基础入门:实时音视频技术基础知识全面盘点

[5] 实时音视频面视必备:快速掌握11个视频技术相关的基础概念

[6] 轻松诙谐,讲解视频编解码技术的过去、现在和将来

[7] 写给小白的实时音视频技术入门提纲

[8] 福利贴:最全实时音视频开发要用到的开源工程汇总

[9] 详解音频编解码的原理、演进和应用选型

[10] 零基础,史上最通俗视频编码技术入门


(本文已同步发布于:http://www.52im.net/thread-4467-1-1.html

posted @ 2023-10-12 11:20 Jack Jiang 阅读(58) | 评论 (0)编辑 收藏

一、更新内容简介

本次更新为次要版本更新,进行了若干优化(更新历史详见:码云 Release NotesGithub Release Notes)。MobileIMSDK 可能是市面上唯一同时支持 UDP+TCP+WebSocket 三种协议的同类开源IM框架。

二、MobileIMSDK简介

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

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

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

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

三、源码托管同步更新

OsChina.net

GitHub.com

四、MobileIMSDK设计目标

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

五、MobileIMSDK框架组成

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

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

整套MobileIMSDK框架的架构组成:

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

六、MobileIMSDK v6.4更新内容 

【重要说明】:

MobileIMSDK v6.4 为次要版本,进行了若干优化! 查看详情 (github

【新增重要特性】:

【解决的Bug】:

  • 1. [Uniapp端] 解决了Demo界面右上角的连接状态title无法更新的问题;
  • 2. [服务端] 解决桥接模式下与最新rabbitmq库不兼容从而断线重连不成功,导致MQ中消息堆积的问题。

【其它优化和提升】:

  • 1. [服务端] 解决登陆连接指令中的一处潜在空指针风险;
  • 2. [微信小程序端] 优化自带Demo中聊天主界面flex布局下的中部聊天列表高度自适应能力;
  • 3. [微信小程序端/H5端] 优化了Demo中的CSS代码;
  • 4. [微信小程序端/H5端] 优化了WebSocket的关闭逻辑,确保标准API中的close方法因异步调用带来socket实例被错误重置的问题;
  • 5. [H5端] 为Demo增加了消息送达状态图标的显示(包括发送中、发送成功、发送失败3种状态);
  • 6. [H5端] 重新设计了Demo的登录界面;
  • 7. [服务端] 升级amqp-client库至5.x版;
  • 8. [服务端] 解决桥接模式下MQ断线自动恢复时消费者Chennal未主动清理,导致channel越来越多的问题(无消费者与其关联的空channel):
  • 9. [Android] 提升targetSdkVersion至33(即Android 13);
  • 10. [Android] 升级开发工程使之支持最新Android Studio Giraffe和Gradle 8.1.1;

【最新版本源码地址】:

posted @ 2023-10-07 12:27 Jack Jiang 阅读(112) | 评论 (0)编辑 收藏

     摘要: 本文由字节教育-成人与创新前端团队分享,本文有修订和改动。1、引言作为开发人员,工作中我们可能会遇到以下问题:1)可能你知道 JavaScript 中 '😁'.length = 2,但 '👨👩👧👦'.length 呢?2)困惑于 Unicode 和 UTF-8 的关系?3)学计算机时会遇到这样的提问:一个汉字是几个字节?4)读取二进制数据时,为何有大端序小端序的分别?5)为何 UTF-8...  阅读全文

posted @ 2023-09-28 11:20 Jack Jiang 阅读(81) | 评论 (0)编辑 收藏

本文由阮一峰(ruanyifeng.com)分享,本文收录时有内容修订和排版优化。

1、引言

今天中午,我突然想搞清楚 Unicode 和 UTF-8 之间的关系,就开始查资料。

这个问题比我想象的复杂,午饭后一直看到晚上9点,才算初步搞清楚。

下面就是我的总结,主要用来整理自己的思路。我尽量写得通俗易懂,希望能对其他朋友有用。毕竟,字符编码是计算机技术的基石,对于程序员来说尤其重要,字符编码的知识是必须要懂的。

 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4433-1-1.html

2、专题目录

本文是“字符编码技术专题”系列文章的第 1 篇,总目录如下:

3、基础知识

计算机中储存的信息都是用二进制数表示的;而我们在屏幕上看到的英文、汉字等字符是二进制数转换之后的结果。通俗的说,按照何种规则将字符存储在计算机中,如'a'用什么表示,称为"编码";反之,将存储在计算机中的二进制数解析显示出来,称为"解码",如同密码学中的加密和解密。在解码过程中,如果使用了错误的解码规则,则导致'a'解析成'b'或者乱码。

字符集(Charset):是一个系统支持的所有抽象字符的集合。字符是各种文字和符号的总称,包括各国家文字、标点符号、图形符号、数字等。

字符编码(Character Encoding):是一套法则,使用该法则能够对自然语言的字符的一个集合(如字母表或音节表),与其他东西的一个集合(如号码或电脉冲)进行配对。即在符号集合与数字系统之间建立对应关系,它是信息处理的一项*本技术。通常人们用符号集合(一般情况下就是文字)来表达信息。而以计算机为*础的信息处理系统则是利用元件(硬件)不同状态的组合来存储和处理信息的。元件不同状态的组合能代表数字系统的数字,因此字符编码就是将符号转换为计算机可以接受的数字系统的数,称为数字代码。

常见字符集名称:ASCII字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。计算机要准确的处理各种字符集文字,需要进行字符编码,以便计算机能够识别和存储各种文字。

4、ASCII 码

我们知道,计算机内部,所有信息最终都是一个二进制值。每一个二进制位(bit)有0和1两种状态,因此八个二进制位就可以组合出256种状态,这被称为一个字节(byte)。也就是说,一个字节一共可以用来表示256种不同的状态,每一个状态对应一个符号,就是256个符号,从00000000到11111111。

上个世纪60年代,美国制定了一套字符编码,对英语字符与二进制位之间的关系,做了统一规定。这被称为 ASCII 码,一直沿用至今。

ASCII 码一共规定了128个字符的编码,比如空格SPACE是32(二进制00100000),大写的字母A是65(二进制01000001)。这128个符号(包括32个不能打印出来的控制符号),只占用了一个字节的后面7位,最前面的一位统一规定为0。

▲ ASCII编码表

5、非 ASCII 编码

英语用128个符号编码就够了,但是用来表示其他语言,128个符号是不够的。比如,在法语中,字母上方有注音符号,它就无法用 ASCII 码表示。于是,一些欧洲国家就决定,利用字节中闲置的最高位编入新的符号。比如,法语中的é的编码为130(二进制10000010)。这样一来,这些欧洲国家使用的编码体系,可以表示最多256个符号。

▲ 扩展ASCII编码表

但是,这里又出现了新的问题。不同的国家有不同的字母,因此,哪怕它们都使用256个符号的编码方式,代表的字母却不一样。比如,130在法语编码中代表了é,在希伯来语编码中却代表了字母Gimel (ג),在俄语编码中又会代表另一个符号。但是不管怎样,所有这些编码方式中,0--127表示的符号是一样的,不一样的只是128--255的这一段。

至于亚洲国家的文字,使用的符号就更多了,汉字就多达10万左右。一个字节只能表示256种符号,肯定是不够的,就必须使用多个字节表达一个符号。比如,简体中文常见的编码方式是 GB2312,使用两个字节表示一个汉字,所以理论上最多可以表示 256 x 256 = 65536 个符号。

中文编码的问题比较复杂,将在文末讨论。这里先了解下,虽然都是用多个字节表示一个符号,但是GB类的汉字编码与后文的 Unicode 和 UTF-8 是毫无关系的。

6、Unicode

正如上一节所说,世界上存在着多种编码方式,同一个二进制数字可以被解释成不同的符号。因此,要想打开一个文本文件,就必须知道它的编码方式,否则用错误的编码方式解读,就会出现乱码。为什么电子邮件常常出现乱码?就是因为发信人和收信人使用的编码方式不一样。

可以想象,如果有一种编码,将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码,那么乱码问题就会消失。这就是 Unicode,就像它的名字都表示的,这是一种所有符号的编码。

Unicode 当然是一个很大的集合,现在的规模可以容纳100多万个符号。每个符号的编码都不一样,比如,U+0639表示阿拉伯字母Ain,U+0041表示英语的大写字母A,U+4E25表示汉字严。具体的符号对应表,可以查询unicode.org,或者专门的汉字对应表

7、Unicode 的问题

需要注意的是,Unicode 只是一个符号集,它只规定了符号的二进制代码,却没有规定这个二进制代码应该如何存储。

比如,汉字严的 Unicode 是十六进制数4E25,转换成二进制数足足有15位(100111000100101),也就是说,这个符号的表示至少需要2个字节。表示其他更大的符号,可能需要3个字节或者4个字节,甚至更多。

这里就有两个严重的问题,第一个问题是,如何才能区别 Unicode 和 ASCII ?计算机怎么知道三个字节表示一个符号,而不是分别表示三个符号呢?第二个问题是,我们已经知道,英文字母只用一个字节表示就够了,如果 Unicode 统一规定,每个符号用三个或四个字节表示,那么每个英文字母前都必然有二到三个字节是0,这对于存储来说是极大的浪费,文本文件的大小会因此大出二三倍,这是无法接受的。

它们造成的结果是:1)出现了 Unicode 的多种存储方式,也就是说有许多种不同的二进制格式,可以用来表示 Unicode。2)Unicode 在很长一段时间内无法推广,直到互联网的出现。

8、UTF-8

互联网的普及,强烈要求出现一种统一的编码方式。UTF-8 就是在互联网上使用最广的一种 Unicode 的实现方式。其他实现方式还包括 UTF-16(字符用两个字节或四个字节表示)和 UTF-32(字符用四个字节表示),不过在互联网上*本不用。重复一遍,这里的关系是,UTF-8 是 Unicode 的实现方式之一。

UTF-8 最大的一个特点,就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号,根据不同的符号而变化字节长度。

UTF-8 的编码规则很简单,只有二条:

  • 1)对于单字节的符号:字节的第一位设为0,后面7位为这个符号的 Unicode 码。因此对于英语字母,UTF-8 编码和 ASCII 码是相同的;
  • 2)对于n字节的符号(n > 1):第一个字节的前n位都设为1,第n + 1位设为0,后面字节的前两位一律设为10。剩下的没有提及的二进制位,全部为这个符号的 Unicode 码。

下表总结了编码规则,字母x表示可用编码的位:

跟据上表,解读 UTF-8 编码非常简单。如果一个字节的第一位是0,则这个字节单独就是一个字符;如果第一位是1,则连续有多少个1,就表示当前字符占用多少个字节。

下面,还是以汉字严为例,演示如何实现 UTF-8 编码。

严的 Unicode 是4E25(100111000100101),根据上表,可以发现4E25处在第三行的范围内(0000 0800 - 0000 FFFF),因此严的 UTF-8 编码需要三个字节,即格式是1110xxxx 10xxxxxx 10xxxxxx。然后,从严的最后一个二进制位开始,依次从后向前填入格式中的x,多出的位补0。这样就得到了,严的 UTF-8 编码是11100100 10111000 10100101,转换成十六进制就是E4B8A5。

9、Unicode 与 UTF-8 之间的转换

通过上一节的例子,可以看到严的 Unicode码 是4E25,UTF-8 编码是E4B8A5,两者是不一样的。它们之间的转换可以通过程序实现。

Windows平台,有一个最简单的转化方法,就是使用内置的记事本小程序notepad.exe。打开文件后,点击文件菜单中的另存为命令,会跳出一个对话框,在最底部有一个编码的下拉条。

里面有四个选项:ANSI,Unicode,Unicode big endian和UTF-8

  • 1)ANSI是默认的编码方式:对于英文文件是ASCII编码,对于简体中文文件是GB2312编码(只针对 Windows 简体中文版,如果是繁体中文版会采用 Big5 码);
  • 2)Unicode编码这里指的是notepad.exe使用的 UCS-2 编码方式:即直接用两个字节存入字符的 Unicode 码,这个选项用的 little endian 格式;
  • 3)Unicode big endian编码与上一个选项相对应:我在下一节会解释 little endian 和 big endian 的涵义;
  • 4)UTF-8编码:也就是上一节谈到的编码方法。

选择完"编码方式"后,点击"保存"按钮,文件的编码方式就立刻转换好了。

10、Little endian 和 Big endian

上一节已经提到,UCS-2 格式可以存储 Unicode 码(码点不超过0xFFFF)。以汉字严为例,Unicode 码是4E25,需要用两个字节存储,一个字节是4E,另一个字节是25。存储的时候,4E在前,25在后,这就是 Big endian 方式;25在前,4E在后,这是 Little endian 方式。

这两个古怪的名称来自英国作家斯威夫特的《格列佛游记》。在该书中,小人国里爆发了内战,战争起因是人们争论,吃鸡蛋时究竟是从大头(Big-endian)敲开还是从小头(Little-endian)敲开。为了这件事情,前后爆发了六次战争,一个皇帝送了命,另一个皇帝丢了王位。

第一个字节在前,就是"大头方式"(Big endian),第二个字节在前就是"小头方式"(Little endian)。

那么很自然的,就会出现一个问题:计算机怎么知道某一个文件到底采用哪一种方式编码?

Unicode 规范定义,每一个文件的最前面分别加入一个表示编码顺序的字符,这个字符的名字叫做"零宽度非换行空格"(zero width no-break space),用FEFF表示。这正好是两个字节,而且FF比FE大1。

如果一个文本文件的头两个字节是FE FF,就表示该文件采用大头方式;如果头两个字节是FF FE,就表示该文件采用小头方式。

11、实例讲解

下面,举一个实例。

打开"记事本"程序notepad.exe,新建一个文本文件,内容就是一个严字,依次采用ANSI,Unicode,Unicode big endian和UTF-8编码方式保存。

然后,用文本编辑软件UltraEdit 中的"十六进制功能",观察该文件的内部编码方式:

  • 1)ANSI:文件的编码就是两个字节D1 CF,这正是严的 GB2312 编码,这也暗示 GB2312 是采用大头方式存储的。
  • 2)Unicode:编码是四个字节FF FE 25 4E,其中FF FE表明是小头方式存储,真正的编码是4E25。
  • 3)Unicode big endian:编码是四个字节FE FF 4E 25,其中FE FF表明是大头方式存储。
  • 4)UTF-8:编码是六个字节EF BB BF E4 B8 A5,前三个字节EF BB BF表示这是UTF-8编码,后三个E4B8A5就是严的具体编码,它的存储顺序与编码顺序是一致的。

UltraEdit下载地址请至官网:https://www.ultraedit.com/

▲ UltraEdit软件

12、最后简要看看中文字符集和编码

12.1GB系列字符集&编码

计算机发明之处及后面很长一段时间,只用应用于美国及西方一些发达国家,ASCII能够很好满足用户的需求。但是当天朝也有了计算机之后,为了显示中文,必须设计一套编码规则用于将汉字转换为计算机可以接受的数字系统的数。

天朝专家把那些127号之后的奇异符号们(即EASCII)取消掉,规定:一个小于127的字符的意义与原来相同,但两个大于127的字符连在一起时,就表示一个汉字,前面的一个字节(他称之为高字节)从0xA1用到 0xF7,后面一个字节(低字节)从0xA1到0xFE,这样我们就可以组合出大约7000多个简体汉字了。在这些编码里,还把数学符号、罗马希腊的 字母、日文的假名们都编进去了,连在ASCII里本来就有的数字、标点、字母都统统重新编了两个字节长的编码,这就是常说的"全角"字符,而原来在127号以下的那些就叫"半角"字符了。

上述编码规则就是GB2312。GB2312或GB2312-80是中国国家标准简体中文字符集,全称《信息交换用汉字编码字符集·*本集》,又称GB0,由中国国家标准总局发布,1981年5月1日实施。GB2312编码通行于中国大陆;新加坡等地也采用此编码。中国大陆几乎所有的中文系统和国际化的软件都支持GB2312。GB2312的出现,*本满足了汉字的计算机处理需要,它所收录的汉字已经覆盖中国大陆99.75%的使用频率。对于人名、古汉语等方面出现的罕用字,GB2312不能处理,这导致了后来GBK及GB 18030汉字字符集的出现。下图是GB2312编码的开始部分(由于其非常庞大,只列举开始部分,具体可查看GB2312简体中文编码表)。

▲ GB2312编码表的开始部分

由于GB 2312-80只收录6763个汉字,有不少汉字,如部分在GB 2312-80推出以后才简化的汉字(如"啰"),部分人名用字(如中国前总理***的"*"字),台湾及香港使用的繁体字,日语及朝鲜语汉字等,并未有收录在内。于是厂商微软利用GB 2312-80未使用的编码空间,收录GB 13000.1-93全部字符制定了GBK编码。根据微软资料,GBK是对GB2312-80的扩展,也就是CP936字码表 (Code Page 936)的扩展(之前CP936和GB 2312-80一模一样),最早实现于Windows 95简体中文版。虽然GBK收录GB 13000.1-93的全部字符,但编码方式并不相同。GBK自身并非国家标准,只是曾由国家技术监督局标准化司、电子工业部科技与质量监督司公布为"技术规范指导性文件"。原始GB13000一直未被业界采用,后续国家标准GB18030技术上兼容GBK而非GB13000。

GB 18030,全称:国家标准GB 18030-2005《信息技术 中文编码字符集》,是中华人民共和国现时最新的内码字集,是GB 18030-2000《信息技术 信息交换用汉字编码字符集 *本集的扩充》的修订版。与GB 2312-1980完全兼容,与GBK*本兼容,支持GB 13000及Unicode的全部统一汉字,共收录汉字70244个。

GB 18030主要有以下特点:

  • 与UTF-8相同,采用多字节编码,每个字可以由1个、2个或4个字节组成;
  • 编码空间庞大,最多可定义161万个字符;
  • 支持中国国内少数民族的文字,不需要动用造字区;
  • 汉字收录范围包含繁体汉字以及日韩汉字。

▲ GB18030编码总体结构

本规格的初版使中华人民共和国信息产业部电子工业标准化研究所起草,由国家质量技术监督局于2000年3月17日发布。现行版本为国家质量监督检验总局和中国国家标准化管理委员会于2005年11月8日发布,2006年5月1日实施。此规格为在中国境内所有软件产品支持的强制规格。

12.2BIG5字符集&编码

Big5,又称为大五码或五大码,是使用繁体中文(正体中文)社区中最常用的电脑汉字字符集标准,共收录13,060个汉字。中文码分为内码及交换码两类,Big5属中文内码,知名的中文交换码有CCCII、CNS11643。Big5虽普及于台湾、香港与澳门等繁体中文通行区,但长期以来并非当地的国家标准,而只是业界标准。倚天中文系统、Windows等主要系统的字符集都是以Big5为*准,但厂商又各自增加不同的造字与造字区,派生成多种不同版本。2003年,Big5被收录到CNS11643中文标准交换码的附录当中,取得了较正式的地位。这个最新版本被称为Big5-2003。

Big5码是一套双字节字符集,使用了双八码存储方法,以两个字节来安放一个字。第一个字节称为"高位字节",第二个字节称为"低位字节"。"高位字节"使用了0x81-0xFE,"低位字节"使用了0x40-0x7E,及0xA1-0xFE。

有关Big5的更多技术细节读者可单独深入研究,本文就不赘述了。

13、本文小结

这些字符集和编码的关系很容易让程序员混淆,现在小结一下。

简单来说:Unicode、GBK和Big5码等就是编码的值(也就是术语“字符集”),而UTF-8、UTF-16、UTF32之类就是这个值的表现形式(即术语“编码格式”)。

另外:Unicode、GBK和Big5码等字符集是不兼容的,同一个汉字在这三个字符集里的码值是完全不一样的。如"汉"的Unicode值与gbk就是不一样的,假设Unicode为a040,GBK为b030。以UTF-8为例,UTF-8码完全只针对Unicode来组织的,如果GBK要转UTF-8必须先转Unicode码,再转UTF-8就OK了。

即GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换:

1)GBK、GB2312 --先转--> Unicode --再转--> UTF8

2)UTF8 --先转--> Unicode --再转--> GBK、GB2312

附录:更多IM技术精华文章

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

[2] 零*础IM开发入门(一):什么是IM系统?

[3] 零*础IM开发入门(二):什么是IM系统的实时性?

[4] 零*础IM开发入门(三):什么是IM系统的可靠性?

[5] 零*础IM开发入门(四):什么是IM系统的消息时序一致性?

[6] 移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

[7] 移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

[8] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

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

[10] 史上最通俗Netty框架入门长文:*本介绍、环境搭建、动手实战

[11] 强列建议将Protobuf作为你的即时通讯应用数据传输格式

[12] IM通讯协议专题学习(一):Protobuf从入门到精通,一篇就够!

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

[14] 探讨组合加密算法在IM中的应用

[15] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[16] IM消息送达保证机制实现(一):保证在线实时消息的可靠投递

[17] 理解IM消息“可靠性”和“一致性”问题,以及解决方案探讨

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

[19] IM群聊消息如此复杂,如何保证不丢不重?

[20] 零*础IM开发入门(四):什么是IM系统的消息时序一致性?

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

[22] 如何保证IM实时消息的“时序性”与“一致性”?

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

[24] 微信的海量IM聊天消息序列号生成实践(算法原理篇)

[25] 社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等

[26] 网易云信技术分享:IM中的万人群聊技术方案实践总结

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

[28] 融云IM技术分享:万人群聊消息投递方案的思考和实践

[29] 为何*于TCP协议的移动端IM仍然需要心跳保活机制?

[30] 一文读懂即时通讯应用中的网络心跳包机制:作用、原理、实现思路等

[31] 微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)

[32] 融云技术分享:融云安卓端IM产品的网络链路保活技术实践

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

[34] 彻底搞懂TCP协议层的KeepAlive保活机制

[35] 深度解密钉钉即时消息服务DTIM的技术设计

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

[37] 跟着源码学IM(十):*于Netty,搭建高性能IM集群(含技术思路+源码)

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


(本文已同步发布于:http://www.52im.net/thread-4433-1-1.html

posted @ 2023-09-27 10:36 Jack Jiang 阅读(70) | 评论 (0)编辑 收藏

     摘要: 本文由腾讯WXG客户端开发工程师yecong分享,本文做了修订和改动。1、引言相对于传统的消费级IM应用,企业级IM应用的特殊之外在于它的用户关系是按照所属企业的组织架构来关联的起来,而组织架构的大小是无法预设上限的,这也要求企业级IM应用在遇到真正的超大规模组织架构时,如何保证它的应用性能不受限于(或者说是尽可能不受限于)企业架构规模,这是个比较有难度的技术问题。本文主要分享的是企业微信在百对百...  阅读全文

posted @ 2023-09-21 11:15 Jack Jiang 阅读(80) | 评论 (0)编辑 收藏

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

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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

posted @ 2023-09-20 12:31 Jack Jiang 阅读(62) | 评论 (0)编辑 收藏

关于MobileIMSDK

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

工程开源地址是:

关于RainbowChat

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

 

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

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

v10.0 版更新内容

此版更新内容更多历史更新日志):

(1)Android端主要更新内容新增群名片、消息转发功能等】:

  • 1)[新增] 新增发送“群名片”消息功能;
  • 2)[新增] 新增了消息转发功能;
  • 3)[新增] 新增了实时音视频聊天记录的功能;
  • 4)[bug] 解决了加载离线消息可能导致首页“消息”列表出现重复item的问题;
  • 5)[优化] 修正了实时语音聊天呼叫ui上的提示文字错误;
  • 6)[优化] 取消了实时音视频聊天必须对方在线才能呼叫的限制;
  • 7)[优化] 安全提升,优化了http接口、文件上传接口、socket长连接的token校验逻辑;
  • 8)[优化] 更换了新的高德地图WebSevice key;
  • 9)[优化] 其它ui细节优化等。

(2)服务端主要更新内容:

  • 1)[新增] 安全提升,实现了一套新的token生成、校验机制(支持对称加密和非对称加密两种模式);
  • 2)[新增] 安全提升,启用了AppKey校验机制.

此版主要功能运行截图更多截图点此查看):

posted @ 2023-09-18 13:39 Jack Jiang 阅读(62) | 评论 (0)编辑 收藏

     摘要: 本文由QQ技术团队分享,本文收录时有内容修订和大量排版优化。1、引言QQ 作为国民级应用,从互联网兴起就一直陪伴着大家,是很多用户刚接触互联网就开始使用的应用。而 QQ 桌面版最近一次技术架构升级还是在移动互联网兴起之前,在多年迭代过程中,QQ 桌面版也积累了不少技术债务,随着业务的发展和技术的进步,当前的架构已经无法很好支撑对 QQ 的发展了。在 2022 年初,我们下定决心对 QQ 进行全面的...  阅读全文

posted @ 2023-09-14 10:30 Jack Jiang 阅读(97) | 评论 (0)编辑 收藏

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

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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

posted @ 2023-09-13 11:22 Jack Jiang 阅读(72) | 评论 (0)编辑 收藏

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

1、引言

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

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

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

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

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

 
技术交流:

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

2、推送系统介绍

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

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

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

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

推送系统的特点是:

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

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

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

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

3.1面临的问题

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

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

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

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

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

原始长连接架构图:

3.2解决方法

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

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

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

三地部署后的架构图:

3.3进一步优化

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

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

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

流量调度系统图:

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

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

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

逻辑层单活架构:

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

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

逻辑层双活架构:

5、流量容灾的技术实现

5.1概述

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

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

5.2常规方案

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

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

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

传统方案下的推送架构:

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

5.3优化方案

优化后的方案:

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

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

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

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

5.4进一步优化

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

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

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

增加控速后的推送架构:

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

6、存储容灾的技术实现

6.1问题

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

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

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

6.2方案

原有消息流程:

1)方案一:

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

2)方案二:

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

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

3)方案三:

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

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

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

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

6.3优化

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

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

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

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

存储容灾方案对比:

7、本文小结

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

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

8、参考资料

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

posted @ 2023-09-07 11:17 Jack Jiang 阅读(94) | 评论 (0)编辑 收藏

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

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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

posted @ 2023-09-06 15:06 Jack Jiang 阅读(88) | 评论 (0)编辑 收藏

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

1、引言

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

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

 
技术交流:

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

2、本文作者

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

3、聊天室整体架构

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

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

主要包括以下部分:

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

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

4、聊天室的接入层

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

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

1)接入速度和质量:

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

2)数据安全:

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

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

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

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

3)自适应的流控策略:

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

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

4)性能优化:

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

5、聊天室的网络传输层

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

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

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

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

什么是WE-CAN?

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

6、聊天室的调度层

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

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

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

1)调度精度:

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

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

2)调度性能:

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

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

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

7、聊天室的服务层

服务层实现了各种业务功能,包括:

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

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

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

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

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

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

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

为此我们还提供了丰富的功能,比如:

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

8、聊天室的CDN 分发层

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

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

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

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

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

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

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

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

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

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

CDN Manager 负责:

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

CDN Pusher 实际负责:

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

9、大规模场景应用案例

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

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

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

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

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

10、聊天室标签应用案例

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

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

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

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

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

比如:

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

如上图,展示了超级小班课的一个场景:1 个主讲教师+ N 个互动小班+ N 个助教,所有学生被划分成了一个一个的小班,由对应的助教完成预习提醒、课后答疑、作业监督、学员学习情况反馈等工作,同时又接收来自主讲老师的直播画面,做到了大课的规模,小课的效果。

11、本文小结

以上,就是本文的全部分享,主要介绍了我们构建一个大型聊天室系统的主要技术以及架构原理。

任何系统的搭建都不是一蹴而就的,我们也会继续打磨底层技术,就像引入 WE-CAN 来提升网络传输效果,也会继续丰富完善我们的功能图谱(如独创的聊天室标签功能等)。

12、参考资料

[1] 直播系统聊天技术(九):千万级实时直播弹幕的技术实践

[2] 海量实时消息的视频直播系统架构演进之路(视频+PPT)

[3] 百万在线的美拍直播弹幕系统的实时推送技术实践之路

[4] 阿里电商IM消息平台,在群聊、直播场景下的技术实践

[5] 微信直播聊天室单房间1500万在线的消息架构演进之路

[6] 百度直播的海量用户实时消息系统架构演进实践

[7] 百万人在线的直播间实时聊天消息分发技术实践

[8] 直播间海量聊天消息的架构设计难点实践

[9] vivo直播系统中IM消息模块的架构实践

[10] 万人群聊消息投递方案的思考和实践

[11] IM中的万人群聊技术方案实践总结

(本文已同步发布于:http://www.52im.net/thread-4404-1-1.html

posted @ 2023-09-01 10:39 Jack Jiang 阅读(131) | 评论 (0)编辑 收藏

本文由QQ技术团队王辉、吴浩、陈俊文分享,编辑Tina整理,本文收录时有内容修订和排版优化。

1、引言

在瞬息万变的互联网行业中,年过二十四的即时通讯IM应用 QQ 堪称超长寿的产品,见证了中国互联网崛起的完整历程。

然而,如今这个元老级产品经历了一次从内到外彻底的重构。在这次重构中,QQ 选择了 Electron 作为 UI 跨平台开发框架。

尽管 Electron 被 Slack、Visual Studio Code 和 Discord 等大型产品广泛使用,但也引发了一些网友的担忧,例如内存占用、安装包体积和启动速度等方面的问题。本文内容整理自 QQ 技术团队的采访,我们一起来看看QQ团队选择Electron作为桌面版跨端框架背后的决策与思考。

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4391-1-1.html

2、系列文章

本文是系列文章中的第8篇,本系列总目录如下:

3、老QQ桌面版的技术债

3.1多端代码不统一

QQ 的第一个版本发布于 1998 年,在 Windows 技术栈的基础上用纯原生的方式开发,在当时互联网带宽非常小的情况下,QQ 将安装包控制在了只有 200K 左右。

2007 年后智能手机开始露出苗头,腾讯行动得比较早,部分前端技术开发开始转型到了移动端,在桌面端, QQ 随着业务和组织的发展,针对三大操作系统陆续组建了三支不同的研发团队,各自负责自己的一套代码。

▲ 初版QQ的注册向导页

▲ 初版QQ的主要功能为即时聊天

三端不同代码,老产品历史包袱,加上移动时代研发人员的转型,导致桌面 QQ 维护成本很高。

QQ 技术团队介绍,拿之前的桌面 QQ 为例,Windows QQ 以前的 UI 框架用的是腾讯自研的 GF 框架,10 多年了,GF 这个框架文档还不全,新加入这个项目的团队人员,要基于这个基础框架去做一些事情,是效率很低的一件事情,慢慢的就没有人愿意去用这个框架了。简而言之,就是技术债。

PS:如果你对QQ的发展史感兴趣可以看看下面这些文章:

  1. 闲话即时通讯:腾讯的成长史本质就是一部QQ成长史
  2. 技术往事:创业初期的腾讯——16年前的冬天,谁动了马化腾的代码
  3. 技术往事:史上最全QQ图标变迁过程,追寻IM巨人的演进历史
  4. QQ的成功,远没有你想象的那么顺利和轻松
  5. 还原真实的腾讯:从最不被看好,到即时通讯巨头的草根创业史

3.2多端功能不一致

旧版的桌面端 QQ,Windows 的功能最丰富,Mac OS 次之, Linux 功能非常简洁。

比如“屏幕共享”这个功能,移动端有,Windows 端有,但是 Mac OS 端是没有的。那用户就会遇到一个问题,像 Mac OS 端无法与其它端 QQ 用户一起来使用这个功能。

“多端不统一不利于用户对于 QQ 的统一认知。我们这次的架构升级就是想尽量通过一套核心代码去拉平所有平台的体验,让它具有更好的可维护性和可扩展性,让桌面 QQ 能够更好地迭代产品交互和功能,升级用户体验,再次焕发生长的生命力。”

3.3QQ NT 项目的诞生

于是 QQ NT 项目的诞生了!

QQ NT 项目是在 2022 年 3 月份正式启动, Mac OS QQ 在 6 月份开始发布内测, 9 月份正式上架了 App Store,迭代了几个版本之后,QQ 团队就同步开发 Linux。

在 2022 年,QQ 发布了新的 macOS 和 Linux 版本,包括 QQ 后台其实也做了很大的改变和重构,核心系统做了全新重写,云原生成熟度也得到了很大的提升。

从 2023 年开始,QQ 团队聚焦做 Windows 端的开发,在 3 月底就开始内测,7 月初上架官网。

同时移动端 QQ NT 也在 7 月初完成了核心系统的重写和全量升级。

在目前全新的框架设计下,无论是核心系统、功能迭代还是设计语言上,都可以尽可能地“原子化”,来让 QQ 后续更好地迭代功能。

4、新QQ桌面版重构的技术挑战

4.1业务功能上的挑战

QQ 的重构其实是两方面的重构:

  • 1)一个是面向复杂业务的梳理重构;
  • 2)一个是面向工程技术债的全新技术重构。

重构之路也是两者相互伴随的过程。

首先:在整个 QQ 重构过程中最大的挑战来自于 QQ 功能的复杂化,QQ 有很多十分复杂的历史功能,这些功能模块也曾经由非常多不同的人经手负责过。其中哪些功能是不合理的或没有价值的,如何去做取舍往往是最难的。“虽然技术上我们做了很多事情,但技术上的实现或许并没有那么难,我们处理起来更有经验和从容。相比于技术的复杂度,业务上的往往需要考虑的更多,这本身就是很大的挑战。”

因为 QQ 已经是近 25 年的产品了,有很多细小复杂的功能。虽然这些功能看看起来很小,但用户量其实又很大,稍微改动可能就会有很多的用户反馈,QQ 团队都得非常的关注。仅从产品功能角度上看,有些功能本身就已经是很重的负债,而 QQ 团队内部有一个叫做“QQ 节能计划”的项目,会有比较严谨的项目流程去评估是否需要下架。

4.2技术重构上的挑战

技术上重构也有不少挑战,这次重构是一次跨平台的重构,而在多个平台里面比较有挑战则是 Linux 平台。

作为程序员,很多人免不了要跟 Linux 打交道。但是这么多年来,对于使用 Linux 系统的用户来讲,有一个特别让人烦恼的问题,那就是没有一个好用的 IM 聊天工具。被寄予厚望的 QQ,此前在 Linux 版本上功能也没有 Windows 和 Mac OS 版本全面,迭代速度也明显慢过其他两个版本。业界甚至猜测 Linux 第一个版本是由腾讯实习生所写,毕竟这个说法进一步加重了其初版的“简陋”特性,也为其“停更”的原因提供了更合理的解释。

QQ 技术团队表示,较之另两个版本,Linux 版本的研发最为复杂:

  • 1)一方面操作系统本身很多碎片化,市面上有非常多的发行版,也不缺乏一些千奇百怪的版本;
  • 2)另一方面因为机器运行环境或编译器的缺失,使得解决适配问题的难度很大。

许多发行版相关的机器和开发环境实际上他们并没有,有时还需要外部公司帮助进行一些测试工作。由于没有相应的开发环境,一旦出现闪退等问题,解决难度自然会变得更大。此外,有时候需要与国产操作系统厂商进行特殊的合作,甚至需要对方寄送特定的编译好的代码库,但前后往往会花费一个月的时间才能收到。

而在本次重构之后,“Linux 功能跟 Windows 一样多了”。

4.3选型Electron的质疑

技术上的另一大挑战便是外界对于 QQ 桌面端使用 Electron 的质疑,尤其是内存方面。

外界有些用户在没有使用和分析的情况下对此发表一些夸大和否定的言论,也确实给 QQ 技术团队带来不小压力,但他们却始终坚定选型方向,也相信其中的问题可以被攻克和解决。

5、为何选择Electron而非纯Native技术栈?

5.1为什么Windows端不用原生实现?

确实当时有很多人在问,为什么 Windows 不用原生去实现?为什么不用 Qt?

首先:不太想和以前一样,Windows、Mac OS、Linux 三端各由一个团队分开负责。在国内这种人才环境里面,相关的纯原生的开发人员其实非常难招了,桌面端的人才稀缺,同时也投入比较大。

而对于 Qt 技术栈,他们首先考虑的其实还是人才的问题,国内熟练 Qt 技术栈的人非常少。如果对这个框架不了解,使用它反而是一个负向作用。

至于微软的 Webview2,从本质上讲,Webview2 和 Electron 并没有太大的区别,只是相对在其中打包了一些微软自身的优化措施,其他方面也不是很完善,而且还无法跨平台。虽然内存方面相较于 Electron 做了更多的优化。但据了解,比如微软 Teams 也没有完全切到 Webview2。并且由于它没有开源,因此也没有办法基于 Webview2 做定制优化。

包括 Flutter,QQ 团队表示他们当时也有过调研。他们放弃的一个原因是 Flutter 在桌面端的完善程度并不高,也担心标准化的问题。虽然当前 Flutter 非常流行,但谁也说不好这是不是“2015 年的 React Native”。大家担心随着时间推移,这套技术可能会失去维护支持,因为本身 Google 使用 Flutter 的占比也比较小。

“虽然它很热,但我们历史上踩过了很多很多非标准化的坑,一旦某个技术栈热度一过、维护力度不够,它就会成为全新的负债,做选型时必然也是避免再有类似经历。”

5.2选择Electron的几个考量

至于为什么最后选择 Electron,QQ 技术团队表示主要是基于以下几个考量。

1)首先最看重的是框架成熟度和技术栈的标准化:

Electron 基于 Web 技术栈,有足够低的上手和使用成本,不需要为了使用框架本身,还需要投入额外巨大人力成本去做基建和周边工具链的建设,以前在 RN、Flutter 的实践上都有类似的情况。而使用 Electron,现有的 Web 前端的大部分基建都可以直接复用,而且使用 Web 开发 UI 的效率,在主流技术栈里算是很高的了。至于迭代效率我觉得从新版桌面 QQ 功能的迭代速度就可以证明,这放在以前是完全办不到的。

另外由于 Web 技术栈是标准化的,假如 Electron 修改开源协议或者要闭源了,他们也能很方便的去写出一套类似的框架。只不过现在已经有开源的了,没必要再去重复建设一个。而且随着 Web 标准长久发展,Web 技术栈也不会有大的问题,而且还会越来越好。

2)其次是技术经验及人才储备:

技术选型是否适合当前团队也是一个很重要的考虑点,团队是否有相关的技术积累,是否有人才储备来持续投入这个技术栈。

Qt 的确在性能上是一个很好的选择,但目前团队对 Qt 没有太多积累,基建基本没有,而且相关人才其实比较匮乏,招聘就更难了。

而当前 QQ 技术团队 Web 前端团队还是有比较多的积累,在 QQ 频道项目中,也完整验证了 Electron 的技术可行性。

3)最后就是 Electron 具备的桌面端跨平台的优势:

但 QQ NT 架构并不是仅指 Electron,Electron 主要是作为 UI 跨平台的框架,只是占比很小的一部分,并且 QQ 桌面端不是全部用 Electron 实现,QQ NT 最核心的部分还是 QQ 底层通用抽象的模块,称之为 NT 内核,包括核心登录、消息系统、关系链、富媒体、长连接、数据库等等模块,完全用 C++ 实现,全平台通用。因此底层是完全跨平台的架构,而 Electron 只是上层桌面端 UI 跨平台较薄的一层。

“其实我们当时选型的时候,也的确看得到大家对 Electron 的评价褒贬不一,但我们还是有信心去解决这个问题,前期也做了一些技术的 Demo 和预研。实际上 Electron 并没有糟糕到这个地步。我们觉得可能是国内很多没有用过 Electron 的开发者,对这个框架有些忌惮。其实你到 Electron 的网站去看,还是有非常多国内外的亿级 DAU 产品都使用 Electron 框架。目前这几年主流的桌面端应用基本都选择了 Electron,如 Visual Studio Code、Discord、Slack、Skype、Whatsapp、Figma 等等,新的应用基本上也是首选 Electron,版本的迭代速度和社区氛围都很在线。”

“我们觉得不需要单纯因为口碑问题,就对这个选型没有了期待。还是要从实际出发,哪种技术栈适合你的产品,看看到底能不能有技术实力去把这个事情搞定。”

6、如何有效控制Electron的内存占用?

外界之所以会觉得 Electron 内存占用高,是因为其本身是一个多进程的架构,主进程基于 Node.js, 而每个窗口都对应一个渲染进程以及 V8 实例。可以说从技术框架层面上,上手写代码很容易,但不容易去管控它的内存。

QQ 技术团队认为:Electron 的开发者更多的是前端的开发者,可能在思维上没有去考虑怎么在这样一套技术框架里,去对内存数据进行管理和管控。开发者需要从前端开发者的思维,转变为客户端开发者的思维。

综合来看:对内存的看法其实不完全是 Electron 的技术框架所导致的,更多的是门槛上、开发思维上,导致内存没有得到很好的关注和优化。其实最简单的 Electron 应用大概也就只有几十兆的内存占用。因为前端原本更多还是停留在开发即用即走的 Web 站点,很少实现一个超大客户端,缺乏控制内存的经验,所以面对 QQ 这么大一个产品的时候,你就必须非常在意内存的使用和管控。

至于优化内存的突破口,可以说是从各个层面:从消息的链路中的每条消息的收发上,数据是怎么管理,包括像窗口及会话的管理,都得精打细算,也会做一些数据本地化和一些机制的按需加载,包括渲染上他们也提出一个根本的原则:“要做到所见才占用”,既我们看到的内容才占用这一部分内存,没看到和用不到的任何场景的内存就不应该再占用,通过各种方式来去让内存达到一个设定的目标。

他们也使用了不同维度的内存分析工具,从 V8 引擎到进程,再到整个应用程序,打通整个链路进行多角度的细节分析,以此来定位内存使用的瓶颈。之后采取一系列的针对性优化策略,包括缓存策略、按需加载、优雅降级等,同时使用线上监控、自动化测试手段,包括借助开发框架、工具建设、代码审查等,来阻止性能退化。(更多细节可以参看技术文章:《IM跨平台技术学习(九):全面解密新QQ桌面版的Electron内存占用优化》)

经过一系列组合优化之后:QQ 的内存在长时间挂机的条件下,平均稳定在 220M 左右。“现在优化还是不错的,比老版本要好很多。我们认为这个难题还是可以被很好的攻克,内存并不是大家认为的这么不可控,但是也需要团队去花费相当精力去探索和实践,才能去把内存控制到一个比较理想的状态。”

7、未来展望

目前 QQ 的前端团队作为一个公线团队,不仅负责桌面 QQ 的研发,还有 QQ 基础运营、QQ 空间以及基于 QQ 生态的创新项目研发,有比较多的线上项目的开发与维护和内部研效工具的建设。涉及的技术栈,包括 H5、Electron、Cocos、小程序、WebGL、WebAssembly、WebRTC 等。他们也表示会继续夯实这些技术,同时也不断地打破立下的性能目标,希望让桌面 QQ 覆盖更多平台。

他们也正在积极拥抱 AI:让 AI 在质量和效率上辅助日常开发。比如:前端设计稿还原,之前更多是一个耗时的体力活,D2C 是 QQ 前端一直探索的方向,之前使用纯规则转换生成代码,在视觉还原上效果还不错,但是代码可读性和可维护性不能很好的满足预期,所以除了一些日抛型的运营活动有些使用之外,比较难扩大成果。现在 D2C 结合大模型,生成的代码质量高了很多,也能很方便的将代码与 UI 组件库做映射,达到可以在核心业务中高效使用,达到通过 AI 提升研发效率的目的。针对一些无设计稿的管理平台开发,使用 P2C 提效,目前也有了一些不错的案例。

另外:QQ 技术团队也在积极探索 AI 更广阔的应用场景,比如代码评审,基本的 Lint 检检是难以实现的,但将已经掌握的内存泄漏模式通过规则的形式给到 AI,可以很方便地给开发同学一些不错的建议,为性能看家护院提供多一道保障。

8、写在最后

QQ NT 项目于 2022 年 3 月份启动,Mac OS QQ 花了该团队 3 个月的开发时间,9 月份上架 App Store,迭代了几个版本后同步开始开发 Linux QQ,并于这一年的最后一天上架各 Linux 应用市场,作为给 Linux 用户的一份特殊的新年礼物。2023 年 QQ 团队开始去聚焦做 Windows QQ NT 的开发,7 月正式上架应用市场和官网。同时移动端的 QQ 从 2022 年的 Q4 开始开发,也已经完成了全量升级和发布。

另外:桌面 QQ 也是在 NT 版本中第一次支持 64 位,这需要将音视频、安全、字节码、图形库等 C++ 模块,包括 Electron 框架都重新进行编译,花费了比较大的工作量。但在 64 位系统上,QQ 从此便不再需要以 32 位应用的方式通过额外的兼容和转换来运行。毕竟额外操作会增加开销,导致性能下降。

至此:QQ 实现了多个系统平台之间架构的统一。而团队的未来规划还是不断地打破性能目标,并覆盖更多平台,同时探索更多提升研发效率的办法,加快研发速度。

腾讯 QQ 用跨平台 Electron 取代之前原生应用程序的开发模式,这一举动引发的反响确实巨大。但我们也能看出,不同于小型产品团队,在大公司里具有一定规模的产品组织架构之下,快速满足用户需求,并逐渐需要为第三、第四乃至第五种运行平台提供支持时,保持一致性和协调性并不是想象中的那么容易。而缓慢而低效,最终会令你输掉比赛。

不管使用什么跨平台开发框架,都要去选择最合适自己团队的,也因此在 Web 标准技术栈上有丰富积累的 QQ 团队才会选择 Electron。并且我们认为没有人真正讨厌 Electron,只是我们对 QQ,对国内 App 寄予了非常高的期盼。

9、相关资料

[1] Electron官方开发者手册

[2] 快速了解新一代跨平台桌面技术——Electron

[3] Electron初体验(快速开始、跨进程通信、打包、踩坑等)

[4] Electron 基础入门 简单明了,看完啥都懂了

[5] vivo的Electron技术栈选型、全方位实践总结

[6] 融云基于Electron的IM跨平台SDK改造实践总结

[7] 闲鱼IM基于Flutter的移动端跨端改造实践

[8] 网易云信基于Electron的IM消息全文检索技术实践

[9] 闲话即时通讯:腾讯的成长史本质就是一部QQ成长史

[10] 技术往事:创业初期的腾讯——16年前的冬天,谁动了马化腾的代码

[11] 技术往事:史上最全QQ图标变迁过程,追寻IM巨人的演进历史

[12] QQ的成功,远没有你想象的那么顺利和轻松

[13] 还原真实的腾讯:从最不被看好,到即时通讯巨头的草根创业史

附录:更多有关QQ、微信的技术故事

技术往事:微信估值已超5千亿,雷军曾有机会收编张小龙及其Foxmail

QQ和微信凶猛成长的背后:腾讯网络基础架构的这些年

2017微信数据报告:日活跃用户达9亿、日发消息380亿条

腾讯开发微信花了多少钱?技术难度真这么大?难在哪?

技术往事:“QQ群”和“微信红包”是怎么来的?

开发往事:深度讲述2010到2015,微信一路风雨的背后

开发往事:微信千年不变的那张闪屏图片的由来

开发往事:记录微信3.0版背后的故事(距微信1.0发布9个月时)

一个微信实习生自述:我眼中的微信开发团队

首次揭秘:QQ实时视频聊天背后的神秘组织

为什么说即时通讯社交APP创业就是一个坑?

微信七年回顾:历经多少质疑和差评,才配拥有今天的强大

前创始团队成员分享:盘点微信的前世今生——微信成功的必然和偶然

即时通讯创业必读:解密微信的产品定位、创新思维、设计法则等

QQ现状深度剖析:你还认为QQ已经被微信打败了吗?

[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗?

QQ和微信止步不前,意味着即时通讯社交应用创业的第2春已来?

那些年微信开发过的鸡肋功能,及其带给我们的思考

读懂微信:从1.0到7.0版本,一个主流IM社交工具的进化史

同为IM社交产品中的王者,QQ与微信到底有什么区别

QQ设计团队分享:新版 QQ 8.0 语音消息改版背后的功能设计思路

社交应用教父级人物的张小龙和马化腾的同与不同

专访马化腾:首次开谈个人经历、管理心得、技术创新、微信的诞生等

一文读懂微信之父张小龙:失败天才、颠覆者、独裁者、人性操控师


(本文已同步发布于:http://www.52im.net/thread-4391-1-1.html

posted @ 2023-08-25 15:24 Jack Jiang 阅读(116) | 评论 (0)编辑 收藏

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持 UDP 、TCP 、WebSocket 三种协议,支持 iOS、Android、H5、标准Java、小程序、Uniapp,服务端基于Netty编写。

工程开源地址是:

关于RainbowChat

► 详细产品介绍:http://www.52im.net/thread-19-1-1.html
► iOS端更新记录:http://www.52im.net/thread-2735-1-1.html
► 全部运行截图:iOS端全部运行截图 (另:Android端运行截图 点此查看
► 在线体验下载:App Store安装地址 (另:Android端下载体验 点此查看

 

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题(可自行下载体验:专业版下载安装)。

RainbowChat可能是市面上提供im即时通讯聊天源码的,唯一一款同时支持TCP、UDP两种通信协议的IM产品(通信层基于开源IM聊天框架 MobileIMSDK 实现)。

v7.0 版更新内容

此版更新内容更多历史更新日志):

  • 1)[新增] 新增了支持从相册中选取视频并发送;
  • 2)[bug] 解决了代码中设置聊天界面中消息文字颜色无作用的问题;
  • 3)[bug] 解决了聊天消息列表中查看短视频后返回时,最后一行消息被输入框档住的问题;
  • 4)[bug] 解决了一处因后台任务未显式结束导致的潜在内存泄漏问题;
  • 5)[bug] 当处于群聊界面是,群主更新群名称时,不能直接刷新群聊界面当前的标题上群名称的最新显示;
  • 6)[优化] 登陆界面中,密码输入框增加了密文和明文切换显示功能;
  • 7)[优化] 解决了iOS16.4+系统上因UIAlertView兼容性导致的某些功能中确认事件不能执行的问题;
  • 8)[优化] 解决了从其它界面返回到注册界面的动画跳转时,原界面导航栏变成黑色块的问题;
  • 9)[优化] 解决了聊天界面下方的功能面板打开状态下,再点“+” 号会切换到文本输入,而不是取消功能面板显示的问题;
  • 10)[优化] 升级了图片选择库以适配最新的iOS系统;
  • 11)[优化] 解决了聊天界面中发送大文件后,会立即弹出软键盘并进入文字输入状态的问题;
  • 12)[优化] 查看图片界面中,长按弹出菜单效果UI美化;
  • 13)[优化] 重新优化了闪屏、登录、帮助、忘记密码、注册、注册成功、查找用户、邀请朋友共计8个界面的UI设计;
  • 14)[优化] 其它未提及的ui细节优化和美感提升。

此版部分界面更新(更多截图点此查看):

 

posted @ 2023-08-23 13:28 Jack Jiang 阅读(82) | 评论 (0)编辑 收藏

本文由vivo互联网技术An Peng分享,本文收录时有内容修订和重新排版。

1、引言

本文通过对分布式ID的3种应用场景、实现难点以及9种分布式ID的实现方式进行介绍,并对结合vivo业务场景特性下自研的鲁班分布式ID服务从系统架构、ID生成规则与部分实现源码进行分享,希望为本文的阅读者在分布式ID的方案选型或技术自研提供参考。

 

技术交流:

(本文已同步发布于:http://www.52im.net/thread-4378-1-1.html

2、专题目录

本文是“IM消息ID技术专题”系列文章的第 7 篇,专题总目录如下:

IM消息ID技术专题(一):微信的海量IM聊天消息序列号生成实践(算法原理篇)

IM消息ID技术专题(二):微信的海量IM聊天消息序列号生成实践(容灾方案篇)

IM消息ID技术专题(三):解密融云IM产品的聊天消息ID生成策略

IM消息ID技术专题(四):深度解密美团的分布式ID生成算法

IM消息ID技术专题(五):开源分布式ID生成器UidGenerator的技术实现

IM消息ID技术专题(六):深度解密滴滴的高性能ID生成器(Tinyid)

IM消息ID技术专题(七):深度解密vivo的自研分布式ID服务(鲁班)》(* 本文)

vivo技术团队分享的其它文章:

vivo的Electron技术栈选型、全方位实践总结

vivo直播系统中IM消息模块的架构实践

3、分布式ID的应用场景

3.1概述

随着系统的业务场景复杂化、架构方案的优化演进,我们在克服问题的过程中,也总会延伸出新的技术诉求。分布式ID也是诞生于这样的IT发展过程中。

在不同的关联模块内,我们需要一个全局唯一的ID来让模块既能并行地解耦运转,也能轻松地进行整合处理。

以下,首先让我们一起回顾这些典型的分布式ID场景。

3.2系统分库分表

随着系统的持续运作,常规的单库单表在支撑更高规模的数量级时,无论是在性能或稳定性上都已经难以为继,需要我们对目标逻辑数据表进行合理的物理拆分。

这些同一业务表数据的拆分,需要有一套完整的 ID生成方案来保证拆分后的各物理表中同一业务ID不相冲突,并能在后续的合并分析中可以方便快捷地计算。

以公司的营销系统的订单为例:当前不但以分销与零售的目标组织区别来进行分库存储,来实现多租户的数据隔离,并且会以订单的业务属性(订货单、退货单、调拔单等等)来进一步分拆订单数据。

具体是:

  • 1)在订单创建的时候,根据这些规则去构造全局唯一ID,创建订单单据并保存在对应的数据库中;
  • 2)在通过订单号查询时,通过ID的规则,快速路由到对应的库表中查询;
  • 3)在BI数仓的统计业务里,又需要汇总这些订单数据进行报表分析。

3.3系统多活部署

无论是面对着全球化的各国数据合规诉求,还是针对容灾高可用的架构设计,我们都会对同一套系统进行多活部署。

多活部署架构的各单元化服务,存储的单据(如订单/出入库单/支付单等)均带有部署区域属性的ID结构去构成全局唯一ID。

创建单据并保存在对应单元的数据库中,在前端根据单据号查询的场景,通过ID的规则,可快速路由到对应的单元区域进行查询。

对应多活部署架构的中心化服务,同步各单元的单据数据时,单据的ID是全局唯一,避免了汇聚数据时的ID冲突。

在公司的系统部署中,公共领域的 BPM 、待办、营销领域的系统都大范围地实施多活部署。

3.4链路跟踪技术

在微服务架构流行的大背景下,此类微服务的应用对比单体应用的调用链路会更长、更复杂,对问题的排查带来了挑战。

应对该场景的解决方案,是会在流量入口处产生全局唯一的TraceID,并在各微服务之间进行透传,进行流量染色与关联,后续通过该全局唯一的TraceID,可快速地查询与关联全链路的调用关系与状态,快速定位根因问题。

在公司的各式各样的监控系统、灰度管理平台、跨进程链路日志中,都会伴随着这么一个技术组件进行支撑服务。

4、分布式ID的核心难点

分布式ID的技术难点比较,这里我简单总结了一下。

最核心的技术难点主要是:

1)唯一性: 保持生成的ID全局唯一,在任何情况下也不会出现重复的值(如防止时间回拔,时钟周期问题);

2)高性能: ID的需求场景多,中心化生成组件后,需要高并发处理,以接近 0ms的响应大规模并发执行;

3)高可用: 作为ID的生产源头,需要100%可用,当接入的业务系统多的时候,很难调整出各方都可接受的停机发布窗口,只能接受无损发布;

4)易接入: 作为逻辑上简单的分布式ID要推广使用,必须强调开箱即用,容易上手;

5)规律性: 不同业务场景生成的ID有其特征,例如有固定的前后缀,固定的位数,这些都需要配置化管理。

5、分布式ID的常见方案

常用系统设计中主要有下图9种ID生成的方式:

以下是详细表格说明之:

上面这些ID算法里,最知名是Twitter的雪花算法(Snowflake)。

Snowflake的核心思想就是:使用一个 64 bit 的 long 型的数字作为全局唯一 ID。

这 64 个 bit 中,其中 1 个 bit 是不用的,然后用其中的 41 bit 作为毫秒数,用 10 bit 作为工作机器 ID,12 bit 作为序列号。

SnowFlake的ID构成:

▲ 图片引用自《深度解密美团的分布式ID生成算法 - 美团为什么不直接用Snowflake算法?

SnowFlake的ID样本:

▲ 图片引用自《深度解密美团的分布式ID生成算法 - 美团为什么不直接用Snowflake算法?

6、自研分布式ID服务(鲁班)的方案

我们的系统跨越了公共、生产制造、营销、供应链、财经等多个领域。

我们在分布式ID诉求下还有如下特点:

  • 1)在业务场景上除了常规的Long类型ID,也需要支持“String类型”、“MixId类型”(后详述)等多种类型的ID生成,每一种类型也需要支持不同的长度的ID;
  • 2)在ID的构成规则上需要涵盖如操作类型、区域、代理等业务属性的标识;需要集中式的配置管理;
  • 3)在一些特定的业务上,基于安全的考虑,还需要在尾部加上随机数来保证ID不能被轻易猜测。

综合参考了业界优秀的开源组件与常用方案均不能满足,为了统一管理这类基础技术组件的诉求,我们选择基于公司业务场景自研一套分布式ID服务:鲁班分布式ID服务。

7、分布式ID服务鲁班的整体架构

鲁班的整体架构如下图所示:

鲁班的架构说明:

8、鲁班支持多种类型的ID规则

目前鲁班分布式ID服务共提供"Long类型"、“String类型”、“MixId类型”等三种主要类型的ID,相关ID构成规则与说明如下。

8.1Long类型

1)构成规则:

静态结构由以下三部分数据组成,组成部分共19位。如下所示。

* 固定部分(4位),由FixPart+ServerPart组成:

  • 1)FixPart(4位):由大区zone 1位/代理 agent 1位/项目 project 1位/应用 app 1位,组成的4位数字编码;
  • 2)ServerPart(4位):用于定义产生全局ID的服务器标识位,服务节点部署时动态分配。

* 动态部分DynPart(13位): System.currentTimeMillis() - 固定配置时间的TimeMillis (可满足使用100年)。

* 自增部分SelfIncreasePart(2位):用于在全局ID的客户端SDK内部自增部分,由客户端SDK控制,业务接入方无感知。共 2位组成。

2)降级机制:

主要自增部分在服务器获取初始值后,由客户端SDK维护,直到自增99后再次访问服务端获取下一轮新的ID以减少服务端交互频率,提升性能,服务端获取失败后抛出异常,接入业务侧需介入进行处理。

3)样例说明:

8.2String类型

1)构成规则:

静态结构由以下五部分数据组成,组成部分共25~27位。

* 固定部分操作位op+FixPart(9~11位):

  • 1)操作位op(2~4位):2~4位由业务方传入的业务类型标识字符;
  • 2)FixPart(7位):业务接入时申请获取,由大区zone 1位,代理 agent 2位,项目 project 2位,应用 app 2位组成。

* 服务器标识部分 ServerPart(1位): 用于定义产生全局ID的服务器标识位,服务节点部署时动态分配A~Z编码。

* 动态部分DynPart(9位):System.currentTimeMillis() - 固定配置时间的TimeMillis ,再转换为32进制字符串(可满足使用100年)。

* 自增部分SelfIncreasePart(3位):用于在全局ID的客户端SDK内部自增部分,由客户端SDK控制,业务接入方无感知。

* 随机部分secureRandomPart(3位):用于在全局ID的客户端SDK的随机部分,由SecureRandom随机生成3位0-9,A-Z字母数字组合的安全随机数,业务接入方无感知。

2)降级机制:

主要自增部分由客户端SDK内部维护,一般情况下只使用001–999 共999个全局ID。也就是每向服务器请求一次,都在客户端内可以自动维护999个唯一的全局ID。

特殊情况下在访问服务器连接出问题的时候,可以使用带字符的自增来做服务器降级处理,使用产生00A, 00B... 0A0, 0A1,0A2....ZZZ. 共有36 * 36 * 36 - 1000 (999纯数字,000不用)= 45656个降级使用的全局ID。

3)样例说明:

8.3MixId类型

1)构成规则:

静态结构由以下三部分数据组成,组成部分共17位。

* 固定部分FixPart(4~6位):

  • 1)操作位op(2~4位):2~4位由业务方传入的业务类型标识字符;
  • 2)FixPart(2位):业务接入时申请获取由代理 agent 2位组成。

* 动态部分DynPart(6位): 生成ID的时间,年(2位)月(2位)日(2位)。

* 自增部分SelfIncreasePart(7位):用于在全局ID的客户端SDK内部自增部分,由客户端SDK控制,业务接入方无感知。

2)降级机制:

无,每次ID产生均需到服务端请求获取,服务端获取失败后抛出异常,接入业务侧需介入进行处理。

3)样例说明:

9、鲁班的业务自定义ID规则实现

鲁班分布式ID服务内置“Long类型”,“String类型”,“MixId类型”等三种长度与规则固定的ID生成算法。除以上三种类型的ID生成算法外,业务侧往往有自定义ID长度与规则的场景诉求。

在鲁班分布式ID服务内置ID生成算法未能满足业务场景时,为了能在该场景快速支持业务,鲁班分布式ID服务提供了业务自定义接口并通过SPI机制在服务运行时动态加载,以实现业务自定义ID生成算法场景的支持。

相关能力的实现设计与接入流程如下。

1)ID的构成部分主要分FixPart、DynPart、SelfIncreasePart三个部分。

2)鲁班分布式ID服务的客户端SDK提供 LuBanGlobalIDClient的接口与getGlobalId(...)/setFixPart(...)/setDynPart(...)/setSelfIncreasePart(...)等四个接口方法。

3)业务侧实现LuBanGlobalIDClient接口内的4个方法,通过SPI机制在业务侧服务进行加载,并向外暴露出HTTP或DUBBO协议的接口。

4)用户在鲁班分布式ID服务管理后台对自定义ID生成算法的类型名称与服务地址信息进行配置,并关联需要使用的AK接入信息。

5)业务侧使用时调用客户端SDK提供的LuBanGlobalIDClient的接口与getGlobalId方法,并传入ID生成算法类型与IdRequest入参对象,鲁班分布式ID服务接收请求后,动态识别与路由到对应ID生产算法的实现服务,并构建对象的ID返回给客户端,完成整个ID生成与获取的过程。

10、鲁班保证ID生成不重复的方案

众所周之,如何保证ID服务生成的ID不碰撞、不重复,是最基本的要求之一。

我们是这样做的:

11、鲁班的无状态无损管理

服务部署的环境在虚拟机上,ip是固定,常规的做法是在配置表里配置ip与机器码的绑定关系(这样在服务扩缩容的时候就需要人为介入操作,存在一定的遗漏配置风险,也带来了一定的运维成本)。

但在容器的部署场景,因为每次部署时IP均是动态变化的,以前通过配置表里ip与机器码的映射关系的配置实现方式显然不能满足运行在容器场景的诉求,故在服务端设计了通过心跳上报实现机器码动态分配的机制,实现服务端节点ip与机器码动态分配、绑定的能力,达成部署自动化与无损发布的目的。

相关流程如下:

需要注意的是:

服务端节点可能因为异常,非正常地退出,对于该场景,这里就需要有一个解绑的过程,当前实现是通过公司平台团队的分布式定时任务服务,检查持续5分钟(可配置)没有上报心跳的机器码分配节点进行数据库绑定信息清理的逻辑,重置相关机器码的位置供后续注册绑定使用。

12、鲁班的使用方接入SDK的设计

SDK设计主要以"接入快捷,使用简单"的原则进行设计。

1)接入时:

鲁班分布式ID服务提供了spring-starter包,应用只需再pom文件依赖该starter,在启动类里添加@EnableGlobalClient,并配置AK/SK等租户参数即可完成接入。

同时鲁班分布式ID服务提供Dubbo & Http的调用方式,通过在启动注解配置accessType为HTTP/DUBBO来确定,SDK自动加载相关依赖。

2)使用时:

根据"Long"、"String"、"MixId"等三种id类型分别提供GlobalIdLongClient、GlobalIdStringClient、GlobalIdMixIDClient等三个客户端对象,并封装了统一的入参RequestDTO对象,业务系统使用时只需构建对应Id类型的RequestDTO对象(支持链式构建),并调用对应id类型的客户端对象getGlobalID(GlobalBaseRequestDTO globalBaseRequestDTO)方法,即可完成ID的构建。

Long类型Id获取代码示例:

packagecom.vivo.it.demo.controller;

 

importcom.vivo.it.platform.luban.id.client.GlobalIdLongClient;

importcom.vivo.it.platform.luban.id.dto.GlobalLongIDRequestDTO;

importorg.springframework.beans.factory.annotation.Autowired;

importorg.springframework.web.bind.annotation.RequestMapping;

 

@RequestMapping("/globalId")

publicclassGlobalIdDemoController {

 

    @Autowired

    privateGlobalIdLongClient globalIdLongClient;

 

    @RequestMapping("/getLongId")

    publicString getLongId() {

        GlobalLongIDRequestDTO globalLongIDRequestDTO = GlobalLongIDRequestDTO.Builder()

                .setAgent("1") //代理,接入申请时确定

                .setZone("0") //大区,接入申请时确定

                .setApp("8") //应用,接入申请时确定

                .setProject("7") //项目,接入申请时确定

                .setIdNumber(2); //当次返回的id数量,只对getGlobalIDQueue有效,对getGlobalID(...)无效

        longlongId = globalIdLongClient.getGlobalID(globalLongIDRequestDTO);

        returnString.valueOf(longId);

    }

}

13、鲁班的关键运行性能优化场景

13.1内存使用优化

在项目上线初时,经常发生FGC,导致服务停顿,获取ID超时。

经过分析,鲁班分布式ID服务的服务端主要为内存敏感的应用,当高并发请求时,过多对象进入老年代从而触发FGC。

经过排查主要是JVM内存参数上线时是使用默认的,没有经过优化配置,JVM初始化的内存较少,高并发请求时JVM频繁触发内存重分配,相关的对象也流程老年代导致最终频繁发送FGC。

对于这个场景的优化思路主要是要相关内存对象在年轻代时就快速经过YGC回收,尽量少的对象进行老年代而引起FGC。

基于以上的思路主要做了以下的优化:

  • 1)增大JVM初始化内存(-Xms,容器场景里为-XX:InitialRAMPercentage);
  • 2)增大年轻代内存(-Xmn);
  • 3)优化代码,减少代码里临时对象的复制与创建。

13.2锁颗粒度优化

客户端SDK再自增值使用完或一定时间后会向服务端请求新的id生成,这个时候需要保证该次请求在多线程并发时是只请求一次。

当前设计是基于用户申请ID的接入配置,组成为key,去获取对应key的对象锁,以减少同步代码块锁的粒度,避免不同接入配置去在并发去远程获取新的id时,锁粒度过大,造成线程的阻塞,从而提升在高并发场景下的性能。

14、应用现状

当前鲁班分布式ID服务日均ID生成量亿级,平均RT在0~1ms内,单节点可支持 万级QPS,已全面应用在公司IT内部营销订单、支付单据、库存单据、履约单据、资产管理编码等多个领域的业务场景。

15、未来规划

在可用性方面,当前鲁班分布式ID服务仍对Redis、Mysql等外部DB组件有一定的依赖(如应用接入配置信息、MixId类型自增部分ID计数器),规划在该依赖极端宕机的场景下,鲁班分布式ID服务仍能有一些降级策略,为业务提供可用的服务。

同时基于业务场景的诉求,支持标准形式的雪花算法等ID类型。

16、参考资料

[1] 微信的海量IM聊天消息序列号生成实践(算法原理篇)

[2] 解密融云IM产品的聊天消息ID生成策略

[3] 深度解密美团的分布式ID生成算法

[4] 开源分布式ID生成器UidGenerator的技术实现

[5] 深度解密滴滴的高性能ID生成器(Tinyid)


(本文已同步发布于:http://www.52im.net/thread-4378-1-1.html

posted @ 2023-08-16 11:31 Jack Jiang 阅读(112) | 评论 (0)编辑 收藏

本文由腾讯技术工程师remyliu分享,原题“微信万亿数据仓库架构设计与实现”,本文收录时有内容修订和重新排版。

1、引言

没有足够的特征数据,安全策略将是“无根之木,无源之水”。

微信的安全数据特征仓库应运而生,并成为整个安全业务的特征数据存储中心,每天服务了万亿级的特征数据读写请求,为整个微信安全策略提供了可靠的数据支撑,是微信安全基石之所在。

然而,微信安全特征数据仓库不仅仅是一个存储中心,更是一个特征管理和数据质量管理的中心。

微信的安全数据特征仓库在演进过程中,一直致力于提升特征管理能力和数据质量保障,实现了特征的管理、共享、分析和数据质量检测等功能。

本文将介绍微信的安全数据特征仓库的背景起源、技术演进、当前的架构设计和实践,以及数据质量保证系统的实现。希望给中大型IM系统的安全数据特征仓库的设计带来启发。

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4374-1-1.html

2、安全策略开发流程

安全业务的核心逻辑是在安全策略中实现的。整个的策略开发流程包括特征数据的收集,安全策略的编写实现,和策略的反馈评估(如下图所示)。

其中特征数据的收集是必不可少的环节,数据的质量将直接影响安全策略的效果。

特征数据收集主要包括:

  • 1)数据接入;
  • 2)特征的计算;
  • 3)特征的存储。

传统特征数据收集流程:

如上图所示:在数据仓库还未建立时,业务同学通过消费离线存储mmdata和tdw接入数据,通过Flink流式计算或者自定义模块对数据进行加工,计算出需要的特征,最终存储到自行维护的KV,然后在安全策略平台上编写安全策略,读取KV中的数据, 实现需要的安全逻辑。

3、为什么需要安全特征数据仓库

前面提到在还未建立数据仓库时,业务同学都按照自己的方式去存储计算出的特征,大多通过自行申请部署KV来存储(如下图中的架构):如A同学把部署一套KV集群,存储特征到KV表中,B同学把特征存储到同KV集群的不同表中,C同学又额外申请了另外一套KV集群存储。

传统安全后台(各业务特征分散存储):

这种特征的分散存储,导致业务同学只了解自己熟悉的特征,难以交流和共享,特征缺乏统一的管理,数据质量难以保证,不同的存储方式,也导致特征访问接口的混乱,业务系统的可靠性也难以保证。

针对上述的问题:我们希望把所有业务的特征,按统一的规范,建立统一的存储,方便特征的共享、管理和维护、并建立数据质量保障体系, 为策略提供可靠的数据。所以我们需要开发数据仓库。

问题和目标:

4、安全业务的后台架构

当前,我们已经把所有的安全策略统一到安全策略平台进行开发和管理,特征数据的接入和计算统一到了Flink实时计算平台和特征平台。

数据仓库作为承上启下的部分,是整个业务体系中不可或缺的部分。

总结一下它作用就是:

  • 1)对上为在安全策略平台上的安全策略提供了数据读写;
  • 2)对下为实时计算平台和特征平台计算输出的特征提供了存储。

安全业务后台架构:

5、安全特征数据仓库的存储选型

微信的安全业务特征数据主要有2种类型:

  • 1)离线特征:用来满足离线计算数据导入线上实时使用的需求(通常特征离线计算,定期的批量后台上线,提供在线读,但不支持实时写入);
  • 2)实时特征:用来满足实时的在线读写需求。

微信内部有多种非常成熟稳定的自研KV:实时读写KV(简称实时KV)、离线写实时读KV(简称离线KV)、***KV等等,这些KV已经在多个业务被验证,有非常好的性能和可靠性,有团队做长期的维护,为此数据仓库的底层存储采用了微信自研的KV。

微信自研的KV主要特点如下:

具体就是:

  • 1)离线KV适合离线特征要求的场景:拥有非常好的读性能,并且提供了版本管理功能,在处理有问题数据时可以非常方便的可以回退版本,采用这种KV存储时,value一般是protobuf对象,新增特征时可以在pb中增加字段;
  • 2)实时KV适合实时特征的场景:在线实时读写性能优秀,而且支持数据过期淘汰,该KV提供了类MySQL表的概念,KV表定义类似于一个MySQL表,而每一个安全业务特征刚好可以用表的一个字段表示。

6、数据仓库的架构设计和演进

6.1统一存储统一接口

数据仓库第一个版本,针对特征存储分散访问接口混乱问题,首先部署了公共的实时KV/离线KV集群,并实现了一个接入层。新增特征和历史特征放到公共的KV存储集群,并且在接入层屏蔽了底层KV的细节,提供了统一的读写特征的接口。

数据仓库架构1.0版:

接入层支持任意多个KV集群,支持多个表,为屏蔽KV的细节,接入层为每个特征分配唯一的标识<sceneid, columnid>,读写特征数据使用唯一标识进行,不需要关注KV类型和KV表ID,方便业务的接入使用。

统一接口:

接入层还实现配置管理、参数校验、模块校验、权限校验、流水上报、PV统计等功能。

6.2读写分离和多IDC同步

1)读写分离:数据仓库的读请求量远远多于实时写入量,为了提高性能,减少读写之间的相互影响,接入层做了读写分离,将读和写接口拆分到两个模块。

2)数据多IDC同步:数据仓库和业务都采用的是多IDC部署,为了不降低查询性能,不希望业务跨IDC访问存储,所以底层的KV也是多IDC部署。这里就带来一个问题,特征数据如何在多IDC的KV之间进行同步? 例如业务在上海写入一个特征,希望在深圳也能读到这个特征。

这里按特征类型进行分类处理:

  • 1)离线特征数据同步:离线特征数据上线流程是通过离线计算在文件系统中生成一个文件,然后将文件导入到离线KV, 而离线KV支持多个IDC共享同一份数据,数据文件只需要生成一份,所有IDC的离线KV拉取同一个文件,新数据最终能同步到所有IDC上;
  • 2)实时特征数据同步:实时特征的同步采用微信自研的分布式队列组件,该组件提供了高可靠、高可用、高吞吐、低延时的数据消息队列服务。数据仓库写接入模块在写入数据时,同时将数据写一份到分布式队列,使用队列做跨IDC的数据同步,在其他IDC启动进程消费队列中的数据,写入到本IDC的实时KV,实现实时特征数据的同步。

数据仓库架构2.0版:

6.3异步写和替代分布式队列

1)异步写入:前一个版本中实时特征是同步写入,影响业务的性能,业务希望是异步写入。

2)替代分布式队列:前一个版本中分布式队列采用的是公共的集群,众多业务使用,出现过数据仓库受干扰影响特征数据同步。

为此:在数据仓库中新增一个异步消息队列模块写MQ,用于异步写入。和分布式队列相比,MQ更轻量,而且MQ我们可以自行维护,更可控。所以新架构中通过MQ实现实时特征的多IDC数据的同步,替代了分布式队列,保证数据同步不受其他业务影响。

数据仓库架构3.0版:

6.4运营系统

前面3个版本解决了特征存储分散、读写接口不统一、数据同步、读写性能问题,但是特征的上线依然采用的是配置发布上线的方式,效率依然低效。

更重要的是特征缺乏统一的管理,共享困难,难以满足业务的需求。

业务常常也有各种疑问:

为此数据仓库新增运营系统模块,实现了特征申请、特征上线、特征管理&分析、特征值查询/修改、特征数据质量管理等功能。

数据仓库架构4.0版:

1)特征申请:

用户不再需要手动的修改配置文件来新增特征,可直接通过WEB页面申请,填写必要的特征信息,通过通用审批系统进行审批。

2)特征上线:

用户不在需要手动的发布配置上线特征,无论是新增的实时特征还是离线特征,审批通过后将自动化的上线,提升体验和效率。

3)特征管理:

特征管理支持对特征meta信息进行查询和修改,包括特征所属的业务分类(索引)、特征类型、特征负责人、给特征打tag等等,业务可以方便的查询需要特征信息,避免重复的计算,方便各业务共享特征。

▲ 特征管理页面

4)特征分析:

追踪特征的原始数据来源、计算过程、数据流路径、最终的存储信息等等, 可以追踪特征完整生产流程。

▲ 特征分析页面

5)特征值查询&修改:运营系统支持在WEB页面查询特征值和修改特征值;

▲ 特征值查询页面

6)特征数据质量管理:保障数据质量, 下一章节详细讲述。

7、数据质量保障手段1:安全特征标准化

数据仓库主要通过两个方面来保障数据质量:特征的标准化和数据空跑系统。本节分享特征的标准化。

特征的标准化是保证数据仓库数据质量的手段之一,标准化是指对数据仓库中的特征进行规范化处理,使得特征能够达到一致性、可重复性等标准,从而提高数据的可靠性和准确性。

对于新增实时/离线特征:数据仓库制定了的特征规范文档,并按规范文档的要求,特征申请/管理页面必须正确的补充完整特征信息,如特征类型、业务分类等等,后台对每个特征都会进行校验,不符合规范的特征无法录入。

另外:数据仓库还提供了接入编程指导文档,并给出完整的C++编程实例,致力于提供标准化的编程最佳实践。

8、数据质量保障手段2:数据空跑系统

离线特征数据来自于业务离线计算在分布式文件系统中生成数据文件,然后将文件上线。

历史上曾因为生成的数据文件存在错误,存在错误的文件数据被上线到离线KV,导致策略出现故障。

为了保障离线特征数据的质量,数据仓库设计了一套空跑系统,在上线前对数据文件进行检查,避免存在问题的数据上线到现网。

数据空跑架构:

数据空跑架构如上图所示,离线特征数据的上线也纳入到了运营系统的管理中。

整个的空跑流程如下。

1)业务发起数据上线:运营系统将数据上线到备用的离线KV表,也就是用于空跑的KV表;

2)打开空跑开关:按一定的比率采样现网的读请求,旁路到新增的读MQ模块,该模块读空跑表的数据,和当前现网做对比, 分析差异率。这里采用的动态采样, 如果表的PV高则采样率低,PV低则采样率高或者100%采样,避免请求量小的表无法进行空跑,而请求量大的表空跑流量太高又消耗太多资源。

3)计算和分析差异率:如果差异率超过了阈值,就自动的拦截数据上线,如果阈值检查通过,就继续后续的检查流程,最终自动上线数据文件到现网离线KV。

差异率示例会如下图(详细的展示了具体的差异细节):

离线特征数据上线完整流程:

完整的数据上线流程如上图所示:空跑差异检测通过后,需要检查数据文件完整性,防止文件被修改或者覆盖,最后数据再上线到现网数据仓库系统,通知业务数据上线成功。如果中间任何一个步骤出错将告警给业务负责人,提醒人工介入处理。

9、本文小结

微信后台安全特征数据仓库将分散的特征全部集中统一管理,提供统一的访问接口,标准化每个一个特征,建立了统一的规范。

并且在此基础保障了数据的质量,夯实了整个安全业务的基础,助力一站式的数据-策略开发,极大的提升了安全对抗的效率,实现了数据价值的最大化。

10、相关资料

[1] 探讨组合加密算法在IM中的应用

[2] IM聊天系统安全手段之通信连接层加密技术

[3] IM聊天系统安全手段之传输内容端到端加密技术

[4] 理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)

[5] 微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解

[6] 移动端安全通信的利器——端到端加密(E2EE)技术详解

[7] 通俗易懂:一篇掌握即时通讯的消息传输安全原理

[8] 基于Netty的IM聊天加密技术学习:一文理清常见的加密概念、术语等

[9] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

11、微信团队的其它技术文章

IM全文检索技术专题(一):微信移动端的全文检索优化之路

IM全文检索技术专题(二):微信移动端的全文检索多音字问题解决方案

微信团队分享:iOS版微信的高性能通用key-value组件技术实践

微信团队分享:iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的?

微信团队原创分享:iOS版微信的内存监控系统技术实践

iOS后台唤醒实战:微信收款到账语音提醒技术总结

微信团队分享:微信Android版小视频编码填过的那些坑

企业微信客户端中组织架构数据的同步更新方案优化实战

微信团队披露:微信界面卡死超级bug“15。。。。”的来龙去脉

微信后台基于时间序的海量数据冷热分级架构设计实践

微信团队原创分享:Android版微信的臃肿之困与模块化实践之路

微信后台团队:微信后台异步消息队列的优化升级实践分享

微信团队原创分享:微信客户端SQLite数据库损坏修复实践

微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解

微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)

iOS版微信安装包“减肥”实战记录

移动端IM实践:iOS版微信界面卡顿监测方案

微信“红包照片”背后的技术难题

移动端IM实践:iOS版微信小视频功能技术方案实录

移动端IM实践:Android版微信如何大幅提升交互性能(一)

移动端IM实践:实现Android版微信的智能心跳机制

IPv6技术详解:基本概念、应用现状、技术实践(上篇)

微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)

微信团队分享:Kotlin渐被认可,Android版微信的技术尝鲜之旅

社交软件红包技术解密(十一):解密微信红包随机算法(含代码实现)

微信团队分享:极致优化,iOS版微信编译速度3倍提升的实践总结

IM“扫一扫”功能很好做?看看微信“扫一扫识物”的完整技术实现

微信团队分享:微信直播聊天室单房间1500万在线的消息架构演进之路

企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等

IM全文检索技术专题(四):微信iOS端的最新全文检索技术优化实践

微信团队分享:微信后台在海量并发请求下是如何做到不崩溃的

微信Windows端IM消息数据库的优化实践:查询慢、体积大、文件损坏等

(本文已同步发布于:http://www.52im.net/thread-4374-1-1.html

posted @ 2023-08-11 11:41 Jack Jiang 阅读(81) | 评论 (0)编辑 收藏

  • 关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持UDP 、TCP 、WebSocket 三种协议,支持iOS、Android、H5、标准Java平台,服务端基于Netty编写。

工程开源地址是:

关于RainbowChat

► 详细产品介绍:http://www.52im.net/thread-19-1-1.html
► 版本更新记录:http://www.52im.net/thread-1217-1-1.html
► 全部运行截图:Android端iOS端
► 在线体验下载:专业版(TCP协议)专业版(UDP协议)      (关于 iOS 端,请:点此查看

 

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题(可自行下载体验:专业版下载安装)。

* RainbowChat可能是市面上提供im即时通讯聊天源码的,唯一一款同时支持TCP、UDP两种通信协议的IM产品(通信层基于开源IM聊天框架  MobileIMSDK 实现)。

v9.0 版更新内容

此版更新内容更多历史更新日志):

(1)Android端主要更新内容适配最新Android系统等多项升级和优化】:

  • 1)[升级] 提升targetSdkVersion至33;
  • 2)[升级] 适配最新Andriod 13+系统的动态权限申请逻辑;
  • 3)[升级] 解决了Android13+系统全面屏手机上,APP下方出现大约15dp的黑色空白问题;
  • 4)[升级] 解决了Android13+手机上无法显示Notification通知的问题(Android13新增了通知权限,需动态申请后才能显示);
  • 5)[优化] 重新优化了闪屏、登录、帮助、忘记密码、注册、注册成功、查找用户、实时语音、实时视频等共计13个界面的UI设计;
  • 6)[优化] 其它未提及的ui细节优化和美感提升。
  • 7)[bug] 解决了从好友列表中打开群聊界面,不显示“返回”按钮的问题。
  • 8)[bug] 解决了当处于群聊界面时,群主更新群名称时,不能同步刷新群聊界面标题上的群名称显示。

(2)服务端主要更新内容:

  • 1)[优化] 解决了桥接模式下与最新rabbitmq库不兼容从而断线重连不成功,导致MQ中消息堆积的问题:
  • 2)[优化] 解决了桥接模式下MQ断线自动恢复时未主动清理Chanel,导致Chanel越来越多的问题;

此版主要功能运行截图更多截图点此查看):

posted @ 2023-07-26 12:53 Jack Jiang 阅读(96) | 评论 (0)编辑 收藏

本文由网易云信李兴分享,原题“深度剖析“圈组”深度剖析“圈组”关系系统设计”,为了提升内容品质,本文收录时有修订。

1、引言

上篇《百万级成员实时社群技术实现(消息系统篇)》中,我们分享了云信“圈组”(“圈组”是云信的类Discord产品实现方案)消息系统的技术设计和实践。

本篇接上篇,将继续分享云信“圈组”的关系系统在技术架构上的设计和实现。希望带给你启发。

 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4333-1-1.html

2、系列文章

本文是系列文章中的第 3 篇:

3、作者介绍

李兴:网易云信资深服务端开发工程师,毕业于浙江大学,硕士毕业后加入网易,负责云信 IM等业务的服务器开发。专注于即时通讯以及相关中间件等技术。

4、“圈组”的关系业务特点

4.1概述

在互联网行业盛行一句话,技术是为业务服务的。具体到技术实践中,一个重要方面就是要面向业务特点设计技术方案。

因此,想要了解“圈组”的关系系统设计,就要首先了解“圈组”的关系业务特点。

4.2业务特点

“圈组”的关系业务特点是什么?

  • 1)其一:是关系复杂,即关系主体多、管理机制杂、联动耦合重;
  • 2)其二:是规模巨大,即成员数量可达百万量级、变更批量可达百万量级。

所谓关系复杂,具体来讲:首先是关系主体多。

在“圈组”业务中,关系主体包括:

  • 1)服务器:承载社群关系,负责社群成员关系维护;
  • 2)频道:从属于服务器,承载内容关系,负责内容互动关系维护;
  • 3)身份组:可从属于服务器或频道,承载身份权限关系,负责身份设定和权限配置;
  • 4)频道分组:从属于服务器,又关联一组频道,承载频道模版关系,负责分类频道和共享配置。

其次是:管理机制杂。

在“圈组”业务中,仅就成员管理机制而言:

  • 1)服务器成员采用邀请/申请机制;
  • 2)频道成员采用公开/私密模式+黑/白名单机制;
  • 3)身份组成员采用加入/移出机制;
  • 4)频道分组成员与频道成员采用同步机制。

最后是:联动耦合。

在“圈组”业务中,以频道成员维护为例:频道成员不仅受到公开/私密模式+黑/白名单配置变更的影响,而且会伴随服务器成员变更、身份组变更、身份组成员变更等做联动变更。

所谓规模巨大,具体来讲:

  • 1)一方面:成员数量可达百万量级(在“圈组”业务中,服务器成员数量可以达到数百万人);
  • 2)进一步:百万成员服务器下的频道和身份组,其成员数量也可以达到百万量级;
  • 3)另一面:是变更批量可达百万量级。

所谓变更批量可达百万量级,包括:删除百万成员的服务器/频道/身份组,增删频道/频道分组黑白名单中的百万成员身份组等。

从“圈组”关系业务的两大特点出发,可以发现:“圈组”关系是不同于群组关系的全新业务场景,将会面临全新的技术难点。

5、“圈组”关系系统的技术难点

5.1概述

技术难点主要有两个方面:

  • 1)其一:是多关系主体、多管理机制在层级结构下关联耦合导致的业务逻辑的复杂性;
  • 2)其二:是成员数量、变更批量规模巨大导致的业务处理在时间、空间、资源等开销上的复杂性。

5.2业务逻辑复杂性

1)首先“圈组”有多级结构:

包括服务器/频道二级结构、服务器/频道分组/频道三级结构等。

单个关系主体变更,不仅涉及自身的变更,而且涉及上下级关系主体的变更,可以说牵一发动全身。相比而言,群组是没有层级的,群组变更只要独善其身就好。

2)其次“圈组”有身份组:

一个身份组是一组有共同权限的服务器成员的集合,不同身份组的成员可以相互交叉,身份组会作为整体参与到成员管理中。

也就是说,成员变更不再只是个别成员(1-100人)的进入退出,将会出现整组成员(1-1000000人)的大进大出。相比而言,群组是没有身份组的,群组特殊成员包括群主、管理员等也都数量不多、互不重复。

3)最后“圈组”有多种成员管理机制:

服务器成员和身份组成员的管理机制与群组类似,频道成员和频道分组成员的管理机制却是全新模式。

频道分为公开和私密两种:

  • 1)公开模式默认允许所有服务器成员可见,但要排除黑名单身份组和黑名单成员;
  • 2)私密模式默认不许所有服务器成员可见,但要放开白名单身份组和白名单成员。

除了受到公开/私密模式+黑/白名单配置变更的影响,频道成员也受到所依赖的关系主体(服务器成员、身份组、身份组成员)变更的影响。进一步,频道成员还受到所同步的频道分组变更的影响。相比而言,群组成员的邀请/申请机制,可以说是小巫见大巫。

5.3业务处理复杂性

1)首先是成员数量规模巨大:

由于成员数量可达百万,整个成员列表的存储空间开销、网络传输开销,变得十分巨大,不论全量成员列表数据的服务器缓存,还是全量成员列表数据从服务器到客户端的同步,都将变得难以实现。

2)其次是变更批量规模巨大:

单次接口调用的关系变更,可能伴随百万规模的联动关系变更,这会导致巨大的处理时间开销、计算资源开销,不论所有变更同步完成处理,还是所有变更单机完成处理,都将变得难以实现。

3)最后是通知消息规模巨大:

关系系统不仅需要做关系变更的数据处理,而且需要通知变更结果到客户端。由于在“圈组”中各个关系主体的成员数量规模巨大,使得单个变更需要扩散为百万通知同时下发,所需计算资源开销、网络传输开销十分巨大。

相比而言,群组方案因为成员数量、变更批量规模有限,并不涉及这些技术难点。

从“圈组”关系系统的两个方面技术难点出发,可以发现:“圈组”关系系统面临不同于群组的全新技术难点,想要解决这些技术难点,需要创新的技术方案。

6、“圈组”的整体架构

“圈组”方案的整体架构:

上面展示了“圈组”方案的整体架构,可以看到“圈组”整体是一个分层架构。

从上到下看:

1)客户层:包括可供客户端集成的移动端、桌面端、跨平台 SDK,和可供服务器调用的 OpenAPI;

2)接入层:包括 LBS 服务、长连接服务和 API 网关,分别对应客户端 SDK 和用户服务器;

3)网络层:包括自研的全球实时传输网络 WE-CAN;

4)业务层:包括用于 SDK 业务处理的 App 服务和用于 OpenAPI 业务处理的 WebServer 服务;

5)服务层:划分有登录、消息、关系、身份组、支持等服务模块,每个服务模块包括有多个微服务或消费者;

6)基础设施层:包括系统所用的数据库和中间件。

7、“圈组”关系系统的架构

上图展示了“圈组”关系系统的技术架构。可以看到“圈组”关系系统遍及“圈组”架构的接入层、网络层、业务层和服务层。

从功能出发整体上分为三个部分:

  • 1)关系操作同步处理模块;
  • 2)关系事件异步处理模块;
  • 3)变更通知在线广播模块。

下面具体讨论三个方案要点的技术细节,包括频道成员关系管理、变更通知在线广播和关系数据云端检索。

8、关系系统技术实现1:频道成员关系管理

频道成员关系管理,是“圈组”中极具挑战性的问题。

频道成员涉及多关系主体、多管理机制、联动变更耦合严重,成员数量和变更批量规模巨大,可以说是“圈组”关系业务的典型代表。

频道成员关系管理在业务逻辑和业务处理两方面的复杂性可想而知。

针对频道成员关系管理问题,“圈组”设计了两大机制加以解决。

包括:

  • 1)终态维护与过渡计算相结合机制;
  • 2)事件按序异步并行处理机制。

终态维护与过渡计算相结合机制,具体来讲:频道成员关系数据最终被维护在持久化数据库中,并在频道成员没有变更的终态阶段,直接支持频道成员数据的查询需求。当频道成员发生变更时,由于变更逻辑和变更处理两方面的复杂性,完成关系变更需要一段时间,称之为过渡阶段。

在过渡阶段,数据库持久化的频道成员表数据是不完全准确的,无法直接支持频道成员数据的查询需求。此时转为由频道成员配置元数据直接计算频道成员以支持查询需求。因为频道成员配置元数据的变更是同步处理的,所以在过渡阶段由频道成员配置元数据直接计算频道成员可以保证查询准确性。通过将频道成员关系管理分为终态和过渡两个阶段,并在不同阶段采用不同频道成员查询方案,不仅解决了单纯由计算获取频道成员资源开销大的问题,而且解决了频道成员变更延迟导致由数据库获取频道成员结果不准确的问题。

除了频道成员的获取查询问题,频道成员的变更处理也很重要。

事件按序异步并行处理机制,就是用于解决频道成员的变更处理问题:

  • 1)其一:通过将影响频道成员关系的变更操作分层级、系统化定义为变更事件,显著降低频道成员关系管理的业务逻辑复杂性;
  • 2)其二:通过 ID 哈希、分布式锁、事件版本号控制等保证变更事件的按序处理,有效避免事件处理乱序导致的持久化数据错误;
  • 3)其三:通过消息队列中转事件并在消费者上异步处理,有效解决联动变更批量过大导致接口调用阻塞的问题;
  • 4)其四:通过在单个事件处理中的多线程并行加速和本地缓存重用加速,显著缩短频道成员关系变更的时间延迟。

9、关系系统技术实现2:变更通知在线广播

关系系统不仅需要做关系变更的数据处理,而且需要通知变更结果到客户端。

在百万量级的“圈组”关系中,每条关系变更通知,都会面临海量扩散的接收者。除了通知分发量激增,不同接收者对于通知接收的缓急差异也值得关注。

针对变更通知在线广播问题, 我们设计了两大机制:

  • 1)变更分类通知机制;
  • 2)数据通知拉取机制。

在变更分类通知机制中:一方面,根据相关人员在变更中的角色,划分为参与者和观察者分类做通知,即参与者一定通知,观察者按照订阅需求通知。其中参与者一般是变更中的少数关键人员,观察者则是除了参与者之外可以看到变更结果的其它人员。通过分类通知,不同接收者对于通知接收的缓急差异得到合理关注,变更通知的扩散规模也得到精准缩小。

另一方面,观察者按照订阅需求通知,可以充分发挥“圈组”的在线广播订阅模式的优势。所谓在线广播订阅模式,是指在用户登陆之后,需要订阅感兴趣的服务器/频道的通知,“圈组”系统会记录下这些订阅信息,当有新的通知时,“圈组”系统通过订阅关系而非成员列表 + 在线状态获取需要在线广播的用户列表,从而不再需要遍历服务器/频道的所有成员及其在线状态。通过采用在线广播订阅模式,不仅显著降低变更通知在线广播的计算开销和带宽开销,而且可以实现变更通知在线广播在长连接服务集群的并行加速和水平扩展。

变更通知的最终目的是将变更后的数据给到客户端:不同于群组,“圈组”并不将变更后的数据直接由通知带给客户端,而是采用通知客户端有变更再触发客户端拉取结果数据的机制。

究其原因,不同于群组将关系数据全量同步到客户端,“圈组”客户端不再存储关系数据的全量镜像,因此不再需要通过全量历史 + 增量变更的方式维护客户端上的关系数据全量镜像。

与此同时,订阅变更通知的观察者也并不是每时每刻都要关心变更的结果数据,关心某次变更结果数据的观察者相比订阅变更通知的观察者在数量上会少很多,因此,数据通知拉取机制会显著降低变更通知的资源开销。

另外,相比带变更数据通知,只通知有变更,便于直接合并相同类型的通知,而不用关心合并变更数据存在的时序、并发等问题,如此,数据通知拉取机制可以通过短时间内通知合并显著降低服务器在线广播开销和客户端通知接收开销。

10、关系系统技术实现3:关系数据云端检索

在“圈组”中,伴随关系规模的大幅增长,群组基于应用服务器全量查询关系数据或客户端全量同步关系数据实现精准查询和灵活排序的方案不再适用。

对此,“圈组”采用了关系数据云端检索的方案。

“圈组”关系数据云端检索方案可支持服务器、频道、成员等的检索能力。

从检索场景上分,包括:

  • 1)广场检索:用于检索感兴趣的服务器。可以根据名称、类别等多种维度检索。检索结果可以根据预定义字段(成员数量等)或自定义值(数据热度等)等进行排序;
  • 2)内部检索:用于检索用户可见的服务器、频道、成员等。可以根据名称、昵称等多种维度检索。检索结果可以根据预定义字段(创建时间等)或自定义值(数据热度等)等进行排序。

11、相关资料

[1] 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等

[2] 以微博类应用场景为例,总结海量社交系统的架构设计步骤

[3] IM开发技术学习:揭秘微信朋友圈这种信息推流背后的系统设计

[4] 直播系统聊天技术(四):百度直播的海量用户实时消息系统架构演进实践

[5] 喜马拉雅亿级用户量的离线消息推送系统架构设计实践

[6] 企业微信客户端中组织架构数据的同步更新方案优化实战

[7] 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等


(本文已同步发布于:http://www.52im.net/thread-4333-1-1.html

posted @ 2023-07-21 14:56 Jack Jiang 阅读(94) | 评论 (0)编辑 收藏

本文由网易云信资深服务器开发工程师曹佳俊分享,原题“深度剖析“圈组”消息系统设计 | “圈组”技术系列文章”,为了提升内容品质,本文有修订和删节。

1、引言

鉴于实时社群产品Discord在IM垂直应用领域的爆火,类似的需求越来越多,云信的“圈组”就是针对这种应用场景的技术产品。

“圈组”产品发布后获得了很大的关注,很多云信用户在接入SDK的同时对于“圈组”的底层技术细节和原理也非常关注,为此我们决定推出“圈组”相关的技术文章,分享云信在“圈组”技术设计上的一些思考和实践。

本文是序列文章的第2篇,将要分享的是云信的实时社群产品“圈组”(“圈组”云信的类Discord产品实现方案)的消息系统技术设计实践。

 
 技术交流:

(本文已同步发布于:http://www.52im.net/thread-4321-1-1.html)

2、系列文章

本文是系列文章中的第 2 篇:

3、作者介绍

曹佳俊:网易云信资深服务器开发工程师,毕业于中国科学院,硕士毕业后加入网易,负责云信 IM/RTC 信令等业务的服务器开发。专注于即时通讯、RTC 信令以及相关中间件等技术,是云信开源项目 Camellia 的作者。

4、“圈组”的技术特点

在介绍“圈组”的技术细节之前,我们先了解一下圈组的技术特点。

“圈组”产品最大的特点是什么?

  • 1)首先:是 server/channel 的二级结构;
  • 2)其次:是构建在二级结构之上的大规模社群(单个 server 数十万甚至上百万成员);
  • 3)以及:使用复杂的身份组系统来管理如此规模的社群组织和成员。

那么对于这样一个新颖的 IM 系统,在技术上应该如何实现呢?

5、“圈组”和传统IM群组的技术差异

5.1概述

一种简单的思路是改造已有的 IM 系统,对于“圈组”这样的类 Discord 社群,第一个思路是拓展我们的群组功能,猛一看在很多方面确实挺像的。

我们做了个简单的对比:

从上面的表格可以看到,“圈组”和群组最大的不同:

  • 1)是容量的区别;
  • 2)是二级结构。

其他的诸如身份组、个性化推送策略,似乎只要适配的做一下就可以了。

那么是不是只要想办法提升一下群组的容量,再在业务层封装一下二级结构就可以了呢?

答案显然是否定的,或者至少说基于群组去扩展不是一个很好的想法。

5.2二级结构的差异

首先是二级结构。

在类 Discord 的二级结构中,成员的管理在 server 层,而 channel 成员是继承自 server 的,而且在 channel 之上还有很多可见性的配置(我们的“圈组”提供了黑白名单机制,而Discord 则提供了查看频道权限)。

在这种机制之下,任何 server 层面的成员变动,都可能影响全部或者部分频道的成员列表。

面对这种复杂的结构,群组有两种思路去实现:

  • 1)一种是 N 个群,逻辑上隶属于同一个 server;
  • 2)一种是一个群映射为一个 server。

不管哪种方式,先不说消息投递这块的逻辑,仅成员管理上逻辑的耦合和交织的复杂性,足以劝退任何人。

5.3容量的差异

常规IM群组的容量一般只有数百,最多可以扩展到数千。

对于IM群组成员的管理,我们一般采取全量+增量同步相结合的方案,客户端和服务器映射到相同的群组镜像(群信息+群成员等)。此时很多操作,例如群成员的展示、检索,消息的艾特等,都可以基于纯客户端进行。

而“圈组”要求几十万甚至上百万的容量,显然客户端无法一次性获取到所有成员,如果你一次性加入多个 server,那成员的数量将更加膨胀。

因此在“圈组”这种大规模社群的设计中,很多逻辑都会转向云端,此时不管是 SDK 还是服务器,均需要修改原有的设计逻辑。

5.4消息规模差异

此外,大规模社群带来的是消息爆炸。

在原有的IM群组设计中,假设一个人同时加入了 1000 个群,那么这 1000 个群内的所有消息均会在第一时间下发给给客户端。

但是在一般的业务场景中,不会所有的群都同时活跃,假设这 1000 个群变成了 1000 个服务器/频道,作为一种社群组织,同时活跃的可能性将大大增加,而且每个服务器/频道的人数远远超过普通的群组,叠加之后带来的消息爆炸现象在原有的群组体系中将带来极大的压力。

压力包括多方面:

  • 1)首先是海量消息的存储压力;
  • 2)其次是海量消息在线广播/离线消息推送带来的带宽和服务器压力;
  • 3)以及客户端在面对大量消息冲击时如何有效地接受和合理的展示。

5.5小结

除了容量、二级结构、消息规模,包括身份组、成员管理、个性化推送策略等等都存在巨大差异。

是否真的适合在群组中添加这些复杂逻辑呢,强行绑定在一起会不会既没有一个好用的类 Discord 平台,也使得原始的群组功能繁杂,反而降低了易用性呢?

经过上面的一些分析,我们基本可以得出一个结论:在已有的群组基础上扩展来实现一个类 Discord 功能的社群,显然不是一个很好的思路。

那么还有其他“捷径”吗?

IM聊天室也是一个潜在的选项,聊天室的一大特点就是支持超大规模同时在线(参见《千万级实时直播弹幕的技术实践》),容量似乎已经不是问题,但是当考虑添加其他一些强社交关系的特性时(如成员、身份组等)就显得有点为难了,聊天室本身就是来去自如的一个开放空间,这个和圈组的产品本身定位互相冲突的。

因此基于聊天室扩展的方案也基本 pass 掉了。

6、“圈组”的技术难点

基于上述种种的思考和讨论,最终选择脱离已有 IM 体系,从零研发一套全新的社群方案“圈组”,“圈组”不是一个简单的 IM 功能,而是一套可以独立运行的 IM 系统。

经过上面的讨论,相信大家对“圈组”本身的技术特点和难点也有所理解。

可以归纳为以下几点:

  • 1)二级结构下成员无上限的社交关系系统设计;
  • 2)超大社群下消息系统设计;
  • 3)复杂高效的身份组系统设计;

7、“圈组”技术实现之整体架构  

“圈组”整体架构:

上面展示了“圈组”服务整体的架构。

可以看到整个“圈组”服务是一个分层的架构:

  • 1)首先是接入层,包括 LBS 服务和长链接服务器以及 API 网关,对应客户端 SDK 和用户服务器;
  • 2)后面是网络层,包括大网 WE-CAN 和协议路由服务;
  • 3)其次是服务层,划分了多个服务模块,每个模块都包括多个微服务;
  • 4)最后是基础设施。

8、“圈组”技术实现之消息系统架构

这其中和消息系统相关联的包括接入层、网络层、以及后端的登录/订阅/消息/检索等模块。

基本架构如下:

消息系统中第一个要讨论的点就是消息的存储和分发方式,包括在线广播、离线推送、历史消息三个维度。

下面几节我们将对消息系统中各模块分别展开介绍。

9、“圈组”消息系统技术实现1:在线广播

对于一般的IM群组来说,在线广播的一般过程是这样的:依次查询群组里的所有人的在线状态,如果在线,则将消息发送给对应的长链接服务器。

显然这种机制无法复制到“圈组”,因为在“圈组”的一个服务器里可能存在超过 100w 的人。

此外:IM聊天室的广播模式也不能直接复用,因为在聊天室架构中,每个长链接映射到一个聊天室,因此当你登录到某个聊天室的时候,你只会收到该聊天室的消息。而对于“圈组”来说,每个用户会同时加入多个服务器/频道,而且会同时收到多个服务器/频道的消息。

针对“圈组”的上述特点:我们设计了消息订阅模式,也就是用户登录之后,需要订阅感兴趣的相关服务器/频道,服务器会记录下这个订阅信息。当有新消息的时候,服务器通过订阅关系(而不是在线状态)查询到需要广播的列表,通过这种方式就不再需要遍历服务器/频道里的所有用户。

但是当一个服务器/频道里在线人数非常多的时候,这个订阅关系仍然是巨大的。

为此:我们设计了一种两层订阅模型,即所有的订阅关系会保存在长链接服务器上(QChatLink/QChatWebLink),同时长链接服务器会定时发送心跳给后端的订阅服务器,心跳信息相比原始的订阅信息会大大简化,比如长链接服务器上会记录账号 A 订阅了某个频道 A 的消息,如果有 1w 个账号,则有 1w 条订阅记录,而心跳信息里只会上报有 1w 个人订阅了某个频道 A 的消息,具体的账号列表则被精简掉了。当一条消息需要广播时,消息服务会访问订阅服务,获取到该服务器/频道被订阅的长链接服务器列表,并依次给该列表中的长链接服务器发送消息下发通知,长链接服务器收到通知后会根据订阅详情再广播给所有客户端。

此外:我们还提供了多种订阅类型,当你非常关心某个频道消息时(比如页面正停留在该频道),此时你可以订阅该频道的消息。对于其他频道,如果你仅仅需要知道该频道有多少条未读消息(或者有无未读消息),则可以选择订阅该频道的未读计数(或者未读状态),此时服务下发时仅会广播精简的消息体用于维护客户端未读计数,并且当未读计数达到一定阈值之后(比如 99+),服务器可以选择不再下发任何通知消息而不影响用户体验。

通过上文介绍的消息订阅模型,极大地提高了超大型的圈组频道/服务器消息在线广播的效率,降低了服务器压力。

除此之外:我们还设计了针对小型频道的特殊策略,对于小型频道,即使不订阅,服务器也会下发消息通知给频道里所有人,从而减轻端侧消息订阅模型的维护成本。针对消息订阅机制本身,后续我们也会根据不同的业务场景,提供更多一站式的策略来帮助降低接入成本,提升整体的易用性。

10、“圈组”消息系统技术实现2:离线推送

在强社交的场景下,离线消息推送对于维持用户粘性+提升产品体验有很大的作用。

从技术角度看的话,主要解决2个问题:

1)第一个是超大型服务器/频道的消息推送的效率问题;

2)另一个是提供足够丰富的推送策略来帮助 C 端用户,避免被过量的推送消息给打扰。

针对第一个问题,我们针对不同规模的服务器/频道采取了不同的策略:

  • 1)对于小型频道:采用类似于群组的消息推送模型;
  • 2)对于大型频道:对于每一条需要推送的消息,会根据目标用户的 ID 进行任务分片,多个节点并行操作,提高推送效率。

此外:分片会采用一致性策略,保证单个用户固定为某些节点,从而提高缓存命中效率。

针对第二个问题,推送策略可以用以下几句话来描述:

  • 1)既关注促活,又保证不打扰;
  • 2)大型 server 是游乐场,只推送与用户相关的重要消息(如 @消息);
  • 3)小型 server 是与朋友相处的小天地,支持消息的全部推送。

并且:未来用户还可以自定义消息的高低优先级,并搭配不同的推送配置(如不同的免打扰配置等),如下图所示。

11、“圈组”消息系统技术实现3:历史消息

历史消息的存储在“圈组”的场景中也需要一些特别的设计。

同样以传统IM群组为例,一般来说消息的存储方式有两种,写扩散和读扩散。在小型的IM群组或者多人会话中,写扩散模式可以简化设计,但是当群组规模扩大到一定程度(如万人群),读扩散就成了选择。

而对于“圈组”这种单个服务器可能上百万人的“群组”中,除了常规的读扩散之外,我们还设计了多级缓存的结构来应对海量的读请求。

基本的存储架构大致如下:

消息的存储主要包括两部分:

  • 1)一部分是消息本身;
  • 2)一部分是未读计数。

首先是写入:对于上述两者,我们都会使用中心化的缓存服务器来存储最近的数据,并使用异步+批量+聚合等手段,通过 MQ 异步落库,从而平衡写入效率(单条写入性能低)和写入读取延迟(异步写入有延迟)的问题,并且针对不同数据类型的特点,我们也选择了不同的存储方案(历史消息使用分布式时间序列数据库,未读计数使用分布式 k-v 数据库),最大化地提升消息存储和查询的性能和效率。

有写就有读,针对读取操作:

  • 1)所有最近的消息和未读计数均会存储在中心化缓存中,并通过先进先出和缓存过期等不同的策略来确保缓存中存储的永远是最新和最热的数据;
  • 2)对于消息 ID 和消息内容本身,中心化缓存中也会有不同的数据结构和过期策略,来平衡缓存命中率和缓存容量消耗;
  • 3)当缓存过期了,如果有关联的读写请求,将会触发缓存的重建,以保证缓存的命中率始终保持在较高水位;
  • 4)当有高频的读请求,还会触发热点 cache 的检测,并将一部分读请求下沉到各个计算节点的内存中,以应对突发流量的冲击。

上述针对“圈组”的特别设计,消息存储系统可以应对几十数百人的小型圈组频道,也可以从容应对上百万的超大型频道。

12、相关资料

[1] IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)?

[2] 网易云信技术分享:IM中的万人群聊技术方案实践总结

[3] 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等

[4] 融云IM技术分享:万人群聊消息投递方案的思考和实践

[5] 微信直播聊天室单房间1500万在线的消息架构演进之路

[6] 百万人在线的直播间实时聊天消息分发技术实践

[7] 千万级实时直播弹幕的技术实践

[8] 深度解密钉钉即时消息服务DTIM的技术设计

[9] 深度揭密RocketMQ在钉钉IM系统中的应用实践

[10] 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等

[11] 一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等

[12] 从新手到专家:如何设计一套亿级消息量的分布式IM系统

(本文已同步发布于:http://www.52im.net/thread-4321-1-1.html

posted @ 2023-07-12 13:42 Jack Jiang 阅读(81) | 评论 (0)编辑 收藏

本文由腾讯产品体验设计师volihuang分享,原题“千万级增长,实时社交产品Discord拆解”,本文收录时有内容修订和大量排版优化。

1、引言

对于大多数人而言,对即时通讯IM应用的认知仍然停留在微信、QQ这类经典的即时通讯聊天场景。

实际上,如今的即时通讯技术已渗透到各种业态中,包括本系列文章将要分享的目前大热的Discord实时社群软件(Discord主要用于游戏社交),研究Discord软件包括技术实现上和产品定义上或许可以对你在其它业态中更好的应用即时通讯技术带来启发,也这是整理分系列文章的初衷。

本文为系列文章的首篇,文章内容不讨论Discord具体的技术实现,仅从其产品定义的角度上对Discord软件进行详尽和具体的介绍,希望能帮助你对Discord从产品形态上有较为完整的认知,也方便你阅读本系列文章的后续篇章。

 
 技术交流:

(本文已同步发布于:http://www.52im.net/thread-4300-1-1.html)

2、系列文章

本文是系列文章中的第 1 篇:

3、Discord是什么

3.1席卷游戏圈的社群

Discord是一家游戏实时聊天应用与社区,Discord从游戏语音、IM工具服务起家,随后转向直播平台,进而开设游戏商店的社区平台,成为游戏玩家在游戏中沟通协作的首选工具。Discord于2015年5月公开发行。

在 2018 年,它就已经席卷游戏圈,成了最受游戏玩家亲睐的「语音聊天工具」。在“英雄联盟”美服,几乎每局游戏开始前,都会有人发送 Discord 频道链接,邀请队友通过 Discord 沟通,而不是使用游戏内置的语音工具。

从语音聊天工具,到游戏玩家社区,Discord 似乎正在开创一种全新的互联网社会形态。它预示了一种比 reddit、Facebook 可能更理想的全新未来。

3.2从「工具」到「社区」

Discord 绝不是最「简单易用」的一个,但 Discord 却在思考如何从最底层优化产品,给到用户更多「可能性」.在疫情的大环境下,从2020年2月到7月,Discord的用户数量增加了47%,学习小组开始使用Discord;老师用它上课;朋友们用它来玩,就像平时放学后或周末一样。

3.3UI界面概览

4、Discord的发展历程

Discord相较于传统图文沟通模式的社群有着显著的优点:在Discord上社区建立者可以通过权限设置,轻松的进行用户细分,精准高效的传递信息;也可以进行社交媒体整合,为自己的其他社群进行引流。而Discord建立如此丰富的功能主要分为三个阶段来实现:

4.1第一阶段:游戏语音工具

核心增长点:极致的基础用户体验。

在工具阶段,Discord不断打磨全面超越竞品的基础体验,从界面审美、多端支持、延迟、降噪等等方面都处于市场领先地位。

通过极致的用户体验与因此收获的口碑传播,获取了第一批深度的种子用户。而这些用户逐渐围绕所玩的游戏形成了游戏社群。

4.2第二阶段:游戏社群

核心增长点:平台设计+能力开放+内容运营+用户质量。

在游戏社群阶段,Discord通过平台设计、能力开放、内容运营等方式加速了游戏社群的形成和壮大,游戏品类用户需求的溢出创造了更多的品类。

平台设计:完全免费设计、PC/Web/移动多端支持、免注册即可使用、无任何广告等,这些产品设计加速了用户的裂变;好友列表、加入服务器等沉淀的关系链继而让用户继续留存。Discord在产品设计中始终按照做一个平台的思路来设计,期望快速获得大量用户以形成网络效应。

能力开放:开放了较多的API能力,如支持游戏厂商接入语音sdk、支持同步Twitch直播状态、同步Steam游戏状态等等。这给用户和其他平台方提供强大的额外价值。

如音视频流可直接接入Discord,在服务器内就可以和好友一同观看Twitch/Youtube。如得知好友的游戏状态可以快速加入相同游戏一起开黑等。这也是平台设计的思路,开放能力接入第三方以获取赋能。

4.3第三阶段:全品类社群/社区

核心增长点:强大的管理能力(机器人开放平台/服务器权限/服务器模板…)。

Discord中服务器的管理能力非常丰富,通过设置不同的频道组和频道、设置身份权限、引入机器人等等手段,数十万人的社群也能够进行得有条不紊。

5、Discord的现状

现阶段,Discord 估计有 3 亿用户,其中包括 1.5 亿月活跃用户,平台上有 1900 万个服务器,涵盖游戏、投资、政治、动漫等领域。2020 年,Discord 每周有 670 万服务器处于活跃状态,基本上每周都有某个给定话题的对话讨论。2021 年,Discord 每周活跃服务器数据增长到了 1900 万。

来自移动产业数据平台 Apptopia 的消息显示,线上社区 App「Discord」的下载总量在近期已突破 5 亿次,同时应用内购营收总额突破 1 亿美元。

Discord 平台上单个日活跃用户(DAU)与平台的平均互动时长,是游戏直播平台 Twitch 的两倍,同时还是 Facebook Gaming、TikTok、Reddit 以及 Snap 等头部社交平台的两倍以上。

但是,即便在如此惊人的增长之后,Discord 似乎并没有太多商业化的动作。2020 年,Discord 的每用户平均收入 (ARPU) 仅为 1.30 美元,在公共社交媒体公司中排名非常靠后。


6、Discord平台机制介绍

6.1基本

Discord以其多样化的平台机制设定,为使用者提供了多种多样免费的功能。

它们是:

  • 1)以高音质、几乎零延迟、无限时间与尽可能多的朋友交谈;
  • 2)只需单击两次,即可将游戏直播带给服务器中的任何人,而且不会存在任何延迟;
  • 3) 使用单独的音量滑块一次观看多个流媒体;
  • 4)可以创建几乎无限量的文本聊天室,甚至可以追溯到几年前的档案;
  • 5)与朋友分享小文件;
  • 6)将机器人融入其中,可以向所有人广播音乐;
  • 7)Discord 支持视频流和屏幕截图等功能。

下面,我们详细介绍Discord中的功能设置。

6.2服务器机制

在 Discord 中有一种别于一般通讯软体之群组的群体聊天,称作服务器(类似社团),服务器拥有者可以在服务器中创造属于自己的社群。

例如:MINECRAFT在Discord的服务器,成员数已超过100w人,达到Discord目前设置的服务器上限。

MINECRAFT界面:

此外,在服务器搜索界面搜索MINECRAFT,可发现Discord上有6000+个MINECRAFT相关服务器,分布于社交、娱乐、同好、动画漫画、创作者等不同板块,绝大部分由玩家自发成立,在其中分享素材及想法。

6.3身份组机制

在 Discord 中可以建立非常多不同的身份组,使用者可以完全自订身分组的颜色、名称、权限、符号等等,身份组会直接影响使用者的名称颜色及用户列表的排序。

6.4频道机制

在伺服器中可以建立名为频道的聊天管道,分为语音、文字,其中的语音频道可以用来直播游戏与聊天等,频道可以设定与身份组整合各种权限,让 Discord 社群系统更加多样化。

文字方面:Discord 使用markdown语法,目的是对富文本一定程度的支持。

语音方面:Discord 使用opus音频格式,目的是压缩语音来降低延迟。

“哈利波特:魔法觉醒”的频道介绍列表:

6.5用户机制

每个 Discord 用户都有一个唯一的四位个人识别码,用户名后有一个"#"(例如ABCD#1234)。这使得多个用户能够拥有相同的用户名,并且用户可以很容易地找到朋友。

用户信息示意图:

6.6机器人

在 Discord 中所有使用者皆可以创立机器人,机器人主要是使用 Python 和 Java 编写,透过 Discord API 的语法扩充来编程。机器人可以发送讯息、图片、嵌入式讯息、嵌入式按钮、新增反应等,大致上与人类使用者权限无太大差异,不过在机器人的名称旁会有一个蓝色的 BOT 标志。机器人一样受到身份组权限的控管。

Topwar中的机器人消息及调用指令:

6.7整合

每个频道皆可以使用Webhook来抓取其他资讯,这使得在使用时甚至可以将Facebook、微博的贴文直接同步到Discord的频道中,另外频道也可以追踪另一个公告频道,来直接同步公告频道中的所有讯息。

6.8软件技术

尽管 Discord 的服务器由于其分布式特性无法匹配对应的传统硬件或虚拟服务器,不过其服务器和频道仍可类比于因特网中继聊天技术。用户可以在 Discord 上创建服务器并设定其他用户的加入条件。

Discord 的客户端使用Web技术构建在 Electron 框架上,这使得它可在多平台运行,既可在网页上运行,又可在个人计算机上作为应用程序运行。除了从 Discord 游戏商店下载和玩游戏为 Windows 独有之外,客户端的所有版本都支持相同的功能集(不包括与桌面音频的屏幕共享)。

Discord 是专门设计用于游戏互动的软件,因为它包括诸如低延迟、用户免费语音聊天服务器和专用服务器基础设施等功能。

6.9与游戏互联

在服务器和用户的层面上,Discord 允许用户连接到 twitch 或其他游戏账号。这种集成方式在一些应用程序中提供了独特的消息传递方法。

例如:如果用户使用自己的账号登录steam 玩游戏,Discord 便可以确定该用户正在玩该游戏。

6.10Nitro

虽然软件本身是免费的,但开发人员致力于研究如何将其商业化以营利,以Nitro计划的方式为对emoji和、贴图、个人化个人资料页面、语音及直播画质提升及文字字数限制进行付费使用。

7、Discord中的用户角色

Discord中的角色为用户提供特定权限。

例如:可以为主持人创建一个角色,并为该角色授予禁止用户和删除邮件的权限。 分配给该角色的任何用户都将继承这些权限。 使用角色可以使不必为每个用户分配权限。

要管理角色,请打开服务器设置,然后单击左侧的“角色”类别。 可以通过单击页面上“角色”标题侧面的小加按钮来添加新角色。 选择一个角色来管理权限。

有很长的权限列表,但重要的权限涉及通过创建新的渠道或角色来管理服务器的能力,通过禁止或删除邮件来管理用户,以及将用户移入和移出语音聊天。

还有一个管理员角色,它提供除服务器所有者特定的权限之外的所有权限(例如:删除服务器)。

8、Discord中的频道

服务器上的每个频道都按类别进行组织。 要创建新通道或类别,请右键单击通道窗格中的任意位置,然后单击“创建通道”或“创建类别”命令。

创建频道时,请为其命名并选择是应该是文字频道还是语音频道。 通道名称不能包含空格(键入空格只会创建连字符)或大写字母。

频道也有自己的频道特定权限,可以通过单击频道旁边的齿轮来访问这些权限。 这些权限默认与频道所属的类别同步,但如果更改它们,它们将保持这种状态,直到再次同步。

还可以将类别和频道设为私有。 当创建频道时,只需选择“私人频道”,然后启用希望能够访问该频道的角色。

如果只想向频道添加一些人,最好为该频道创建一个新角色,然后将用户添加到该角色。

下面我们讲介绍常见频道类型。

8.1)欢迎频道/规则频道:

欢迎频道一般包括服务器及游戏内容的大概说明、禁止的事项、频道发言规范等信息。可以由公告或文本频道设置而成。也可再次频道设置本地化相关选项(如语言)。

8.2)游戏活动公告频道组:

官方针对游戏内活动及社群相关活动的推宣,以公告频道的形式呈现。

8.3)游戏直播、其他社交媒体链接:

可以选择同步自身的twitter也可将自身所有媒体链接以消息的形式呈现,有助于游戏自身社交平台间的相互引流。

8.4)二创内容频道组:

通常包含玩家的绘画创作、视频创作、cosplay等,官方可在此频道中发布相应活动的信息并发放相应的活动奖励。

8.5)玩家公共讨论区频道组:

设置所有玩家都可参与的公共频道,为玩家提供交友、游戏内容交流甚至闲聊的空间。

8.6)语音讨论频道组:

为玩家建立可公共使用的语音频道,方便玩家与好友进行组队语音交流

8.7)娱乐频道组:

歌房:一起听歌的语音频道。

9、Discord中的机器人

除了聊天功能和社交架构之外,Discord 平台最引人注目的部分可能是其蓬勃发展的机器人生态系统。

在 2020 年的一篇博文中,Discord 宣布已经创建了超过 300 万个机器人,其中一些已经在数百万个服务器端上使用。

机器人举例:

  • 1)MEE6 是一个特别受欢迎的机器人应用,超过 1400 万服务器使用它来创建自定义欢迎消息、主动引导不良行为者、分配社区角色、并为积极参与社区活动的用户授予“XP”(“经验点”);
  • 2)ldleRPG 是一个提供更多创意服务的机器人应用,一旦它与服务器集成,社区成员就可以参与角色扮演游戏,这个游戏风格与《龙与地下城》相似,而且可以通过聊天命令参与。

从用户的角度来看,Discord 的机器人生态系统其实非常重要,因为可以扩展功能并增加游戏感。

而站在企业角度来看,机器人生态系统能从业务层面提供支撑,因为它允许开发人员在其应用程序接口(API)上进行构建。

10、Discord带来的启发

Discord背后的模式值得以社交的视角进行借鉴,辅助游戏端外社群运营。

1)首先:学会给用户创造一个新习惯,融入用户的生活场景,让用户对社区产生粘性。

Discord在提供给游戏玩家一个新的实时通话的社交平台的同时,其实是在给用户培养一个新的使用习惯,培养出来有社交互动需求的用户在玩游戏的时候,会的使用discord的习惯。

在培养用户的使用习惯以及粘性的这个过程中,需要团队专注于解决用户的核心需求,并且持续的提供技术支持。也就是要专注做好一个社交平台应该做的事情。

国内其实也有一个很好的例子。早年中国也有本土产出的用于服务游戏玩家“开黑”这定需求的社交软件,比方说,早年新浪上线的语音聊天产品UT,同期的在线群聊产品,以及后来的黑马YY语音。

2)其次:专注于解决用户的核心需求,找准定位,求同存异,保持用户的好感度。

从Discord的案例来说,它一开始的定位非常明确,就是小而精,针对于游戏群体的实时通话软件,然后在不断的完善功能的同时,扩大用户群体然后迅猛增长。

Discord专注于提升用户的体验并且保持用户社交的私密性,解决了解决用户的核心需求——网络实时社交。

11、相关资料

[1] 快速了解新一代跨平台桌面技术——Electron

[2] 盘点移动互联网时代的社交产品进化史(上篇):谁主沉浮

[3] 盘点移动互联网时代的社交产品进化史(下篇):大浪淘沙

[4] 中国互联网社交二十年:全民见证的互联网创业演义

[5] 别做梦了,社交产品哪有那么容易成功

[6] 同为IM社交产品中的王者,QQ与微信到底有什么区别

[7] 渐行渐远的人人网:十年亲历者的互联网社交产品复盘和反思

[8] 即时通讯创业必读:解密微信的产品定位、创新思维、设计法则等

[9] QQ的成功,远没有你想象的那么顺利和轻松

[10] 同为IM社交产品中的王者,QQ与微信到底有什么区别

[11] 还原真实的腾讯:从最不被看好,到即时通讯巨头的草根创业史

(本文已同步发布于:http://www.52im.net/thread-4300-1-1.html

posted @ 2023-07-07 12:13 Jack Jiang 阅读(109) | 评论 (0)编辑 收藏

本文由云信IM技术团队分享,原题“千万级在线直播弹幕方案”,本文有修订和改动。

1、引言

疫情期间,线上演唱会是一种很常见的直播娱乐形式,由于线下社交距离的限制,线上形式演唱会比以往更火爆,而对技术的要求也更高。

本文基于网易云信针对TFBOYS某场线上演唱会的技术支持,为你分享千万级在线用户量的直播系统中实时弹幕功能的技术实践,希望能带给你启发。

 

技术交流:

(本文已同步发布于:http://www.52im.net/thread-4299-1-1.html)

2、系列文章

本文是系列文章中的第 9 篇:

3、弹幕整体技术方案

本次的弹幕方案以IM聊天室技术为基础,提供了登录直播间、发送弹幕、礼物消息等能力。同时按照千万级在线广播的目标,为期设计了基于CDN的弹幕广播服务。

直播间收发实时消息(也就是弹幕、礼物)的主要流程如下:

  • 1)获取直播间接入地址;
  • 2)登录直播间;
  • 3)收发消息(弹幕、礼物)。

下面将围绕以上流程的三个阶段,在技术上分别阐述如何实现千万级在线直播实时弹幕的能力。

4、弹幕技术方案之获取直播间接入地址

为了提供稳定高可用的实时弹幕服务,需要通过GSLB(Global Server Load Balancing)服务给用户分配最佳的接入地址。

GSLB服务需要从以下几个维度综合考虑:

  • 1)用户网络类型;
  • 2)机房网络容量;
  • 3)服务器负载;
  • 4)成本。

1)用户网络类型和机房网络容量:

为了用户能够快速、稳定的登录直播间收发消息,一般要根据用户所在地理位置以及网络运营商类型综合考虑给用户分类接入服务器。

机房一般提供BGP网络、三线网络两种接入方案,分配服务根据用户IP地址分析用户的地域、运营商类型并分配最佳接入地址。

一般优先按运营商类型分配三线地址(例如电信用户分配电信接入地址),如果是小运营商或无法识别的IP地址则分配BGP地址,两种接入方式用户都可以获得稳定的网络环境。

2)服务器负载:

单台服务器能够承载的TCP长链接有限,尤其是在高并发进入直播间的情况下,握手协议需要完成链路加密工作,对系统的CPU资源消耗比较大,因此需要实现一套良好的均衡分配策略。

3)一套基于服务器负载均衡的分配策略:

长链接接入服务器周期性上报当前服务器负载到负载均衡服务集群,负载信息存储在共享缓存中,接入分配服务根据负载信息动态分配接入地址。

一般情况下用户请求直播间地址,地址分配服务会查询负载均衡服务(或者直接查询负载缓存),然后根据获取到的信息分配当前负载最低的服务器。

在千万级别的在线直播活动场景下,开播时大量用户并发进入直播间,分配服务可达50万到100万TPS,这么高的TPS下如果还用“一般分配”方案,负载均衡(缓存)服务的TPS和集群之间的机房网络带宽非常高,单台服务器亦可能因为负载信息滞后导致超负荷分配。

为解决机房内带宽和超负载分配的问题,我们对分配方案进行了优化:

  • 1)长链接服务器上报负载的周期从1秒调整到5毫秒,负载均衡服务器可以更实时的同步负载信息;
  • 2)“地址分配”服务不再按请求查询负载信息,而是开启单独的同步线程周期性(同样是5毫秒)同步负载数据,从而有效降低负责信息同步的TPS和网络开销;
  • 3)“地址分配”服务不在按最低负载分配,而是将服务接入地址按负载排序,单个接入地址分配一定次数后按顺序分配下一个接入地址(避免低负载服务器瞬间被打爆)。

在实际方案落地中,需要结合负载、用户网络类型、机房线路容量等因素综合分配。

5、弹幕技术方案之登录直播间

登录直播间主要有两项任务:

  • 1)握手;
  • 2)身份认证。

1)握手:

SDK建立TCP长链接后,首先向服务器发送握手协议,主要提供SDK版本、协议版本、支持的加密算法等信息,服务器根据SDK提供的信息选择合适的协议版本以及加密算法,建立安全的通信链路。

我们支持的非对称算法包括:RSA、SM2等算法。支持的对称加密算法包括:AES,SM4等(SM2、SM4为国密算法)。

非对称加密算法对CPU资源消耗非常高,为了提高性能一般可以考虑选择合适的密钥长度,另外针对Java平台建议考虑使用JNI技术提高非对称加密计算性能。

2)身份认证:

引言中提到的该次直播活动是在线付费直播,因此身份认证包含了账号认证和业务认证两部分,即用户必须使用正确的账号密码登录App,且必须付费购买直播门票才有权限观看直播。

为优化系统性能,实时弹幕服务将“地址分配和鉴权”服务进行了特殊优化:

鉴权中心提供用户进入直播间弹幕服务的身份鉴权策略配置。在该次直播活动中采用了动态Token的鉴权机制,即根据用户账号、登录时间、分配的接入地址以及鉴权中心按时间区间生成的“随机数以及对应的Token算法”动态计算鉴权Token。

用户打开直播App,首先完成账号鉴权。在进入直播间时通过业务中心完成直播付费身份认证和弹幕服务地址分配(同步获取到弹幕服务的动态鉴权token),最后根据接入地址登录弹幕服务,弹幕服务依据鉴权中心的策略校验Token正确性。

动态Token鉴权采用进程本地计算的方式。可以在不访问用户服务的情况下完成身份鉴权,在提高登录认证的性能同时有效的降低了业务成本。

6、弹幕技术方案之收发消息(弹幕、礼物)

实时收发消息是直播间的核心业务,主要分为弹幕和礼物两类:

  • 1)礼物因涉及付费等因素一般通过客户方业务服务器发送;
  • 2)弹幕消息则可以通过聊天室长链接发送。

在千万级直播间场景下,因消息量太高,因此需要从消息量、消息体大小、消息比例等多个方面优化,因此我们设计了一套基于优先级队列的弹幕服务。

首先:为了节约消息产生的带宽,在大型直播项目开始阶段,就需要对消息格式进行优化,充分精简消息体大小。例如将礼物消息展示相关的资源文件提前预加载到直播App中,礼物消息转化为业务编号,可极大的减少消息大小;

其次:针对上行消息设计流控机制。为了能全局控制上行消息体量,设计了逐级流控方案。上层级根据下层级能够支撑处理能力设计相对较粗粒度的本地流控机制。在弹幕反垃圾业务阶段,因需要全局控制消息量,因此采用分布式全局流控方案;弹幕广播阶段则根据业务广播需求再一次进行消息流控。

上行消息通过反垃圾监测后被投递到弹幕服务处理。基于优先级队列的弹幕服务首先按业务划分不同的消息队列,例如:系统广播、高优先级礼物、低优先级、弹幕,然后按队列分配消息比例,最后根据单位时间(1秒)内用户需要接收到的消息量计算各个队列应该投递的消息数量。在实际投递消息的过程中,若前一个队列消息量不足,可将剩余的消息数量叠加到下一个队列,以确保每一个周期都发送足够的消息给用户。

弹幕可通过长连接或CDN广播给其他用户。为了给用户提供极致的弹幕体验,充分发挥边缘加速的优势,在千万级在线直播场景下优先选择CDN方案(如下图所示)。

基于CDN广播弹幕有两种方案:

1)基于推流的方案:类似于直播视频推流技术,即将消息伪装成视频流的形式推送到CDN,直播App以订阅数据流的方式同步弹幕信息;

2)静态文件加速方案:即弹幕服务将不同队列中的消息组装成一个静态文件,直播App周期性的到CDN服务器下载弹幕静态文件。

相对来说:

  • 1)静态文件加速方案实现更简单但实时性不高(取决于弹幕同步的周期时长);
  • 2)推流的方案消息实时性更高,但实现相对复杂,且需要考虑到不同终端的兼容性。

实际项目中可根据场景和终端类型灵活选择不同的方案。

为了保障服务的可靠性,可考虑融合CDN的方案,即同时将消息推送到多家CDN厂商,并结合CDN厂商的容量比例以及网络延迟情况综合调度(例如基于权重的轮巡调度策略)。

7、弹幕稳定性设计之单元化部署

ChatLink和ChatServer采用单元化部署的方案,有以下优点:

  • 1)单元内依赖的核心服务单元之间相互独立,水平扩展能力好,且单元内服务故障不影响其他单元,可以有效避免整个服务不可用的问题;
  • 2)跨机房部署,避免单个机房容量不足,或单机房不可用问题;
  • 3)弹幕方案采用了单元无状态的设计理念,因此不需要考虑单元之间同步数据的问题。

单个直播间的“接入服务”和“弹幕服务”因需要全局控制未采用单元化部署方案,但是在实施阶段采用了跨机房部署的方案(包括依赖的存储资源、服务),可以避免单个机房故障导致服务不可用的问题。

8、弹幕稳定性设计之单点服务高可用

针对“接入服务”和“弹幕服务”,除了采用跨机房部署外,在服务设计上核心依赖的存储资源、服务,采用主备模式。

例如:心跳负载依赖的缓存服务,单个缓存实例本身高可用,但考虑到极端情况(例如缓存集群内超过一半的服务器宕机导致服务不可用),因此采用主备缓存集群方案,当主集群不可用后,业务主动切换到备用集群,可保障业务在5秒内恢复正常。

9、幕稳定性设计之系统监控与数据大盘

为了实时了解系统运行状态,在弹幕方案中实现了秒级数据大盘方案。

监控大盘围绕用户和消息主要展示以下信息:

  • 1)用户地域分布变化;
  • 2)上行消息量;
  • 3)广播消息量;
  • 4)机房出口带宽;
  • 5)CDN带宽;
  • 6)消息流控比例;
  • 7)端侧CDN弹幕同步指标(成功比例、延迟状况)。

为了达成秒级监控的目标,数据收集采用了“业务预聚合+数据中心合并”的实时计算方案。即业务服务直接在本地进程内聚合计算指标上报到数据中心,数据中心仅需要按时间窗口合并监控指标数据即可输出到监控大盘。

10、弹幕稳定性设计之故障与应急预案演练

为确保活动顺利完成,弹幕方案还进行了多次故障与应急预案演练措施。

具体包含两个方面。

1)预设故障演练:即针对高可用设计方案的故障演练,按预设有计划的制造故障,主要验证高可用方案是否生效。

2)随机故障演练:无计划的随机制造故障,主要用于检查应急预案、异常监控报警、数据大盘等应急监测机制是否生效。

11、相关资料

[1] 海量实时消息的视频直播系统架构演进之路(视频+PPT)

[2] 百万在线的美拍直播弹幕系统的实时推送技术实践之路

[3] 阿里电商IM消息平台,在群聊、直播场景下的技术实践

[4] 微信直播聊天室单房间1500万在线的消息架构演进之路

[5] 百度直播的海量用户实时消息系统架构演进实践

[6] 百万人在线的直播间实时聊天消息分发技术实践

[7] 直播间海量聊天消息的架构设计难点实践

[8] vivo直播系统中IM消息模块的架构实践

[9] 万人群聊消息投递方案的思考和实践

[10] IM中的万人群聊技术方案实践总结

(本文已同步发布于:http://www.52im.net/thread-4299-1-1.html

posted @ 2023-06-29 11:32 Jack Jiang 阅读(95) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第18 期。

[- 1 -] IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?

[链接http://www.52im.net/thread-1647-1-1.html

[摘要] MQ消息中间件可以理解一个水池,水池的这头是消息生产者,水池的那头是消息消费者,生产者和消息者无需直接对接,这将带来很多好处:业务解耦、架构分布式化等,生产者和消费者互相完全透明。但市面上的MQ消息中间件产品很多,作为IM系统中必不可少的一环,我们该如何选型?那么请继续阅读本文。


[- 2 -] 腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面

[链接http://www.52im.net/thread-1811-1-1.html

[摘要] 本文适合有过几年工作经验、正处于技术上升期的程序员阅读,内容少有浮夸,多为实践经验总结,希望能为您的技术成长加油助力。


[- 3 -] 以微博类应用场景为例,总结海量社交系统的架构设计步骤

[链接http://www.52im.net/thread-1910-1-1.html

[摘要] 本文让我们结合典型的互联网应用架构设计原则,通过一个模拟的微博应用场景,和你一起看看在微博这种海量社交应用实践中究竟如何分步进行架构设计的。


[- 4 -]快速理解高性能HTTP服务端的负载均衡技术原理

[链接http://www.52im.net/thread-1950-1-1.html

[摘要] 本文将以简洁通俗的文字,为你讲解主流的HTTP服务端实现负载均衡的常见方案,以及具体到方案中的负载均衡算法的实现原理。理解和掌握这些方案、算法原理,有助于您今后的互联网项的技术选型和架构设计,因为没有哪一种方案和算法能解决所有问题,只有针对特定的场景使用合适的方案和算法才是最明智的选择。


[- 5 -] 子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践

[链接http://www.52im.net/thread-1961-1-1.html

[摘要] 本文内容来自对网易云信首席架构师周梁伟的采访,采访内容主要围绕网易云信这种海量用户IM云平台的关键技术难点以及对应的技术实践。


[- 6 -] 知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路

[链接http://www.52im.net/thread-1968-1-1.html

[摘要] 知乎存储平台团队基于开源Redis 组件打造的知乎 Redis 平台,经过不断的研发迭代,目前已经形成了一整套完整自动化运维服务体系,提供很多强大的功能。本文作者陈鹏是该系统的负责人,本次文章深入介绍了该系统的方方面面,值得互联网后端程序员仔细研究。


[- 7 -] IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列

[链接http://www.52im.net/thread-1979-1-1.html

[摘要] 对于即时通讯开发者来说,正确地理解MQ消息队列,对于IM或消息推送系统的架构设计、方案选型等都大有裨益。


[- -]  新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践

[链接http://www.52im.net/thread-2007-1-1.html

[摘要] 即时通讯网作为IM和推送技术研究、学习和分享的社区,整理了大量的跟IM和推广技术有关的基础技术资料(比如网络基础、通信理论、架构基础等),本文内容虽然看起来跟IM和推送技术没有直接的关联性,但因为设计IM和推送系统的技术思路和原理跟典型大型互联网分布式架构都是一脉相承的,因而读懂本文内容对于IM和推送系统的架构设计同样大有裨益。


[- 9 -] 阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史

[链接http://www.52im.net/thread-2050-1-1.html

[摘要] 今天,阿里数据库事业部研究员张瑞,将为你讲述双11数据库技术不为人知的故事。在零点交易数字一次次提升的背后,既是数据库技术的一次次突破,也见证了阿里技术人永不言败的精神,每一次化“不可能”为“可能”的过程都是阿里技术人对技术的不懈追求。


[- 10 -] 阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路

[链接http://www.52im.net/thread-2072-1-1.html

[摘要] OceanBase 是蚂蚁金服自研的分布式数据库,在其 9 年的发展历程里,从艰难上线到找不到业务场景濒临解散,最后在双十一的流量考验下浴火重生,成为蚂蚁金服全部核心系统的承载数据库。这一路走来的艰辛和故事,蚂蚁金服高级研究员、OceanBase 团队负责人阳振坤将为你娓娓道来。


[- 11 -] 即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载均衡?

[链接http://www.52im.net/thread-2600-1-1.html

[摘要] Nginx(及其衍生产品)是目前被大量使用的服务端反向代理和负载均衡方案,从某种意义上来讲,Nginx几乎是低成本、高负载Web服务端代名词。


[- 12 -] 即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途

[链接http://www.52im.net/thread-2620-1-1.html

[摘要] 本文将带你从基本概念、原理和用途方面,快速理解快速理解RPC技术,以便您在进行IM集群开发时能更好的进行方案设计和实现。


[- 13 -]  多维度对比5款主流分布式MQ消息队列,妈妈再也不担心我的技术选型了

[链接http://www.52im.net/thread-2625-1-1.html

[摘要] 本文将从17个维度综合对比Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ这5款当前最主流的MQ消息中间件产品,希望能为您的下一次产品的架构设计和MQ消息中间件选型提供参考依据。


[- 14 -] IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!

[链接http://www.52im.net/thread-2759-1-1.html

[摘要] 本文将分析传统数据库(即SQL数据库)存在的一些问题,以及盘点目前市面上几大类 NoSQL 特性、优缺点等,希望给大家提供一些在不同业务场景下存储技术选型方面的参考。


[- 15 -] IM开发基础知识补课(九):想开发IM集群?先搞懂什么是RPC!

[链接http://www.52im.net/thread-2996-1-1.html

[摘要] 本文将以通俗易懂的白话形式,帮你快速理解IM集群中的关键技术——RPC。


[- 16 -] IM开发基础知识补课(十):大型IM系统有多难?万字长文,搞懂异地多活!

[链接http://www.52im.net/thread-3742-1-1.html

[摘要] 本文从一个简单的系统例子开始,从单机架构、主从副本、同城灾备、同城双活,再到异地双活、异地多活,由浅入深、循序渐进地讲解了大型分布式系统异地多活容灾架构的技术原理和基本的实现思路,非常适合入门者学习。


👉52im社区本周新文:《直播系统聊天技术(九):千万级实时直播弹幕的技术实践 http://www.52im.net/thread-4299-1-1.html》,欢迎阅读!👈


我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-06-28 12:23 Jack Jiang 阅读(92) | 评论 (0)编辑 收藏

本文由得物技术团队Uni分享,本文有内容修订和大量排版优化。

1、引言

关于Java网络编程中的同步IO和异步IO的区别及原理的文章非常的多,具体来说主要还是在讨论Java BIO和Java NIO这两者,而关于Java AIO的文章就少之又少了(即使用也只是介绍了一下概念和代码示例)。

在深入了解AIO之前,我注意到以下几个现象:

  • 1)2011年Java 7发布,它增加了AIO(号称异步IO网络编程模型),但12年过去了,平时使用的开发框架和中间件却还是以NIO为主(例如网络框架Netty、Mina,Web容器Tomcat、Undertow),这是为什么?
  • 2)Java AIO又称为NIO 2.0,难道它也是基于NIO来实现的?
  • 3)Netty为什么会舍去了AIO的支持?(点此查看);
  • 4)AIO看起来貌似只是解决了有无,实际是发布了个寂寞?

Java AIO的这些不合常理的现象难免会令人心存疑惑。所以决定写这篇文章时,我不想只是简单的把AIO的概念再复述一遍,而是要透过现象,深入分析、思考和并理解Java AIO的本质。

 

技术交流:

(本文已同步发布于:http://www.52im.net/thread-4283-1-1.html

2、我们所理解的异步

AIO的A是Asynchronous(即异步)的意思,在了解AIO的原理之前,我们先理清一下“异步”到底是怎样的一个概念。

说起异步编程,在平时的开发还是比较常见的。

例如以下的代码示例:

@Async

publicvoidcreate() {

    //TODO

}

 

publicvoidbuild() {

    executor.execute(() -> build());

}

不管是用@Async注解,还是往线程池里提交任务,他们最终都是同一个结果,就是把要执行的任务,交给另外一个线程来执行。

这个时候,我们可以大致的认为,所谓的“异步”,就是用多线程的方式去并行执行任务。

3、Java BIO和NIO到底是同步还是异步?

Java BIO和NIO到底是同步还是异步,我们先按照异步这个思路,做异步编程。

3.1BIO代码示例

byte[] data = newbyte[1024];

InputStream in = socket.getInputStream();

in.read(data);

// 接收到数据,异步处理

executor.execute(() -> handle(data));

 

publicvoidhandle(byte[] data) {

    // TODO

}

如上:BIO在read()时,虽然线程阻塞了,但在收到数据时,可以异步启动一个线程去处理。

3.2NIO代码示例

selector.select();

Set<SelectionKey> keys = selector.selectedKeys();

Iterator<SelectionKey> iterator = keys.iterator();

while(iterator.hasNext()) {

    SelectionKey key = iterator.next();

    if(key.isReadable()) {

        SocketChannel channel = (SocketChannel) key.channel();

        ByteBuffer byteBuffer = (ByteBuffer) key.attachment();

        executor.execute(() -> {

            try{

                channel.read(byteBuffer);

                handle(byteBuffer);

            } catch(Exception e) {

 

            }

        });

    }

}

 

publicstaticvoidhandle(ByteBuffer buffer) {

    // TODO

}

同理:NIO虽然read()是非阻塞的,通过select()可以阻塞等待数据,在有数据可读的时候,异步启动一个线程,去读取数据和处理数据。

3.3产生的理解偏差

此时我们信誓旦旦地说,Java的BIO和NIO是异步还是同步,取决你的心情,你高兴给它个多线程,它就是异步的。

果真如此么?

在翻阅了大量博客文章之后,基本一致的阐明了——BIO和NIO是同步的。

那问题点出在哪呢,是什么造成了我们理解上的偏差呢?

那就是参考系的问题,以前学物理时,公交车上的乘客是运动还是静止,需要有参考系前提,如果以地面为参考,他是运动的,以公交车为参考,他是静止的。

Java IO也是一样,需要有个参考系,才能定义它是同步还是异步。

既然我们讨论的是关于Java IO是哪一种模式,那就是要针对IO读写操作这件事来理解,而其他的启动另外一个线程去处理数据,已经是脱离IO读写的范围了,不应该把他们扯进来。

3.4尝试定义异步

所以以IO读写操作这事件作为参照,我们先尝试的这样定义,就是:发起IO读写的线程(调用read和write的线程),和实际操作IO读写的线程,如果是同一个线程,就称之为同步,否则是异步。

按上述定义:

  • 1)显然BIO只能是同步,调用in.read()当前线程阻塞,有数据返回的时候,接收到数据的还是原来的线程;
  • 2)而NIO也称之为同步,原因也是如此,调用channel.read()时,线程虽然不会阻塞,但读到数据的还是当前线程。

按照这个思路,AIO应该是发起IO读写的线程,和实际收到数据的线程,可能不是同一个线程。

是不是这样呢?我们将在上一节直接上Java AIO的代码,我们从 实际代码中一窥究竟吧。

4、一个Java AIO的网络编程示例

4.1AIO服务端程序代码

publicclassAioServer {

 

    publicstaticvoidmain(String[] args) throwsIOException {

        System.out.println(Thread.currentThread().getName() + " AioServer start");

        AsynchronousServerSocketChannel serverChannel = AsynchronousServerSocketChannel.open()

                .bind(newInetSocketAddress("127.0.0.1", 8080));

        serverChannel.accept(null, newCompletionHandler<AsynchronousSocketChannel, Void>() {

 

            @Override

            publicvoidcompleted(AsynchronousSocketChannel clientChannel, Void attachment) {

                System.out.println(Thread.currentThread().getName() + " client is connected");

                ByteBuffer buffer = ByteBuffer.allocate(1024);

                clientChannel.read(buffer, buffer, newClientHandler());

            }

 

            @Override

            publicvoidfailed(Throwable exc, Void attachment) {

                System.out.println("accept fail");

            }

        });

        System.in.read();

    }

}

 

publicclassClientHandler implementsCompletionHandler<Integer, ByteBuffer> {

    @Override

    publicvoidcompleted(Integer result, ByteBuffer buffer) {

        buffer.flip();

        byte[] data = newbyte[buffer.remaining()];

        buffer.get(data);

        System.out.println(Thread.currentThread().getName() + " received:"+ newString(data, StandardCharsets.UTF_8));

    }

 

    @Override

    publicvoidfailed(Throwable exc, ByteBuffer buffer) {

 

    }

}

4.2AIO客户端程序

publicclassAioClient {

    publicstaticvoidmain(String[] args) throwsException {

        AsynchronousSocketChannel channel = AsynchronousSocketChannel.open();

        channel.connect(newInetSocketAddress("127.0.0.1", 8080));

        ByteBuffer buffer = ByteBuffer.allocate(1024);

        buffer.put("Java AIO".getBytes(StandardCharsets.UTF_8));

        buffer.flip();

        Thread.sleep(1000L);

        channel.write(buffer);

 }

}

4.3异步的定义猜想结论

分别运行服务端和客户端程序:

在服务端运行结果里:

1)main线程发起serverChannel.accept的调用,添加了一个CompletionHandler监听回调,当有客户端连接过来时,Thread-5线程执行了accep的completed回调方法。

2)紧接着Thread-5又发起了clientChannel.read调用,也添加了个CompletionHandler监听回调,当收到数据时,是Thread-1的执行了read的completed回调方法。

这个结论和上面异步猜想一致:发起IO操作(例如accept、read、write)调用的线程,和最终完成这个操作的线程不是同一个,我们把这种IO模式称之AIO。

当然了,这样定义AIO只是为了方便我们理解,实际中对异步IO的定义可能更抽象一点。

5、 AIO示例引发思考1:“执行completed()方法的线程是谁创建、什么时候创建?”

一般,这样的问题,需要从程序的入口的开始了解,但跟线程相关,其实是可以从线程栈的运行情况来定位线程是怎么运行。

只运行AIO服务端程序,客户端不运行,打印一下线程栈(备注:程序在Linux平台上运行,其他平台略有差异)。如下图所示。

分析线程栈,发现,程序启动了那么几个线程:

  • 1)线程Thread-0阻塞在EPoll.wait()方法上;
  • 2)线程Thread-1、Thread-2~Thread-n(n和CPU核心数量一致)从阻塞队列里take()任务,阻塞等待有任务返回。

此时可以暂定下一个结论:AIO服务端程序启动之后,就开始创建了这些线程,且线程都处于阻塞等待状态。

另外:发现这些线程的运行都跟epoll有关系!

提到epoll,我们印象中,Java NIO在Linux平台底层就是用epoll来实现的,难道Java AIO也是用epoll来实现么?

为了证实这个结论,我们从下一个问题来展开讨论。

6、 AIO示例引发思考2:AIO注册事件监听和执行回调是如何实现的?

带着这个问题,去阅读JDK分析源码时,发现源码特别的长,而源码解析是一项枯燥乏味的过程,很容易把阅读者给逼走劝退掉。

对于长流程和逻辑复杂的代码的理解,我们可以抓住它几个脉络,找出哪几个核心流程。

以注册监听read为例clientChannel.read(...),它主要的核心流程是:注册事件 -> 监听事件 -> 处理事件。

注册事件:

注:注册事件调用EPoll.ctl(...)函数,这个函数在最后的参数用于指定是一次性的,还是永久性。上面代码events | EPOLLONSHOT字面意思看来,是一次性的。

监听事件:

处理事件:

 

核心流程总结:

在分析完上面的代码流程后会发现:每一次IO读写都要经历的这三个事件是一次性的,也就是在处理事件完,本次流程就结束了,如果想继续下一次的IO读写,就得从头开始再来一遍。这样就会存在所谓的死亡回调(回调方法里再添加下一个回调方法),这对于编程的复杂度大大提高了。

7、 AIO示例引发思考3:监听回调的本质是什么?

7.1概述

先说一下结论:所谓监听回调的本质,就是用户态线程调用内核态的函数(准确的说是API,例如read、write、epollWait),该函数还没有返回时,用户线程被阻塞了。当函数返回时,会唤醒阻塞的线程,执行所谓回调函数。

对于这个结论的理解,要先引入几个概念。

7.2系统调用与函数调用

函数调用:找到某个函数,并执行函数里的相关命令。

系统调用:操作系统对用户应用程序提供了编程接口,所谓API。

系统调用执行过程:

  • 1)传递系统调用参数;
  • 2)执行陷入指令,用用户态切换到核心态(这是因为系统调用一般都需要再核心态下执行);
  • 3)执行系统调用程序;
  • 4)返回用户态。

7.3用户态和内核态之间的通信

用户态->内核态:通过系统调用方式即可。

内核态->用户态:内核态根本不知道用户态程序有什么函数,参数是啥,地址在哪里。所以内核是不可能去调用用户态的函数,只能通过发送信号,比如kill 命令关闭程序就是通过发信号让用户程序优雅退出的。

既然内核态是不可能主动去调用用户态的函数,为什么还会有回调呢,只能说这个所谓回调其实就是用户态的自导自演。它既做了监听,又做了执行回调函数。

7.4用实际例子验证结论

为了验证这个结论是否有说服力,举个例子:平时开发写代码用的IntelliJ IDEA,它是如何监听鼠标、键盘事件和处理事件的。

按照惯例,先打印一下线程栈,会发现鼠标、键盘等事件的监听是由“AWT-XAWT”线程负责的,处理事件则是“AWT-EventQueue”线程负责。如下图所示。

定位到具体的代码上:可以看到“AWT-XAWT”正在做while循环,调用waitForEvents函数等待事件返回。如果没有事件,线程就一直阻塞在那边。如下图所示。

8、Java AIO的本质是什么?

8.1Java AIO的本质,就是只在用户态实现了异步

由于内核态无法直接调用用户态函数,Java AIO的本质,就是只在用户态实现异步,并没有达到理想意义上的异步。

1)理想中的异步:

何谓理想意义上的异步?这里举个网购的例子。

两个角色,消费者A、快递员B:

  • 1)A在网上购物时,填好家庭地址付款提交订单,这个相当于注册监听事件;
  • 2)商家发货,B把东西送到A家门口,这个相当于回调。

A在网上下完单,后续的发货流程就不用他来操心了,可以继续做其他事。B送货也不关心A在不在家,反正就把货扔到家门口就行了,两个人互不依赖,互不相干扰。

假设A购物是用户态来做,B送快递是内核态来做,这种程序运行方式过于理想了,实际中实现不了。

2)现实中的异步:

A住的是高档小区,不能随意进去,快递只能送到小区门口。

A买了一件比较重的商品,比如一台电视,因为A要上班不在家里,所以找了一个好友C帮忙把电视搬到他家。

A出门上班前,跟门口的保安D打声招呼,说今天有一台电视送过来,送到小区门口时,请电话联系C,让他过来拿。

具体就是:

  • 1)此时,A下单并跟D打招呼,相当于注册事件。在AIO中就是EPoll.ctl(...)注册事件;
  • 2)保安在门口蹲着相当于监听事件,在AIO中就是Thread-0线程,做EPoll.wait(..);
  • 3)快递员把电视送到门口,相当于有IO事件到达;
  • 4)保安通知C电视到了,C过来搬电视,相当于处理事件(在AIO中就是Thread-0往任务队列提交任务,Thread-1 ~n去取数据,并执行回调方法)。

整个过程中,保安D必须一直蹲着,寸步不能离开,否则电视送到门口,就被人偷了。

好友C也必须在A家待着,受人委托,东西到了,人却不在现场,这有点失信于人。

所以实际的异步和理想中的异步,在互不依赖,互不干扰,这两点相违背了。保安的作用最大,这是他人生的高光时刻。

异步过程中的注册事件、监听事件、处理事件,还有开启多线程,这些过程的发起者全是用户态一手操办。所以说Java AIO本质只是在用户态实现了异步,这个和BIO、NIO先阻塞,阻塞唤醒后开启异步线程处理的本质一致。

8.2Java AIO的其它真相

Java AIO跟NIO一样:在各个平台的底层实现方式也不同,在Linux是用epoll、Windows是IOCP、Mac OS是KQueue。原理是大同小异,都是需要一个用户线程阻塞等待IO事件,一个线程池从队列里处理事件。

Netty之所以移除掉AIO:很大的原因是在性能上AIO并没有比NIO高。Linux虽然也有一套原生的AIO实现(类似Windows上的IOCP),但Java AIO在Linux并没有采用,而是用epoll来实现。

Java AIO不支持UDP。

AIO编程方式略显复杂,比如“死亡回调”。

9、参考资料

[1] 少啰嗦!一分钟带你读懂Java的NIO和经典IO的区别

[2] 史上最强Java NIO入门:担心从入门到放弃的,请读这篇!

[3] Java的BIO和NIO很难懂?用代码实践给你看,再不懂我转行!

[4] Java新一代网络编程模型AIO原理及Linux系统AIO介绍

[5] 从0到1的快速裂变:详解快的打车架构设计及技术实践

[6] 新手入门:目前为止最透彻的的Netty高性能原理和框架架构解析

[7] 史上最通俗Netty框架入门长文:基本介绍、环境搭建、动手实战

[8] 高性能网络编程(五):一文读懂高性能网络编程中的I/O模型

[9] 高性能网络编程(六):一文读懂高性能网络编程中的线程模型

[10] 高性能网络编程(七):到底什么是高并发?一文即懂!

[11] 从根上理解高性能、高并发(二):深入操作系统,理解I/O与零拷贝技术

[12] 从根上理解高性能、高并发(三):深入操作系统,彻底理解I/O多路复用

[13] 从根上理解高性能、高并发(四):深入操作系统,彻底理解同步与异步

[14] 从根上理解高性能、高并发(五):深入操作系统,理解高并发中的协程

(本文已同步发布于:http://www.52im.net/thread-4283-1-1.html

posted @ 2023-06-21 11:19 Jack Jiang 阅读(266) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第17 期。

[- 1 -] 社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等

[链接] http://www.52im.net/thread-2202-1-1.html

[摘要] 本文将从架构开始,到手机 QQ 移动端优化,再到个性化红包和 AR 新玩法,为大家全面解密 QQ 红包技术方案。


[- 2 -] 社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进

[链接http://www.52im.net/thread-2519-1-1.html

[摘要今天下午跟大家分享的主题是:微信团队是如何从0到1实现“有把握”的微信春晚摇一摇红包系统的。


[- 3 -] 社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节

[链接http://www.52im.net/thread-2533-1-1.html

[摘要本文将由微信团队工程师张文瑞分享微信春节摇一摇红包技术背后的方方面面,希望能给同行们带来启发。


[- 4 -]社交软件红包技术解密(四):微信红包系统是如何应对高并发的

[链接] http://www.52im.net/thread-2548-1-1.html

[摘要本文将为读者介绍微信百亿级别红包背后的高并发设计实践,内容包括微信红包系统的技术难点、解决高并发问题通常使用的方案,以及微信红包系统的所采用高并发解决方案。


[- 5 -] 社交软件红包技术解密(五):微信红包系统是如何实现高可用性的

[链接http://www.52im.net/thread-2564-1-1.html

[摘要本次分享介绍了微信红包后台系统的高可用实践经验,主要包括后台的 set 化设计、异步化设计、订单异地存储设计、存储层容灾设计与平行扩缩容等。听众可以了解到微信红包后台架构的设计细节,共同探讨高可用设计实践上遇到的问题与解决方案。


[- 6 -] 社交软件红包技术解密(六):微信红包系统的存储层架构演进实践

[链接http://www.52im.net/thread-2568-1-1.html

[摘要] 微信红包本质是小额资金在用户帐户流转,有发、抢、拆三大步骤。在这个过程中对事务有高要求,所以订单最终要基于传统的RDBMS,这方面是它的强项,最终订单的存储使用互联网行业最通用的MySQL数据库。支持事务、成熟稳定,我们的团队在MySQL上有长期技术积累。但是传统数据库的扩展性有局限,需要通过架构解决。


[- 7 -] 社交软件红包技术解密(七):支付宝红包的海量高并发技术实践

[链接http://www.52im.net/thread-2573-1-1.html

[摘要本文将为读者剖析支付宝红包系统背后的技术细节。


[- 8 -]  社交软件红包技术解密(八):全面解密微博红包技术方案

[链接http://www.52im.net/thread-2576-1-1.html

[摘要在服务器数量一定的情况下,如何构建高并发操作、瞬间峰值高的稳定服务?对于团队和架构师都是一个极大的挑战。这时候系统的架构尤为重要!本文将为你分享这些内容。


[- 9 -] 社交软件红包技术解密(九):谈谈手Q红包的功能逻辑、容灾、运维、架构等

[链接http://www.52im.net/thread-2583-1-1.html

[摘要本文将会详细介绍手Q春节红包项目的功能设计/逻辑、容灾、运维、架构以及实践总结。


[- 10 -] 社交软件红包技术解密(十):手Q客户端针对2020年春节红包的技术实践

[链接] http://www.52im.net/thread-2966-1-1.html

[摘要对于这种大体量的IM社交应用运营活动,技术上除了前端、后台的大力支撑,对于手Q客户端来说,又是从哪些方面来保证整个红包活动的灵活性、稳定性和用户体验的呢?带着这个问题,我们一起来阅读余下的文字。


[- 11 -] 社交软件红包技术解密(十一):解密微信红包随机算法(含代码实现)

[链接] http://www.52im.net/thread-3125-1-1.html

[摘要本文根据有限的资料,分享了微信红包随机算法实现中的一些技术要点,并整理了两种比较靠谱的红包算法实现思路(含可运行的实现代码),希望能给你的红包算法开发带来启发。


[- 12 -] 社交软件红包技术解密(十二):解密抖音春节红包背后的技术设计与实践

[链接http://www.52im.net/thread-3945-1-1.html

[摘要本文将要分享的是春节期间海量红包社交活动为抖音所带来的各种技术挑战,以及抖音技术团队是如何在实践中一一解决这些问题的。


👉52im社区本周新文:《到底什么是Java AIO?为什么Netty会移除AOI?一文搞懂AIO的本质!http://www.52im.net/thread-4283-1-1.html》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-06-19 13:40 Jack Jiang 阅读(93) | 评论 (0)编辑 收藏

► 相关链接:

一、技术准备

您是否已对Web端即时通讯技术有所了解?

您需要对WebSocket技术有所了解:

WebSocket标准文档、API手册:

二、开发工具准备

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-Uniapp端核心算法层的log输入,方便开发者调试。
  • 参数enable :{boolean} true表示开启log输出,否则不输出,开发者不调用本函数的话系统默认是false(即不输出log)。

7)IMSDK.setDebugSDKEnable(enable):

  • 用途:是否开启MobileIMSDK-Uniapp端框架层的log输入,方便开发者调试。
  • 参数enable :{boolean} true表示开启log输出,否则不输出,开发者不调用本函数的话系统默认是false(即不输出log)。

8)IMSDK.setDebugPingPongEnable(enable):

  • 用途:是否开启MobileIMSDK-Uniapp端框架层的底层网络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-Uniapp端核心逻辑,开发者可以不需要实现!)。
  • 推荐用法 :开发者可在此回调中处理底层网络的活动情况。

17)IMSDK.callback_onIMPong():

  • 用途:由开发者设置的回调方法:收到服务端的心跳包反馈的回调通知(本回调并非MobileIMSDK-Uniapp端核心逻辑,开发者可以不需要实现!)。
  • 推荐用法 :开发者可在此回调中处理底层网络的活动情况。

18)IMSDK.callback_onIMShowAlert(alertContent):

  • 用途:由开发者设置的回调方法:框架层的一些提示信息显示回调(本回调并非MobileIMSDK-Uniapp端核心逻辑,开发者可以不需要实现!)。
  • 说明 :开发者不设置的情况下,框架默认将调用wx.showModal()显示提示信息,否则将使用开发者设置的回调——目的主要是给开发者自定义这种信息的UI显示,提升UI体验,别无它用】。
  • 参数1:{String}:必填项,文本类型,表示提示内容。

19)IMSDK.callback_onIMKickout(kickoutInfo):

  • 用途:由开发者设置的回调方法:收到服务端的“踢出”指令(本回调并非MobileIMSDK-Uniapp端核心逻辑,开发者可以不需要实现!)。
  • 参数1 :{PKickoutInfo}:非空,详见:PKickoutInfo

20)IMSDK.callback_onMessagesLost(lostMessages):

  • 用途:由开发者设置的回调方法:消息未送达的回调事件通知。
  • 发生场景 :比如用户刚发完消息但网络已经断掉了的情况下,表现形式如:就像手机qq或微信一样消息气泡边上会出现红色图标以示没有发送成功)。
  • 建议用途:应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送失败”以便即时告之用户。
  • 参数1:{Array<rotocal>}:由框架的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从入门到精通,半小时就够!

posted @ 2023-06-15 11:55 Jack Jiang 阅读(113) | 评论 (0)编辑 收藏

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统,是RainbowChat的姊妹系统(RainbowChat是一套基于开源IM聊天框架 MobileIMSDK(Github地址) 的产品级移动端IM系统)。

二、v5.0 版更新内容

此版更新内容更多历史更新日志):

  • 1)[bug][前端]     - 解决了当首页“消息”无item时,从好友列表中删除某人时不自动清空聊天面板和右侧详情面板的问题;
  • 2)[bug][前端]     - 解决了处于群列表Tab时,退群或解散群不会更新群列表中“当前群聊”数字的问题 ;
  • 3)[bug][前端]     - 解决了处于群列表Tab时,点击创建群聊后,不会在群聊列表中自动选中此创建的群的问题;
  • 4)[优化]             - 升级核心通信层框架MobileIMSDK-Web至最新v5.1版;
  • 5)[优化][前端]    - 优化了当发送名片消息时,如名片者未设置头像,则在聊天消息界面中显示默认头像(提升体验);
  • 6)[优化][服务端] - 进一步加固了uid登陆时的sql注入风险;
  • 7)[优化][服务端] - 解决与最新rabbitmq-client库不兼容从而断线重连不成功,导致MQ中消息堆积的问题:
  • 8)[优化][服务端] - 解决MQ断线自动恢复时消费者Chennal未主动清理,导致空channel越来越多的问题;
  • 9)[优化][前端]    - 解决了被踢出群的情况下,仍能退群、邀请别人入群等问题;
  • 10)[优化][前端]  - 解决了高版本Tomcat下文件名中包含了特殊符号的大文件无法下载的问题。
  • 11)[新增][前端]  - 聊天区上方实现了聊天对象信息的显示(可显示昵称、群名称等信息);
  • 12)[新增][前端]  - 新增了消息送达状态图标的显示(包括发送中、发送成功、发送失败3种状态)。

三、v5.0 版新增特性截图

聊天区上方聊天对象信息的演示运行截图更多运行截图):

消息送达状态的演示运行截图更多运行截图):

四、主要界面截图概览

 ▲ 主界面(更多截图更多演示视频

▲ 主界面(聊天窗全屏时)(更多截图更多演示视频

▲ 主界面(聊天窗关闭时)(更多截图更多演示视频 

posted @ 2023-06-12 12:27 Jack Jiang 阅读(96) | 评论 (0)编辑 收藏

     摘要: 本文由will分享,个人博客zhangyaoo.github.io,原题“基于Netty的IM系统设计与实现”,有修订和重新排版。1、引言本文将要分享的是如何从零实现一套基于Netty框架的分布式高可用IM系统,它将支持长连接网关管理、单聊、群聊、聊天记录查询、离线消息存储、消息推送、心跳、分布式唯一ID、红包、消息同步等功能,并且还支持集群部署。本文中针对这套架构和系统设...  阅读全文

posted @ 2023-06-08 14:57 Jack Jiang 阅读(140) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第16 期。

[- 1 -] 浅谈IM系统的架构设计

[链接] http://www.52im.net/thread-307-1-1.html

[摘要] 下面把我近年来从技术上我对IM系统(即时消息的传输,不包括语音,视频,文件的传输)的理解和设计分享出来,浅薄之见,望大家别见笑,欢迎给出批评意见。


[- 2 -] 简述移动端IM开发的那些坑:架构设计、通信协议和客户端

[链接] http://www.52im.net/thread-289-1-1.html

[摘要] 有过移动端开发经历的开发者都深有体会:移动端IM的开发,与传统PC端IM有很大的不同,尤其无线网络的不可靠性、移动端硬件设备资源的有限性等问题,导致一个完整的移动端IM架构设计和实现都充满着大量的挑战。本文将简述移动端IM最重要的架构设计和通信协议选择方面的坑点,希望为IM开发者同行带来些许启发。


[- 3 -] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文

[链接] http://www.52im.net/thread-812-1-1.html

[摘要] 本文分享了一套完整的海量在线用户的移动端IM架构设计,来自于作者的真实项目实践总结,包含了详细的算法原理图、数据结构定义、表结构定义等等。


[- 4 -] 一套原创分布式即时通讯(IM)系统理论架构方案

[链接] http://www.52im.net/thread-151-1-1.html

[摘要] 无论是IM消息通信系统还是客户消息系统,其本质都是一套消息发送与投递系统,或者说是一套网络通信系统,其本质两个词:存储与转发。推荐:如有兴趣,本文作者的另一篇《一套高可用、易伸缩、高并发的IM群聊架构方案设计实践》,适合进行IM群聊架构设计的参考。


[- 5 -] 从零到卓越:京东客服即时通讯系统的技术架构演进历程

[链接] http://www.52im.net/thread-152-1-1.html

[摘要] 京东的客服即时通讯系统名为咚咚是。咚咚之于京东相当于旺旺之于淘宝,它们都是服务于买家和卖家的沟通。自从京东开始为第三方卖家提供入驻平台服务后,咚咚也就随之诞生了。


[- 6-] 蘑菇街即时通讯/IM服务器开发之架构选择

[链接] http://www.52im.net/thread-31-1-1.html

[摘要] 由于IM服务器里面的内容比较多,这个可以是一个系列的内容,所以这里只介绍服务器的架构以及为什么选择这样的架构。


[- 7 -] 腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT

[链接] http://www.52im.net/thread-158-1-1.html

[摘要] 众所周知海量互联网服务能力是世界公认的技术难题。经过十多年的发展,腾讯在海量互联网服务方面已有不少技术积累。PPT中以QQ IM后台服务为例,重现了QQ在线用户从百万级到亿级的整个过程中遇到的技术挑战,并与与会者分享了众多在海量互联网后台服务研发运营方面不为人知的秘密。


[- 8-]  微信后台基于时间序的海量数据冷热分级架构设计实践

[链接] http://www.52im.net/thread-895-1-1.html

[摘要] 时隔3年,微信团队再次分享了本文所述架构的最新升级版本及其改造过程,有兴趣可以前往阅读《微信后台基于时间序的新一代海量数据存储架构的设计实践》。


[- 9 -] 微信技术总监谈架构:微信之道——大道至简(演讲全文)

[链接] http://www.52im.net/thread-200-1-1.html

[摘要] 微信——腾讯战略级产品,创造移动互联网增速记录,10个月5000万手机用户,433天之内完成用户数从零到一亿的增长过程,千万级用户同时在线,摇一摇每天次数过亿...在技术架构上,微信是如何做到的?日前,在腾讯大讲堂在中山大学校园宣讲活动上,腾讯广研助理总经理、微信技术总监周颢在两小时的演讲中揭开了微信背后的秘密。


[- 10-] 如何解读《微信技术总监谈架构:微信之道——大道至简》

[链接] http://www.52im.net/thread-201-1-1.html

[摘要] 最近在朋友圈看到有人分享腾讯微信技术总监周颢的一个技术报告,题目是《微信技术总监谈架构:微信之道——大道至简》(演讲全文整理、演讲PPT讲稿下载),我也转发了一下。然后就被本司妹子看到了,非让我解释一下。


[- 11-] 快速裂变:见证微信强大后台架构从0到1的演进历程(一)

[链接] http://www.52im.net/thread-168-1-1.html

[摘要] 2个月的开发时间,微信后台系统经历了从0到1的过程。从小步慢跑到快速成长,经历了平台化到走出国门,微信交出的这份优异答卷,解题思路是怎样的?


[- 12-] 17年的实践:腾讯海量产品的技术方法论

[链接] http://www.52im.net/thread-159-1-1.html

[摘要] 在首届腾讯云技术峰会上,腾讯公司副总裁姚星完整的介绍了腾讯整体技术发展脉络。


[- 13-] 移动端IM中大规模群消息的推送如何保证效率、实时性?

[链接] http://www.52im.net/thread-1221-1-1.html

[摘要] 当然,实际在生产环境下,群消息的发送都会想尽办法进行压缩,并开展各种改善性能的处理办法,而不是像上述举例里的直接扩散写(即2000人群里,一条消息被简单地复制为2000条一对一的消息投递)。具体有哪些优先策略?本文或许可以带给你一些启发。


[- 14-] 现代IM系统中聊天消息的同步和存储方案探讨

[链接] http://www.52im.net/thread-1230-1-1.html

[摘要] 本文内容主要涉及IM系统中的消息系统架构,探讨一种适用于大用户量的消息同步以及存储系统的架构实现,能够支持消息系统中的高级特性『多端同步』以及『消息漫游』。在性能和规模上,能够做到全量消息云端存储,百万TPS以及毫秒级延迟的消息同步能力。


[- 15-]WhatsApp技术实践分享:32人工程团队创造的技术神话

[链接] http://www.52im.net/thread-1542-1-1.html

[摘要] 我们再次回顾了当时HighScalability创始人Tod Hoff撰文分析的收购原因和WhatsApp的高可靠架构,内容虽然并不完整,以今天的眼前来看成,仍有有许多值得学习的地方。


[- 16-]微信朋友圈千亿访问量背后的技术挑战和实践总结

[链接]http://www.52im.net/thread-1569-1-1.html

[摘要] 朋友圈的数据是永远存储的,而且随着业务的快速发展,存储容量、带宽和设备的消耗大量增加,尤其重大节日带来的使用量增长,更加剧了消耗,也给运维人员的保障带来了巨大压力。


[- 17-]王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等

[链接] http://www.52im.net/thread-1595-1-1.html

[摘要] 今天分几部分和大家介绍王者后台开发过程中的一些内容和思考:包括王者整个背景的介绍,后端的架构,上线之后做了什么样的调整,还有网络同步方案,反作弊方案等。

👉52im社区本周新文:《跟着源码学IM(十一):一套基于Netty的分布式高可用IM详细设计与实现(有源码) http://www.52im.net/thread-4257-1-1.html》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-06-05 11:59 Jack Jiang 阅读(107) | 评论 (0)编辑 收藏

本文内容由百度技术团队分享,原题“基于公共信箱的全量消息实现”,为了帮助理解,有较多修订、内容重组和重新排版。

1、引言

百度的IM消息中台为百度APP以及厂内百度系产品提供即时通讯的能力,提供包括私聊、群聊、聊天室、直播弹幕等用户沟通场景,并帮助业务通过消息推送触达用户。

如今,百度APP新增了一种需要以“低用户打扰”的形式触达全量用户的场景需求,而现有的IM消息中台主要是基于用户“私有信箱”通知拆分的机制(通俗了说也就是IM里的“扩散写”),所以如果不进行改造,是很难低成本、高时效的满足该场景诉求。

基于上述问题,本文介绍了百度现有IM消息中台系统的主要组成,并对比多种实现方案的优劣,以“公有信箱”通知读扩散的技术方案对现有IM消息中台系统进行改造,从而达成了低成本、高时效地实现全量用户通知推送需求。

技术交流:

本文已同步发布于:http://www.52im.net/thread-4235-1-1.html

2、全量用户消息推送需求背景

百度APP新增了需要通过IM实时通知触达全量用户的诉求,比如2022年12月7日解除疫情管控结束后,将经过筛选的官方政策解读、专题汇总、知识科普、实用工具类介绍等信息,通过官方号“x度小助手”下发触达到百度APP用户,从而来有效体现人文关怀,提高用户粘性。

在以IM消息服务进行全量用户消息触达时,需要满足以下诉求:

具体就是:

  • 1)在触达范围上:希望尽量扩大用户触达范围,包括百度APP月活用户、以及非月活用户但是近期新注册或登录的用户;
  • 2)在时效上:一次全量触达,希望短时间内完成(比如小时级、甚至分钟级),抢占时效性;
  • 3)在用户打扰方面:消息触达不能给用户带来较大的打扰,每次消息下发,只触达一次,不能重复打扰用户(但是需要保留回访入口,满足用户二次查看的诉求)。

3、现有IM消息中台的技术痛点

我们现有的IM(即时通讯)服务中,每个IM用户对应一个用户信箱。

基于现有的IM技术实现方案,如果想完成全量用户的消息触达,需要把消息推送到每个用户的信箱(也就是IM中的扩散写)。

这样的话,要完成6亿以上的消息写入(假定每条占用存储4KB,每秒写入2W条消息),在消息写入时效性以及存储资源消耗上,都是很难接受的。

且现有的基于用户私有信箱的方案,在同时支持多条全量用户通知消息的场景下,扩展性也较差。

基于上述需求背景和技术痛点,我们本次的改造目的,就是要找到一种技术方案,从而在特定业务场景下通过改造后的消息服务,低成本、高时效的给全量用户推送内容一致的消息通知。

4、现有IM消息中台的主要技术实现

在讨论改造方案前,我们有必要介绍一下目前IM消息系统的现状,包括消息系统的组成、通知拉取模式、用户信箱等。

4.1 消息系统组成

从普通用户的直观体验上看,一个IM系统可以包括如下元素:

  • 1)用户主体;
  • 2)用户账号;
  • 3)账号关系;
  • 4)聊天会话;
  • 5)聊天消息。

用自然语言串一下以上元素就是:

  • 1)“用户主体”具有“用户账号”;
  • 2)“用户主体”具有头像、昵称等用户属性;
  • 3)“用户主体”通过“用户账号”登录IM系统,进行聊天;
  • 4)“用户账号”之间的关注、屏蔽、免打扰等构成“用户关系”;
  • 5)通过用户之间的互动环节可以产生“聊天消息”;
  • 6)聊天记录构成了一个“聊天会话”。

下面这张图可能更直观一些:

从集成消息服务的业务方角度看:

  • 1)一个IM系统可以包括消息客户端(消息客户端UI组件、消息SDK)和消息服务端;
  • 2)IM消息可以作为一种服务,嵌入到各业务系统中,为业务系统提供“实时交互”能力;
  • 3)业务通过集成IM服务,提升其用户体验;
  • 4)业务APP集成IM SDK,通过IM SDK与IM Server交互,完成用户上行通讯能力;
  • 5)业务APP Server通过与IM Server交互,完成通知下行触达用户。

下图为一个集成了IM SDK的业务架构图:

从使用场景来看,消息包括:

  • 1)“私信消息”(包括用户上下行消息);
  • 2)“通知消息”(业务方给用户推送的下行消息);
  • 3)“群聊”、“聊天室”;
  • 4)“直播间弹幕”等。

4.2 消息的通知拉取模式

百度的IM消息系统,采用通知拉取(notify-pull)模式来感知新消息、拉取新消息。

IM SDK登录时,与IM 服务端建立长连接(LCS, Long Connect Service),用户有新的消息时,通过长连接下发notify,实时通知用户的IM SDK。

实时notify不写用户信箱,因为noitfy不是消息(可以理解为提醒在线用户有新消息的信号),IM SDK根据这个信号,来服务端拉取消息。

业务方server或者其他用户给该用户发送消息后,经过IM业务处理模块,把消息写入接收者信箱,IM Server会根据用户的登录和路由信息,给消息接收者(私信场景下也包括“消息发送者”,用于消息的多端同步)发送新消息notify,接收到notify的IM设备,通过IM SDK来IM Server端拉取(pull)消息。

4.3 用户信箱介绍

为了暂存尚未拉取到IM SDK本地的离线消息,需要对消息进行服务端存储,而消息的离线存储是通过消息信箱服务完成的。

目前百度的IM用户消息信箱主要包括:

  • 1)用户私有信箱;
  • 2)群公共信箱(非下文提到的用户公共信箱);
  • 3)直播间弹幕mcast等。

用户信箱通过“消息所属应用”+“IM标识用户的唯一ID”来标识。

就一条消息而言:消息参与者有“消息发送者”和“消息接收者”,消息收发双方的信箱都是相互独立的(假设发送方删除了自己信箱的某一条消息,不会影响消息接受者信箱的消息)。

对于有查看历史消息诉求的一方来说:消息需要入该方的信箱,比如用户之间的私信(也就是一对一单聊)消息需要入发送者和接收者的信箱。

而对于全量用户消息通知的场景:消息不需要存储发送者信箱,而只需要存接收者的信箱。而用户的信箱排序,是基于信箱Timeline(详见《现代IM系统中聊天消息的同步和存储方案探讨》)。即消息在信箱内部基于时间线存储,每条消息对应一个unix 微秒时间戳(如第一条消息1679757323320865),用户进行信箱拉取时,基于时间范围正序或者逆序拉取。

如下为信箱Timeline的示例:

用户信箱中的每一条消息记录都包含四个主要部分:

  • 1)“消息ID”;
  • 2)“消息用户标识”;
  • 3)“消息通用属性”;
  • 4)“消息业务属性”。

下面详细介绍以上四个部分:

  • 1)消息ID:为unix微秒时间戳,不需要全局唯一,只需要特定用户信箱范围内唯一即可;
  • 2)消息用户标识:包括from_uid、to_uid、contacter;
  • 3)消息通用属性:包括create_time、expire、is_read;
  • 4)消息业务属性:包括category、type、priority、business_type、APP_id、msgkey、content等。

如下为一条消息记录示例:

5、全量用户消息推送技术方案选型

5.1 需求分析

目前百度的IM消息推送机制中,主要支持:

  • 1)单播:消息推送方式,每次给一个用户推送一条消息;
  • 2)批量单播:每次给小范围用户推送消息,比如30个;
  • 3)广播:基于关注关系的推送,如给全量粉丝推送。

上述三种消息推送机制推送的消息,均需要存储服务端的用户私有信箱。为了完成百度APP 6亿以上全量月活用户的消息推送,目前有三种可选的方案,接下来我们逐一分析。

5.2 方案1:全流程从通知入口推送

该种方式下:需要获取全量的月活用户列表,经过IM Server推送入口,给每一个用户推送疫情相关通知。

该通知写入到用户信箱时:

  • 1)若用户在线,在实时拉取该通知;
  • 2)若用户离线,再下次登录IM服务时,拉取离线通知。

该种方案下:推送行为会覆盖IM的全流程,推送的通知会进入每个月活用户的私有信箱,服务压力大。其中增量用户不会收到通知推送(这里增量用户指的是不在月活用户列表的用户)。

5.3 方案2:跳过通知入口直接写信箱

该种方式跳过IM消息推送流程中的中间环节,直接把通知消息写入用户信箱。

由于跳过了中间流程直接写入信箱,通知写入速度主要取决于信箱底层存储的压力承受情况。

该种方案下,同方案1一样,无法给用户发送实时通知,依赖用户IM SDK的主动消息拉取(断链后重新登录/新消息提醒拉取),无法给增量用户发送通知。

该方案由于跳过中间环节直接写信箱,风险较大,无法直接提供给业务方使用,不建议如此操作。

5.4 方案3:公有信箱实现机制

该种公有信箱机制的逻辑是把通知消息写入“公共信箱”。在用户消息拉取时,合并“用户私信信箱”+“公共信箱”的消息。

5.5 三种方案比较

方案1和2都是写扩散方式,基于现有“用户私有信箱”的机制,把通知消息写入每个接收通知的用户私有信箱。

方案2与方案1的差别主要是跳过了消息中间流程,可以避免因为中间环节负载瓶颈导致整体消息写入速度过低。

方案3是读扩散方式,消息不用再写入接收通知的用户私有信箱,而只需要在公共信箱存储一份。在用户拉取消息时,实时拉取公共信箱的消息。方案③中可以采用内存缓存方案,解决对公共信箱的读压力。

本质上来说:方案3与方案前两种相比,是用读成本(CPU)换写成本(存储)。

6、基于公有信箱技术方案的全量用户消息推送实现

6.1 概述

基于上述方案3的思路,我们进行基于公有信箱的全量消息设计与实现。

该种方案中包含两个主要流程:

  • 1)全量消息的管理;
  • 2)用户私有+公有信箱的拉取。

6.2 全量消息的管理

全量消息管理主要分为:

  • 1)运营O端操作平台:复用运营消息平台;
  • 2)全量消息处理服务:复用IM服务的连接层、逻辑处理层、信箱代理、信箱处理。

运营O端平台为运营同学提供可视化界面,可以对全量消息进行编辑、预发布、发布、修改、停止、撤回等操作。

具体就是:

  • 1)接入层:对接运营O端,进行参数校验、转发IM后端逻辑处理模块;
  • 2)逻辑处理层:进行全量消息的创建、修改、停止、删除、撤回等逻辑操作;
  • 3)信箱代理层:复用IM服务的信箱CRUD操作;信箱存储层公共信箱的底层存储。

全量消息管理流程:

6.3 用户信箱拉取

用户通过IM SDK,以长连接的方式,在逻辑处理层进行消息拉拉取。

在用户拉取信箱消息时,需要对“用户个人信箱”和“公有信箱”进行合并。于是每次用户信箱拉取,都需要进行信箱的合并拉取。

6.3.1)公共信箱内存缓存机制:

百度APP的IM用户,在IM SDK登录时需要拉取信箱中的消息。每次消息拉取时,需要检查公共信箱中是否有消息。

因此,公共信箱需要能抗住日常和峰值流量(拉取峰值为4.7Wqps)。为了防止流量击穿,流量打到底层的持久化公共信箱MYSQL存储,我们设计了基于内存的公共信箱缓存机制。同时公共信箱内容变化时,也要实时(或者在能容忍的范围内做到准实时)变更内存缓存信箱中的消息,我们采用Bthread定期轮询持久化公共信箱,更新内存公共信箱,轮询间隔可配置(比如设置1秒)。

6.3.2)分级发布机制:

同时,在逻辑层实现白名单机制,支持全量消息在“预发布”状态下,仅对白名单用户可见,从而达到分级验证的效果。

白名单的用户列表通过逻辑处理成的配置加载,也支持通过CURL请求动态修改白名单的配置。

7、基于公有信箱技术方案的技术挑战

公有信箱的技术方案,需要解决如下问题:

8、基于公有信箱技术方案的优缺点总结

8.1 优点

以公共信箱的方式,实现全量用户消息分发,具有:“分发速度快”、“资源成本低”的特点。

8.2 缺点

但公共信箱的方式也存在一定的局限性。

8.2.1)不适用于个性化要求高的场景:

由于消息在公共信箱只存储一份,下发消息内容固定,无法很大程度下,下发个性化消息(当然也不是一定无法下发个性化的消息,可以通过在公共信箱存储消息模板,根据拉取消息的用户ID获取个性化信息,在消息拉取时,临时拼装消息,这样就增大了消息拉取时的代价)。

8.2.2)不适用于实时消息提醒场景:

1)从业务场景上看:全量消息优先级低,不需要在全量生效的瞬间让用户感知。

2)从实现上看:全量消息实时消息提醒成本高。因为实时消息提醒Notify,需要以类似单播的形式实时通知用户。和单播的区别是,Notify不用触达离线用户,也就是不用写用户信箱,只需实时触达在线用户。

3)从系统压力看:全量在线用户均收到实时新消息提醒,会带来信箱拉取请求的瞬时流量(手机百度IM SDK长连接峰值在线1550W,假定新消息提醒在瞬间下发,同时在线用户信箱拉取请求,会把db打挂的)。

9、基于公有信箱技术方案的落地实施效果

全量消息目前已经在百度APP得到应用,包括:重大通知的下发;百度APP功能更新介绍通知;消息的撤回,后续还将推广到其他的矩阵APP的全量通知推送场景。

举个具体的例子:22年Q4宣布疫情解封时,利用全量消息推送,低成本、高时效的完成3条“疫情解封专项”全量消息下发。

 

在这个例子中,三次全量消息下发,到达数据在2亿+(该值小于月活的6亿+),主要因为几个原因:

  • 1)本次全量消息有效期仅3天左右,全量消息有效期内登录IM SDK的用户才有机会拉到全量消息;
  • 2)本次下发使用了新的消息展示模板,所以限制了拉取全量消息的百度APP版本,只有高版本百度APP可以拉到;
  • 3)本次全量消息,限制了仅有百度APP登录用户拉取。

10、未来展望

本文介绍了现有IM消息中台系统,并通过公有信箱技术方案的改造,达成了低成本、高分发速度完成全量用户消息下发的设计、实现与应用。

在全量用户消息应用方面,除了业务上的使用,后续也可以用于广播消息、批量单播消息的撤回。比如由于误操作发送了广播消息,用户已经把广播消息拉到了端,并持久化到端,这是可以“以全量消息的方式,下发删除指令”,删除已经缓存到端的垃圾消息。

我们希望,通过消息系统持续不断优化,为更多的业务提供低成本、高稳定性的即时通讯能力。

11、相关资料

[1] 现代IM系统中聊天消息的同步和存储方案探讨

[2] 百度APP移动端网络深度优化实践分享(一):DNS优化篇

[3] 百度APP移动端网络深度优化实践分享(二):网络连接优化篇

[4] 百度APP移动端网络深度优化实践分享(三):移动端弱网优化篇

[5] 百度直播的海量用户实时消息系统架构演进实践

[6] 深入了解百度开源的分布式RPC框架brpc的方方面面

[7] 百度网盘千万节点的P2P架构设计(PPT)

[8] 零基础IM开发入门(一):什么是IM系统?

[9] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[10] 一套原创分布式即时通讯(IM)系统理论架构方案

[11] 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等

[12] 基于实践:一套百万消息量小规模IM系统技术要点总结

[13] 一套十万级TPS的IM综合消息系统的架构实践与思考

[14] 从新手到专家:如何设计一套亿级消息量的分布式IM系统

[15] 闲鱼亿级IM消息系统的架构演进之路

[16] 深度解密钉钉即时消息服务DTIM的技术设计

[17] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[18] 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等

本文已同步发布于:http://www.52im.net/thread-4235-1-1.html

posted @ 2023-05-26 10:57 Jack Jiang 阅读(174) | 评论 (0)编辑 收藏

     摘要: ► 相关链接:① MobileIMSDK-Uniapp端的详细介绍② MobileIMSDK-Uniapp端的开发手册new(* 精编PDF版)一、理论知识准备您需要对Uniapp和Vue开发有所了解:1)Uniapp 官方入门教程2)可能是最好的 uniapp 入门教程3)Uniapp 官方 Vue 快速入门教程您需要对...  阅读全文

posted @ 2023-05-18 12:04 Jack Jiang 阅读(142) | 评论 (0)编辑 收藏

Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang