赞
踩
本文由ELab团队公众号授权发布,原题《Rust语言在IM客户端的实践》,来自抖音电商前端团队的分享,本文有修订和改动。
本文将介绍飞鸽IM前端团队如何结合Rust对飞鸽客户端接待能力进行的技术提升,一步步从概念验证、路径分解到分工开发,再到最后上线收益论证,并分享了其中遇到的技术挑战与经验总结等。
本项目是一个长周期的复杂项目,相信本项目落地的经验对其他同学及团队能有所借鉴。
技术交流:
- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》
- 开源IM框架源码:https://github.com/JackJiang2011/MobileIMSDK(备用地址点此)
(本文已同步发布于:http://www.52im.net/thread-4620-1-1.html)
飞鸽是在抖音电商业务上面向商家和用户的聊天工具,其拉通售前、售中、售后渠道,为商家履约提供重要支撑。
对于飞鸽桌面端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进行重写,彻底解除这一块的性能瓶颈!
飞鸽im sdk是一个对运行稳定性要求高的组件,其工程量大、逻辑复杂,对于异步特性使用非常频繁,其对于内存安全、 线程安全有着比较严格的要求。
假如使用C++,作为新手并没有把握能够将复杂的IM SDK少bug的编写下来(团队限制)。
Rust学习曲线虽然陡峭,但是其为安全设计的各类语言特性、强大的编译器,能够将新人编写代码的问题数降到最低(逻辑问题除外)。
并且飞书团队提供了客户端的rust生态库,帮助我们解决很多的基建问题,所以这里使用Rust是相当合适的。
Rust学习成长曲线:
如背景中所描述,历史架构存在这两个问题:
具体是:
为了验证推测切实可行,我们提前做了完备的POC验证。
在POC中,我们针对“单进程单线程模型”、“多进程模型”、“多线程模型”,这三种模型搭建了mvp demo,即简易的客服聊天模型,并进行压力测试,并监测其内存、cpu等指标。
通过POC,我们得出的结论是:
具体就是:
路要一步步走,整个项目粗估下来会有上百的工作日,作为业务团队,我们无法在短期内投入大量的资源去做这个项目,所以需要一步一步拆解、验证、拿收益。
团队内native开发资源有限,这件事情的进行也需要团队进行学习、成长。下面我们将详细分享这个过程 。
造房子先得有一个地基 —— Rust工程的基础建设,是Native业务的前置条件!
桌面端同学牵头搭建了整个RustSDK地基,地基解决的问题如下图所示:
需要做的工作:
在拥有一部分地基后,我们开始针对IM SDK的基础能力进行实现和验证。
因为只有完成基础能力验证之后,我们才会有信心在新的架构上叠加更多的功能。
这阶段我们关注以下指标( 希望其存在优化,至少不劣化):
仅实现长链能力下沉,验证&提升其稳定:
本阶段论证结果如下:
这阶段的工作是考验耐心的,因为这个阶段并不能带来实质性的用户体验提升、也无法拿到明显的提升数据,只是作为中间阶段,它有存在的必要性。
这阶段后,在稳定性治理、基础能力验证、 Rust 语言经验、指标制定合理性这几方面,我们踩上了一个更结实的台阶,更有信心去进行更复杂的下一阶段。
夯实基础后,我们开始发力冲刺,大刀阔斧的对IM SDK进行重新设计、实现、联调以及上线。
此阶段要实现im sdk的全部能力、 并对线上运行的js im sdk进行替换。
由于飞鸽im对于通信模块的稳定程度要求是很高的,替换过程就像是在高速行驶的车辆上替换轮胎,如果出现问题也容易导致大量的客服负面反馈。
因此,新rust sdk的稳定性、异常问题时的兜底方案、灰度时的监控观察、对新增反馈的留意都很重要,放量过程会存在一定精神压力。
工作内容大致如下。
1)多实例的Rust IM SDK设计(商家单聊、群聊、平台客服)、Js -> Rust IMSDK跨端调用协议设计:
2)开发:
3)测试:
4)异常兜底方案实现:
设计数据冗余,当Rust进程出现崩溃、无响应、不可恢复的网络错误时,识别并fallback到 web版本,使用冗余数据快速恢复im sdk正常运行状态,确保用户体验。
5)稳妥的上线方案 & 稳定性治理。
6)调用&适配优化,结合Native能力进一步性能优化。
7)结果回收。
8)其中各个步骤都会存在一些挑战,在后后面的内容会提到。
调用简化模型:
IM Core简化模型:
最后的阶段,我们基于完善的Rust IM SDK的能力进行形态的升级。
本阶段正在进行中,完成后会做更多的分享。
1)多窗口改造:销毁后台的多开账号,让多开账号数量突破到25个。
2)消息提醒、通知流程改造。
3)消息本地化能力:加快消息上屏。
一个有战斗力的团队,一定是持续学习、进步的。
比如:
比如 :
团队Native开发同学少,且各自并行业务需求,需合理的安排开发路线,减少总开发时长。
1)编写模块的健康自检,检测到异常时用最小的代价切换备用老方案。
2)完善业务监控&技术指标监控:crash率、无响应率、长链在线率、发消息成功率、请求成功率、卡顿率等。
3)对真实用户使用体验进行跟踪:
4)放量节奏的把控:
频率过高的IPC通信可能使得CPU优化适得其反,因为老版本都运行在Js中,所以调用频率是没有节制的(循环读取数据也经常出现),必须要在设计上降低下来——降低业务JS线程的压力。
以下措施可以将本场景通信成本降低90%以上。
1)更高效的数据协议 protobuf:相较于json,数据更小、解析和序列化性能更高、跨语言生成代码工具。
2)Rust push to js:使用数据收集去重 + debounce批量更新的策略,合并多个数据回调接口,减少通信频率。
3)Js call rust(单次基础耗时4ms):
针对某种场景做的优化工作不容易在大盘数据中得到体现(尤其在灰度阶段),我们应该针对特殊场景建立新指标。
即编写策略,识别并收集极端场景下的数据:为了衡量极端场景的的卡顿优化,建立了忙碌与卡顿指标,可以衡量出用户接待忙碌程度与卡顿率的关系,并且通过此指标将优化清晰的衡量出来。
具体是:
压力评测:
数据表现:
解读一下:
全量至今,再无大量进线导致卡顿的反馈。回访历史反馈用户,皆无因大量接待导致的卡顿现象
[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)
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。