Jack Jiang

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

2024年2月22日

一、关于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 阅读(7) | 评论 (0)编辑 收藏

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

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

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

posted @ 2024-06-13 11:53 Jack Jiang 阅读(31) | 评论 (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 阅读(30) | 评论 (0)编辑 收藏

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

posted @ 2024-06-06 12:45 Jack Jiang 阅读(37) | 评论 (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 阅读(8) | 评论 (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 阅读(42) | 评论 (0)编辑 收藏

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

posted @ 2024-05-23 14:20 Jack Jiang 阅读(78) | 评论 (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 阅读(63) | 评论 (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 阅读(73) | 评论 (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 阅读(63) | 评论 (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 阅读(61) | 评论 (0)编辑 收藏

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

posted @ 2024-05-06 12:35 Jack Jiang 阅读(66) | 评论 (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 阅读(69) | 评论 (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 阅读(36) | 评论 (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 阅读(59) | 评论 (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 阅读(68) | 评论 (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 阅读(50) | 评论 (0)编辑 收藏

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

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

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

posted @ 2024-03-28 11:21 Jack Jiang 阅读(107) | 评论 (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 阅读(67) | 评论 (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 阅读(16) | 评论 (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 阅读(53) | 评论 (0)编辑 收藏

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

posted @ 2024-03-07 10:59 Jack Jiang 阅读(67) | 评论 (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 阅读(66) | 评论 (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 阅读(103) | 评论 (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 阅读(100) | 评论 (0)编辑 收藏

Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang