Swoft 源码剖析 - Swoole和Swoft的那些事 (Http/Rpc服务篇)

做者：bromine
连接：https://www.jianshu.com/p/4c0...
來源：简书
著做权归做者全部，本文已得到做者受权转载，并对原文进行了从新的排版。
Swoft Github: https://github.com/swoft-clou...

Swoft源码剖析系列目录： https://segmentfault.com/a/11...

前言

Swoft在PHPer圈中是一个门槛较高的Web框架，不只仅因为框架自己带来了不少新概念和前沿的设计，还在于Swoft是一个基于Swoole的框架。Swoole在PHPer圈内学习成本最高的工具没有之一，虽然Swoft的出现下降了Swoole的使用成本，但若是你对Swoole自己了解不够深刻，仍然很难避免栽进种种"坑"中。

考虑到这个现状，也为下降阅读难度，后续几个和Swoole联系较为密切的机制，笔者会调整写做思路，将文章的定位从 「帮助读者深刻理解Swoft」 调整为 「帮助读者理解Swoft和Swoole」，叙述节奏也会放慢。

三种PHP应用的Web模型

LNMP和LAMP是绝大多数PHPer最熟悉的基础Web架构，这里以常见的LNMP做为例子描述一个常见 无Swoole应用的构件组成：Nginx充当Web Service, PHP-FPM维护一个进程池去运行Web项目。

对比更古老的CGI模型,PHP-FPM已经引入了进程常驻的概念，避免每次请求建立并销毁进程的开销以及拓展加载的开销，可是每一个请求仍然要执行PHP RINIT 与 RSHUTDOWN 之间的全部流程，包括从新加载一次框架源码以及项目代码，形成极大的性能浪费。

这种模型的优势是简单成熟和稳定，一次运行随后销毁 带来的开发便捷性是PHP可以流行起来的缘由之一。市面上绝大多数PHP项目使用的都是基于该种架构的变体。

LNMP-with-Swoole 是 LNMP的一种变体，其在LNMP的基础上引入了Swoole组件。
和PHP-FPM同样，Swoole有一套本身的进程管理机制。但因为代码变得高度常驻和编程思惟须要从同步到异步的转变，因此Swoole和传统的基于PHP-FPM的Web框架亲和度很低,即便是适配升级过的老式Web框架，目前在Swoole上运行的表现每每并很差。

所以出现了这在这种折中方案，并无直接将原有PHP代码运行在Swoole中，而是使用Swoole搭建了一个服务，系统经过接口与Swoole通讯，从而为Web项目补充了异步处理的能力。我称呼这种同时使用PHP-FPM和Swoole的系统为 半Swoole应用。由于接入简单，因此是绝大多数现有项目优先考虑的Swoole接入方案。

LNMP-with-Swoole模型虽然引入了Swoole和异步处理能力，可是核心仍是PHP-FPM，实际上还远远没有发挥出Swoole的真正优点。

Swoole-HTTP-Server和LNMP-with-Swoole相比有巨大的变化,这种模型中充当Web Server角色的构件不只仅有Nginx，应用自己也包含了一个内建Web Server,不过因为Swoole Http Server不是专业的HTTP Server，对Http的处理不完善 ，所以仍然须要使用Nginx做为静态资源服务器以及反代，Swoole HTTP Server仅仅处理PHP相关的HTTP流量。

一方面因为Swoole已经包含了WebServer，再也不须要实现CGI或者Fast-CGI的通用协议去和Web Server通讯，另外一方面Swoole有本身的进程管理，所以PHP-FPM能够直接被去除了。对于PHP资源而言，在这种模型中,Swoole Http Server的地位至关于传统模型中的Nginx和PHP-FPM之和。

一次加载常驻内存，不一样的请求间基本上复用了onRequest之外的全部流程，使得每一个请求的开销大大下降；异步IO的特性使得这种模型吞吐量远远高于传统的LNMP模型。另外相对于独立的Swoole服务，内嵌在Web系统中的Swoole使用更加的直接方便，支持更好。

Swoft 和 Swoole 的关系是什么 ?

1. Swoole是一个异步引擎,核心是为PHP提供异步IO执行的能力，同时提供一套异步编程可能会用到的工具集。
2. Swoole-HTTP-Server是Swoole的一个组件，是SwooleServer中的一种，提供了一个适合Swoole直接运行的HttpServer环境。
3. Swoft一个现代的Web框架，和Swoole亲和性高，同时也是上面提到的Swoole-HTTP-Server模型的一个实践。

Swoft管理着该Web模型中的Swoole,以及Swoole-HTTP-Server，对开发者屏蔽Swoole的种种复杂操做细节，并做为一个Web框架向开发者提供各类Web开发须要用到的路由，MVC，数据库访问等功能组件等。

Swoft 是如何使用 Swoole 的 ?

最核心的就是HttpServer以及RpcServer

HTTP 服务器

Swoft直接使用的是Swoole内建的\Swoole\Http\Server，它已经处理好全部HTTP层面的全部东西，咱们只须要关注应用自己,咱们来看一下HTTP服务几个重要生命周期点。

Swoole 启动前

这个阶段进行的行为有几个特征

1. 基础bootstrap行为:如必须的常量定义，Composer加载器引入，配置读取等；
2. 须要生成被全部Worker/Task进程共享的程序全局期的对象,如Swoole\Lock,Swoft\Memory\Table的建立；
3. 启动时，全部进程中合计只能执行一次的操做：如前置Process的启动；
4. Bean容器基本初始化，以及项目启动流程须要的coreBean的加载。

这块涉及东西比较杂，为控制篇幅后续用单独文章介绍。

和Http服务关系最密切的进程是Swoole中的Worker进程(组)，绝大部分业务处理都在该进程中进行。
对于每一个Swoole事件，Swoft都提供了对应的Swoole监听器(对应@SwooleListener注解)做为事件机制的封装。要理解Swoft的HttpServer是如何在Swoole下运行的咱们重点须要关注下两个在两个Swoole事件swoole.workerStart和swoole.onRequest。

swoole.workerStart 事件

WorkerStart事件在TaskWorker/Worker进程启动时发生，每一个TaskWorker/Worker进程里都会执行一次。
这是个关键节点，由于swoole.workerStart回调以后新建的对象都是进程全局期的，使用的内存都属于特定的Task/Worker进程，相互独立。也只有在这个阶段或之后初始化的部分才是能够被热重载的。
事件底层关键代码以下：

// Swoft\Bootstrap\Server\ServerTrait.php
/**
 * @param bool $isWorker
 * @throws \InvalidArgumentException
 * @throws \ReflectionException
 */
protected function reloadBean(bool $isWorker)
{
    BeanFactory::reload();
    $initApplicationContext = new InitApplicationContext();
    $initApplicationContext->init();

    if($isWorker && $this->workerLock->trylock() && env('AUTO_REGISTER', false)){
        App::trigger(AppEvent::WORKER_START);
    }
}

这里作的事情有3点

1. 初始化Bean容器:
   上文中的BeanFactory::reload();就是Swoft的Bean容器初始化入口，注解的扫描也是在此处进行（实际上这个说法并不许确，Bean容器真正的初始化阶段在Swoole Server启动前的BootStrap阶段就已经进行了，只不过那时进行的是少部分初始化，相对swoole.workerStart中的初始化的Bean数量，比重很小）。在workerStart中初始化Bean容器是Swoft能够热更新代码的基础。
2. 初始化的应用上下文
   initApplicationContext->init()会注册Swoft事件监听器（对应@Listener）,方便用户处理Swoft应用自己的各类钩子。随后触发一个swoft.applicationLoader事件,各组件经过该事件进行配置文件加载,HTTP/RPC路由注册。
3. 服务注册
   具体内容会在服务治理章节讲述。

swoole.onRequest 事件

每一个HTTP请求到来时仅仅会触发swoole.onRequest事件。
框架代码自己都是由大量进程全局期和少许程序全局期的对象构成,而onReceive中建立的对象譬如$request和$response都是请求期的，随着HTTP请求的结束而回收。

事件底层关键代码以下：

/**
 * @param array ...$params
 * @return \Psr\Http\Message\ResponseInterface
 * @throws \InvalidArgumentException
 */
public function dispatch(...$params): ResponseInterface
{
    /**
     * @var RequestInterface $request
     * @var ResponseInterface $response
     */
    list($request, $response) = $params;

    try {
        // before dispatcher
        $this->beforeDispatch($request, $response);

        // request middlewares
        $middlewares = $this->requestMiddleware();
        $request = RequestContext::getRequest();
        $requestHandler = new RequestHandler($middlewares, $this->handlerAdapter);
        $response = $requestHandler->handle($request);

    } catch (\Throwable $throwable) {
        /* @var ErrorHandler $errorHandler */
        $errorHandler = App::getBean(ErrorHandler::class);
        $response = $errorHandler->handle($throwable);
    }

    $this->afterDispatch($response);

    return $response;
}

1. beforeDispatch($request, $response):
   设置请求上下文，并触发一个swoft.beforeRequest事件。
2. RequestHandler->handle($request):
   执行各个 中间件 和请求对应的 Action，具体处理能够参考RPC章节，原理基本相同。
3. $afterDispatch($response):
   整理HTTP响应报文发送客户端并触发swoft.resourceRelease（详情在链接池一文中说起）事件和swoft.afterRequest事件

总的来讲，纵观这几个生命周期点你须要搞清楚几件事：

1. Swoole的Worker进程是你绝大多数HTTP服务代码的运行环境。
2. 一部分初始化和加载操做在Swoole的Server启动前完成，一部分在swoole.workerStart事件回调中完成，前者没法热重载但可能被多个进程共享。
3. 初始化代码只会在系统启动和Worker/Task进程启动时执行一次， 不像PHP-FPM每次请求都会执行一次，框架对象也不像PHP-FPM会随请求返回而销毁。
4. 每次请求都会触发一次swoole.onRequest事件，里面就是咱们的请求处理代码真正运行的地方，只有这事件内产生的对象才会在请求结束时被回收。

RPC服务器

生命周期和HTTP服务基本一致，详情参考《Swoft源码剖析-RPC功能实现》