微信服务器协程原理解析及优化

By guenchi at 2017-12-17 • 0人收藏 • 200人看过

http://gad.qq.com/article/detail/20041


一、缘起

  前段时间把几个接入服务,做了协程的优化。微信开发框架里很好的集成了协程(基于部门开源的libco),所以涉及的开发量很少,但涉及到的思考却很多,要追溯到几年前曾经困扰我的问题。

  曾经开发这种类型的服务:接入层负责做一点点处理、然后转发给后端的服务做实际的运算;相比接入层,后端处理速度非常慢,有数千倍的差距,在后端计算时,接入层是等在那里的(也就是同步、阻塞)。

  为了应付不断增长的请求量,后端不断扩容。假设后端有10台机器,每个机器开启24个线程;为了把后端压满,前端就需要至少240个线程来匹配,如果是3个C1的机器,那每个机需要80个线程。如果后端扩容一倍,那前端线程也需要扩容一倍。每个机器160个线程感觉太多了,这些线程大部分时间是等待io的,直观上感觉系统的context switch开销会很大,CPU没有完全用于实际的业务处理。


二、有没有办法优化这个问题呢?

  Todo:linux的线程实现实际上效率很高,一个机器多少线程才算多?多少context switch算高,才需要优化?需要实际测试,或者实际业务具体分析。

  我们知道,网络服务框架大多采用半异步半同步的架构,比如上面的svkkit的框架模型图。利用epoll来处理client发起的连接、读写请求,这是框架的“异步”那部分(高效)。而框架同步的那部分,就发生在worker实际处理请求、以及RPC调用时,也是发生等待的地方(cpu等io),比较低效。



  直观的想法是,如果我们把RPC也利用epoll+ callback的方式来处理,这样不就高效了吗?

  然后我就着手开始进行开发、封装接口,很快就发现了问题所在。这种模式需要注册各种callback,成功的、失败的、超时的等等,把这种复杂性暴露出来很难管理和理解;此外更重要的是还需要一种灵活的保持上下文的机制,如何在调用callback时获得上次请求的上下文、临时变量等等?如何处理各种错误逻辑?即便咬牙实现了,也不够易用,远离了框架的初衷。

  Nginx却恰恰是在异步这条路上走到了极致,提到Nginx常见的描述都是异步、高性能、复杂、不好理解等等。基于Nginx模块开发也不失为一个方案。Python的Twisted也是类似的思路,笔者也用过一阵子,感觉比较难用。

  后来看到python的gevent(基于greenlet)以及由此接触到协程(coroutine)这个概念,貌似是解决这个问题的银弹。当一个greenlet遇到IO操作时,比如访问网络,就自动切换到其他的greenlet,等到IO操作完成,再在适当的时候切换回来继续执行。由于IO操作非常耗时,经常使程序处于等待状态,有了gevent为我们自动切换协程,就保证总有greenlet在运行,而不是等待IO。可以认为greenlet增强了python的协程机制,什么是协程呢?


三、什么是coroutine

  coroutine不是一个新概念,早在70年代就已经出现了,后来由于某种原因一直没引起大家的重视,近几年却开始被广泛使用(跟深度学习的尿性很像)。

  本质上讲Coroutine是一种特殊类型的subroutine,它可以在执行过程中多次暂停(yield)、然后过一段时间又可以重新从暂停的地方开始执行(resume),在重新执行时subroutine的上下文(局部变量)是保持的。

  function object也可以有类似的保存上下文的能力,coroutine不同的地方在于每次是从上次暂停的地方开始继续执行,而function object每次是从头开始执行。



  此外coroutine和进程、线程也比较像,都可以理解为一种“指令的执行序列”。协程和这俩之间有啥关系和区别呢?

  首先,协程对于OS来说透明的,OS只知道进程、线程(统称task),但不知道协程。这意味着对应同一线程的多个协程之间只是伪并发,不能像多线程那样利用多核,因为OS只能调度线程。

  如果OS不知道协程,那协程是如何被调度、执行的呢?答案是程序员自己控制协程什么时候暂停,什么时候切换、以及切换到哪个协程。

  我们知道OS对整个计算机负责,控制着各种权限,开放出一些syscall给process、thread调用访问系统资源,决定下一步执行那个task,保证整个计算机的高效、安全的运行;如果开放出调度的权限给我们,那整个计算机不就乱套了吗?事实上也不会有这种问题,同样是因为OS并不知道coroutine,多个coroutine只会瓜分同一个task的资源(OS分配的cpu时间片之类),至于如何瓜分,就随便程序员你了,OS并不care。


四、coroutine有啥用

  Coroutine主要几个用途,最开始应用在数据处理、xml解析等情景,利用coroutnie能够代码逻辑比较清晰,但是这种需求并不广泛。;coroutine也可以应用在网络服务、并发编程里;但可能由于机器性能、OS优化,进程、线程的改进,直接利用线程来做类似的事情也不会差到哪里去,所以协程就被大家遗忘了。但现在海量服务越来越多,利用coroutine优化网络服务性能这个需求又冒了出来,所以还是时势造英雄啊。

  微信的libco专注于利用协程解决RPC情景遇到的问题,通过hooksocket系统调用的方式(类似于python gevent),程序员可以采用同步的写法,写出异步执行的代码。

  启用协程后,协程在会阻塞的地方(比如socket read),自动挂起,然后选择执行其他ready的协程执行;未来某个时间协程等待的数据到达时,协程转化为就绪状态,可以重新开始执行。而协程的挂起、继续执行对程序员是透明的。但这一切的基础是协程的context switch相比线程要是非常高效的,否则利用线程完全可以做同样的事情。


五、coroutine的调度

  那我该如何控制coroutine的调度呢?有两个问题要回答:选择哪个coroutine执行,如何让他执行。

  我们都学过OS的进程、线程调度,OS的调度目标是保证公平、响应时间、优先级等条件下最大化机器的利用率。

  而协程这里要考虑的问题要简单些,一个task内的多个协程谁能跑谁就跑,至于跑多长时间则无所谓,如果有个协程一直能跑那也可以一直不切换。但如果当前正在执行的协程跑不动了(网络IO),那它要主动退出(靠自觉),靠另外一个Manager协程选择另一个能跑的协程继续跑。

  Manager如何知道哪个协程能跑呢?这个就要自己实现了,一般协程挂起时,都是由于需要等待一个条件的满足,比如socket的可读事件,如果socket有数据可读就会触发相应的协程由等待状态转化为就绪状态。

  由此可见协程是一种cooperative类型的调度策略,而OS的调度一般都是preemptive的,不然有些恶意程序一直while(true)死循环,这个机器就跪了。

  如何让某个协程开始执行呢?简单说来就是利用getcontext、makecontext、swapcontext来做用户态的contextswitch。

  就像在本文开始提到的,我们之所以使用coroutine技术就是期望协程具有比线程更好的context switch性能,因此swapcontext的性能对于协程就至关重要。

  Boost::Context、 libco都有自己的实现(汇编代码,跟硬件架构有关)。Boost::Context测试比系统调用的swapcontext性能有几十倍的提升,这样整个coroutine的技术方案终于make sense了。



六、并发带来的复杂性

  微信的开发框架基本都利用libco支持了协程,总体工作量很小。但由于引入了协程,在开发的过程中需要额外注意一些问题。

  我们都知道线程的引入带来了很多好处,多线程向进程内部引入了额外的并发,线程之间共享地址空间、共享打开的文件。这些并发、共享带来了高效率,但恰恰由于这些并发、共享,多线程开发就需要额外注意共享资源之间的同步问题,需要引入线程锁、原子操作等复杂性来保证多线程程序的正常操作。

  类似地,协程进一步向线程内部引入了并发,这时线程局部变量对协程来说也是共享的,同样需要注意并发安全的问题。

  我觉得最好要保证函数是reentrant的,因为有可能一个协程在函数内部挂起,然后另一个协程重新进入这个函数。这就意味着要特别注意对全局变量、静态变量的使用。还要特别注意锁的使用。libco提供了协程局部变量,使这个问题容易解决一些。

  其实为了处理协程之间访问共享变量的竞争的问题,只要不发生协程切换就好了,对于libco就是不发生网络IO。


七、协程的其他实现

  python、Boost提供了更通用的协程实现。当然还有很多其他语言。

  python的协程可以看看这个pdf:

  "A Curious Course on Coroutines and Concurrency "

  http://www.dabeaz.com/coroutines/Coroutines.pdf

  libco的代码是公司内开源的,阅读下也挺好的


登录后方可回帖

登 录
信息栏

Scheme中文社区

推荐实现 ChezScheme / r6rs / r7rs large
theschemer.org
Q群: 724577239

精华导览

社区项目

包管理器:Raven
HTTP服务器:Igropyr (希腊火)
官方插件:vscode-chez

社区目标:

完善足以使Scheme工程化和商业化的库,特别是开发极致速度的Web服务器和ANN模块。

一直以来Scheme缺少一个活跃的中文社区,同时中文资料的稀少,导致大多数因为黑客与画家和SICP而接触Scheme的朋友,在学完SICP后无事可做,不能将Scheme转换为实际的生产力。最后渐渐的放弃。
同时Chicken等实现,却因效率问题无法与其他语言竞争。本社区只有一个目的,传播Scheme的文明之火,在最快的编译器实现上,集众人之力发展出足够与其他语言竞争的社区和库。


友情链接:

Clojure 中文论坛
函数式·China


Loading...