用于网站服务器处理事件的方法和设备与流程

本申请涉及计算机领域，尤其涉及一种网站服务器处理事件技术。

背景技术：

随着互联网的快速发展，互联网不断被普及和应用。Web(互联网)服务是一种通过Web进行访问的服务，网站的服务架构决定着服务器的性能。

目前，服务架构端在架构上大致分为两种，一种是Web服务器与后端应用服务器的组合，Web服务器只做一个Web接入层代理，通过配置将请求转发给后端的应用服务器；还有一种是在支持模块化扩展的Web服务器上通过扩展模块(插件)的方式嵌入应用的业务逻辑，这种方式通过编写Web服务器模块的形式来实现业务逻辑难度较大，要求业务逻辑的实现方式必须融入到Web服务器本身的架构当中，需要对Web服务器本身架构有较深的理解。

现有的主流Web服务器(例如，Nginx服务器)主流使用的是多进程单线程模式下，即一个进程内只有一个主线程，通过在不同请求间切换来实现并发服务于多个请求，并且可以通过编写模块来扩展各种可以通过编写模块来扩展各种功能。其中比较主流的一种编写模块的方式是使用带协程机制的脚本语言。这种方式会通过一个主线程在不同请求间切换来实现并发，在主线程中为每个请求都创建一个协程，业务逻辑执行时会从主线程切换到请求的协程中，直到遇到阻塞输入输出接口(IO)或请求结束才切换回主线程(阻塞IO执行完毕后会再从主线程切换回请求的协程恢复执行)。这种机制可以简化业务逻辑的实现难度，但是，也存在一个问题，如果业务逻辑中有CPU(中央处理器)密集型任务，那么就会导致这个请求的协程长期占用CPU资源，无法切换回主线程，导致同时正在被并行处理的其他请求无法得到及时处理，造成其他请求的响应时间变长。

技术实现要素：

本申请的目的是提供一种网站服务器处理事件的方法与设备，以解决对于响应时间长的请求进行处理时影响其他请求的问题，降低系统的平均响应时间，保持高吞吐、低延迟的性能，并且提高CPU的利用率。

根据本申请的一个方面，提供了的一种网站服务器处理事件的方法，包括：

运行主线程，由所述主线程基于事件的处理请求创建协程后，再挂起所述主线程并切换至所述协程；

运行所述协程，由所述协程创建通信管道，并将所述事件的主要业务逻辑交由工作线程池进行处理，再挂起所述协程并切换至所述主线程；

再次运行所述主线程，由所述主线程继续处理事件循环，直至获取所述通信管道发送的所述工作线程池处理完毕的消息，挂起所述主线程并切换至所述协程；

再次运行所述协程，由所述协程处理所述事件的次要业务逻辑，并在处理完毕后，结束所述协程并切换回所述主线程。

根据本申请的另一方面，还提供了一种网站服务器处理事件的设备，包括：

主线程运行装置，用于运行主线程，由所述主线程基于事件的处理请求创建协程后，再挂起所述主线程并切换至所述协程；

协程运行装置，用于运行所述协程，由所述协程创建通信管道，并将所述事件的主要业务逻辑交由工作线程池进行处理，再挂起所述协程并切换至所述主线程；

主线程恢复运行装置，用于再次运行所述主线程，由所述主线程继续处理事件循环，直至获取所述通信管道发送的所述工作线程池处理完毕的消息，挂起所述主线程并切换至所述协程；

协程恢复运行装置，用于再次运行所述协程，由所述协程处理所述事件的次要业务逻辑，并在处理完毕后，结束所述协程并切换回所述主线程。

与现有技术相比，根据本申请的实施例所述方法及设备，通过主线程基于事件的处理请求创建协程后，挂起所述主线程并切换至所述协程；由 所述协程创建通信管道，并将所述事件的主要业务逻辑交由工作线程池中的某个工作线程进行处理，再挂起所述协程并切换至所述主线程，由所述主线程继续处理其他事件的处理请求，避免了事件的请求处理的协程长期占用CPU资源，无法切换回主线程造成的正在被并行处理的其他请求无法得到及时处理的问题，降低了系统的平均响应时间；所述主线程直至获取所述通信管道发送的所述工作线程池中工作线程处理主要业务逻辑完毕的消息，挂起所述主线程并切换至所述协程，由所述协程处理所述事件的次要业务逻辑，并在处理完毕后，结束所述协程并切换回所述主线程。进一步地，在拥有多核CPU的机器上，使得其他空闲的CPU得到利用，提高了CPU利用率。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出根据本申请一个方面的一种网站服务器处理事件的方法流程示意图；

图2示出根据本申请一个方面的一个优选实施例的一种网站服务器架构示意图；

图3示出根据本申请又一个方面的一种网站服务器处理事件的设备结构示意图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

图1示出根据本申请一个方面的一种网站服务器处理事件的方法流程示意图。所述方法包括步骤S11、步骤S12、步骤S13和步骤S14。其中，所述步骤S11运行主线程，由所述主线程基于事件的处理请求创建协程后，再挂起所述主线程并切换至所述协程；所述步骤S12运行所述协程，由所述协程创建通信管道，并将所述事件的主要业务逻辑交由工作线程池进行处理， 再挂起所述协程并切换至所述主线程；所述步骤S13再次运行所述主线程，由所述主线程继续处理事件循环，直至收到所述通信管道发送的所述工作线程池处理完毕的消息，挂起所述主线程并切换至所述协程；所述步骤S14再次运行所述协程，由所述协程处理所述事件的次要业务逻辑，并在处理完毕后，结束所述协程并切换回所述主线程。

具体地，在步骤S11中，运行主线程，由所述主线程基于事件的处理请求创建协程后，再挂起所述主线程并切换至所述协程。

在此，所述主线程是指当一个程序启动时，就有一个进程被操作系统创建，与此同时一个线程也立刻运行，该线程为程序的主线程。在网站服务器架构中，服务器的主线程处理事件循环时即从若干事件处理请求中选择某一事件的处理请求进行处理，首先针对该请求创建协程，协程创建成功后将主线程挂起暂时不继续执行下去并切换至所创建的协程，由协程继续执行。

具体地，在步骤S12中，运行所述协程，由所述协程创建通信管道，并将所述事件的主要业务逻辑交由工作线程池进行处理，再挂起所述协程并切换至所述主线程。

在此，所述通信管道包括两个相互关联的可读文件句柄和可写文件句柄。向其中一个可写文件句柄写的数据能从另一个可读文件句柄中读到。所述协程在创建通信管道后需要为通信管道的可读文件句柄关联一个读事件，添加一个对应的事件处理逻辑，并将该事件添加到事件循环的监听列表中。这样，当该读事件发生时，即通信管道的可读文件句柄有数据可读，主线程会调用对应的事件处理逻辑执行对应的处理。所述事件的主要业务逻辑是指需要长期占用CPU资源的业务请求。当工作线程池进行处理主要业务逻辑时将协程挂起并切换至主线程，主线程进行处理其他服务请求，达到了工作线程池与主线程并行处理业务逻辑的目的，从而避免响应时间长的请求影响其他请求，降低系统的平均响应时间，合理利用CPU资源。

具体地，在步骤S13中，再次运行所述主线程，由所述主线程继续处理事件循环，直至收到所述通信管道发送的所述工作线程池处理完毕的消息，挂起所述主线程并切换至所述协程。

在此，恢复之前被挂起的主线程，此时，主线程可以继续处理其他事件 的处理请求，等工作线程将主要业务逻辑处理完成后，主线程收到所述通信管道发送的处理完毕的消息，由于主线程监听了该通信管道的可读文件句柄的读事件，因此主线程在下次事件循环处理到该事件时执行了该读事件对应的事件处理逻辑，就会恢复之前被挂起的协程继续往下执行。

具体地，在步骤S14中，再次运行所述协程，由所述协程处理所述事件的次要业务逻辑，并在处理完毕后，结束所述协程并切换回所述主线程。

在此，主线程在收到工作线程处理事件的主要业务逻辑完毕消息后挂起自己并切换至协程，由该协程继续处理事件的次要业务逻辑，其中，所述次要业务逻辑指不需要长期占用CPU资源的业务逻辑，例如，对于一个具体的图像缩放的业务逻辑中，图像缩放处理为主要业务逻辑，整理处理结果并发送应答等为次要业务逻辑。在处理完次要业务逻辑后，结束所述协程并切换回所述主线程；或处理过程中遇到输入输出端口阻塞时再次挂起所述协程。

本申请一实施例所述方法用于网站服务器处理事件，通过引入处理业务逻辑的工作线程池，再利用协程和主线程的切换来解决处理长期占用CPU资源的请求时无法切换回主线程的问题，工作线程池与主线程的并行处理业务逻辑的实现使得同时正在被并行处理的其他请求得到及时的处理。同时，在拥有多核CPU的机器上，其他空闲的CPU得到合理的利用，提高CPU利用率。

优选地，所述方法还包括：创建用于处理事件的主要业务逻辑的业务逻辑模块，所述业务逻辑模块具有供所述协程调用的应用程序编程接口。

在一实施例中，引入处理业务逻辑的工作线程池，再利用协程和主线程的切换来解决处理长期占用CPU资源的请求时无法切换回主线程的问题时还需要将业务逻辑封装出一个独立的模块，该模块会提供一个应用程序编程接口供协程调用，并且需要调用应用程序编程接口挂起当前协程；同时在这个模块中引入一个用于执行需要长期占用CPU资源的业务逻辑的工作线程池，该工作线程池包含若干个工作线程，其中，工作线程在程序启动时就已创建。

优选地，所述步骤S11包括：运行所述协程，由所述协程将所述事件的主要业务逻辑的参数发送给所述工作线程池，再挂起所述协程并切换至所述 主线程；运行所述工作线程池，由所述工作线程池的工作线程处理所述事件的主要业务逻辑。

在此，运行所述协程包括：由所述协程将所述事件的主要业务逻辑的参数通过所述应用编程接口发送至所述工作线程池；运行所述工作线程池包括：运行所述工作线程池，由所述工作线程池的工作线程基于所述业务逻辑模块处理所述事件的主要业务逻辑。

接前例，所述工作线程池中的工作线程的处理函数是执行业务逻辑，在没有业务逻辑需要处理时处于空闲状态，在协程中调用应用程序编程接口，将主要业务逻辑的参数传递给工作线程池中的某个工作线程，其中，主要业务逻辑的参数指主要业务逻辑的原始信息和目标处理信息，例如，图片缩放的业务逻辑里参数为原图和目标尺寸；传递参数唤醒工作线程进行工作，一次只唤醒一个工作线程，工作线程池中设定多个工作线程是为了实现并发，例如，对于图片缩放这个处理请求，若工作线程池中有三个工作线程，当这个请求的参数传递给其中一个工作线程A时，进行图片缩放处理，在处理过程中，又有下一个图片缩放处理请求，则唤醒工作线程B进行工作，同理可唤醒工作线程C进行处理图片缩放的请求，当工作线程池中所有的工作线程都在工作时，再来请求时需要等待，直至有空闲的工作线程。

优选地，所述通信管道包括两个相互关联的可读文件句柄和可写文件句柄。

在此，向所述通信管道中的可写文件句柄写的数据能从可读文件句柄中读到，本领域技术人员应能理解，所述文件句柄是指在文件输入输出端口中，要从一个文件读取数据，应用程序首先要调用操作系统函数并传送文件名，并选一个到该文件的路径来打开文件；该函数取回一个顺序号，即文件句柄，该文件句柄对打开的文件是唯一的识别依据。

更优选地，所述运行所述协程还包括：由所述协程创建所述通信管道，并为所述通信管道的可读文件句柄关联一读事件，其中，所述读事件对应一用于恢复协程的执行的事件处理逻辑。在一实施例中，为通信管道的可读文件句柄关联一个读事件，添加一个对应的事件处理逻辑，并将该读事件添加到事件循环的监听列表中，当该事件发生时，主线程在处理事件循环时就会 对该事件进行处理，执行该事件的对应事件处理逻辑。一个读事件对应一个事件处理逻辑，事件处理逻辑是恢复协程的执行，当该事件发生时，主线程在事件循环中处理该读事件，就执行对应的事件处理逻辑，恢复之前被挂起的协程继续往下执行。

另外，运行所述协程还包括：由所述协程将所述可写文件句柄的参数通过所述应用编程接口发送至所述工作线程池。更优选地，所述运行所述工作线程池还包括：运行所述工作线程池，所述工作线程池的工作线程处理所述事件的主要业务逻辑，当处理完毕时，所述工作线程池基于接收的所述可写文件句柄的参数向所述可写文件句柄写入完成标识，所述完成标识被所述可读文件句柄读取。

接前例，在协程代码中，调用之前封装好的业务逻辑模块提供的应用程序编程接口，将管道的可写文件句柄的参数传递给工作线程池中要处理主要业务逻辑的工作线程，等主要业务逻辑处理完毕后，工作线程会向之前传入的通信管道的可写文件句柄中写入数据(如一个字节)表示事件的主要业务逻辑已处理完毕的完成标识，触发通信管道的可读文件句柄的读事件，这样可读文件句柄的读事件就发生了，因主线程将可读文件句柄的读事件添加到了事件循环的监听列表中，主线程在事件循环时处理该读事件，读取到所述完成标识时，执行所述读事件对应的事件处理逻辑就会恢复之前被挂起的协程继续往下执行。

更优选地，所述步骤S13还包括：

再次运行所述主线程，由所述主线程继续处理事件循环，当所述主线程处理到所述通信管道的可读文件句柄所关联的读事件，读取到所述完成标识时，执行所述读事件对应的事件处理逻辑，以挂起所述主线程并切换至所述协程。

继续接前例，主线程从协程中切换回来恢复执行，因主线程将可读文件句柄的读事件添加到了事件循环的监听列表中，主线程在事件循环时处理该读事件，读取到所述完成标识时，执行所述读事件对应的事件处理逻辑，即恢复协程的执行，以挂起所述主线程并切换至所述协程进行后续的次要业务逻辑的处理。

优选地，所述步骤S14还包括：当所述协程处理所述事件的次要业务逻辑时，遇到输入输出接口阻塞时，则挂起所述协程并切换回所述主线程。

继续接前例，挂起所述主线程并切换至所述协程，协程恢复运行，用于处理事件的次要业务逻辑，如发送应答，当遇到输入输出接口(I/O)阻塞时，则挂起所述协程并切换回所述主线程，主线程从协程中切换回来恢复执行。

进一步地，现有的服务架构有Nginx+Lua模块，Nginx是通过一个主线程在不同请求间切换来实现并发，如果某一个请求长期占用CPU资源，会导致同时在处理的其他请求的响应时间被拖长。在Lua代码中的业务逻辑执行时会从Nginx的主线程切换到请求的协程中，直到遇到阻塞I/O或请求结束才切回主线程。因此，如果业务逻辑中有CPU密集型任务，那么就会导致这个请求的协程长期占用CPU资源，无法切回Nginx主线程，也就导致同时正在被并行处理的其他请求无法得到及时处理，造成其他请求的响应时间变长。此外，在拥有多核CPU的机器上，可能存在其他空闲的CPU无法得到利用，造成资源浪费的问题。针对以上问题，本申请的一个优选实施例提出了架构Nginx+Lua模块的优化方案，使得这种架构在遇到CPU密集型任务时也能保持高吞吐、低延迟的性能，并能提高CPU利用率。以下针对架构Nginx+Lua模块的优化这一优选实施例进行详细说明。

需要说明的是，所述Nginx服务器是一个优秀的Web服务器，性能出色、资源占用率低、扩展能力强。Nginx服务器出色的性能得益于其异步非阻塞事件驱动机制，即Nginx最主流使用的多进程单线程模式下，一个进程内只有一个线程，同时并发服务于多个请求。另外，Nginx的扩展能力很强，可以通过编写模块来扩展各种功能。所述的Lua是一个强大、高性能、轻量级的嵌入式脚本语言。Nginx的Lua模块能够将Lua的强大能力集成到Nginx中，令Nginx具备解析执行Lua脚本的能力。通过Lua的协程特性，Nginx的Lua模块解决了编写一些业务逻辑较为复杂的模块的问题，可以在Lua代码中以同步的方式编写业务逻辑，实现各种功能。所述CPU密集型任务为需要长时间占用CPU资源的任务，如图像处理等。

图2示出根据本申请一个方面的一个优选实施例的Nginx+Lua模块优化架构示意图。主线程在进行处理事件循环时处理某个需要通过Lua代码 执行的请求，针对该请求新建Lua协程，接着，主线程挂起自己并切换到Lua协程，Lua模块在CPU密集型业务逻辑执行前创建一个通信管道，其中，通信管道包含两个相关联的文件句柄集合，向其中一个可写文件句柄写的数据能从另一个可读文件句柄中读到，并为通信管道中的可读文件句柄关联一个读事件，事件处理逻辑是恢复协程的执行。在程序启动时，处理业务逻辑对应的工作线程已创建，将业务逻辑封装出一个独立的模块，即业务逻辑模块，该模块会提供一个C语言的API(应用程序编程接口)供Lua调用，并且需要调用Lua语言的C API(C语言的应用程序编程接口)来挂起当前协程，同时在该模块中引入一个工作线程池，用于执行CPU密集型的业务逻辑，所述工作线程池中包含若干个工作线程，这些工作线程的处理函数是执行业务逻辑，在没有业务逻辑需要处理时工作线程是空闲状态。在Lua代码中，调用业务逻辑模块提供的C API，将业务逻辑需要的参数以及通信管道的可写文件句柄传递给工作线程池中的某个工作线程，唤醒工作线程进行工作，然后挂起当前协程。这样，就可以从Lua协程切换回Nginx的主线程，此时主线程可以去服务其他请求。同时，业务逻辑模块的工作线程可以利用其他空闲CPU已经开始并行执行业务逻辑。等业务逻辑处理完毕，工作线程会向之前传入的通信管道的可写文件句柄写入数据进行通知，由于Nginx主线程监听了该通信管道的可读文件句柄的读事件，因此，Nginx主线程在下次事件循环处理到这个事件时就会恢复之前被挂起的协程继续往下执行，恢复执行的协程继续执行Lua代码进行处理次要业务逻辑，如整理处理结果并发送应答等，若遇到阻塞I/O再次恢复挂起的主线程，主线程从Lua协程中切换回来恢复执行，处理事件循环；若继续执行Lua代码进行处理次要业务逻辑执行完毕后恢复挂起的主线程。需要说明的是，上述业务逻辑需要的参数，比如在一个具体地图像缩放的业务逻辑中，其参数就是原图和目标尺寸。

通过上述的优选实施例可知，通过引入专用于处理CPU密集型业务逻辑的工作线程池，再结合Nginx的Lua模块的协程功能，通过Lua协程中创建和工作线程池通信的管道并在调用工作线程工作后挂起自己，切回Nginx主线程，等工作线程完成业务逻辑处理后通过管道通知Nginx主线 程，然后在由Nginx主线程切换回Lua协程继续往下执行，从而避免响应时间长的请求影响其他请求，降低系统的平均响应时间，并且提高CPU利用率。

本领域技术人员应能理解，上述Nginx+Lua模块的优化为本申请一个优选地实施例，也可以为其他架构，如其他的Web服务器与嵌入式脚本语言组合的架构，现有及今后可能出现的服务架构，如能适用本申请，均可以引用的方式包含于本申请。

图3示出根据本申请一个方面的一种网站服务器处理事件的设备结构示意图。所述设备1包括主线程运行装置11、协程运行装置12、主线程恢复运行装置13和协程恢复运行装置14。其中，主线程运行装置11用于运行主线程，由所述主线程基于事件的处理请求创建协程后，再挂起所述主线程并切换至所述协程；协程运行装置12用于运行所述协程，由所述协程创建通信管道，并将所述事件的主要业务逻辑交由工作线程池进行处理，再挂起所述协程并切换至所述主线程；主线程恢复运行装置13用于再次运行所述主线程，由所述主线程继续处理事件循环，直至收到所述通信管道发送的所述工作线程池处理完毕的消息，挂起所述主线程并切换至所述协程；协程恢复运行装置14用于再次运行所述协程，由所述协程处理所述事件的次要业务逻辑，并在处理完毕后，结束所述协程并切换回所述主线程。

在此，所述设备1包括但不限于用户设备、或用户设备与网络设备通过网络相集成所构成的设备。所述用户设备其包括但不限于任何一种可与用户通过触摸板进行人机交互的移动电子产品，例如智能手机、PDA等，所述移动电子产品可以采用任意操作系统，如android操作系统、iOS操作系统等。优选地，设备1还可以是运行于所述用户设备、或用户设备与网络设备、触摸终端或网络设备与触摸终端通过网络相集成所构成的设备上的脚本程序。当然，本领域技术人员应能理解上述设备1仅为举例，其他现有的或今后可能出现的设备1如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

具体地，主线程运行装置11用于运行主线程，由所述主线程基于事件的处理请求创建协程后，再挂起所述主线程并切换至所述协程。

在此，所述主线程是指当一个程序启动时，就有一个进程被操作系统创建，与此同时一个线程也立刻运行，该线程为程序的主线程。在网站服务器架构中，服务器的主线程处理事件循环时即从若干事件处理请求中选择某一事件的处理请求进行处理，首先针对该请求创建协程，协程创建成功后将主线程挂起暂时不继续执行下去并切换至所创建的协程，由协程继续执行。

具体地，协程运行装置12用于运行所述协程，由所述协程创建通信管道，并将所述事件的主要业务逻辑交由工作线程池进行处理，再挂起所述协程并切换至所述主线程。

在此，所述通信管道包括两个相互关联的可读文件句柄和可写文件句柄。向其中一个可写文件句柄写的数据能从另一个可读文件句柄中读到。所述协程在创建通信管道后，需要为通信管道的可读文件句柄关联一个读事件，添加一个对应的事件处理逻辑，并将该事件添加到事件循环的监听列表中，当该读事件发生时，事件循环就会执行对应的事件处理逻辑。所述事件的主要业务逻辑是指需要长期占用CPU资源的业务请求。当工作线程池进行处理主要业务逻辑时将协程挂起并切换至主线程，主线程进行处理其他服务请求，达到了工作线程池与主线程并行处理业务逻辑的目的，从而避免响应时间长的请求影响其他请求，降低系统的平均响应时间，合理利用CPU资源。

具体地，主线程恢复运行装置13用于再次运行所述主线程，由所述主线程继续处理事件循环，直至收到所述通信管道发送的所述工作线程池处理完毕的消息，挂起所述主线程并切换至所述协程。

在此，恢复之前被挂起的主线程，此时，主线程可以继续处理其他事件的处理请求，等工作线程将主要业务逻辑处理完成后，主线程收到所述通信管道发送的处理完毕的消息，由于主线程监听了该通信管道的可读文件句柄的读事件，因此主线程在下次事件循环处理到该读事件时执行了所监听的读事件对应的事件处理逻辑，就会恢复之前被挂起的协程继续往下执行。

具体地，协程恢复运行装置14用于再次运行所述协程，由所述协程处理所述事件的次要业务逻辑，并在处理完毕后，结束所述协程并切换回所述主线程。

在此，主线程在收到工作线程处理事件的主要业务逻辑完毕消息后挂 起自己并切换至协程，由该协程继续处理事件的次要业务逻辑，其中，所述次要业务逻辑指不需要长期占用CPU资源的业务逻辑，例如，对于一个具体的图像缩放的业务逻辑中，图像缩放处理为主要业务逻辑，整理处理结果并发送应答为次要业务逻辑。在处理完次要业务逻辑后，结束所述协程并切换回所述主线程；或处理过程中遇到输入输出端口阻塞时再次挂起所述协程。

本申请一实施例所述设备1用于网站服务器处理事件，通过引入处理业务逻辑的工作线程池，再利用协程和主线程的切换来解决处理长期占用CPU资源的请求时无法切换回主线程的问题，工作线程池与主线程的并行处理业务逻辑的实现使得同时正在被并行处理的其他请求得到及时的处理。同时，在拥有多核CPU的机器上，其他空闲的CPU得到合理的利用，提高CPU利用率。

优选地，所述设备1还包括：创建装置(未示出)，创建用于处理事件的主要业务逻辑的业务逻辑模块，所述业务逻辑模块具有供所述协程调用的应用程序编程接口。

在一实施例中，引入处理业务逻辑的工作线程池，再利用协程和主线程的切换来解决处理长期占用CPU资源的请求时无法切换回主线程的问题时还需要将业务逻辑封装出一个独立的模块，该模块会提供一个应用程序编程接口供协程调用，并且需要调用应用程序编程接口挂起当前协程；同时在这个模块中引入一个用于执行需要长期占用CPU资源的业务逻辑的工作线程池，该工作线程池包含若干个工作线程，其中，工作线程在程序启动时就已创建。

优选地，所述协程运行装置11包括：发送单元，用于运行所述协程，由所述协程将所述事件的主要业务逻辑的参数发送给所述工作线程池，再挂起所述协程并切换至所述主线程；处理单元，用于运行所述工作线程池，由所述工作线程池的工作线程处理所述事件的主要业务逻辑。

在此，所述发送单元用于：由所述协程将所述事件的主要业务逻辑的参数通过所述应用编程接口发送至所述工作线程池；所述处理单元用于：运行所述工作线程池，由所述工作线程池的工作线程基于所述业务逻辑模块处理所述事件的主要业务逻辑。

接前例，所述工作线程池中的工作线程的处理函数是执行业务逻辑，在没有业务逻辑需要处理时处于空闲状态，在协程中调用应用程序编程接口，将主要业务逻辑的参数传递给工作线程池中的某个工作线程，其中，主要业务逻辑的参数指主要业务逻辑的原始信息和目标处理信息，例如，图片缩放的业务逻辑里参数为原图和目标尺寸；传递参数唤醒工作线程进行工作，一次只唤醒一个工作线程，工作线程池中设定多个工作线程是为了实现并发，例如，对于图片缩放这个处理请求，若工作线程池中有三个工作线程，当这个请求的参数传递给其中一个工作线程A时，进行图片缩放处理，在处理过程中，又有下一个图片缩放处理请求，则唤醒工作线程B进行工作，同理可唤醒工作线程C进行处理图片缩放的请求，当工作线程池中所有的工作线程都在工作时，再来请求时需要等待，直至有空闲的工作线程。

优选地，所述通信管道包括两个相互关联的可读文件句柄和可写文件句柄。

在此，向所述通信管道中的可写文件句柄写的数据能从可读文件句柄中读到，本领域技术人员应能理解，所述文件句柄是指在文件输入输出端口中，要从一个文件读取数据，应用程序首先要调用操作系统函数并传送文件名，并选一个到该文件的路径来打开文件；该函数取回一个顺序号，即文件句柄，该文件句柄对打开的文件是唯一的识别依据。

更优选地，所述发送单元还用于：运行所述协程，由所述协程创建所述通信管道，并为所述通信管道的可读文件句柄关联一读事件，其中，所述读事件对应一用于恢复协程的执行的事件处理逻辑。在一实施例中，为通信管道的可读文件句柄关联一个读事件，添加一个对应的事件处理逻辑，并将该读事件添加到事件循环的监听列表中，当该事件发生时，主线程在处理事件循环时就会对该事件进行处理，执行对应的事件处理逻辑。一个读事件对应一个事件处理逻辑，事件处理逻辑是恢复协程的执行，当该事件发生时，主线程在事件循环中处理该读事件，就执行对应的事件处理逻辑，恢复之前被挂起的协程继续往下执行。

另外，发送单元还用于：由所述协程将所述可写文件句柄的参数通过所述应用编程接口发送至所述工作线程池。更优选地，所述处理单元用于：运 行所述工作线程池，所述工作线程池的工作线程处理所述事件的主要业务逻辑，当处理完毕时，所述工作线程池基于接收的所述可写文件句柄的参数向所述可写文件句柄写入完成标识，所述完成标识被所述可读文件句柄读取。

接前例，在协程代码中，调用之前封装好的业务逻辑模块提供的应用程序编程接口，将管道的可写文件句柄的参数传递给工作线程池中要处理主要业务逻辑的工作线程，等主要业务逻辑处理完毕后，工作线程会向之前传入的通信管道的可写文件句柄中写入数据(如一个字节)表示事件的主要业务逻辑已处理完毕的完成标识，触发通信管道的可读文件句柄的读事件，这样可读文件句柄的读事件就发生了，因主线程将可读文件句柄的读事件添加到了监听列表中，主线程在事件循环时处理该读事件，读取到所述完成标识时，执行所述读事件对应的事件处理逻辑，就会恢复之前被挂起的协程继续往下执行。

更优选地，所述主线程恢复运行装置13还用于：

再次运行所述主线程，由所述主线程继续处理事件循环，当所述主线程处理到所述通信管道的可读文件句柄所关联的读事件，读取到所述完成标识时，执行所述读事件对应的事件处理逻辑，以挂起所述主线程并切换至所述协程。

继续接前例，主线程从协程中切换回来恢复执行，因主线程将可读文件句柄的读事件添加到了监听列表中，主线程在事件循环时处理该读事件，读取到所述完成标识时，执行所述读事件对应的事件处理逻辑，即恢复协程的执行，以挂起所述主线程并切换至所述协程进行后续的次要业务逻辑的处理。

优选地，所述协程恢复运行装置14还用于：当所述协程处理所述事件的次要业务逻辑时，遇到输入输出接口阻塞时，则挂起所述协程并切换回所述主线程。

继续接前例，挂起所述主线程并切换至所述协程，协程恢复运行，用于处理事件的次要业务逻辑，如发送应答，当遇到输入输出接口(I/O)阻塞时，则挂起所述协程并切换回所述主线程，主线程从协程中切换回来恢复执行。

进一步地，现有的服务架构有Nginx+Lua模块，Nginx是通过一个主线程在不同请求间切换来实现并发，如果某一个请求长期占用CPU资源，会导 致同时在处理的其他请求的响应时间被拖长。在Lua代码中的业务逻辑执行时会从Nginx的主线程切换到请求的协程中，直到遇到阻塞I/O或请求结束才切回主线程。因此，如果业务逻辑中有CPU密集型任务，那么就会导致这个请求的协程长期占用CPU资源，无法切回Nginx主线程，也就导致同时正在被并行处理的其他请求无法得到及时处理，造成其他请求的响应时间变长。此外，在拥有多核CPU的机器上，可能存在其他空闲的CPU无法得到利用，造成资源浪费的问题。针对以上问题，本申请的一个优选实施例提出了架构Nginx+Lua模块的优化方案，使得这种架构在遇到CPU密集型任务时也能保持高吞吐、低延迟的性能，并能提高CPU利用率。以下针对架构Nginx+Lua模块的优化这一优选实施例进行详细说明。

需要说明的是，所述Nginx服务器是一个优秀的Web服务器，性能出色、资源占用率低、扩展能力强。Nginx服务器出色的性能得益于其异步非阻塞事件驱动机制，即Nginx最主流使用的多进程单线程模式下，一个进程内只有一个线程，同时并发服务于多个请求。另外，Nginx的扩展能力很强，可以通过编写模块来扩展各种功能。所述的Lua是一个强大、高性能、轻量级的嵌入式脚本语言。Nginx的Lua模块能够将Lua的强大能力集成到Nginx中，令Nginx具备解析执行Lua脚本的能力。通过Lua的协程特性，Nginx的Lua模块解决了编写一些业务逻辑较为复杂的模块的问题，可以在Lua代码中以同步的方式编写业务逻辑，实现各种功能。所述CPU密集型任务为需要长时间占用CPU资源的任务，如图像处理等。

图2示出根据本申请一个方面的一个优选实施例的Nginx+Lua模块优化架构示意图。主线程在进行处理事件循环时处理某个需要通过Lua代码执行的请求，针对该请求新建Lua协程，接着，主线程挂起自己并切换到Lua协程，Lua模块在CPU密集型业务逻辑执行前创建一个通信管道，其中，通信管道包含两个相关联的文件句柄集合，向其中一个可写文件句柄写的数据能从另一个可读文件句柄中读到，并为通信管道中的可读文件句柄关联一个读事件，事件处理逻辑是恢复协程的执行。在程序启动时，处理业务逻辑对应的工作线程已创建，将业务逻辑封装出一个独立的模块，即业务逻辑模块，该模块会提供一个C语言的API(应用程序编程接口) 供Lua调用，并且需要调用Lua语言的C API(C语言的应用程序编程接口)来挂起当前协程，同时在该模块中引入一个工作线程池，用于执行CPU密集型的业务逻辑，所述工作线程池中包含若干个工作线程，这些工作线程的处理函数是执行业务逻辑，在没有业务逻辑需要处理时工作线程是空闲状态。在Lua代码中，调用业务逻辑模块提供的C API，将业务逻辑需要的参数以及通信管道的可写文件句柄传递给工作线程池中的某个工作线程，唤醒工作线程进行工作，然后挂起当前协程。这样，就可以从Lua协程切换回Nginx的主线程，此时主线程可以去服务其他请求。同时，业务逻辑模块的工作线程可以利用其他空闲CPU已经开始并行执行业务逻辑。等业务逻辑处理完毕，工作线程会向之前传入的通信管道的可写文件句柄写入数据进行通知，由于Nginx主线程监听了该通信管道的可读文件句柄的读事件，因此，Nginx主线程在下次事件循环处理到这个事件时就会恢复之前被挂起的协程继续往下执行，恢复执行的协程继续执行Lua代码进行处理次要业务逻辑，如整理处理结果并发送应答等，若遇到阻塞I/O恢复挂起的主线程，主线程再次从Lua协程中切换回来恢复执行，处理事件循环；若继续执行Lua代码进行处理次要业务逻辑执行完毕后恢复挂起的主线程。需要说明的是，上述业务逻辑需要的参数，比如在一个具体地图像缩放的业务逻辑中，其参数就是原图和目标尺寸。

通过上述的优选实施例可知，通过引入专用于处理CPU密集型业务逻辑的工作线程池，再结合Nginx的Lua模块的协程功能，通过Lua协程中创建和工作线程池通信的管道并在调用工作线程工作后挂起自己，切回Nginx主线程，等工作线程完成业务逻辑处理后通过管道通知Nginx主线程，然后在由Nginx主线程切换回Lua协程继续往下执行，从而避免响应时间长的请求影响其他请求，降低系统的平均响应时间，并且提高CPU利用率。

本领域技术人员应能理解，上述Nginx+Lua模块的优化为本申请一个优选地实施例，也可以为其他架构，如其他的Web服务器与嵌入式脚本语言组合的架构，现有及今后可能出现的服务架构，如能适用本申请，均可以引用的方式包含于本申请。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。