Jack Jiang

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

2023年11月15日

本文由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 阅读(18) | 评论 (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 阅读(23) | 评论 (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 阅读(42) | 评论 (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 阅读(45) | 评论 (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 阅读(67) | 评论 (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 阅读(41) | 评论 (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 阅读(44) | 评论 (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 阅读(41) | 评论 (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 阅读(82) | 评论 (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 阅读(47) | 评论 (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 阅读(72) | 评论 (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 阅读(14) | 评论 (0)编辑 收藏

     摘要: 本文由字节跳动技术团队杨晨曦分享,本文有修订和改动。1、引言本文将带你一起初步认识Thrift的序列化协议,包括Binary协议、Compact协议(类似于Protobuf)、JSON协议,希望能为你的通信协议格式选型带来参考。  技术交流:- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》- 开源IM框架源码:https://github.com/JackJ...  阅读全文

posted @ 2023-12-28 10:52 Jack Jiang 阅读(51) | 评论 (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 阅读(47) | 评论 (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 阅读(53) | 评论 (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 阅读(49) | 评论 (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 阅读(58) | 评论 (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 阅读(62) | 评论 (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 阅读(44) | 评论 (0)编辑 收藏

     摘要: 本文由字节跳动技术团队高原、汤中峰分享,原题“抖音功耗优化实践”,本文有修订和改动。一、引言功耗优化是应用体验优化的一个重要课题,高功耗会引发用户的电量焦虑,也会导致糟糕的发热体验,从而降低了用户的使用意愿。而功耗又是涉及整机的长时间多场景的综合性复杂指标,影响因素很多。不论是功耗的量化拆解,还是异常问题的监控,以及主动的功耗优化对于开发人员来说都是很有挑战性的。本文结合抖...  阅读全文

posted @ 2023-12-07 11:37 Jack Jiang 阅读(113) | 评论 (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 阅读(62) | 评论 (0)编辑 收藏

     摘要: 本文由竹子爱熊猫分享,原题“(十一)Netty实战篇:基于Netty框架打造一款高性能的IM即时通讯程序”,本文有修订和改动。1、引言关于Netty网络框架的内容,前面已经讲了两个章节,但总归来说难以真正掌握,毕竟只是对其中一个个组件进行讲解,很难让诸位将其串起来形成一条线,所以本章中则会结合实战案例,对Netty进行更深层次的学习与掌握,实战案例也并不难,一个非常朴素的I...  阅读全文

posted @ 2023-11-30 12:28 Jack Jiang 阅读(57) | 评论 (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 阅读(51) | 评论 (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 阅读(57) | 评论 (0)编辑 收藏

     摘要: 本文由B端技术中心分享,原题“从0到1:哔哩哔哩智能客服系统的设计与实现”,本文有修订和改动。1、引言本文将要分享的是哔哩哔哩从0到1自研智能客服IM系统的技术实践过程,包括整体架构设计和主要核心功能的技术实现思路等,希望带给你启发。* 推荐阅读:《得物从0到1自研客服IM系统的技术实践之路》。  技术交流:- 移动端IM开发入门文章:《新手入门一篇就够...  阅读全文

posted @ 2023-11-23 11:53 Jack Jiang 阅读(71) | 评论 (0)编辑 收藏

     摘要: 本文由微信客户端团队rhythm分享,原题“视频号直播:如何进一步降低功耗占用?”,本文有修订和改动。1、引言功耗优化一直是 app 性能优化中让人头疼的问题,尤其是在直播这种用户观看时长特别久的场景。怎样能在不影响主体验的前提下,进一步优化微信iOS端视频号直播的功耗占用,本文给出了一个不太一样的答案。  技术交流:- 移动端IM开发入门文章:《新手入...  阅读全文

posted @ 2023-11-16 11:57 Jack Jiang 阅读(54) | 评论 (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 阅读(51) | 评论 (0)编辑 收藏

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