[Sw] Swoole 生态迷局,基于 Swoole 的第 109 框架

通过llama.cpp与羊驼聊天的网页界面- 详解 Serge 的启动使用

 

这两天,又一全栈式 Swoole 协程框架面世了 - hyperf,实现思路是我内心点了赞同的,就集成现有 PHP 生态优质组件到 Swoole 的协程中来。

有人想到,为什么不是 Swoole 集成到 Web 框架中,当然已经有案例了,如果是老项目这么做是可以通过常驻内存提升性能的,并且利用到 Swoole 一些特性。

但是天花板也正是传统 Web 框架的限制,它们运行组件不是为常驻内存和协程而设计的,所以99.9%无法透明支持 Swoole 的,这是历史使然。

php-fpm 是多进程模型打天下的,Web 服务器是 Nginx 多,PHP 从不用考虑太多,憋说话,加机器就能解决的问题算问题吗。

现在科技进步了,都会举一反三了,眼界也必须要高呀,要省机器,要高性能,要云原生,矛盾就这么出现了。

所有基于 Swoole 的开发框架,上来必先普及一番 Swoole 协程的注意事项,这些注意事项都是在 Swoole 官方 wiki 上都有的,但依然穿插在框架文档的各个地方,

大家都这样做,厌恶感莫名就上来了,为什么 Swoole 官方 wiki 上有,你的开发框架文档上还要再拷贝一份呢,其实在我看来,这不会是简单的拷贝,

起码是框架作者深谙 Swoole 协程用法,拷贝顺带自己的理解敲上去的,因为不写的话,肯定大伙儿一用都是坑,到时候先吐槽,啥玩意儿,还不如我裸写的呢。

是的,当你把 Swoole 官方 wiki 上的特性、注意事项都了然于胸的时候,裸写是最爽的,性能最高,但是咋维护呀,这必须解决呀。

那么些个框架都出来好久了,用用看?要是写个小开源衍生作品,用就用呗,挂就挂了,不兼容就不兼容了,存档就存档了,不管那么多。

谁还没裸写过,这时候你理直气壮的创造了基于 Swoole 的第 109 个框架 swoole-micro .

 

Refer:Swoole的生态环境

Link:https://www.cnblogs.com/farwish/p/11062359.html

posted on 2019-06-21 09:08  ercom  阅读(904)  评论(0编辑  收藏  举报