Swoole 5.0 版本请求意见稿

[twose]

Swoole 5.0 版本请求意见稿

项目方向

Swoole项目从创建至今已经有超过6年的历史了, 但Swoole协程却是一个全新的事物, 随着4.0版本Swoole的有栈协程问世, Swoole的协程化才真正步入了稳定发展阶段.

Swoole从4.0开始一直致力于提升底层代码的稳定性, 不断地做代码精简与优化, 但异步时代的Swoole遗留下来的历史包袱积重难返, 制约了Swoole的进一步发展, 因此我们Swoole开发组决定面对这些历史问题, 做出一个大胆的决定, 从内核中剔除掉一些会导致协程生态混乱的模块, 只保留纯协程的编码模式, 直接提供PHP协程的最佳实践方案, 开发者无需再去纠结于各种复杂繁琐的配置, 甚至在同步, 异步和协程之中迷茫. Swoole后续的生态将完全建立在协程之上, 并且我们会基于5.0版本重新书写文档, 提供Swoole的最佳实践指南, 最大程度减小Swoole开发者的学习成本.

如果你的应用已经完全基于协程实现(如你正在使用Swoft/EasySwoole3等纯协程框架/组件), 那么5.0的改动不会对你造成多少影响.

我将会在下方列出所有涉及删除或改动的内容, 以重要程度优先级排序, 如果你赞同某部分提案, 请点👍 以表明支持

[twose]

删除异步客户端

它们的存在严重的导致了协程生态的混乱, 你不可能在协程中混用它们, 协程可以100%甚至更好的实现异步, 你可以用轻松地用协程写出异步的效果(你只要使用go创建一个协程, 把代码帖进去, 它就是异步的了), 但异步却无法拥有协程强大的调度能力.

• swoole_mysql_client
• swoole_redis_client
• swoole_http_client

暂不考虑删除timer, 异步写文件等, 在很多场景下它们都很有用, 如异步写日志等, 你无需过多思考或者创建新的协程.

[twose]

删除一些无用的异步回调

• onBufferEmpty
• onBufferFull

这两个水位线回调只是在异步时代为了在缓冲区快满时避免发送失败, 增加了大量的心智负担, 你有了协程以后再也不用理会它了, 协程会帮你自动调度.

[twose]

删除同步阻塞TCP客户端

只应用于fpm模式下, 而且底层为此加入了一些环境判断.

[twose]

删除Runtime配置方法和enable_coroutine选项并强制开启

我们要拥抱一个纯协程的生态, 我们就不再需要它们, 就像go语言那样简单纯粹, 既然你使用了Swoole协程, 那么你就要全面启用它, 你的代码里就不应该存在同步阻塞, 否则你写出来的程序将毫无意义.

因此, 协程化将强制开启, 各种事件回调中都会是协程的环境, 而PHP中曾经同步阻塞的一系列IO方法也会变成协程的, 你将不会有太多顾虑, 尽管书写你的协程代码:

• phpredis扩展
• 使用mysqlnd模式的pdo、mysqli扩展，如果未启用mysqlnd将不支持协程化 (PHP默认就是mysqlnd)
• soap扩展
• file_get_contents、fopen等一系列文件函数
• stream_socket_client (和所有基于它实现的库, 如predis)
• stream_socket_server(和所有基于它实现的库)
• fsockopen, gethostbyname(dns查询)
• sleep, usleep, time_nanosleep, time_sleep_until

[twose]

删除不必要的协程环境自动识别

现在的Swoole中, 如果你使用了coroutine_hook, 或是开启了Runtime::enableCoroutine, 在hook同步函数转为协程调度的时候, 底层会判断当前是否为协程环境, 如不是则退化为同步模式, 这一判断兼容完全没有必要, 而且增加了检查开销, 一旦你使用了协程化, 你就应该只在协程中使用它, 否则你的程序会立即退化为同步模式.

[twose]

最大程度地禁止同步阻塞的方法

目前的Runtime::enableStrictMode是一个比较鸡肋的方法, 而且会和Runtime::enableCoroutine冲突, 如实行了上一个提案内容, 那么严格模式也有了用武之地, Swoole内核将会强制开启严格模式, 禁止所有协程之外的阻塞IO操作, 一旦你在不小心使用了阻塞IO, 你的程序将会立即退化为同步模式, 损失大量的性能, 协程也将失去意义.

所以底层将会在开发者使用了协程的时候, 阻止开发者错误地使用阻塞方法, 并在此时抛出一个致命的错误警告.

[twose]

删除Process模式(有争议的内容)

根据Swoole创始人Rango的意见, Process是一个不那么必要的设计, Process模式最大的作用是在worker进程异常退出的时候Master能够保持长连接不断开. 但是Process模式增加了两次IPC开销, 不支持一些高级功能, 其性能相比于Base模式相差巨大(Base简单高效, 能快速承载海量连接), 并且开发者时常在各种投递模式(dispatch_mode)中作无谓的纠结, 且由于Proces模式的复杂性, 它可能会更容易出错.

Process模式完全可以被nginx等专业的代理替代, 并且在对外的生产环境中, nginx总是必须的, 如http服务, swoole只实现了基本的应用服务器级别的协议解析支持, 而nginx则是拥有最为完备的协议解析支持.

就算没有Process模式, Base模式也支持异步安全重启特性和max_request等特性

[twose]

删除Swoole\Serialize

此功能与PHP内核各种设计和数据结构强依赖, 而PHP内核每个版本都有很大变动, 已经无法继续兼容维护各个版本, 且该功能在一些场景下稳定性无法保证, php的serialize十分稳定且能满足绝大部分开发者的需求, 无需为了节省一些小小的内存而去使用Swoole\Serialize.

[twose]

Swoole\Server协程化

目前Swoole协程还是异步化回调模式的, 如果使用了协程模式, 思路就会非常清晰, 而且代码也是如同同步模式一般, 像长连接的tcp协议(如websocket), 可以直接同步顺序书写每个请求的处理代码, 而不是每次都在回调里处理.

$socket = new Swoole\Coroutine\Socket(AF_INET, SOCK_STREAM, IPPROTO_IP); // 创建服务器socket
$socket->bind('127.0.0.1', 9501); // 绑定端口
$socket->listen(128); // 监听并设置backlog大小
while ($conn = $socket->accept()) {
    // 每接收到一个请求, 就创建一个协程去并发地处理它
    go (function () use ($conn) {
        // 打个招呼
        $conn->send(tcp_pack('Hello~'));
        // 先接收TCP包头长度的数据, 解析包长数据, 再接收包长长度的主体数据
        $data = $conn->recv(tcp_length($conn->recv(tcp_type_length())));
        // 打包后原封不动地发回去
        $conn->send(tcp_pack($data));
        // 开始循环接收, 直到超时或者对方关闭了连接
        while ($len = $conn->recv(tcp_type_length(), 1)) {
            $data = $conn->recv($len);
            echo "{$data}\n";
        }
        // 退出循环体就关闭了
        $conn->close();
    });
}

[huangzhhui]

不赞成删除同步阻塞TCP客户端，Swoole的TCP客户端可以与基于Swoole的TCP服务端很好的配合使用，几乎所有非全新项目，都会存在PHP-FPM和Swoole共存的情况，因此保留同步阻塞TCP客户端有必要。

[matyhtf]

@huangzhhui 可以用 php 的 stream_socket_client 来替换。删除同步阻塞的客户端，可以停止对 fpm 的支持。彻底转变为 cli 的扩展。

[youmingdot]

增加协程切换回调

支持设置协程切换回调方法，并在协程切换时进行调用。这个机制能够给予用户或框架更大的自由，以方便在协程切换前，程序能够对本身所设计的上下文进行切换。

以下为示例：

\Swoole\Coroutine::setYieldCallback(function ($leaving, $coming) {
    echo "协程正在切换，切出协程编号：{$leaving}；切入协程编号：{$coming}";
});

[TonyChen-SH]

不支持xdebug，代码怎么读。好像关于调试的便捷性问题，各位大佬好像都不怎么关注。

[niwsmbulai1989]

什么时候可以出一些有关swoole的组件以及demo，那该多好

[bnubobby]

有没有办法加强TCP封包，解包，可做成c扩展的形式，动态调用
目前的形式限制过大，比如通过tcp传过来，json格式的协议（正确的json格式，没有包长度、末尾没有\r\n）没办法解析，xml格式协议也没办法解析，等。
目前的貌似只能通过接收原始数据，把数据根据客户端 fd 放到缓存里，再用php逐字解析？

[sayid]

希望能默认支持更多的客户端

[assert6]

删除Process 的话, 那swoft 的Process 功能要用Task 实现?

[lizhichao]

纯粹，极致，简单，稳定，高效

[onanying]

删除Runtime配置方法和enable_coroutine选项并强制开启

我们要拥抱一个纯协程的生态, 我们就不再需要它们, 就像go语言那样简单纯粹, 既然你使用了Swoole协程, 那么你就要全面启用它, 你的代码里就不应该存在同步阻塞, 否则你写出来的程序将毫无意义.

因此, 协程化将强制开启, 各种事件回调中都会是协程的环境, 而PHP中曾经同步阻塞的一系列IO方法也会变成协程的, 你将不会有太多顾虑, 尽管书写你的协程代码:

• phpredis扩展
• 使用mysqlnd模式的pdo、mysqli扩展，如果未启用mysqlnd将不支持协程化 (PHP默认就是mysqlnd)
• soap扩展
• file_get_contents、fopen等一系列文件函数
• stream_socket_client (和所有基于它实现的库, 如predis)
• stream_socket_server(和所有基于它实现的库)
• fsockopen, gethostbyname(dns查询)
• sleep, usleep, time_nanosleep, time_sleep_until

协程必然是好的，但是现有 github ，composer 中的库，包括大公司ali, tx这些云平台提供的库，都多少有一些全局变量的问题，导致无法使用协程方式开发，强制只能使用协程，虽然可以全部写到一个子协程里保证兼容，但是不是太浪费了一些？

[onanying]

最大程度地禁止同步阻塞的方法

目前的Runtime::enableStrictMode是一个比较鸡肋的方法, 而且会和Runtime::enableCoroutine冲突, 如实行了上一个提案内容, 那么严格模式也有了用武之地, Swoole内核将会强制开启严格模式, 禁止所有协程之外的阻塞IO操作, 一旦你在不小心使用了阻塞IO, 你的程序将会立即退化为同步模式, 损失大量的性能, 协程也将失去意义.

所以底层将会在开发者使用了协程的时候, 阻止开发者错误地使用阻塞方法, 并在此时抛出一个致命的错误警告.

我要用 redis 的 brpop 怎么办？在 golang 里也是能用的。

[jonny77]

弱弱地问一下 啥时候出 从入门到精通的教程 如果能像thinkphp的文档一样牛皮 推进速度会快100倍

[onanying]

删除Process模式(有争议的内容)

根据Swoole创始人Rango的意见, Process是一个不那么必要的设计, Process模式最大的作用是在worker进程异常退出的时候Master能够保持长连接不断开. 但是Process模式增加了两次IPC开销, 不支持一些高级功能, 其性能相比于Base模式相差巨大(Base简单高效, 能快速承载海量连接), 并且开发者时常在各种投递模式(dispatch_mode)中作无谓的纠结, 且由于Proces模式的复杂性, 它可能会更容易出错.

Process模式完全可以被nginx等专业的代理替代, 并且在对外的生产环境中, nginx总是必须的, 如http服务, swoole只实现了基本的应用服务器级别的协议解析支持, 而nginx则是拥有最为完备的协议解析支持.

就算没有Process模式, Base模式也支持异步安全重启特性和max_request等特性

移除 Process 的话，那得要像 go 一样支持 runtime.GOMAXPROCS 才行啊，不然开多个相同代码的进程才能使用到其他 cpu ，感觉有些不太好吧。

[limingxinleo]

@onanying 如果开启了严格模式，brpop将无法使用么？严格模式应该是避免在协程里面有阻塞的方法吧。。如果本来就是同步的cli，使用brpop应该没事吧。。我没研究过这里，不太清楚。。。

[motecshine]

在现有代码里 没有看到 corouting 调度的策略 , 也就是每个go 都是 新的thread么

[mojianyuan]

请考虑一下exec、curl原生协程的支持，特别是curl这个组件在composer, tx, aliyun的sdk中应用太多， 要替换成stream之类的库是个丰常麻烦的事。

[xianqiangzhao]

swoole 扩展功能模块很多，同步，异步，协程，未来的方向是什么？
更快，更易维护，更稳定，更好的生态。
刚开始是做加法，什么功能都加进入，现在是做减法，去掉包袱，更好的前行。
还要考虑老用户，老版本要维护，是不是令开辟一个产品线去主攻协程更好呢？

[twose]

计划中的5.0版本就是这样的一个纯协程版本，4.x转为lts，同步异步协程并存。

[GXhua]

删除Process模式(有争议的内容)

根据Swoole创始人Rango的意见, Process是一个不那么必要的设计, Process模式最大的作用是在worker进程异常退出的时候Master能够保持长连接不断开. 但是Process模式增加了两次IPC开销, 不支持一些高级功能, 其性能相比于Base模式相差巨大(Base简单高效, 能快速承载海量连接), 并且开发者时常在各种投递模式(dispatch_mode)中作无谓的纠结, 且由于Proces模式的复杂性, 它可能会更容易出错.

Process模式完全可以被nginx等专业的代理替代, 并且在对外的生产环境中, nginx总是必须的, 如http服务, swoole只实现了基本的应用服务器级别的协议解析支持, 而nginx则是拥有最为完备的协议解析支持.

就算没有Process模式, Base模式也支持异步安全重启特性和max_request等特性

来自开发组内部的争议主要是我反对 - -
1 base模式下如果用户没有解决内存泄漏通过 max_request来规避内存泄漏 会造成连接意外断开，如果内部服务或者直接用swoole写自定义的网关 相当于服务器频繁重启 这个是很难接受的。
2 如果用户解决了内存泄漏问题 很多状态会保存在进程的静态变量里面，会用到Server->bind来将用户请求指定worker进程，base模式也是支持不了的。

[twose]

@onanying @limingxinleo brpop只是会阻塞对应的协程客户端和客户端所绑定的单个协程, 其它协程仍在运行, 不受影响, 在协程里曾经的阻塞方法都会被自动调度, 让出控制权.

[luohonen]

强烈支持纯协程版本，5.0出来立马再捐献一波

[ligaofeng]

希望从5.0起文档详细点，样例多点。以往的文档对普通开发者要求要掌握的理论太多了

[tw2066]

多进程开发,数据同步问题, 比golang还考虑的多; 很多需要借助第三方工具,希望5.0能有好的解决方案;

[daydaygo]

删除同步阻塞TCP客户端

只应用于fpm模式下, 而且底层为此加入了一些环境判断.

可以拆分出来单独维护么? swoole 的一些 client 确实比其他的好用, 特别是 socket\client

[windrunner414]

@fdreamsu 理论上可以实现dispatch_mode 但是会稍微复杂一点……

[matyhtf]

删除同步阻塞TCP客户端

只应用于fpm模式下, 而且底层为此加入了一些环境判断.

可以拆分出来单独维护么? swoole 的一些 client 确实比其他的好用, 特别是 socket\client

这个建议很好，我们考虑一下。拆分成几个独立的扩展。Swoole 5.0 core 目前只会保留协程的模式。

[Yurunsoft]

1. 希望能够监听协程的创建和销毁，以便管理上下文
2. 协程MySQL和协程Redis是否也可以砍掉，直接上PDO和phpredis，减少不必要的维护工作，因为有很多新特性，可能不能及时去支持，虽然一键协程化后的性能要比Swoole实现的差一些
3. xdebug调试不兼容，如果用gdb那根本不现实，也不利于推广swoole
4. 如果禁止协程中跑阻塞代码，那如果有某个sdk不支持协程，一键协程化也不能支持，那想要在项目里将就用都做不到，那肯定很难受

[fdreamsu]

1. 希望能够监听协程的创建和销毁，以便管理上下文
2. 协程MySQL和协程Redis是否也可以砍掉，直接上PDO和phpredis，减少不必要的维护工作，因为有很多新特性，可能不能及时去支持，虽然一键协程化后的性能要比Swoole实现的差一些
3. xdebug调试不兼容，如果用gdb那根本不现实，也不利于推广swoole
4. 如果禁止协程中跑阻塞代码，那如果有某个sdk不支持协程，一键协程化也不能支持，那想要在项目里将就用都做不到，那肯定很难受

@Yurunsoft

• “协程销毁“的监听，可以用钩子实现。
• 协程MySQL和协程Redis可以直接开启defer特性，这个是传统client不能比拟的。

[TonyChen-SH]

@TonyChen-SH

不支持xdebug，代码怎么读。好像关于调试的便捷性问题，各位大佬好像都不怎么关注。

Xdebug设计上大量依赖了全局变量导致无法支持协程, swoole现在有协程迭代器, 协程调用栈跟踪, 协程gdb调试工具, 基本能满足一般的调试或者断点, 可能你只是固守了xdebug的方式, 没有了解.
https://wiki.swoole.com/wiki/page/968.html
https://wiki.swoole.com/wiki/page/967.html
https://wiki.swoole.com/wiki/page/1011.html

能支持PHPSTORM断点调试么？

[cariers]

@twose 是不是对现有的API及对象进行抽像，目前的Server感觉是一个巨无霸。

[twose]

@twose 是不是对现有的API及对象进行抽像，目前的Server感觉是一个巨无霸。

@ewenlaz 目前的Server配置的确过于复杂, 未来会有全新的协程Co\Server, 不再是异步回调模式

[twose]

支持 CURL 协程

这个关键性就不说了，很多工具库都直接用了 curl，改是很难，如果底层直接支持协程，效果非同凡响。

已在计划中

[ganl]

有Windows的支持计划吗？

[twose]

有Windows的支持计划吗？

有Windows下的开发环境支持: https://www.swoole.com/page/download

[pengbotao]

现在想迁移到swoole碰到的两个痛点，一个是全局变量/类静态变量，一个是大量的CURL请求。第一个看起来只能调整，第二个curl的支持有计划发布时间吗？

[windrunner414]

@pengbotao 是第三方库用的curl？不然可以考虑把curl替换一下

[pengbotao]

@pengbotao 是第三方库用的curl？不然可以考虑把curl替换一下

第三方的库有使用，也有很多自己调用。这个跟业务有关系，业务决定需要大量调用不同类型的第三方接口，当第三方接口超时时简直是灾难，但系统用其他语言重构成本更高，相比swoole协程方案改动还算少的了。看前面说支持已经有几个月了，不支持什么时间可以支持。

[yankeys]

弱弱地问一下 啥时候出 从入门到精通的教程 如果能像thinkphp的文档一样牛皮 推进速度会快100倍

tp不是因为文档牛皮，而是因为tp简单

[hpp321]

弱弱地问一下 啥时候出 从入门到精通的教程 如果能像thinkphp的文档一样牛皮 推进速度会快100倍

tp不是因为文档牛皮，而是因为tp简单

如果不能出入门到精通，出个入门到放弃也可以啊

[fdreamsu]

弱弱地问一下 啥时候出 从入门到精通的教程 如果能像thinkphp的文档一样牛皮 推进速度会快100倍

tp不是因为文档牛皮，而是因为tp简单

如果不能出入门到精通，出个入门到放弃也可以啊

这个应该是swoft/es等框架的工作，swoole是一种扩展。
就相当于thinkphp会有很直观的教程，但是php本身需要很长时间精通。

[pricemok]

请问5.0现在什么情况了？

[qq475281441]

去掉 SWOOLE_PROCESS 模式，是否就是现在使用 addProcess 不能使用了，创建 Process 需要在 server start 之前手动 start?　那这个自定义 process 怎么和 server 进行通信？刚才试了一下 4.x 的 BASE 模式下，好像 $server->sendMessage 也不能使用了。

可以使用swoole_event_add给process添加eventLoop

[munggruel]

感觉调试还是太难，如果有断点调试 我就用了

[niwsmbulai1989]

目前学习成本还是太大了，官方的demo太少，以及文档看起来不是很方便，文档建议参考 看云，看起来很舒服，找起来也很方便！

[bnubobby]

链接池优化
目前的链接池，每个进程各自独立
是否可增加一个进程间链接池？
主要目的是减少数据库和redis的链接数量

是否可以共用 1 个 redis 或 mysql 连接 ？
绝对不可以。必须每个进程单独创建 Redis、MySQL、PDO 连接，其他的存储客户端同样也是如此。原因是如果共用 1 个连接，那么返回的结果无法保证被哪个进程处理，持有连接的进程理论上都可以对这个连接进行读写，这样数据就发生错乱了。

如果有进程间链接池，那应用可以自行取出链接对象，处理完毕后再压入队列
类似现在的的swoole\table ，增加一个 swoole\queue

[twose]

链接池优化
目前的链接池，每个进程各自独立
是否可增加一个进程间链接池？
主要目的是减少数据库和redis的链接数量

是否可以共用 1 个 redis 或 mysql 连接 ？
绝对不可以。必须每个进程单独创建 Redis、MySQL、PDO 连接，其他的存储客户端同样也是如此。原因是如果共用 1 个连接，那么返回的结果无法保证被哪个进程处理，持有连接的进程理论上都可以对这个连接进行读写，这样数据就发生错乱了。

如果有进程间链接池，那应用可以自行取出链接对象，处理完毕后再压入队列
类似现在的的swoole\table ，增加一个 swoole\queue

你说的这个就是proxy, 各个数据库生态都有类似的东西

https://github.com/louislivi/SMProxy
https://github.com/twitter/twemproxy

[bnubobby]

链接池优化
目前的链接池，每个进程各自独立
是否可增加一个进程间链接池？
主要目的是减少数据库和redis的链接数量

是否可以共用 1 个 redis 或 mysql 连接 ？
绝对不可以。必须每个进程单独创建 Redis、MySQL、PDO 连接，其他的存储客户端同样也是如此。原因是如果共用 1 个连接，那么返回的结果无法保证被哪个进程处理，持有连接的进程理论上都可以对这个连接进行读写，这样数据就发生错乱了。

如果有进程间链接池，那应用可以自行取出链接对象，处理完毕后再压入队列
类似现在的的swoole\table ，增加一个 swoole\queue

你说的这个就是proxy, 各个数据库生态都有类似的东西

https://github.com/louislivi/SMProxy
https://github.com/twitter/twemproxy

还是有点不同的， 理论上，我只需要全局保存socket就可以了，不需要第三方做那么工作，比如解析协议，路由，注解 那一大套，特别协议解析，用官方的就挺好。

[limingxinleo]

你说的这个单进程模型是ok的，在多进程模型的情况下，应该做不到吧。

不过，这里我水平有限，不是很懂

[twose]

@bnubobby
不可能的, MySQL/Redis都是请求响应的流式协议, 一个连接只能同时处理一个请求, 多少并发就得有多少连接, 这是不可改变的, 除非你重新造一套支持并发的协议并且自己写一套客户端

跨进程连接池解决的问题只能是把远程连接减少, 转化为更高效的本地连接

没有万能的技术

[bnubobby]

@bnubobby
不可能的, MySQL/Redis都是请求响应的流式协议, 一个连接只能同时处理一个请求, 多少并发就得有多少连接, 这是不可改变的, 除非你重新造一套支持并发的协议并且自己写一套客户端

跨进程连接池解决的问题只能是把远程连接减少, 转化为更高效的本地连接

没有万能的技术

你说的没错，MySQL/Redis都是请求响应的流式协议，在多进程间使用同一个socket链接，带来的后果是数据错乱， 而不是完全没法使用， 我的意思是，是否能解决数据错乱这个问题，比如说通过多进程共享的队列，应用在request的时候中取出socket链接，使用完后再压进队列
SMProxy 做的事情太多了，我对它协议解析和长期维护方面，是抱有有怀疑态度的

[flyinghail]

多进程开发,数据同步问题, 比golang还考虑的多; 很多需要借助第三方工具,希望5.0能有好的解决方案;

同意，多进程用于 web 很简便。
但是如果想扩大到更广泛的服务（例如 ws），涉及到跨进程，就需要做进程间通信，额外引入了复杂度。这方面 golang 反而更简单。
同样这也造成连接池的问题，因为要给每个进程开一个池。