既然Nginx比Apache快,为什么Nginx没有取代Apache?

netcraft统计,2016年2月份,在排名前一百万最繁忙的站点中,Apache约46%,Nginx约25%,IIS不足12%.值得注意的是,在前百万繁忙的站点中,Nginx份额接约25%并保持增长趋势,Apache和IIS均呈下降趋势.也就是说高并发的网站转向Nginx是趋势,比如国内阿里使用的Tengine就是基于Nginx二次开发的分支.

而对于大多数虚拟主机用户来说,根本谈不上高并发,因为带宽才是瓶颈,2M带宽还谈什么并发,是吧.而且Apache支持不用重载配置的.htaccess配置,在易用性上要比Nginx配置好一些.也就是Apache+PHP架构要比Nginx简单,在不追求什么并发的场景,为什么要换一套架构呢?够用能用好用就行了呗.

Nginx返回502 Bad Gateway错误不是因为Nginx的问题,而是因为后端的问题.
比如后端PHP-FPM在处理一个请求时进程崩溃了,那么Nginx就会返回502错误.
当然你可以用fastcgi_next_upstream配置让Nginx把请求转移给另一个upstream处理.
fastcgi_next_upstream error timeout invalid_header http_500 http_502 http_504;
Nginx+PHP-FPM实现了动静分离,负载均衡,故障转移,在高并发场景确实要比Apache有优势.
内置PHP模块的Apache进程在处理PHP时就无法处理静态资源,而Nginx则不需要担心这个问题,因为处理PHP是PHP-FPM的事,这就是动静分离.而且Nginx支持upstream配置PHP-FPM集群实现负载均衡,这点也是Apache不擅长的.

PHP-FPM配合Nginx还可以把I/O密集操作分离出来,减少阻塞对整个PHP应用的影响.
用户下载和curl请求是典型的I/O密集型操作,因为耗时主要发生在网络I/O和磁盘I/O.
需要PHP认证的下载操作可以委托为Nginx的AIO线程池:
header("X-Accel-Redirect: $filepath");
至于curl操作,比如可以建立一个监听9001端口的名为io的PHP-FPM进程池(pool),
专门负责处理curl操作(通过Nginx分发),避免curl操作阻塞到监听9000端口的www进程池.
这时io进程池多开点进程也无所谓:

nginx.conf: 访问io.php的请求都交给监听9001的PHP-FPM进程池处理location = /io.php {
    include fastcgi_params;
    fastcgi_pass 127.0.0.1:9001;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
php-fpm: 正常脚本由静态www池处理,阻塞脚本由动态io池处理
[www]
;名为www的进程池监听9000端口,常驻进程数量为固定4个listen = 127.0.0.1:9000pm = static
pm.max_children = 4[io]
;名为io的进程池监听9001端口,进程数常驻4个,最大8个listen = 127.0.0.1:9001pm = dynamic
pm.max_children = 8pm.start_servers = 4pm.min_spare_servers = 4pm.max_spare_servers = 4

其中I/O密集这个进程池[io]采用动态的prefork进程,比如这里是繁忙时8个,空闲时4个.
利用PHP-FPM提供的池的隔离性,分离计算密集和I/O密集操作,可以减少阻塞对整个PHP应用的影响.

写在最后:

任何东西都有优点和缺点 所以完全替代会很难 最好就是结合着用 再说以前好多都用的apache 好多人懒得弄新的东西 人们刚开始对新的事物都有抵触心理 就好像你没来帝都的时候回想地铁挤得要死 节奏快 当你真的来了会发现也没那么恐怖