为什么不推荐使用swoole和hyperf官方框架

浏览:6794 发布日期:2021/01/15 分类:技术分享
开篇之前,为了证明自己不是为了黑而黑,先说明对swoole和hyperf的接触

(1).参考swoole捐献列表信息(其他小额的未统计,每年都有捐款):

200.00 高久峰 希望 swoole 协程客户端生态越来越好 开源中国
(2).我们已经购买swoole商业产品tracker(目前内网部署)

(3).线上使用hyperf的项目(目前已经停用)+部分论坛项目(正在使用中)

先说下目前swoole和hyperf发展状况:

【一】.swoole

(1).swoole从异步模式到同步协程模式,编码方式及其舒服

(2).基本php官方维护的扩展或函数基本已经全部hook

(3).全面c++后的代码工整规范了很多,阅读比之前容易了

(4).目前4.x还是非常稳定的,bug越来越少

(5).文档大改,舒服多了

(6).生产可用

(6).最新版本的curl_hook是真的curl了,不是phplibrary实现了

【二】.hyperf

(1).2.0版本相当稳定

(2).越来越多的官方协程客户端支持

(3).phar打包的确舒服

(4).生产可用

swoole的发展对于所有phper来说是好事情,因为没有swoole,我们都是在fpm上开发,最多接触下cli,不会花太多时间研究多进程、进程通信、信号管理、同步异步、Yield、Select、Epoll、端口复用、阻塞非阻塞、协程调度之类的技术,这一点我们必须感谢swoole。因此我标题的意思只是不建议使用,学习还是要学习的,学了没有坏处。

对于不推荐使用swoole和官方框架hyperf主要是从技术选型来说的,一个项目选择某项技术要考虑很多因素:例如考虑所采用的技术是否稳定、社区是否活跃、社区的支持程度、定制型、是否官方方案(很重要)。切记,项目特别小或者公司特别大,不要担心,随便用。小项目能用多久还是问题,大公司swoole自己定制修改即可。

现在看看swoole和hyperf目前的问题吧

【一】.swoole

(1).swoole并不是严格意义上的官方扩展,我从3年前就以为swoole是php官方扩展,其实swoole只是官方pecl扩展,真正的官方扩展是php-src中包含由官方在维护的扩展。目前算php官方pecl扩展的有409个,突然想到之前还帮swoole刷pecl排名,差点害了swoole,这里道歉一下。

(2).swoole不太可能也没可能合并到php-src,因为合并到php-src必然是c语言+最小核心,而swoole目前是大量c++,而且太多乱七八糟的功能。为了合并到php-src,swoole团队中的成员独立搞出了swow扩展,这个目前看起来有可能合并到php-src,而且swow的代码及其简洁,是真的骚,我们公司有位同学也在贡献,但是看起来项目不怎么活跃了。有兴趣的可以关注下国外的fiber项目,可能会合并到php-src

(3).swoole有点激进,对于我们开发者来说,我们当然希望全部用最新的php版本,swoole目前开始不再支持 PHP7.1

(4).扩展兼容性,最新swoole使用协程时,无法使用pcntl官方扩展。swoole的出发点很好,但是不支持官方扩展有点.....

(5).Hook只是开始,协程生态道阻且艰。完善协程生态有很多路,一种是和amphp和reactphp一样使用纯php造客户端,在 v4 版本后内置了 Library 模块,所以这个路子+jit是可行的,但是路太远,各种客户端协议维护成本高,一种是要求第三方扩展使用底层提供的socket或者stream来实现客户端,貌似不可行,php本身用户量没有那么大,第三方不太可能为了你专门适配。这种只需要swoole全部hook了zend提供的api,第三方客户端来适配即可,但是我觉得不太可能,这个可以在php-src中看到php官方人员的回复,即使可能对于第三方来说修改很小,对方也不愿意去修改。

(6).swoole官方的运营非常失败,从有赞、Hyperf,Swoole_plus,Swoole微课程,Swoole出版图书来分析。有赞事件我不太清楚真相,swoole如果能再包容点,或许还能帮助swoole推进发展步伐,如今有赞直接上Java,拜拜了您;Hyperf事件中swoole如果能做好library的中立性或许就不会出现现在这种尴尬的状况,swoft、mixphp、easyswoole或许还很积极帮助swoole发展;swoole_plus是swoole的商业化探索,是一个好的出发点,开源没有收益,没有饭吃,哪里有精神来开源,可惜swoole_plus刚出来就是号称“比社区版更稳定”,一瞬间社区版变为“小白鼠版本”。后来讨伐严重了,swoole声称“我们是卖给商业公司帮助社区版踩坑”,你觉得商业版的用户是傻子吗?商业版和社区版唯一的区别只能是功能增强,千万别拿稳定说事;Swoole微课程付费学习swoole,学员在Q群投诉不按照约定进行发布课程,要求退款,结果被踢出群。我也是服了,人家花钱没有买到服务被踢了;Swoole出版图书销售没有问题,只有电子版卖到400还是480,这个金额没问题,后来发现国外卖的比国内还便宜,这不是割韭菜,因为连目录都不给,被喷的太惨了。

(7).协程底层Hook中各种大量的定时器和进程IPC开销,也不算缺点,貌似也只能这样。

(8).核心贡献者不活跃了,韩天峰又开始自己亲自上了,参考github

(9).phpcon之后继续组织好未来开发者大会卖票,来重复讲Hyperf和PHP8特性?最后卖不出去直接免费直播了。。。。

【二】.Hyperf

(1).Hyperf的作者黄朝辉本身是Swoft团队中的一员,Hyperf和Swoft代码相似度高达百分之80以上,前期的代码直接抄,相关吃瓜和图片链接等下底部加上。

(2).Hyperf的作者没有开源精神,常规操作(修改命名空间、删除注释、删除版权、不注明出处),把Laravel抄的裤衩子都不剩了,作者解释是自己不熟悉mit协议,mit协议不熟悉,难道你不知道什么叫许可文件,版权文件的字面意思,你不是第一天做开源了吧,其成员李铭吸在群中说已经道歉了,目前我没有找到任何道歉文章,如此严重的抄袭,是在哪里道歉的?

(3).Hyperf官方组件删除注释,面对质疑,一名叫李铭吸的作者直接开骂, 虽然后来进行道歉了。面对质疑号称是非官方开发小组成员,难道你们内部没有审核机制?然后各种踢人操作

(4).Hyperf目前的确稳定,刚发布就号称生产验证、生产可用,我们从1.0开始,基本每周都能修复我们部分小bug

(5).Hyperf的用户其实还不如thinkphp,开源中国投票存在大量刷票行为,加了作者的人应该都收到每天的群发消息了,[email protected],作者微信更是每天自动邀请未加群的人。

(6).Hyperf作者在面对选择框架的时候的回答,“还有其他框架可以选?”请问是谁给你的自信啊,哈哈

(7).Hyperf作者其他的金句自己搜瓜

从swoole和hyperf来说,商业化不是问题,成功的开源项目需要商业化支持。但是把用户当作韭菜收割,吃相未免太难看。如果开源夹杂太多的利益和虚荣注定走不远,这才是重中之重。

从Swoole和Hyperf现状来看,如果追求真正的稳定和长期,还是不推荐使用Swoole和Hyperf,当然也包括其他Swoole框架。官方方案fpm+opcache+jit+长连接,或者workerman,稳如老狗,官方方案,有问题自己轻松解决。实在没有办法可以引入第三方语言综合即可。如果你关注PHP官方的协程或者异步方案,可以浏览下Amphp作者推出的Fiber扩展,已经进入rfc阶段。

附上各种吃瓜链接:

吃瓜链接1

吃瓜链接2

吃瓜链接3

吃瓜链接4

吃瓜链接5

吃瓜链接6

为了避免Hyperf的某素质小伙李铭昕认为我是其他swoole框架成员来黑Hyperf,提前去掉了首页帮助其他框架作者推荐的链接了,之前这货以为我是imi框架的人,后来说我是easyswoole框架的人,现在不会怀疑mix-php框架了吧。老夫不站队的,保持中立,也不用swoole的框架。

提一下我最尊敬的php领域开源作者:

(1).workerman作者

(2).mix-php作者(并非推荐swoole框架,如果可以请使用mix-go)

两位真正拥有开源精神的作者带给我很多知识上的成长,同时非常尊重开源协议。

转载自https://www.gaojiufeng.cn/?id=1751
最佳答案
评论( 相关
后面还有条评论,点击查看>>