前言

workerman v5在經(jīng)歷了幾年的開發(fā)和測試，于2025年元旦正式發(fā)布，webman開發(fā)框架及眾多周邊插件也緊隨其后更新兼容了v5版本；作為PHP界老牌的網(wǎng)絡(luò)容器，workerman的穩(wěn)定性及易用性毋庸置疑，常駐內(nèi)存的運(yùn)行模式、多進(jìn)程、多協(xié)議支持等高性能高效率的特性讓許多PHPer接觸到了之前不曾觸摸過的技術(shù)方向；那么v5版本相較于之前版本給開發(fā)者帶來了什么比較明顯且用的上的特性呢？

• 以revolt/event-loop為基建的事件驅(qū)動(dòng)庫
• 兼容多方協(xié)程實(shí)現(xiàn)的協(xié)程功能

以上是變化較大且意義重大的特性，除此之外還有許多的優(yōu)化內(nèi)容及特性升級，請參考官方文檔

“前生”

我個(gè)人一直認(rèn)為所謂‘協(xié)程’其實(shí)是至少包含了上下文管理、協(xié)程調(diào)度器、協(xié)程執(zhí)行器三部分的完整方案，在沒有Fiber之前，原生PHP中其實(shí)已經(jīng)有了無棧協(xié)程的相關(guān)實(shí)現(xiàn)，借助yield完成，但不論是Fiber還是yield，都不是完整的‘協(xié)程’，只是和上下文相關(guān)的一些功能而已，并沒有調(diào)度及執(zhí)行兩部分。而非原生PHP中僅有swoole是一套完整的協(xié)程實(shí)現(xiàn)方案，不論是它早期底層類yield的異步還是現(xiàn)如今比較現(xiàn)代化的Coroutine，它們都包含了成熟的事件循環(huán)驅(qū)動(dòng)（調(diào)度/執(zhí)行）和豐富的上下文管理工具。

可能有人會(huì)問了，workerman也有事件循環(huán)驅(qū)動(dòng)，為什么沒有協(xié)程？先說結(jié)論，因?yàn)椴缓霉芾砬疑鷳B(tài)不夠統(tǒng)一，生態(tài)的支持度也不足夠。

在沒有Fiber之前，借助yield來實(shí)現(xiàn)協(xié)程方案需要保存特別特別多的棧上下文，你可以把它們理解為因?yàn)槭謩?dòng)中斷的入?yún)?shù)，他們需要存放在比如靜態(tài)變量（也就是內(nèi)存）中等待下一次的喚醒，喚醒后繼續(xù)從中斷的地方執(zhí)行，再主動(dòng)中斷的這個(gè)過程中，進(jìn)程就可以交給其他的事務(wù)進(jìn)行執(zhí)行，整個(gè)進(jìn)程內(nèi)的所有不同事務(wù)呈現(xiàn)無序的交替運(yùn)行狀態(tài)，就像是我們?nèi)嗽诠ぷ鞯臅r(shí)候時(shí)不時(shí)去上個(gè)廁所、接杯咖啡，回來繼續(xù)工作；

Fiber其實(shí)也類似，只不過它并沒有像yield一樣直接返回暫停時(shí)的棧上下文，而是主動(dòng)保存在一個(gè)特定的地方自行管理，這樣就省去了自行使用內(nèi)存管理的問題，簡化了操作，在我每一次歸來后無需再翻看我的記事本查看我到底寫到那里了，而是直接就可以銜接。

workerman之前也有利用yield+promise包做的異步方案，但都要進(jìn)行很多侵入式的改造，代價(jià)大于收益。

“今世”

workerman v5基于revolt/event-loop作為事件驅(qū)動(dòng)引擎，一方面是由此引入Fiber，一方面是減少目前PHP開發(fā)中過多的事件驅(qū)動(dòng)引擎的分化問題，另外還兼容了swow、swoole的事件驅(qū)動(dòng)引擎，是支持中國本土化的內(nèi)容，另外本質(zhì)上也是為了減少分化和加強(qiáng)協(xié)程的引入；就此，在workerman v5中就可以使用以上三種驅(qū)動(dòng)的協(xié)程方案。

那么協(xié)程能干什么呢？

假設(shè)一個(gè)場景，我們需要?jiǎng)?chuàng)建一個(gè)異步導(dǎo)出任務(wù)，這個(gè)異步導(dǎo)出任務(wù)可能的實(shí)現(xiàn)方式就會(huì)是：

開源技術(shù)小棧

• 前端請求接口 -> 接口創(chuàng)建任務(wù) -> 將任務(wù)投遞至消息隊(duì)列
• 消息隊(duì)列消費(fèi)導(dǎo)出 -> 修改任務(wù)狀態(tài)
• 前端輪詢查詢?nèi)蝿?wù)狀態(tài)及下載連接

而有了協(xié)程我們可以實(shí)現(xiàn)以下兩種方案：

1.  自輪詢消費(fèi)（查詢數(shù)據(jù)如果使用阻塞方法還是會(huì)阻塞）

public function test(): Response
{
    $id = 'your_file_id';
    // 根據(jù)請求參數(shù)獲取分片數(shù)量
    $count = YourData::getShardingCount($request = request()->all());
    for ($i = 0; $i < $count; $i++) {
        // 分片獲取數(shù)據(jù)
        if ($data = YourData::getListBySharding($request, $i)) {
            // 導(dǎo)出追加
            YourExcel::append($id, $data);
        }
        // 協(xié)程隨機(jī)出讓1-10 ms
        Timer::sleep(rand(1, 10) / 1000);
    }

    return new Response(200, body: json_encode(YourExcel::getUrl($id)));
}

2.  自輪詢查詢方式

public function test(): Response
{
    $id = 'your_file_id';
    // 發(fā)布至消息隊(duì)列
    YourMessageMQ::publish($id, $request = request()->all());
    while (1) {
        // 查詢消息隊(duì)列消費(fèi)情況
        if (YourMessageMQ::isComplete($id)) {
            break;
        }
        // 協(xié)程隨機(jī)出讓1-10 ms
        Timer::sleep(rand(1, 10) / 1000);
    }

    return new Response(200, body: json_encode(YourMessageMQ::getReturn($id)));
}

以上兩種方式都不會(huì)特別的阻塞當(dāng)前進(jìn)程而實(shí)現(xiàn)一個(gè)長輪詢接口，避免了前端短輪詢的資源消耗問題；類似SSE的實(shí)現(xiàn)方式也會(huì)更簡單一些，只需要利用Timer::sleep主動(dòng)出讓當(dāng)前協(xié)程控制權(quán)給事件驅(qū)動(dòng)引擎就可以，而且這樣的好處是既保留了PHP系統(tǒng)層面的CPU控制權(quán)出讓sleep/usleep又提供了事件驅(qū)動(dòng)控制權(quán)的出讓，區(qū)別于Swow和Swoole對系統(tǒng)函數(shù)的hook改造，但缺點(diǎn)又是無法改變已經(jīng)存在的阻塞式函數(shù)的阻塞調(diào)用邏輯。

“來世”

因?yàn)镻HP的協(xié)程方案是單線程的，同一時(shí)刻只能運(yùn)行一個(gè)任務(wù)，所以需要在事件循環(huán)內(nèi)盡可能地non-blocking出讓控制權(quán)，才可能讓事件循環(huán)驅(qū)動(dòng)在有限的時(shí)間內(nèi)執(zhí)行更多的任務(wù)；而目前PHP生態(tài)大多數(shù)的組件工具都是blocking的，協(xié)程所能覆蓋的業(yè)務(wù)范圍很窄，現(xiàn)存的很多協(xié)程組件并不能照顧大部分開發(fā)者的情緒，所以我真的希望在未來，PHP能夠涌現(xiàn)更多的開發(fā)者來貢獻(xiàn)協(xié)程相關(guān)的生態(tài)，而不是分裂，希望在有限的時(shí)間和空間內(nèi)，看到這門歷史不算太久的老編程語言能夠煥發(fā)青春。