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
php-fpm和cron没你说的这么不堪,这两个都是非常可靠健壮的服务.
PHP开发者真要提高自己,建议还是去学学PHP的网络编程及HTTP协议实现,多进程编程以及进程间通信:
PHP网络编程:socket/stream/event/swoole (其中event和swoole是第三方事件库)
多进程编程及进程间通信:pcntl/posix/sysvmsg/sysvsem/sysvshm/shmop (都是内置库)
https://www.zhihu.com/question/395494009/answer/1241701447
你的意思是我连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等图片.