摘要：和服務(wù)關(guān)系最密切的進(jìn)程是中的進(jìn)程組，絕大部分業(yè)務(wù)處理都在該進(jìn)程中進(jìn)行。隨后觸發(fā)一個事件各組件通過該事件進(jìn)行配置文件加載路由注冊。事件每個請求到來時僅僅會觸發(fā)事件。服務(wù)器生命周期和服務(wù)基本一致，詳情參考源碼剖析功能實現(xiàn)

作者：bromine
鏈接：https://www.jianshu.com/p/4c0...
來源：簡書
著作權(quán)歸作者所有，本文已獲得作者授權(quán)轉(zhuǎn)載，并對原文進(jìn)行了重新的排版。
Swoft Github: https://github.com/swoft-clou...

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

Swoft在PHPer圈中是一個門檻較高的Web框架，不僅僅由于框架本身帶來了很多新概念和前沿的設(shè)計，還在于Swoft是一個基于Swoole的框架。Swoole在PHPer圈內(nèi)學(xué)習(xí)成本最高的工具沒有之一，雖然Swoft的出現(xiàn)降低了Swoole的使用成本，但如果你對Swoole本身了解不夠深入，仍然很難避免栽進(jìn)種種"坑"中。

考慮到這個現(xiàn)狀，也為降低閱讀難度，后續(xù)幾個和Swoole聯(lián)系較為密切的機制，筆者會調(diào)整寫作思路，將文章的定位從 「幫助讀者深入理解Swoft」 調(diào)整為 「幫助讀者理解Swoft和Swoole」，敘述節(jié)奏也會放慢。

LNMP和LAMP是絕大多數(shù)PHPer最熟悉的基礎(chǔ)Web架構(gòu)，這里以常見的LNMP作為例子描述一個常見 無Swoole應(yīng)用的構(gòu)件組成：Nginx充當(dāng)Web Service, PHP-FPM維護(hù)一個進(jìn)程池去運行Web項目。

對比更古老的CGI模型,PHP-FPM已經(jīng)引入了進(jìn)程常駐的概念，避免每次請求創(chuàng)建并銷毀進(jìn)程的開銷以及拓展加載的開銷，但是每個請求仍然要執(zhí)行PHP RINIT 與 RSHUTDOWN 之間的所有流程，包括重新加載一次框架源碼以及項目代碼，造成極大的性能浪費。

這種模型的優(yōu)點是簡單成熟和穩(wěn)定，一次運行隨后銷毀 帶來的開發(fā)便捷性是PHP能夠流行起來的原因之一。市面上絕大多數(shù)PHP項目使用的都是基于該種架構(gòu)的變體。

LNMP-with-Swoole 是 LNMP的一種變體，其在LNMP的基礎(chǔ)上引入了Swoole組件。
和PHP-FPM一樣，Swoole有一套自己的進(jìn)程管理機制。但由于代碼變得高度常駐和編程思維需要從同步到異步的轉(zhuǎn)變，所以Swoole和傳統(tǒng)的基于PHP-FPM的Web框架親和度很低,即使是適配升級過的老式Web框架，目前在Swoole上運行的表現(xiàn)往往并不好。

因此出現(xiàn)了這在這種折中方案，并沒有直接將原有PHP代碼運行在Swoole中，而是使用Swoole搭建了一個服務(wù)，系統(tǒng)通過接口與Swoole通信，從而為Web項目補充了異步處理的能力。我稱呼這種同時使用PHP-FPM和Swoole的系統(tǒng)為 半Swoole應(yīng)用。因為接入簡單，所以是絕大多數(shù)現(xiàn)有項目優(yōu)先考慮的Swoole接入方案。

LNMP-with-Swoole模型雖然引入了Swoole和異步處理能力，但是核心還是PHP-FPM，實際上還遠(yuǎn)遠(yuǎn)沒有發(fā)揮出Swoole的真正優(yōu)勢。

Swoole-HTTP-Server和LNMP-with-Swoole相比有巨大的變化,這種模型中充當(dāng)Web Server角色的構(gòu)件不僅僅有Nginx，應(yīng)用本身也包含了一個內(nèi)建Web Server,不過由于Swoole Http Server不是專業(yè)的HTTP Server，對Http的處理不完善 ，因此仍然需要使用Nginx作為靜態(tài)資源服務(wù)器以及反代，Swoole HTTP Server僅僅處理PHP相關(guān)的HTTP流量。

一方面由于Swoole已經(jīng)包含了WebServer，不再需要實現(xiàn)CGI或者Fast-CGI的通用協(xié)議去和Web Server通信，另一方面Swoole有自己的進(jìn)程管理，因此PHP-FPM可以直接被去除了。對于PHP資源而言，在這種模型中,Swoole Http Server的地位相當(dāng)于傳統(tǒng)模型中的Nginx和PHP-FPM之和。

一次加載常駐內(nèi)存，不同的請求間基本上復(fù)用了onRequest以外的所有流程，使得每個請求的開銷大大降低；異步IO的特性使得這種模型吞吐量遠(yuǎn)遠(yuǎn)高于傳統(tǒng)的LNMP模型。另外相對于獨立的Swoole服務(wù)，內(nèi)嵌在Web系統(tǒng)中的Swoole使用更加的直接方便，支持更好。

Swoole是一個異步引擎,核心是為PHP提供異步IO執(zhí)行的能力，同時提供一套異步編程可能會用到的工具集。

Swoole-HTTP-Server是Swoole的一個組件，是SwooleServer中的一種，提供了一個適合Swoole直接運行的HttpServer環(huán)境。

Swoft一個現(xiàn)代的Web框架，和Swoole親和性高，同時也是上面提到的Swoole-HTTP-Server模型的一個實踐。

Swoft管理著該Web模型中的Swoole,以及Swoole-HTTP-Server，對開發(fā)者屏蔽Swoole的種種復(fù)雜操作細(xì)節(jié)，并作為一個Web框架向開發(fā)者提供各種Web開發(fā)需要用到的路由，MVC，數(shù)據(jù)庫訪問等功能組件等。

最核心的就是HttpServer以及RpcServer

Swoft直接使用的是Swoole內(nèi)建的SwooleHttpServer，它已經(jīng)處理好所有HTTP層面的所有東西，我們只需要關(guān)注應(yīng)用本身,我們來看一下HTTP服務(wù)幾個重要生命周期點。

這個階段進(jìn)行的行為有幾個特征

基礎(chǔ)bootstrap行為:如必須的常量定義，Composer加載器引入，配置讀取等；

需要生成被所有Worker/Task進(jìn)程共享的程序全局期的對象,如SwooleLock,SwoftMemoryTable的創(chuàng)建；

啟動時，所有進(jìn)程中合計只能執(zhí)行一次的操作：如前置Process的啟動；

Bean容器基本初始化，以及項目啟動流程需要的coreBean的加載。

這塊涉及東西比較雜，為控制篇幅后續(xù)用多帶帶文章介紹。

和Http服務(wù)關(guān)系最密切的進(jìn)程是Swoole中的Worker進(jìn)程(組)，絕大部分業(yè)務(wù)處理都在該進(jìn)程中進(jìn)行。
對于每個Swoole事件，Swoft都提供了對應(yīng)的Swoole監(jiān)聽器(對應(yīng)@SwooleListener注解)作為事件機制的封裝。要理解Swoft的HttpServer是如何在Swoole下運行的我們重點需要關(guān)注下兩個在兩個Swoole事件swoole.workerStart和swoole.onRequest。

WorkerStart事件在TaskWorker/Worker進(jìn)程啟動時發(fā)生，每個TaskWorker/Worker進(jìn)程里都會執(zhí)行一次。
這是個關(guān)鍵節(jié)點，因為swoole.workerStart回調(diào)之后新建的對象都是進(jìn)程全局期的，使用的內(nèi)存都屬于特定的Task/Worker進(jìn)程，相互獨立。也只有在這個階段或以后初始化的部分才是可以被熱重載的。
事件底層關(guān)鍵代碼如下：

// SwoftBootstrapServerServerTrait.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點

初始化Bean容器:
上文中的BeanFactory::reload();就是Swoft的Bean容器初始化入口，注解的掃描也是在此處進(jìn)行（實際上這個說法并不準(zhǔn)確，Bean容器真正的初始化階段在Swoole Server啟動前的BootStrap階段就已經(jīng)進(jìn)行了，只不過那時進(jìn)行的是少部分初始化，相對swoole.workerStart中的初始化的Bean數(shù)量，比重很?。?。在workerStart中初始化Bean容器是Swoft可以熱更新代碼的基礎(chǔ)。

初始化的應(yīng)用上下文
initApplicationContext->init()會注冊Swoft事件監(jiān)聽器（對應(yīng)@Listener）,方便用戶處理Swoft應(yīng)用本身的各種鉤子。隨后觸發(fā)一個swoft.applicationLoader事件,各組件通過該事件進(jìn)行配置文件加載,HTTP/RPC路由注冊。

服務(wù)注冊
具體內(nèi)容會在服務(wù)治理章節(jié)講述。

每個HTTP請求到來時僅僅會觸發(fā)swoole.onRequest事件。
框架代碼本身都是由大量進(jìn)程全局期和少量程序全局期的對象構(gòu)成,而onReceive中創(chuàng)建的對象譬如$request和$response都是請求期的，隨著HTTP請求的結(jié)束而回收。

事件底層關(guān)鍵代碼如下：

/**
 * @param array ...$params
 * @return PsrHttpMessageResponseInterface
 * @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;
}

beforeDispatch($request, $response):
設(shè)置請求上下文，并觸發(fā)一個swoft.beforeRequest事件。

RequestHandler->handle($request):
執(zhí)行各個 中間件 和請求對應(yīng)的 Action，具體處理可以參考RPC章節(jié)，原理基本相同。

$afterDispatch($response):
整理HTTP響應(yīng)報文發(fā)送客戶端并觸發(fā)swoft.resourceRelease（詳情在連接池一文中提及）事件和swoft.afterRequest事件

總的來說，縱觀這幾個生命周期點你需要搞清楚幾件事：

Swoole的Worker進(jìn)程是你絕大多數(shù)HTTP服務(wù)代碼的運行環(huán)境。

一部分初始化和加載操作在Swoole的Server啟動前完成，一部分在swoole.workerStart事件回調(diào)中完成，前者無法熱重載但可能被多個進(jìn)程共享。

初始化代碼只會在系統(tǒng)啟動和Worker/Task進(jìn)程啟動時執(zhí)行一次， 不像PHP-FPM每次請求都會執(zhí)行一次，框架對象也不像PHP-FPM會隨請求返回而銷毀。

每次請求都會觸發(fā)一次swoole.onRequest事件，里面就是我們的請求處理代碼真正運行的地方，只有這事件內(nèi)產(chǎn)生的對象才會在請求結(jié)束時被回收。

生命周期和HTTP服務(wù)基本一致，詳情參考《Swoft源碼剖析-RPC功能實現(xiàn)》