纯 PHP 协程框架 Wind Framework 0.1.0 发布

来源: 投稿
作者: Pader
2021-01-24

Wind Framework 是我一开始基于纯 PHP 协程实现开发出的一个实验性项目,目的是为了测试纯 PHP 协程应用于工作中的可行性。但经过测试发现应对绝大部分 IO 密集型的场景是完全可行的,于是便基于此不断开发出来的框架。

基于此框架,可以使用纯 PHP 做到一个完全自足型的 PHP 程序。

传统的 php-fpm 做法,PHP 的应用场景非常有限,很多功能需要依赖周边工具做到,比如计划任务通过 crontab 来设置,消息队列可能以计划任务每分钟启动来执行,或通过进程的守护 Supervisord 来做一个很拙劣的长驻,基于对于数据库之类的连接数暴涨也要使用一些中间件,还有很多场景甚至是束手无策或者实现非常之差,php-fpm 碰到高并发时,实际并发数受到进程数的限制,想要把并发数做大实际付出也非常之大,所以往往企业规模做大,或者业务场景复杂之后都要引入其它语言的方案,这表面上是因为其它语言的生态问题,核心还是因为其它语言支持多线程或协程这两个重要的特性。

而基于纯 PHP 的协程框架,PHP 可以用相对非常少的资源实现以上的这些功能。

该框架是基于两个最重要的库 Workerman + Amphp 实现的。

  • Workerman 提供了 Socket 服务器、客户端,进程管理,Channel 等基础组件。

  • Amphp 提供了纯 PHP 的协程实现,以及协程的 MySQL、Http 客户端等等。

目前框架拥有以下组件:

  • HTTP 服务器(支持基于控制器路由的动态程序和静态文件)

  • 依赖注入

  • 缓存(实现 PSR-16 SimpleCache 的协程缓存)

  • 进程信息收集组件

  • 定时任务组件

  • 协程 MySQL 客户端、支持连接池、查询构造器

  • 日志组件(基于 MonoLog,支持异步写入)

  • 自定义进程组件

  • 异步消息队列组件(支持 Redis、Beanstalk 作为驱动)

  • 协程 Redis 客户端

  • TaskWorker(可将同步调用发到其它进程为异步调用)

  • 视图组件(支持 Twig 等多种实现)

PHP 从 7.0 开始大幅度提升了 PHP 的性能,从 8.0 开始又加入了 JIT 又能够大大提升程序的运算性能,这些性能的提升对于传统的 php-fpm 意义并不是很大,应用在长驻式的协程框架中才能把威力彻底发挥出来。

而根据目前的 PHP 相关讨论和提案,很可能会在 8.1版本开始引入官方的协程实现基础。到时候 Wind-Framework 也会及时跟进。

Wind-Framework GitHub 地址:https://github.com/wind-framework

Composer 包:https://packagist.org/packages/wind-framework/

展开阅读全文
7 收藏
分享
加载中
精彩评论
Phpwind?你是一阵风,来无影去无踪。
2021-01-24 20:03
5
举报
目前最有可能的是fiber扩展,和作者交流过,这个rfc好多年了,最近又继续开始讨论了。个人也希望swow合并,但是估计提个rfc又是下一个十年。
2021-01-24 23:48
2
举报
哈,phpwind 确实也有过一款相同名字的框架。只可惜,phpwind 连同框架都已经被放弃了。
2021-01-24 23:04
2
举报
也不见得,假如 swow 进了官方的方案呢?但是作为语言的基础,一般会更加偏向于轻量的实现方式,提供一个比较基础的东西,而不是一整套的全盘实现。
2021-01-24 23:01
2
举报
swow你去看看多久不更了。。。。
2021-01-24 23:43
1
举报
最新评论 (25)
golang一步到位,散了吧
2021-01-25 17:39
0
回复
举报
workerman出的web框架 ,可以看看 https://www.workerman.net/doc/webman#/
2021-01-25 17:29
0
回复
举报
golang一步到位,散了吧 [Dog头]
2021-01-25 15:30
0
回复
举报
还以为是自己基于PHP的yield协程和select事件实现的协程框架,没想到是又套WorkerMan框架,又套AmPHP框架,这么套来套去,没有核心竞争力,还不如Swoole一步到位.

php-fpm和cron没你说的这么不堪,这两个都是非常可靠健壮的服务.
PHP开发者真要提高自己,建议还是去学学PHP的网络编程及HTTP协议实现,多进程编程以及进程间通信:
PHP网络编程:socket/stream/event/swoole (其中event和swoole是第三方事件库)
多进程编程及进程间通信:pcntl/posix/sysvmsg/sysvsem/sysvshm/shmop (都是内置库)
2021-01-25 14:26
0
回复
举报
终于正好看到你了,我之前在知乎还是哪里看到一个你写的 进程 模拟nginx的那个帖子,我正好在看这方面的编程,觉得很受启发,忘记保存了,能在给个地址吗?
2021-01-25 15:38
0
回复
举报
用PHP开发一个类似Nginx多进程架构的事件驱动的PHP应用服务器,这个是我写的Demo:
https://www.zhihu.com/question/395494009/answer/1241701447
2021-01-25 16:39
0
回复
举报
说实话写的很一般。
2021-01-25 17:05
0
回复
举报
没办法,我就是普通人,不写得一般点,我怕我自己看不懂.至少比那些个没实践过的强多了.
2021-01-25 17:22
0
回复
举报
多学学workerman源码,你这缺少完整协议处理,事件库也抽离,方便用其他事件库。就一个多进程,一个libevent没啥特色。我觉得还不如PHPwind。。
2021-01-25 17:37
0
回复
举报
回复 @OSC官方认证胖子 : 为什么你会认为用PHP解析HTTP/1.1这种\r\n分隔的纯文本协议是一件困难的事呢?
你的意思是我连explode/parse_str/parse_url都不会用的么?
一个explode就能把请求头转成结构化的数组.
一个parse_str就能把URL和请求体中的查询字符串转成经过urldecode的结构化的数组.
一个parse_url就能把URL转成结构化的数组获取路径和查询字符串等各种信息.

libevent内置的HTTP服务器不是完备的HTTP服务器,比如文件上传就没有实现.
需要自己手动获取请求体数据自行进行解析获取到文件上传表单的参数.
会解析multipart/form-data这种请求体,就不可能不会解析HTTP协议.

我还是普及下HTTP协议的知识吧.

HTTP请求报文组成:请求行+请求头+请求体
HTTP响应报文组成:响应行+响应头+响应体
请求行: 请求方法(HEAD/GET/POST/PUT/DELETE) + 请求URL + HTTP协议版本
响应行: HTTP协议版本 + 状态码 + 状态码描述
请求头: 结构为"name: value",比如Cookie头就在这.
响应头: 结构为"name: value",比如Set-Cookie头就在这.
请求体: 两种格式,一种是查询字符串也就是x-www-form-urlencoded,一种是用boundary分隔参数的form-data.
响应体: 格式可以是多种,包括但不限于常见的HTMLJSON等文本和PNG/JPG等图片.
2021-01-27 16:36
0
回复
举报
回复 @eechen : 谁告诉你\r\n 困难 你眼xia看错了吧。。。。。你说这么多废话应该给小白哈哈
2021-01-27 20:53
0
回复
举报
回复 @eechen : workerman又不是只支持http 你看人家实现了多少协议,你那demo开源中国有几个不会写,何必丢人现眼呢。。。。
2021-01-27 20:54
0
回复
举报
多学习,少装X.
2021-01-29 11:28
0
回复
举报
那个帖子我觉得写的非常的简单直接,非常的棒!!可惜当时开的网页过多,不小心关掉了,在找就找不到了。终于又看到你发留言了,可以给个链接吗:)谢谢
2021-01-25 15:41
0
回复
举报
恩恩,还不如 Go 一步到位。
2021-01-25 15:54
0
回复
举报
swoole的吃相你还不知道?还在跪舔?官方fpm+cli就行了,用什么非官方的swoole方案,你是想用swoole_plus当我没说。swoole的确好用,但是携程客户端的生态问题,唉,官方的吃相,唉,swoole包袱也真多,核心只搞携程即可。连php-src得官方人员都说了这个客户端生态问题,各种扩展都不愿意给swoole适配,swow遥遥无期,fiber或许有可能,现在还是老实用fpm+cli处理就行了。
2021-01-25 17:21
0
回复
举报
不管是哪种协程方案,首先要尽快实现,先实现基本的功能,后面再慢慢迭代
2021-01-25 10:00
0
回复
举报
支持,swoole这种非官方方案最后迟早被替代。
2021-01-24 20:08
0
回复
举报
也不见得,假如 swow 进了官方的方案呢?但是作为语言的基础,一般会更加偏向于轻量的实现方式,提供一个比较基础的东西,而不是一整套的全盘实现。
2021-01-24 23:01
2
回复
举报
swow你去看看多久不更了。。。。
2021-01-24 23:43
1
回复
举报
目前最有可能的是fiber扩展,和作者交流过,这个rfc好多年了,最近又继续开始讨论了。个人也希望swow合并,但是估计提个rfc又是下一个十年。
2021-01-24 23:48
2
回复
举报
确实,我个人也比较倾向于 Fiber,这个也是目前 amphp v3 的基础。
2021-01-25 09:23
0
回复
举报
Phpwind?你是一阵风,来无影去无踪。
2021-01-24 20:03
5
回复
举报
哈,phpwind 确实也有过一款相同名字的框架。只可惜,phpwind 连同框架都已经被放弃了。
2021-01-24 23:04
2
回复
举报
支持一下
2021-01-24 19:44
0
回复
举报
更多评论
25 评论
7 收藏
分享
返回顶部
顶部