(转载)为什么不推荐使用swoole和hyperf官方框架

开篇之前,为了证明自己不是为了黑而黑,先说明对swoole和hyperf的接触

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

200.00 高久峰 希望 swoole 协程客户端生态越来越好 开源中国

(2).我们已经购买swoole商业产品tracker(目前内网部署)

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

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

##【一】.swoole

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

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

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

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

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

(6).生产可用

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

(8).swoole商业版加密软件是真好用(扯偏了,不过赞1下,哈哈)

##【二】.hyperf

(1).2.0版本相当稳定

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

(3).phar打包的确舒服

(4).生产可用


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

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

现在看看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特性?最后卖不出去直接免费直播了。。。。

(10).php8之后的下一代php很有可能就是php官方协程的探索,目前fiber协程扩展方案已经申请合并到php-src,swow协程扩展方案也在准备合并到php-src,swoole未来或许会边缘化,更多的是提供商业支持。

##【二】.Hyperf

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

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

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

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

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

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

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

(8).Hyperf作者最近承认了自己删除别人代码版权和许可证问题,但是认为不是恶意的。好吧我认可,但是你们说已经道歉了,我问在哪里道歉,她说反正又不是向我们道歉。。所以哈哈。。。

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

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

附上各种吃瓜链接:

吃瓜链接1

吃瓜链接2

吃瓜链接3

吃瓜链接4

吃瓜链接5

吃瓜链接6

吃瓜链接7

总有别人恶意抹黑我是其他swoole框架成员:

(1).Hyperf框架作者李铭西在微信群直接把我当imi框架的人

(2).Imi框架作者在自己群直接说我是es框架的人

(3).Hyperf作者在开源中国直接把我当es框架的人

我活跃在各种swoole群,包括swoole官方群(已经退出,因为不用),Hyperf官方群(已经退出,作者恶心),Imi官方群(因为作者当时地域黑骂群成员,所以我退群了,虽然不是我的地域,很反感,另外imi作者在自己QQ群抹黑别人,被自己的人截图,还骂别人是奸细,真的是搞笑,进你群就是支持你的?),Swoft官方群(一直在,方便吃瓜),OpenMix(一直在,常规划水群),还是那句话,不建议用swoole相关框架,狗才站队。

无论如何,swoole都为社区带来了伟大的贡献,也希望在未来能看到swow合并到php-src中,感谢swoole和swow为php社区的贡献,今年swow扩展开始创建rfc,未来或许swow扩展会成为php官方协程方案,理性看待,合理选择适合自己团队的技术栈。

本文转载不需要征求作者同意。

麦志建博客
请先登录后发表评论
  • latest comments
  • 总共1条评论
麦志建博客

犹他 : 干货

2021-05-26 22:06:13 回复