Swoole和webman那么强,为什么laravel官方不用这些,为什么依然很多人用laravel和tp之类的

Swoole和webman那么强,为什么laravel官方不用这些,为什么依然很多人用laravel和tp之类的

《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
讨论数量: 57

一顿操作猛如虎,一看 IP 250

1个月前 评论

这个,强要看哪种吧。没生态只说强也没用的吧

1个月前 评论
deatil (作者) 1个月前
GDDD 1个月前
GDDD 1个月前
Sw-A 1个月前
Alone88 1个月前

这种东西看各种各样的需求吧,照着这个说法,go和其他语言那么强,为什么还用php?各有各的强项

1个月前 评论
yyy123456 1个月前
Sw-A 1个月前
working (作者) 1个月前
yWNN

主要还是很多php习惯fpm的思维模式,开发起来快,坑少。

1个月前 评论
GDDD 1个月前
Sw-A 1个月前
翟宇鑫

强与弱都是相对的,swoole 和 webman 可能也有其致命的缺点。

1个月前 评论
Payne 1个月前
GDDD 1个月前
翟宇鑫 (作者) 1个月前
GDDD 1个月前
一念沧海一念桑田 2周前
随波逐流 1周前
yangweijie

有扩展吧 roadrunner 两个都支持

1个月前 评论

一顿操作猛如虎,一看 IP 250

1个月前 评论
游离不2

laravel 和 tp 都有对 swoole 的支持,先了解了解再下结论。swoole 和 webman、laravel、tp 的区别是啥都没搞清楚呢。

1个月前 评论

现在 PHP 性能很高了!主要是 Fpm 一直停滞不前,拉胯 :joy:

1个月前 评论

因为强大的生态,开发效率,开发习惯,开发门槛,大部分项目并没有很高的并发,实现功能即可,快速上线才是王道,而且php-fpm依然是工业级的产品,如果需要效率,加机器可能比用swoole更高效,swoole和workerman只是在特定业务下才能发挥作用,但是特定业务下和go或者java有体现不出优势

1个月前 评论

因为开发快啊

1个月前 评论

你用了就知道了,fpm的方式是简单,无需考虑很多问题,如果你使用了swoole要考虑很多问题,首先变量的销毁以及内存泄漏问题,虽然swoole的性能很好,但是也要你懂它,不然你分分钟写了一堆bug

1个月前 评论
GDDD

Swoole是扩展。webman是框架,webman生态和所有框架都一样,composer,开发起来并无二致。建议有重构项目,或者新项目的同学使用,特别是当你们有性能要求的时候,那是真香。没有性能要求 用啥都一样

1个月前 评论
黑将军 1周前

你这问题问的, Laravel / TP 和 Swoole 就不是一个东西,前者是框架,后者是 php 扩展,再说这两个框架都有扩展支持 Swoole。

不过 Webman 确实快

1个月前 评论

先赚到钱再说,不赚钱讨论啥框架都是耍流氓

1个月前 评论
ncccc1 1个月前

file

1个月前 评论
zjason 1个月前
sheshou 1个月前
阿尔卡蒂奥 1个月前
liaosp 1个月前
liaosp 1个月前

个人理解,webman虽然测试成绩很强,但是有水分的,webman的每个worker中还是阻塞执行,也就是说,涉及要访问第三方api或者某些耗时操作的话,把worker都阻塞了,性能就会大幅度下降,不像go有协程,可以挂起耗时操作先执行其他的。测试出来的性能高是因为逻辑简单,测试机器配置也好,测试时没有阻塞的情况。

1个月前 评论
sheshou 1个月前
Payne (作者) 1个月前
sheshou 1个月前
Payne (作者) 1个月前

Laravel和Swoole,Webman之类的框架都有各自的优缺点,并不是一个更好就把另一个淘汰。Laravel官方的选择可能是基于对Laravel框架的了解,认为它更适合满足他们的需求。此外,许多人仍然喜欢使用Laravel和TP等框架,可能是因为它们对于他们来说更加熟悉和方便,或者是因为他们已经在使用这些框架,没有必要改变。总之,选择使用哪种框架取决于个人喜好和实际需求。

1个月前 评论
gema

都是工具 什么顺手用什么, 有的时候是性能优先, 有的时候是开发速度优先

1个月前 评论
sanders

octane 不算 laravel 官方对 swoole 的应用吗?除此之外还有 laravels 和 laravel-swoole 这些其他开发者的项目。

1个月前 评论

杀鸡为什么不用牛刀

1个月前 评论

普通的项目用不到啊,除非是高并发、长链接之类的

2周前 评论

按照这种理论,PHP可以原地淘汰,还有就是swoole、webman这种是常驻内存的,和普通的cgi模式有比较大的差别,如果团队硬要换生态还不如直接切换语言

2周前 评论
sudden3 2周前

只谈个人看法:
你的问题是Laravel、ThinkPHP用户群更大, 使用Webman Swoole 的人不多。
回答:
laravel 官方已经支持openswoole learnku.com/docs/laravel/8.x/octan...
为何没有支持Workerman , 你可以去搜索一下issues 已经有人提过问了。
octane 已经预留编程接口,按照实现即可。

laravel thinkphp 出现很早,已经大量积累现有项目,长期使用FPM 编程已经习惯,自然不愿意改变。
何况很多项目还没有到达性能瓶颈,他们更多关注业务如何设计。

常驻Server 优势:
Swoole 、Workerman
它们提供不仅仅是性能上提升,还有网络通信的支持。
不需要依赖第三方语言去实现。
做网络安装Gatewayworker 直接使用,定时任务直接用webman-crontab 不需要你用操作系统的计划任务。

开发效率:
webman 开发效率不比thinkphp laravel 低,常驻内存代码不更新问题,通过框架配置文件指定目录,自动代码自动更新。
掌握难度我觉得和laravel thinkphp 差不多,没有特别关注的。
只担心内存泄漏问题,这个官方有解决方案,也不必大惊小怪(go, java 都有的)

官方终极解决方案:
$worker->onMessage = function($connection, $data) {
static $request_count;
// 业务处理略
if(++$request_count > 10000) {
// 请求数达到10000后退出当前进程,主进程会自动重启一个新的进程
Worker::stopAll();
}
};

webman 生态是兼容Composer的。
官方组件 Laravel orm、symfony event、symfony console 本身大量使用第三方composer,你觉得这个说服力不够?

作者初心是简单方便很多人使用,兼容composer php 现有生态。

接下来谈谈swoole:
常驻内存无协程的swoole 和 webman(workerman) 也差不多。
但多数时候说的swoole ,指的是全协程Server。
不使用因为很多人技术能力不够,害怕解决不了问题,并且不兼容composer 生态。
单线程多协程会造成静态变量数据混乱,数据库也需要改造为连接池,那不然协程数量内存不得啃光,数据库都被并发打死。
swoole 框架主要就是hyperf,如果使用hyperf 开发只能用官方的包,如果你技术能力很强也可以自己改造composer包。
总的来说,大多数人技术不行,不敢使用,害怕翻车。

多说一点:
workerman官网webman开发: www.workerman.net/
webman admin: www.workerman.net/doc/webman-admin... 作者亲自写的
可能你担心webman 不稳定,大可放心!
webman 本身就只实现路由部分,其余全是现有comopser 生态拼装而成,不信看源码就知道。
真正决定webman 是否稳定是workerman 容器,而不是webman。
workerman 作者自己开发过很多项目,拿其中的“泡泡IM”,这个项目已经有4年多了。何况workerman 已经出现8年多了,不用怀疑稳定性。

workerman 不稳定只可能是event 扩展,但这个扩展发布很多稳定版本了。pcntl 扩展更不用多说吧!
event 稳定版链接:pecl.php.net/package/event
最早版本追溯到 2004年,不用质疑扩展稳定性。

总结:
swoole 全协程运行不兼容composer 生态,技术门槛高一些,何况很多项目未达到性能瓶颈。
webman 常驻内存多worker,兼容composer 生态环境,简单容易上手,难度和thinkphp 差不多。

1周前 评论
mrpzx001 1周前
青春不留白 (作者) 5天前
mrpzx001 5天前

等哪天, packagist 上 webman 的下载量超过 laravel 的收藏量, 再考虑用

1周前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!