使用 swoft 的话是否完全可以抛弃 PHP -fpm?

[sunmoon1983]

要开发一套新的商城，项目中想使用 swoft，但是没有相关的经验，很纠结，是否完全可以抛弃 php-fpm?

nginx 只用来反向代理或者处理静态文件！

对于用惯了 Yii2 的我们，在使用 swoft 的时候，有没有什么建议？

有没有什么坑需要注意？

[xnode]

我是习惯用 laravel，swoole 我也在看，但是正式的开发没有写过，swoft 自己用无所谓，开发软件的话，感觉会有坑

[salamanderMH]

可能应该问，swoole 里有什么坑的

[sagaxu]

fpm 写的再烂也不会崩，swoole 写的不好就糟糕了，team 平均工资提高个 5000

[salamanderMH]

我是用 workerman 的，然后套了一个 slim
https://github.com/salamander-mh/WebWorker

[xnode]

@salamanderMH 大佬 已 star

[yepinf]

@sagaxu 哈哈哈
提高工资，干脆写 go 多好

[zn]

开发难度变大。
调试难度变大。
windows 下无法运行调试。
趟的坑(如果碰到的话)也会更难爬出来。

这几个能接受的话可以考虑。

[sunmoon1983]

@sagaxu 我就是在纠结，PHP-FPM 再差应该比 SWOOLE 实现的 HTTP server 差太多吧，何况 FPM 还不差~~

[sunmoon1983]

@salamanderMH 是弃用了 nginx+php-fpm 吗？直接用 workerman 的 http server 处理各种逻辑？

[xnode]

@sunmoon1983 性能是差很多 但是 php-fpm 的回收效率上 是高了很多

[gouchaoer]

🙄swoole 生态的本质是 php-cli 协程化，类似 golang 的路子，如果后台的 io 很重用 swoft 就比较适合，但是鲁棒性就会降低（比如内存泄漏、coredump、第三方库以及热更新啥的），商城如果流量小+feature 特别复杂，还是 fpm 好一点。。。。如果流量大+feature 比较少功能简单，swoft 就没问题

[abcbuzhiming]

@sunmoon1983 首先你要搞明白一件事情，SWOOLE 的本质是和类似 Nodejs 那样，基于 jit 将二进制程序常驻内存来获得调用速度的提升，这在本质上的和 PHP-FPM 是有区别的，PHP-FPM 仍然算是解释执行，并没有讲源码 jit 后二进制常驻，就算它上了缓存也是如此。
其次，php-fpm 是一个中间处理器，通过 CGI 协议和真正的 HTTP 服务器进行沟通，所以我觉得你把 PHP-FPM 和 Http 服务器放在一起对比是不合适的，你会把一辆拉人的小汽车和拉货的小汽车放一起比吗？
最后，你都打算放弃 PHP-FPM 了，就算你不愿意去转重一点的 Java，Golang，有一个和 Swoole 原理接近的 Nodejs 为啥不愿意选呢，虽然 NodeJS 这东西自身和真正的重量级后端差的远了，但是它的功能和特点，取代所有 PHP 能出现的场合是毫无问题的，而且 NodeJS 的应用可比 Swoole 广泛的多了，各种操作系统下面都能跑，它的鲁棒性可不是 Swoole 这种一直没有大面积铺开使用的框架能比的

[gouchaoer]

@abcbuzhiming swoole 比 nodejs 也还要先进一点，nodejs 是异步，没有解决 callback hell 问题，swoole 和 fibjs 对标，不过 fibjs 没啥人用就是了。。。另外 swoole 和 jit 无关。。。如果要舍弃 fpm 推荐转 java 吧，鲁棒生态又成熟。。。。nodejs 这个生态咋说呢，比较适合前端程序员需要做一些后端的东西的情况，因为可以不用在学一门语言了

[sunmoon1983]

@abcbuzhiming 不是不愿意选其他的语言，而是项目要求的开发时间短，而我们的团队大部分的时间都是在用 php(Yii2)开发，所以我们只能在 PHP 中的做选择~

[zjsxwc]

如果不用 symfony、zend 的这类大而全的框架的话，swoft 比用 yii2 好

[yann1992]

一般来说，引入的问题比解决的问题还要多的方案就不要采用了。是否用 swoole 还是要看你团队对 swoole 是否熟悉，如果不熟的话，不建议用

[abcbuzhiming]

@sunmoon1983 时间短那还想什么，先怼上线再说，引入 swoole 你不怕踩坑浪费时间吗

[liaohongxing]

试过一把 workerman, 铁定的内存泄露，swoole 估计一样，比如 curl 类等资源句柄根本不会回收，不太好用。

[cabing]

快速开发，建议直接使用 php 撸吧，先上线。fpm 是 php 的进程管理器，一般 http 服务器用的是 nginx。

直接使用 swoole 就是使用它替换+nginx+fpm，当然这里 nginx 做反向代理。



swoole 这种三方库慎用，如果有啥 core dump，你们咋办。当然你们的同事 hold 的住吗？到时候着急不如提前考虑清楚。

没啥性能问题就用 php。有性能问题也可以先用 php 上一版本。如果业务发展的好再把模块抽出来，用 java 或者 golang 或者 c++抽出做成 rpc 服务就行啊。

比如微博就是移动端都走的 php，对的是 php，你们调用的接口一般都是走的 php，核心模板使用 java 封装成了接口，便于快速开发业务。


如果以后想用 java，spring cloud 来一套，生态全，真的不要太容易啊。

[EscYezi]

yii2-swoole 了解一下。有时间的话可以踩踩坑🌚

[elarity]

作为一个拥有生产环境主导部署 swoole 的人，我决定现身说法一波儿，但可惜我并不是来推荐你用 swoole 的，我的态度是中立，我只客观描述事实，你自己做决定。

项目是我 前前东家 的时候，我是服务端主程，产品是基于 LBS 地理位置的陌生社交，名字叫做积目（不怕有人说我广告狗），用户在百万级别。这种情况下，至于你们敢不敢上 swoole，反正我敢。。。确切说，我是从一开始就直接用了 swoole，一直从几千用户支撑到了百万（可不是一百万，比这个还要高）以上。

说下这个东西相对于 fpm 的优势：
1、常驻内存，节省了 php 代码反复解析耗费的资源
2、可以使用长链接方式连接 mysql 等数据存储介质
3、可以使用 TCP 协议了
4、服务器上确实不用部署 nginx，fpm 了

我们从来没有尝试过异步写业务，这里的准则就是“没有钢筋钻，不烂瓷器活”。

swoole 在项目里的主要用途是部署内网 RPC 服务，对外则有 API Gateway 统一协议，端上是无法连接到 swoole 服务器的。

1、我们用的比较保守，尚未遇到过 core dump
2、内存泄漏一直是有的，但没有那么严重，除非你自己手很残，这个问题可以通过 max-request 参数来解决，类似于 fpm 中的 max-request

不会推荐，也不会不推荐，毕竟也不是什么银弹，用站着说话不腰疼的方式说就是“其实就是个 epoll 高性能网络库+worker 进程（只不过这个 worker 中能写异步代码也能写同步代码）”。

然后是这个东西在大公司，一直是没什么场景的，尽管天峰在不断布道。原来我在 momo 的时候，我知道的只有我们部门一个小项目在用；现在我在 didi，除了王晶（桶哥）那个部门，其他部门也暂未听说有场景应用。不过有趣的是，最近天峰去 momo 专门布道 swoole 了，是我 momo 同事告诉我的。

swoole 本身的值得尊重的，毕竟他弥补了现有 PHP 生态里最大的缺陷；但是，我并不会说什么但是，没有了。

对于绝大部分 PHPer 从业者而言，如果自身不具备科班出身或者较为踏实的基础，swoole 看起来很难，你不能指望以前连进程、socket 等、同步异步阻塞非阻塞这些概念都不理解的人能很快接受吸纳这个东西；

但实际上对于科班出身或者基础较为踏实的人来说，这个东西其实确实也没什么的。


最后说点儿有用的，如果你打算转 swoole，而且你的小伙伴基础不太好，最好保证你的小伙伴们快速熟悉一下下列概念，对于开展工作会有很大帮助，我认为是算是短期育肥比较有效的方法：
1、进程
2、进程间通信
3、同步异步阻塞非阻塞
4、socket，epoll
5、TCP 协议，主要是拆包，粘包概念

然后安利一下当初我们用的基于 swoole 1.9.22 封装的东西，希望你协助你快速开展业务拆分： https://github.com/elarity/ti-rpc

这个比 swoft 粗暴粗旷很多，几乎没有做什么厚重封装，理解起来会快太多太多

[gouchaoer]

@elarity swoole 的醍醐味就在于类似 golang 那样的协程，所以 2.0 以下的版本感觉比较鸡肋

[salamanderMH]

@sunmoon1983
是的，自己开个 http server。不过就像楼上说的，有内存泄露问题，我也是用 max-request 解决的。
@gouchaoer nodejs 有 await 和 async，写起来就跟同步代码一样

[tanszhe]

楼主可以试试这个 https://github.com/lizhichao/one
完全支持 fpm 和 swoole 的协成。如果觉得 swoole 不保险，完全可以在 fpm 下运行。
非常轻量的框架，如果用过 laravel tp 或者 yii 可能有似曾相识的感觉。

[gouchaoer2]

@salamanderMH await 和 async 也有 callback hell 问题啊，而且 php 和 nodejs 的生态最大的不同是 js 的 api 天生是异步的，而 php 天生是同步的，这就导致了一个问题，要把 php 的 api 改造成 async/await 都会遇到 callback hell 问题。。。于是干脆 hook 统一协程化

[2kCS5c0b0ITXE5k2]

如果是自己的项目随便玩啊,如果是工作还是快点写完摸鱼把,别老想着搞新技术,老板不认的.还嫌弃你做的慢....

[k9982874]

@gouchaoer #13 我觉得你对 node.js 有误解

[sagaxu]

@abcbuzhiming swoole 哪来的 jit?
@liaohongxing openssl 也有 free 无法释放的资源
@gouchaoer2 await 和 async 也有 callback hell 问题? 能举个例子吗

[gouchaoer2]

@sagaxu 如果把一个同步的 api 换成 async 的 api，那这个 api 就得一层层往里改 async

[sunmoon1983]

@zjsxwc 何以见得?

[sagaxu]

@gouchaoer2 https://jsfiddle.net/5ste9ou8/

function fa() {
(async function() {
const v = await fc();
alert(v);
})();
}

function fb() {
fc().then(function(v) {
alert(v)
});
}

async function fc() {
const a = await ft(1000) + await ft(2000);
return a;
}

function ft(delay) {
return new Promise(function(resolve, reject) {
setTimeout(function() {
resolve(delay);
}, delay);
})
}

ft 是一个传统的返回 Promise 的函数，它 sleep 指定的时间后返回。
fc 是一个 async 函数，因此 fc 里面可以 await ft 返回的 Promise，用同步的写法。
fb 不是 async 函数，所以它可以把 fc 的返回值当作 Promise 使用。
fa 也不是 async 函数，但是它可以使用 async 闭包 await fc 的返回值。
async 函数中也能使用回调，比如 function fb()改成 async function fb()也是对的。

被标记为 async 的函数 fc，
它不会把 async 往下层传递，下层继续使用 Promise，ft 是不需要关心它的调用者是不是 async 函数
它也不会把 async 向上层传递，fb 把它当作一个返回 Promise 对象的函数使用，fa 则通过 async 闭包调用它。
fa 和 fb 都是普通函数，他们的调用者可以是任意的函数，跟 async 一点儿关系都没有。

假如你把某个 API 换成了 async 的，作为使用者，我不需要做任何修改。但是 API 的内部实现，你可以获得 async/await 的便利性了。async 的传染性，只在你希望加入 await 的那一层，它不强迫调用它的上层函数做改变，也不强迫被它调用的下层做改变。


如果把一个同步的 api 换成 async 的 api，那这个 api 就得一层层往里改 async
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 这个一层层往里改，如何体现？

[salamanderMH]

@gouchaoer2 不用一层层改，套一层 Promise 就可以了

[zjsxwc]

@sunmoon1983

swoft 整体设计比 yii2 先进，比如 yii2 的依赖注入有点简陋，又比如 github 上那个 star 很多的 yii2 模板项目里面不少硬编码反模式改都改不了。

[gouchaoer2]

@sagaxu 我看不太懂，js 太难了

[sunmoon1983]

@zjsxwc 但是，我看 swoft 的 issue 里面也有好多问题~~而且，我们的商城业务肯定不会太简单，单独使用 swoft 的内置 server 我怕搞不定。。。

[flowerains]

@elarity 很赞成你说的这些话。
我们公司也是少有的把 swoole 用在生产环境的公司，希望有机会一起交流一下~

[elarity]

@flowerains 嗯，联系方式 https://t.ti-node.com/about

[sagaxu]

@gouchaoer2 js 的确复杂，我也不太懂。不过关于 async 传染性这一点，还是不要以讹传讹了。

[sagaxu]

@flowerains 我司可能是 swoole 最大用户之一了，swoole 处理的日请求量超过百亿

[Govda]

不如稳一手使用 fpm，选择这玩意儿写简单的项目还好，一旦大项目失控了转身成本太高。

[flowerains]

@sagaxu 我司虽然请求量没有达到这个数量级，但是遇到的坑也是非常多。

今年使用 swoole 之后，觉得在排查和解决问题上面，给使用者提出了非常高的要求。
我苦于基础支持不扎实和本身对于 swoole 不了解，在这上面吃了很多亏。
不过在未来的一段时间内，还是要继续使用。。。

兄弟方便留个联系方式交流交流？

[banyancheung]

@sagaxu 按照这个数量级，用在一般的生产环境上肯定是没啥问题了吧

[runAll]

既然大多时间都在使用 Yii2, 项目又需要赶时间,
还是推荐使用 Yii2 (nginx+fpm),
根据业务设计好 cache, 开启 APC, 相信瓶颈不会在 fpm(或者 Yii2)上, 如果真有问题还可以负载均衡来救场.
项目的附加功能可以考虑 swoft 试水, 比如: API, WebSocket, SSO, 邮件 /短信通知

[hcheng]

用了不熟悉的技术,到时候有的爬坑

[sunmoon1983]

@runAll 嗯，我觉得这种方案最稳~~

[slince]

yii 也可以常驻内存运行

roadrunner/php-pm + yii2 ; 来替换 nginx+fastcgi + yii2 的组合

[zcmzcm]

看到有提 Swoole 1.9 版本, 吓得我看了下发帖时间...
这都 Swoole 4.2 了, 大家还是有必要去学习使用下 Swoft 的
而且 Swoft 2.0 正在开发中哦
跟 Yii 等 FPM 框架最大的不同我认为应该是生命周期
见过好多小伙伴在 Controller 属性里存放请求的信息
这样会爆炸的... 因为 Controller 是全局生命周期
总体来说呢 , 即使现在不用也可以看下
注解, AOP, 代理, 事件, 总有一款适合你

[loudefa]

@emeab 说得很对。。

[loudefa]

如果引入的问题比解决的问题多。。。那暂时是没法用。。