比如把 webman 做成 laravel 的一个 package,假设这个包叫 workerman/laravel-webman
这个包其实就和 https://github.com/walkor/webman 代码差不多
composer require workerman/laravel-webman
后,会在laravel里注册一个command,比如就叫 webman(可以使用 php artisan webman 执行)
这样 laravel 专用的包就可以直接用了(比如 dcat/laravel-admin
),用于做管理后台,用nginx + fpm部署
webman 用于写 api 接口,用 nginx 代理 webman 这种方式部署
既发挥了 laravel 的特长(快速开发,生态完善,性能不好无所谓做后台用)
也发挥了 webman 的特长(简单高效,性能强悍)
开始想的是这样规划目录
但是这样的缺点就是:
拿走不谢:
https://github.com/joanhey/AdapterMan.git
https://github.com/Itinysun/laraman.git
https://github.com/mouyong/laravel-octane-workerman
https://github.com/JieAnthony/laravel-octane-workerman.git
多谢
1、这个你还不如直接用基于workerman用于lavael 的加速器,性能也能提高10倍左右,
2、就是你想的二个项目平行,高性能走webman webman可以和laravel 共享的,直接把你的webman项目放入你的laravel下面,webman中的composer.json中定义laravel中的共享目录,建议模块化开发,如在psr-4中定义laravel的模块目录:
"Modules\": "../modules/"
要注意:1、依赖包二边都要有。
2、引用的缓存,orm文件先自己定义一下:如orm公共文件二边都定义一个:app\modle;缓存:app\cache,这样在使用时就用公共的2边都能识别,类式以下方法把二边引用调为一至即可。放到各自的app公共目录中,已实现开发的业务代码二边通用,也就是开发是不要使用默认的:Illuminate\Database\Eloquent\Model,类式二边引用不一样的都通过这种自定义转一下后在用就行了,已达到二边共享,只须要二边使用的底层包一样,对开发没有啥影响,老项目可以采用批量替换一键就转过来了,就算平时开发也不建议直接引用laravel的原生引用,因为后期如果你要调整,不可能一个文件一个文件调整,比如以下试例中的日期,laravel升级后不是你想要的日期格式了,由于你自定义了model 直接修改app\model是加入日期转换就全局转了,不至于使用原生的每一个文件去改。使用上把以前的:use Illuminate\Database\Eloquent\Model 改为:use App\Models\Model ,其它缓存与不通用的使用方法同理方法调整即可,按这个规则开发,就可以实现一套代码二个平台运行,对性能没有要求时直接laravel运行,对性能要求高的如小程序app啥的,就可以启用webman运行,
也可以自己在webman中实现laravel的底层类:已实现代码共享如laravel的DB类在webman实现方法:
大哥,"基于workerman用于lavael 的加速器"这个有文档吗
是有点麻烦,其实就是贪图 laravel 里面一堆现成的admin包
能加速laravel也是可以的
有的,可以直接workerman加速,论坛里面有,须要小改一下上传的验证
哪个链接啊
https://www.workerman.net/q/9831
小调整一下就可以正式用了,目前没发现其它问题
感觉没必要, 使用laravel的orm等composer包就够了