C/C++协程库libco：微信怎样漂亮地完成异步化改造资源-CSDN文库

135 浏览量 2021-02-01 13:55:07 上传评论收藏 214KB PDF 举报

资源推荐

资源详情

资源评论

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

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip