没有合适的资源?快使用搜索试试~ 我知道了~
首页微信异步改造:C++协程库libco的幕后技术
C/C++协程库libco在微信异步化改造中的关键作用 微信作为全球最大的即时通讯应用之一,其背后的异步化改造是一个技术壮举。在2011年微信起步时,由于用户量迅速增长,到了2013年面临了巨大的并发压力。原有的系统架构采用半同步半异步模式,存在并发能力有限的问题,尤其是在面对海量RPC调用和数万台服务器时,系统的稳定性和效率成为亟待解决的挑战。 在这个背景下,微信团队面临着两种异步化改造方案:一是全面切换到异步模型(A线程异步化),即整个框架和业务逻辑层面的重构,这虽然能显著提高并发能力,但工作量大,风险高;二是采用C/C++协程库libco进行非侵入式的异步化改造(B协程异步化),只针对部分框架进行调整,保持业务逻辑的同步风格,同时利用协程自动管理异步状态,减少了维护复杂度和内存开销。 相比于A方案,B协程方案的优势在于其简洁性与性能。在B方案中,协程自动保存和恢复上下文,程序员无需显式管理异步状态,只需关注核心业务逻辑。这种非侵入性的改造使得微信能在保持原有开发模式的同时,提高系统的并发处理能力,极大地节省了服务器资源,确保了系统的稳定运行。 自2013年起,libco在微信后台的广泛应用使得微信能够高效地处理大量用户请求,同时降低了运维复杂性。通过C/C++协程库的巧妙运用,微信成功地完成了技术上的华丽转身,实现了后台服务的高效异步化,支撑了其庞大的用户基础和快速增长的业务需求。 总结来说,libco在微信的异步化改造中扮演了关键角色,它不仅优化了系统的并发处理能力,还降低了开发和维护的难度,是微信技术团队在复杂场景下实现高效、优雅技术演进的一个典范。
资源详情
资源推荐
C/C++协程库协程库libco:微信怎样漂亮地完成异步化改造:微信怎样漂亮地完成异步化改造
如今,微信拥有月活跃用户8亿。
不可否认,当今的微信后台拥有着强大的并发能力。
不过, 正如罗马并非一日建成;微信的技术也曾经略显稚嫩。
微信诞生于2011年1月,当年用户规模为0.1亿左右;2013年11月,微信月活跃用户数达到3.55亿,一跃成为亚洲地区拥有最
大用户群体的移动终端即时通讯软件。
面对如此体量的提升,微信后台也曾遭遇棘手的窘境;令人赞叹的是技术人及时地做出了漂亮的应对。
这背后有着怎样的技术故事?
此时此刻,你在微信手机端发出的请求,是怎样被后台消化和处理的?
该项目在保留后台敏捷的同步风格同时,提高了系统的并发能力,节省了大量的服务器成本;自2013年起稳定运行于微信的
数万台机器之上。
微信后端遇到了问题
早期微信后台因为业务需求复杂多变、产品要求快速迭代等需求,大部分模块都采用了半同步半异步模型。接入层为异步模
型,业务逻辑层则是同步的多进程或多线程模型,业务逻辑的并发能力只有几十到几百。
随着微信业务的增长,直到2013年中,微信后台机器规模已达到1万多台,涉及数百个后台模块,RPC调用每分钟数十亿。在
如此庞大复杂的系统规模下,每个模块很容易受到后端服务或者网络抖动的影响。因此我们急需对微信后台进行异步化的改
造。
异步化改造方案的考量
当时我们有两种选择:
A 线程异步化:把所有服务改造成异步模型,等同于从框架到业务逻辑代码的彻底改造
B 协程异步化:对业务逻辑非侵入的异步化改造,即只修该少量框架代码
两者相比,工作量和风险系数的差异显而易见。虽然A方案服务器端多线程异步处理是常见做法,对提高并发能力这个原始目
标非常奏效;但是对于微信后台如此复杂的系统,这过于耗时耗力且风险巨大。
无论是异步模型还是同步模型,都需要保存异步状态。所以两者在技术细节的相同点是,两个方案,都是需要维护当前请求的
状态。在A异步模型中方案,当请求需要被异步执行时,需要主动把请求相关数据保存起来,再等待状态机的下一次调度执
行;而在B协程模型方案中,异步状态的保存与恢复是自动的,协程恢复执行的时候就是上一次退出时的上下文。
因此,B协程方案不需要显式地维护异步状态:一方面在编程上可以更简单和直接;另一方面协程中只需要保存少量的寄存
器。因此在复杂系统上,协程服务的性能可能比纯异步模型更优。
综合以上考虑,最终我们选择了B方案,通过协程的方式对微信后台上百个模块进行了异步化改造。
接管历史遗留的同步风格API
方案敲定之后,接下来做的就是实现异步化的同时尽可能地少做代码修改。
通常而言,一个常规的网络后台服务需要connect、write、read等系列步骤,如果使用同步风格的API对网络进行调用,整个
服务线程会因为等待网络交互而挂起,这就会造成等待并占用资源。原来的这种情况很明显地影响到了系统的并发性能,但是
当初这样的选择是因为对应的同步编程风格具有其独特的优势:代码逻辑清晰、易于编写并且支持业务快速迭代敏捷开发。
我们的改造方案需要消除同步风格API的缺点,但是同时还希望保持同步编程的优点。
最后在不修改线上已有的业务逻辑代码的情况下,我们的libco框架创新地接管了网络调用接口(Hook)。把协程的让出与恢
复作为异步网络IO中的一次事件注册与回调。当业务处理遇到同步网络请求的时候,libco层会把本次网络请求注册为异步事
件,当前的协程让出CPU占用,CPU交给其它协程执行。在网络事件发生或者超时的时候,libco会自动的恢复协程执行。
libco的架构
libco架构从设计的时候就已经确立下来了,最近的在GitHub上一次较大更新主要是功能上的更新。(注:libco为开源项目,
源码同步更新,可移步:https://github.com/tencent/libco)。
libco框架有三层:分别是协程接口层、系统函数Hook层以及事件驱动层。
下载后可阅读完整内容,剩余3页未读,立即下载
weixin_38547397
- 粉丝: 2
- 资源: 907
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- OptiX传输试题与SDH基础知识
- C++Builder函数详解与应用
- Linux shell (bash) 文件与字符串比较运算符详解
- Adam Gawne-Cain解读英文版WKT格式与常见投影标准
- dos命令详解:基础操作与网络测试必备
- Windows 蓝屏代码解析与处理指南
- PSoC CY8C24533在电动自行车控制器设计中的应用
- PHP整合FCKeditor网页编辑器教程
- Java Swing计算器源码示例:初学者入门教程
- Eclipse平台上的可视化开发:使用VEP与SWT
- 软件工程CASE工具实践指南
- AIX LVM详解:网络存储架构与管理
- 递归算法解析:文件系统、XML与树图
- 使用Struts2与MySQL构建Web登录验证教程
- PHP5 CLI模式:用PHP编写Shell脚本教程
- MyBatis与Spring完美整合:1.0.0-RC3详解
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功