3月8日,PHP 社区发起了将 Fiber RFC 添加到 PHP 的投票,这一举动引起了开发者领域的激烈讨论。
Fiber 作为有栈协程的尝试,对 PHP 的标准化提供了一些新的可能性。按照计划,投票将于 3 月 22 日截止,目前投票的数据情况(截止至3月17日12:00)为 41 票赞同、12 票反对,根据规定,Fiber 很大可能会通过投票从而被添加到 PHP(获得 2/3 的赞成票即可通过)。
但这件事情在开发者领域引起激烈讨论的导火索,是两位投出了反对票 KOL —— PHP 创始人 Rasmus Lerdorf 和 Swoole 创始人韩天峰@matyhtf。
特别是 Swoole 的创始人韩天峰@matyhtf,作为“利益相关人士”,这一张反对票被解读出了意味深长的含义。
Swoole 与 Fiber 的关系
在讨论这张反对票之前,我们要先来了解一下 Fiber 和 Swoole 两个产品。
根据 Fiber RFC 中的描述,Fiber 主要用于为异步 I/O 实现协程,提供了独立栈分配、函数调用的暂停和恢复功,它将作为扩展集成到 PHP 中。
而 Swoole 是一个 PHP 协程框架,为 PHP 提供协程、高性能网络编程支持,并提供了多种通信协议的网络服务器和客户端模块,可以方便快速地实现 TCP/UDP 服务、高性能 Web、WebSocket 服务、物联网、实时通讯、游戏、微服务等,使 PHP 不再局限于传统的 Web 领域。
对这两个产品,韩天峰@matyhtf 也在文章中给出了他认为的差别:
Fiber 只是协程 Context 管理的一种实现,更像是 Generator 的升级版。
Swoole 是完整的协程 Runtime & Framework,更像是 Golang。
Fiber 对 Swoole,有什么威胁?
正如我们开头所说,Fiber 作为有栈协程的尝试,是 PHP 协程标准化的一个进步。Swoole 作为一个先驱者,在推进协程标准化上做得不多。但标准化是 PHP 未来的发展大趋势,如果 Swoole 不能解决标准化的问题,那么 Fiber 的发展必然将获得开发者和社区的支持。
所以 Swoole 的创始人韩天峰@matyhtf,作为“利益相关人士”投出的这一张反对票,对很多开发者来说就“别有意味”,怀疑他是在担心 Fiber 的发展会成为 Swoole 的竞争对手,对之后的商业化道路造成阻碍。
不过 Swoole 创始人韩天峰@matyhtf 也在文章中表示,Fiber 扩展进入内核后不会对 Swoole 产生影响。“Fiber 是一个非常底层的 API,并不是直接可以使用的技术,真正和 Swoole 竞争的是应该是 Amphp、ReactPHP 。”
韩天峰@matyhtf 还提出,在某一些层面Fiber 反而对 Swoole 是有好处的。PHP 内核开发者维护了协程切换的全局状态列表,Swoole PHPCoroutine 这部分的代码实现就变简单了。另外,其他扩展也会注意到协程的存在,使用 C 全局变量或栈上内存时考虑到协程切换的可能性,避免出现 Crash。ext-fiber 合并进来之后,也应标记为 alpha 状态,一些特殊情况能会引起崩溃,需要比较长的时间去收集解决这些问题。
他认为在 PHP 8.1 加入 Fiber 是一个仓促的决定。不如先进行一些系统的设计,比如从以下 7 个方面考虑:
EventLoop API
协程(对应 ext-fiber)
IO 调度器(Socket/FileSystem/ChildProcess/Signal/Timer/Stdout/Stdin)
CPU 调度器
现有同步阻塞 IO 扩展(redis、curl、php_stream、sockets、mysqli、pdo_mysql 等)和内置函数(sleep、shell_exec、sleep、gethostbyname 等)如何实现支持协程,变成异步非阻塞模式
协程通信(channel)
服务器:实现 PHP-FPM 协程版,或者提供一个新的协程 HttpServer
PHP 开发者想要从传统的 LAMP/LNMP 短生命周期、串行编程的模式转型到 CSP 协程+通道并发编程,真正需要的是一种完整的、系统性、成体系、简单易用、可靠的一整套技术方案。因此不如创建多个 RFC ,把这些问题讨论清楚,在 PHP9 版本中提供完整的协程方案实现。不求做到 Golang 的程度,至少要能达到生产可用。这样 PHP 才会有大的改变。
但正如韩天峰@matyhtf 自己所说,这样就真的是要取代 Swoole 了。
普通开发者怎么看?
涉及到编程语言的话题,总能引其开发者的关注,PHP 是不是最好的语言,也是个亦正亦邪的讨论焦点。但无论如何,编程语言或者其他技术都需要随着技术以及社会的发展,进行相应的变化,以跟上时代的潮流。
对于 Swoole,很多开发者认为目前其实已经很有可用性了。但也像很多人指出的那样,更多是一个解决方案、一个框架而不是一种语言特性。可能还需要进一步拆分,大而化小,争取在 9.0 的时候成为一个成熟完备的体系。
而 Fiber 作为一个简单的特性,不管对 Swoole 是敌是友,都为开发者们提供了无限的想象空间,从 php 官方的角度来说,这一特性也属于开发者可以不用,但是不能没有系列。
相信大部分投出支持票的人,并不单单是觉得 Fiber 未来可期,而是觉得“有总比没有强”、“变化的前方是希望”。但目前发出较大声量的两位 KOL 在某些程度上都有一些利益相关,作为普通开发者都在等待一些更加中立、客观的声音。
从目前投票来看,Fiber 提案的通过基本上是板上钉钉的事情,通过之后能带来哪些影响或变化,我们只能拭目以待了。
以上
3月8日,PHP 社区发起了将 Fiber RFC 添加到 PHP 的投票,这一举动引起了开发者领域的激烈讨论。
Fiber 作为有栈协程的尝试,对 PHP 的标准化提供了一些新的可能性。按照计划,投票将于 3 月 22 日截止,目前投票的数据情况(截止至3月17日12:00)为 41 票赞同、12 票反对,根据规定,Fiber 很大可能会通过投票从而被添加到 PHP(获得 2/3 的赞成票即可通过)。
但这件事情在开发者领域引起激烈讨论的导火索,是两位投出了反对票 KOL —— PHP 创始人 Rasmus Lerdorf 和 Swoole 创始人韩天峰@matyhtf。
特别是 Swoole 的创始人韩天峰@matyhtf,作为“利益相关人士”,这一张反对票被解读出了意味深长的含义。
Swoole 与 Fiber 的关系
在讨论这张反对票之前,我们要先来了解一下 Fiber 和 Swoole 两个产品。
根据 Fiber RFC 中的描述,Fiber 主要用于为异步 I/O 实现协程,提供了独立栈分配、函数调用的暂停和恢复功,它将作为扩展集成到 PHP 中。
而 Swoole 是一个 PHP 协程框架,为 PHP 提供协程、高性能网络编程支持,并提供了多种通信协议的网络服务器和客户端模块,可以方便快速地实现 TCP/UDP 服务、高性能 Web、WebSocket 服务、物联网、实时通讯、游戏、微服务等,使 PHP 不再局限于传统的 Web 领域。
对这两个产品,韩天峰@matyhtf 也在文章中给出了他认为的差别:
- Fiber 只是协程 Context 管理的一种实现,更像是 Generator 的升级版。
- Swoole 是完整的协程 Runtime & Framework,更像是 Golang。
Fiber 对 Swoole,有什么威胁?
正如我们开头所说,Fiber 作为有栈协程的尝试,是 PHP 协程标准化的一个进步。Swoole 作为一个先驱者,在推进协程标准化上做得不多。但标准化是 PHP 未来的发展大趋势,如果 Swoole 不能解决标准化的问题,那么 Fiber 的发展必然将获得开发者和社区的支持。
所以 Swoole 的创始人韩天峰@matyhtf,作为“利益相关人士”投出的这一张反对票,对很多开发者来说就“别有意味”,怀疑他是在担心 Fiber 的发展会成为 Swoole 的竞争对手,对之后的商业化道路造成阻碍。
不过 Swoole 创始人韩天峰@matyhtf 也在文章中表示,Fiber 扩展进入内核后不会对 Swoole 产生影响。“Fiber 是一个非常底层的 API,并不是直接可以使用的技术,真正和 Swoole 竞争的是应该是 Amphp、ReactPHP 。”
韩天峰@matyhtf 还提出,在某一些层面Fiber 反而对 Swoole 是有好处的。PHP 内核开发者维护了协程切换的全局状态列表,Swoole PHPCoroutine 这部分的代码实现就变简单了。另外,其他扩展也会注意到协程的存在,使用 C 全局变量或栈上内存时考虑到协程切换的可能性,避免出现 Crash。ext-fiber 合并进来之后,也应标记为 alpha 状态,一些特殊情况能会引起崩溃,需要比较长的时间去收集解决这些问题。
他认为在 PHP 8.1 加入 Fiber 是一个仓促的决定。不如先进行一些系统的设计,比如从以下 7 个方面考虑:
- EventLoop API
- 协程(对应 ext-fiber)
- IO 调度器(Socket/FileSystem/ChildProcess/Signal/Timer/Stdout/Stdin)
- CPU 调度器
- 现有同步阻塞 IO 扩展(redis、curl、php_stream、sockets、mysqli、pdo_mysql 等)和内置函数(sleep、shell_exec、sleep、gethostbyname 等)如何实现支持协程,变成异步非阻塞模式
- 协程通信(channel)
- 服务器:实现 PHP-FPM 协程版,或者提供一个新的协程 HttpServer
PHP 开发者想要从传统的 LAMP/LNMP 短生命周期、串行编程的模式转型到 CSP 协程+通道并发编程,真正需要的是一种完整的、系统性、成体系、简单易用、可靠的一整套技术方案。因此不如创建多个 RFC ,把这些问题讨论清楚,在 PHP9 版本中提供完整的协程方案实现。不求做到 Golang 的程度,至少要能达到生产可用。这样 PHP 才会有大的改变。
但正如韩天峰@matyhtf 自己所说,这样就真的是要取代 Swoole 了。
普通开发者怎么看?
涉及到编程语言的话题,总能引其开发者的关注,PHP 是不是最好的语言,也是个亦正亦邪的讨论焦点。但无论如何,编程语言或者其他技术都需要随着技术以及社会的发展,进行相应的变化,以跟上时代的潮流。
对于 Swoole,很多开发者认为目前其实已经很有可用性了。但也像很多人指出的那样,更多是一个解决方案、一个框架而不是一种语言特性。可能还需要进一步拆分,大而化小,争取在 9.0 的时候成为一个成熟完备的体系。
而 Fiber 作为一个简单的特性,不管对 Swoole 是敌是友,都为开发者们提供了无限的想象空间,从 php 官方的角度来说,这一特性也属于开发者可以不用,但是不能没有系列。
相信大部分投出支持票的人,并不单单是觉得 Fiber 未来可期,而是觉得“有总比没有强”、“变化的前方是希望”。但目前发出较大声量的两位 KOL 在某些程度上都有一些利益相关,作为普通开发者都在等待一些更加中立、客观的声音。
从目前投票来看,Fiber 提案的通过基本上是板上钉钉的事情,通过之后能带来哪些影响或变化,我们只能拭目以待了。
扫码二维码 获取免费视频学习资料
- 本文固定链接: http://phpxs.com/post/7979/
- 转载请注明:转载必须在正文中标注并保留原文链接
- 扫码: 扫上方二维码获取免费视频资料