站在巨人的肩膀上，通过 Swoole 加速 Laravel/Lumen

[hhxsv5]

背景：公司严重依赖 Laravel 和 Lumen 框架，显暴露出来了性能问题。

解决：站在巨人的肩膀上，通过 Swoole 加速 Laravel/Lumen 调研了目前已有的 Laravel+Swoole 结合方案，多多少少都有点儿问题，有的定制化太强，有的没有再维护了。于是决定再造此轮子。

成果： LaravelS https://github.com/hhxsv5/laravel-s 通过 Swoole 来加速 Laravel/Lumen，常驻内存，内置 HTTP 服务器，平滑 Reload，与 Nginx 配合搭建高可用分布式服务器群，开箱即用。

目前已经在公司生产环境用起来了，后面考虑加入连接池和协程客户端的封装。

有需求的可以尝试下，Give me star

[eslizn]

@server io 倒还好，大不了自己根据协议来封，关键 swoole 改了很多底层的东西，有点不可控。相比 swoole，个人觉得 reactphp 更稳定些。当然 go 更好~~

[eslizn]

@hhxsv5 是的，所以看你怎么处理 di 的包

[eslizn]

@hhxsv5 错了，只是调用内涉及 [同步 IO] 的操作需要 Coroutine::call_user_func_array，否则还是个大坑，不要问我为什么。。。

[eslizn]

@hhxsv5 也就是说，作为框架，你根本不知道什么时候该用 call_user_func_array，什么时候该用 Coroutine::call_user_func_array，我之前也想这样干，后来不了了之

[wanghanlin]

可以试试 php-pm，基于 reactphp 的

[male110]

来用 C# 吧，.net core

[hhxsv5]

@wanghanlin php-pm 不错啊，再结合上 Swoole 的协程客户端

[kslr]

感觉还是 php-pm 这种侵入性低的方便

[hhxsv5]

@eslizn 可以用 PHP 动态函数来代替吧，例如$func = "doXxx";$ret = $func("abc"); 不过参数还是有点儿蹩脚。

[hhxsv5]

@kslr LaravelS 设计的初衷就是低侵入性，composer require=>加 service provider=>改下监听地址=>php artisan run http server=>nginx 代理到此 server。

[eslizn]

@hhxsv5 这样的话同步调用就回阻塞整个进程

[hhxsv5]

@eslizn 呃 call_user_func_array 也是同步的呀

[eslizn]

Coroutine:: call_user_func_array 可以将同步 io 挂起，继续去执行其他的协程，关键问题是，在框架中，没办法知道你开发的逻辑中是同步操作还是异步操作

[hhxsv5]

@eslizn 哦，你说的是 Coroutine 下的。感觉只有程序员自己判断。

[eslizn]

@hhxsv5 Laravel 里面大量依赖了 di，而 di 的实现都是要依赖这组函数，所以想了解下你这块是咋处理的，因为看了下源码好像没有涉及 di 的改造

[hhxsv5]

@eslizn di 那块儿是同步的，没有加入协程的支持。考虑把协程封装暴露出来，开发者显式使用，这样底层才知道什么时候用 Coroutine:: call_user_func_array。

[gouchaoer]

这么说吧，异步的 swoole 中用了同步阻塞函数情况会比 fpm 还要差，因为一旦阻塞当前 swoole worker 进程下别的 request 就得不到执行。。。

给 lz 推荐一个框架，swoft，这几天会放出 1.0beta 版本，彻底解决问题

[hhxsv5]

@gouchaoer Swoft 有所了解，有个朋友 xjj 在参与开发。对 LaravelS 的定位其实很低，没有那么高的目标，简单的常驻进程，避免重复的资源加载，再上点儿协程；兼容 Laravel 和 Lumen 的用法。其实这样挺好，基于 Swoole 的百花齐放，让 PHP 开发者有了更多的出路。

[lizhenda]

swoole + yaf + yii 路过~

[wujunze]

改善 PHP 生态 赞