PHP cli模式和fpm模式有什么区别、优缺点？

基于CLI写HTTP服务的PHP开发者水平,一般来说是要比FPM高一些.主要还是因为Nginx/PHP-FPM这套架构比较完备可靠,开发者不需要考虑太多业务逻辑外的问题.HTTP/HTTPS这些协议的解析和实现,并不需要PHP-FPM下的PHP程序关心,单个请求内的脚本运行周期,也不用担心内存泄漏这种问题,还有就是PHP-FPM自带一套进程管理机制,保证总是有工作进程在服务,服务基本上是不会中断的.而如果你是自己基于CLI写HTTP服务,你就要关心更多东西了.首先,因为代码逻辑常驻内存,代码默认没有热更新,你定义了新的类和函数,必须重启服务才能生效,服务会出现中断的问题(表现为长连接会断开).还有,你要自己实现一套进程管理机制,保证服务进程因为代码出错退出后自动重启一个新的进程,比如说PHP语法错误就会导致CLI进程直接退出,却不会导致FPM进程退出.还有,你要自己实现一套多进程架构来利用CPU多核,PHP里你需要用到的pcntl和posix这两个跟进程编程相关的扩展库.还有,你为了体现出超越FPM这种阻塞型架构的优势,你还得为你的CLI服务增加事件驱动的支持,PHP里你需要用到event(基于libevent)这类事件通知库,来体现出单个进程维持C10K个连接这种FPM不具备的能力,还有非阻塞的定时器等等之类的特性.最好还得有非阻塞的Redis客户端,实现非阻塞的brpop和subscribe这些在FPM下会导致明显长时间阻塞的获取消息的操作.对了,你还得自己实现HTTP的解析,自己把读到的原始数据,根据HTTP/1.1,对其进行解析,把TCP/UDP协议的五元组(协议, 源IP地址, 源端口, 目的IP地址, 目的端口)和HTTP/1.1里的(请求行+请求头+请求体)+(响应行+响应头+响应体)都解析出来,赋值给对应变量,因为你不能像FPM里直接用 ${}_{S}ERVER,$_POST,${}_{G}ET,$_COOKIE,$_FILES 拿到这些数据.这也就意味着你要对HTTP协议很熟悉,否则举步维艰.而且这还只是HTTP/1.1这种文本类型的协议,如果你要支持HTTP2/HTTP3,你还得重新搞一套解析方案,相当蛋疼.对了,为了实现对HTTPS支持,你还得专门去实现SSL那块支持,这也是个麻烦事.<?php
// 下面是使用PHP开发基于Event扩展(依赖libevent库)的事件驱动的单进程HTTP/1.1服务器.
// 本质上调用的是libevent库内置的那个HTTP服务器,libevent算是封装的东西很多的事件库了.
// 看着好像能用,但其实很多还得靠自己实现,比如POST数据的解析(包括文件上传等).
// 而且是个单进程服务(孤儿),明显不能利用多核,还得自己实现一套多进程架构.
$base = new EventBase();
$http=newEventHttp($base);
$http->bind(‘0.0.0.0’, 8888);
$http->setDefaultCallback(function($req) {
$uri = $req->getUri(); // 分析URI,进行路由
$html = ‘Hello World’; // 渲染模板,返回HTML
$buf = new EventBuffer();
$buf->add($html);
$req->sendReply(200, ‘OK’, $buf);
});
$base->loop();
PHP-FPM模式下其实也提供有一些内存常驻的支持,比如开启了MySQL/Redis持久连接后,在请求结束时,FPM进程并不会断开这些连接.opcache则会把PHP文件解析后生成的中间码opcode缓存在内存(或文件),避免每次请求都重复解析PHP文件.另外,PHP 7.4引入的opcache.preload可以实现PHP类和函数的内存常驻,避免每次请求都定义一次类和函数,从而提升网站性能.在ZendFramework框架的测试中,开启预加载(opcache.preload)后性能提升30%到50%,框架越庞大,提升越明显.PHP-FPM模式下也提供了一些非阻塞的支持,比如可以调用fastcgi_finish_request()结束请求后继续执行其他代码.另外,还利用PHP-FPM提供的池的隔离性,配合Nginx重写把不同请求分配到监听不同端口的PHP-FPM进程池,把带有明显长时间阻塞操作(subscribe/brpop)的请求分离出来,减少阻塞对整个PHP服务的影响.所以,躲在Nginx这种完备的HTTP服务器后面,安安心心在PHP-FPM的保护下进行PHP开发,专心实现业务逻辑,其实也是一种不错的选择,毕竟稳定压倒一切.
技术软件咨询