关于PHP8.1的FiberRFC

最新的 PHP 8.1 增加了一个 Fiber 的提案&＃xff0c;最近讨论的比较多。有不少好事者拿来说事儿&＃xff0c;说是 “Fiber 进入内核之后&＃xff0c;Swoole 的使用者就大幅减少“

实际上 Fiber 扩展进入内核后&＃xff0c;由于它是一个非常底层的 API &＃xff0c;并不是直接可以使用的技术&＃xff0c;不会对 Swoole 产生影响。真正和 Swoole 竞争的是应该是 Amphp 、ReactPHP 。Fiber 反而对 Swoole 是有好处的&＃xff0c;PHP 内核开发者维护了协程切换的全局状态列表&＃xff0c;Swoole PHPCoroutine 这部分的代码实现就变简单了。另外&＃xff0c;其他扩展也会注意到协程的存在&＃xff0c;使用 C 全局变量或栈上内存时考虑到协程切换的可能性&＃xff0c;避免出现 Crash。ext-fiber 合并进来之后&＃xff0c;也应标记为 alpha 状态&＃xff0c;一些特殊情况能会引起崩溃&＃xff0c;需要比较长的时间去收集解决这些问题。

最近这几年即便官方连续出了很多个大版本&＃xff0c;PHP 还是一直是在走下坡路。有许多 PHP 开发者说是因为 PHP 性能不行&＃xff0c;没有 JIT。于是 PHP8.0 加入了 JIT。还有人说 PHP 没有协程&＃xff0c;所以 PHP8.1 要加入 Fiber。马上就会有人说 PHP 缺少多线程&＃xff0c;按照现在这个节奏&＃xff0c;可以预见未来有可能 PHP 的多线程扩展 parallels 也会合并到内核。PHP8 还加入了一个 FFI 模块&＃xff0c;甚至可以直接使用 PHP 调用 C 库。

可是真的加入如此多的能力&＃xff0c;PHP 就得到很大的改变了吗&＃xff1f;

你们想要的 Fiber 是这样的&＃xff1a;

实际上 PHP 8.1 Fiber 是这样的&＃xff1a;

动态语言中除了 PHP 之外&＃xff0c;Python、Ruby、Lua 在很早就有协程支持了&＃xff0c;但实际上这些编程语言在协程并发编程方面并没有多出色。真正将协程技术发扬光大的是 Golang &＃xff0c;为什么 Golang 在协程编程方面的如此成功&＃xff1f;这是因为它提供了完整的、成体系的一整套技术方案&＃xff0c;从语言设计到编译器、协程调度器、标准库、调试器&＃xff0c;这才是工业级的技术。在多线程技术方向&＃xff0c;很多编程语言都有多线程支持&＃xff0c;但真正被广泛使用、达到工业级水平的多线程系统只有 Java 。在 PHP 中真正能达到工业级水平的技术也就是 Apache&＃43;mod_php 和 PHP-FPM 。

协程的技术也是一样&＃xff0c;PHP 开发者想要从传统的 LAMP/LNMP 短生命周期、串行编程的模式转型到 CSP 协程&＃43;通道并发编程&＃xff0c;目前暂时也只有 Swoole 是相对来说最成熟的方案。用户真正需要的是一种完整的、系统性、成体系、简单易用、可靠的一整套技术方案。

PHP 8.1 加入 Fiber 我认为是一个仓促的决定。不如系统性地设计一下&＃xff0c;从这些7个方面考虑&＃xff1a;

• EventLoop API
• 协程&＃xff08;对应 ext-fiber&＃xff09;
• IO 调度器&＃xff08;Socket/FileSystem/ChildProcess/Signal/Timer/Stdout/Stdin&＃xff09;
• CPU 调度器
• 现有同步阻塞 IO 扩展&＃xff08;redis、curl、php_stream、sockets、mysqli、pdo_mysql
  等&＃xff09;和内置函数&＃xff08;sleep、shell_exec、sleep、gethostbyname 等&＃xff09;如何实现支持协程&＃xff0c;变成异步非阻塞模式
• 协程通信&＃xff08;channel&＃xff09;
• 服务器&＃xff1a;实现 PHP-FPM 协程版&＃xff0c;或者提供一个新的协程 HttpServer

事件循环

EventLoop 是协程实现中最核心的基础设施&＃xff0c;这里不是指具体实现&＃xff0c;C 层面 select/epoll/poll &＃xff0c;PHP 层面 stream_select 或者 libevent/libuv/event 扩展都可以实现&＃xff0c;如果 ZendVM 底层提供了 EventLoop&＃xff0c;那么不同的框架、不同的库可以在同一个 Loop 中&＃xff0c;协程调度器也可以构建在此之上。如果没有统一的 EventLoop 的基础设施&＃xff0c;amphp 、 reactphp 等框架都需要各自实现&＃xff0c;意味着你在使用 amphp 的程序时&＃xff0c;无法使用 reactphp 实现的任何类库。

Node.js、Golang、Swoole 底层都有一个全局的 EventLoop&＃xff0c;所有 IO 行为都会被注册到 EventLoop 中&＃xff0c;事件触发后执行 callback 或者调度协程。

阻塞 IO 函数

PHP 提供的很多 IO 操作函数都是阻塞的&＃xff0c;如果在协程中发生阻塞&＃xff0c;就会导致并发失效。退化成和普通 PHP-FPM 一样的串行模式。协程实现中必须要考虑到如何解决这个问题。

Amphp 和 ReactPHP 目前&＃xff08;2021年&＃xff09;采用的实现方式&＃xff0c;是使用 PHP 代码实现基于协程的异步非阻塞 IO 版本&＃xff0c;在 2018 年之前 Swoole 也是采用这个模式。这样做最大的问题是&＃xff0c;

• 成本太高&＃xff0c;无法复用 PHP 生态&＃xff0c;重复造轮子&＃xff0c;需要重新实现 Redis、MySQL、CURL、Http2、WebSocket、Kafka等大量网络 IO 库
• 质量不高&＃xff0c;不像同步阻塞的版本经过大规模验证
• 兼容性差&＃xff0c;如果用户使用了一个第三方库&＃xff0c;其中包含了阻塞 IO 的客户端调用&＃xff0c;就前功尽弃了
• 学习成本高&＃xff0c;用户需要学习一套全新的 API &＃xff0c;这对 PHP 开发者非常不友好
• PHP 实现的版本可能还会存在性能问题&＃xff0c;在 Swoole 中由于是使用 C 实现的不存在这一点

所以 Swoole 在 4.1 版本&＃xff08;2018年&＃xff09;开始采用了全新的实现方式&＃xff0c;会 Hook 掉 PHP 扩展中的函数指针&＃xff0c;通过很少的工作量就彻底解决了这个问题。PHP 开发者直接使用同步阻塞客户端的 API 即可&＃xff0c;底层会自动替换为非阻塞的协程版本。比如下面的代码

Swoole 会替换 PHP 内置的 sleep 和 file_get_contents 函数&＃xff0c;变成协程版本&＃xff0c;上面的程序就变成了完全并发的了&＃xff0c;对用户来说是无感知的。

CPU 调度器

由于 PHP 是动态解释执行的编程语言&＃xff0c;在实现协程 CPU 调度器方面比 Golang 有优势。Golang 需要在编译器内做很多工作&＃xff0c;控制单个协程占用的 CPU 时间&＃xff0c;避免几个协程耗尽 CPU 资源。PHP 可以在 VM 层面直接实现中断&＃xff0c;精准控制每个协程最大可执行的时间。

Golang 使用 GPM 模型解决了这个问题&＃xff0c;如果一部分协程持续占用 CPU &＃xff0c;调度器会创建更多 Thread 执行新的任务&＃xff0c;退化为操作系统调度。PHP 由于不支持多线程&＃xff0c;暂时无法实现 GPM 模型&＃xff0c;目前 Swoole 所采作用的 VM 中断调度实现是最优解

在 Swoole 的实现中&＃xff0c;底层创建了一个中断线程&＃xff0c;每 5ms 会产生一个中断信号&＃xff0c;在中断函数中判断当前协程执行的时长&＃xff0c;如果超过了规定的 10ms 最大执行时间&＃xff0c;会自动让出 CPU 切换至其他可执行的协程。

以上程序会交替执行&＃xff0c;每个协程最大执行时间不超过 10ms

我认为正确的方式

创建多个 RFC &＃xff0c;把这些问题讨论清楚&＃xff0c;在 PHP9 版本中提供完整的协程方案实现。不求做到 Golang 的程度&＃xff0c;至少要能达到生产可用。这样 PHP 才会有大的改变。不过这可能就真要取代 Swoole 了 [哭笑]。

再介绍一下 Swoole 现在做到什么程度&＃xff1a;

• 完整的协程&＃43;通道实现
• 提供了 CPU 调度器&＃xff0c;即使是密集计算的程序&＃xff0c;也可以使用协程&＃xff0c;调度器会按照10ms时间片切换协程
• 支持绝大部分 PHP 的常用扩展和内置函数&＃xff0c;LAMP 时代的代码可以不用修改直接 copy
  到协程里运行&＃xff0c;而且是异步非阻塞的方式&＃xff0c;是真正的并发&＃xff0c;我认为这才是黑科技&＃xff0c;PHP 协程方案的关键技术
• curl 扩展也可以协程化&＃xff0c;包括 curl 和 curl_multi&＃xff0c;guzzle 可以直接用&＃xff0c;腾讯云、阿里云的 PHP SDK
  可以直接在协程中使用
• 提供了 PGSQL 协程实现&＃xff0c;基于 pgsql 官方 C 库的异步 API 实现
• 提供了 ZooKeeper 协程实现&＃xff0c;是基于官方的 C 库 插入了 Hook 代码实现
• Kafka 协程库的实现
• 支持协程的新一代调试器&＃xff1a;yasd
• 支持 PHP7.2-8.0 所有版本&＃xff0c;ext-fiber 只支持 8.0 以上版本

PHP 作为一个社区驱动的开源项目&＃xff0c;背后没有商业公司支持&＃xff0c;没有 Golang、Java、Node.js(v8) 这样充足的研发资源投入&＃xff0c;需要依赖全世界各地的贡献者提交代码&＃xff0c;在产品化方面还是做的不够好。国内有一些人一直在 diss Swoole 有商业公司&＃xff0c;但正是因为有商业收入&＃xff0c;才保证了我们在 Swoole 开源项目研发上的连续性&＃xff0c;在产品化方面也会做的更好。

我对 Fiber 的担忧

Fiber 集成到 PHP 中之后&＃xff0c;会有很多 PHP 的框架或者类库创建自己的协程方案&＃xff0c;由于 PHP 只提供了 Coroutine Context 的实现&＃xff0c;其他几个方面并没有提供&＃xff0c;在 PHP 生态中将会出现很多流派的 EventLoop、AsyncIO 、NetworkClient 多种多样的实现。就拿 sleep 函数来说&＃xff0c;现在 Amphp 和 ReactPHP 分别叫做 amp\delay 和 react\sleep 。

没有统一的标准&＃xff0c;意味着社区的高度分裂。一旦确定了方向&＃xff0c;技术的发展演进是非常快的&＃xff0c;多样性是一件好事&＃xff0c;但也会带来更多新问题&＃xff0c;再想统一是很困难的一件事情。即便是 Symfony、Laravel 这样处于顶端的 PHP 框架&＃xff0c;也不具备能够 100% 覆盖整个 PHP 生态的能力&＃xff0c;这将走向失控。

基于 Swoole/Swow 的方案&＃xff0c;实际上依旧是 PHP 原先的生态&＃xff0c;大家使用的依然是最熟悉的那些 PHP 函数和库&＃xff0c;异步编程和同步阻塞 IO 编程的生态是一致的。比如在 Swoole 协程中可以直接使用阿里云、腾讯云、AWS 提供的 SDK&＃xff0c;Fiber 生态下情况就会比较复杂。

Swow 是一个从 Swoole 项目中剥离与协程无关特性&＃xff0c;使用 Swoole 协程设计方案的全新实现&＃xff0c;与 php-src 保持一致使用了 C 语言实现&＃xff0c;目前正在准备 RFC 提案&＃xff0c;贡献到 PHP 内核中

Swoole 与 Fiber 的差别

Fiber 只是协程 Context 管理的一种实现&＃xff0c;更像是 Generator 的升级版
Swoole 是完整的协程 Runtime & Framework&＃xff0c;更像是 Golang

Swoole 是否会使用 ext-fiber &＃xff1f;

暂时不会。有两方面的原因&＃xff1a;1. Swoole 的实现是双层协程设计&＃xff0c;底层是 C 协程&＃xff0c;上层是 PHP 协程。而 Fiber 的实现耦合在一起的。Swoole 是内核协程化设计&＃xff0c;在 core 层面对协程操作进行了封装&＃xff0c;外层只需要调用 API 即可&＃xff0c;不需要关心发生阻塞 IO 时协程如何切换&＃xff0c;PHP 层实际上只是 wrapper &＃xff0c;2. Fiber 是以扩展方式加入 PHP 内核的&＃xff0c;并不是 ZendAPI&＃xff0c;地位等同于 curl/mysql 等扩展库。在 PHP 中扩展依赖管理做的很糟糕。处理不好容易出现找不到 符号&＃xff08;symbol not found&＃xff09;&＃xff0c;而 Swoole 同样也是 PHP 的一个扩展&＃xff0c;它与 ext-fiber 是平级关系&＃xff0c;协程是 Swoole 的核心部分&＃xff0c;不太好依赖另外一个库的实现。

当然 Swoole 会对齐 ext-fiber 在 PHP 协程切换部分的代码&＃xff0c;保证一致性。由于 PHP 暂时还未提供 EventLoop 的基础设施&＃xff0c;Swoole 扩展提供的功能和其他基于 ext-fiber 扩展实现的 PHP 协程类库&＃xff0c;不在同一个 Loop 中&＃xff0c;也无法实现共存。

创建 C 协程

创建 PHP 协程

在 PHP 代码中创建协程

我们也会持续关注 ext-fiber &＃xff0c;在未来某个节点&＃xff0c;ext-fiber 足够成熟稳定&＃xff0c;并且迁移到 ZendAPI 中时&＃xff0c;Swoole 也会考虑使用 ext-fiber

点关注&＃xff0c;不迷路

好了各位&＃xff0c;以上就是这篇文章的全部内容了&＃xff0c;能看到这里的人呀&＃xff0c;都是人才。之前说过&＃xff0c;PHP方面的技术点很多&＃xff0c;也是因为太多了&＃xff0c;实在是写不过来&＃xff0c;写过来了大家也不会看的太多&＃xff0c;所以我这里把它整理成了PDF和文档&＃xff0c;如果有需要的可以点这里进阶PHP月薪30k>>>架构师成长路线【视频、面试文档免费获取】