由Nginx集中代理分散的PHP集群的实践 | 二丫讲梵
二丫讲梵 首页 运维 最佳实践 迎刃而解 Nginx Php Zabbix Prometheus Grafana CentOS Systemd Docker Rancker Ansible Ldap Gitlab GitHub Etcd Consul RabbitMQ Kafka MySql MongoDB OpenVPN KVM VMware Other 专题 ELK K8S LLM Nexus Jenkins 生活 随写编年 家人物语 追忆青春 父亲的朋友圈 电影音乐 效率工具 博客相关 编程 Shell 前端实践 Vue学习笔记 Golang学习笔记 Golang编程技巧 周刊 学习周刊 Obsidian插件周刊 关于 友链 页面 本站索引 分类 标签 归档 本站页面 导航 打赏 我的工具 备忘录清单
(opens new window)
json2go
gopher
微信MD编辑
国内镜像
出口IP查询
代码高亮工具
外站页面
开往
ldapdoc
HowToStartOpenSource
vdoing-template
行者常至，为者常成
（点击图片了解详情）
关于nginx请求头中有下划线_的坑
利用nginx+sftp实现一个可供用户下载的服务
nginx配置文件及模块
通过脚本按天切割nginx的日志
nginx通过四层代理实现端口转发
NGINX基于cookie针对同一域名进行分流转发
nginx利用内置模块配置限速限流
利用NGINX内置模块mirror进行流量复制等操作
使用$remote_user字段记录访问NGINX的用户
从NGINX自身配置文件中定义访问日志按时间切割
NGINX配置单独代理百度的sitemap文件
nginx配置微信小程序校验及其他
nginx配置gzip压缩
由Nginx集中代理分散的PHP集群的实践
1，以往
2，现在
3，另外
http状态码详解
OpenResty-1-13-6-2-新增ldap模块儿
排查NGINX的open_file_cache导致发布后访问404的问题
制作OpenResty-1-19-9-1的RPM包
从Nginx过滤打印user-agent为clb-healthcheck的日志聊聊Nginx的日志自定义打印
Loki
Supervisord
Docker-Compose
Rancher
OpenLdap
GitLab
Mysql
Kvm
配置文件详解
运维观止
2021-01-24
目录
文章发布较早，内容可能过时，阅读注意甄别。
(adsbygoogle = window.adsbygoogle || []).push({});
以往的 PHP 项目处理方案大多沿用了经典的 lnmp，然后几乎有 PHP 的主机都会配套一个 Nginx，接着有多少个 PHP，就会有多少个 Nginx，然后 lb 后边就得挂上这所有的 Nginx。
但事实上还可以用如下办法来将 PHP 分散管理。
Nginx 主配置像配置 Java 应用一般反代转发给 PHP 服务：
upstream php-fpm
server
127.0
.0.1:9006
weight
max_fails
300
fail_timeout
5s
.0.1:9007
listen
80
server_name
10.3
.7.7
proxy_connect_timeout
proxy_read_timeout
fastcgi_connect_timeout
fastcgi_send_timeout
fastcgi_read_timeout
location /
root /data/www/liql
index index.php index.html index.htm
proxy_set_header Host
$host
proxy_set_header X-Real-IP
$remote_addr
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for
try_files
$uri
/ /index.php?
$query_string
location ~
.php
fastcgi_pass
php-fpm
fastcgi_index
index.php
fastcgi_split_path_info ^
.+
.*
include
fastcgi_params
fastcgi_param
SCRIPT_FILENAME
$document_root
$fastcgi_script_name
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
这样只需要将代码放入到 PHP 容器内即可：
cat
liql/index.php
<
?php
phpinfo
>
Dockerfile
FROM reg.eryajf.net/multienv/wpt_phpfpm:7.2.34
COPY
/data/www/
然后重新打镜像：
docker
build
-t
aaa
启动两个容器进行访问，可以发现权重很均衡的取到了两个 PHP 容器之内：
"remote_addr"
"10.105.201.43"
"@timestamp"
"2021-01-24T17:14:27+08:00"
"upstream_addr"
"127.0.0.1:9006"
"request_uri"
"/"
"verb"
"GET"
"httpversion"
"HTTP/1.1"
"response"
"200"
"body_bytes_sent"
"28892"
"referrer"
""
"user_agent"
"Mozilla/5.0 (Macintosh; Intel Mac OS X 11_1_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
"http_x_forwarded_for"
"server_name"
"10.3.7.7"
"request_time"
"0.003"
"upstream_response_time"
"realpath_root"
"cookie"
"grafana_session=02bc6ce5e1489781ff5ed00ef9fb61ca"
"request_body"
"nginx_version"
"1.13.6"
"scheme"
"http"
"2021-01-24T17:14:28+08:00"
"127.0.0.1:9007"
"28895"
"0.004"
申明
原创文章
eryajf
，未经授权，严禁转载，侵权必究！此乃文中随机水印，敬请读者谅解。
Copyright
版权所有
在测试过程中发现，如果代理的两个容器有一个没有起来，竟丝毫不影响服务的访问，转发的方式也非常有意思，从日志中观察：
"2021-01-24T17:36:27+08:00"
"28898"
"/data/www/liql"
"2021-01-24T17:36:29+08:00"
"127.0.0.1:9007, 127.0.0.1:9006"
"28899"
"0.000, 0.004"
注意日志中的
upstream_addr
字段，第一条请求被 9006 端口正常解析，第二条的解析竟然两个端口都有，也就是说，9007 端口不存在或者无法正常解析的时候，此请求会被正常的 9006 给解析掉，看错误日志里记录下了 9007 的错误：
2021
/01/24
:36:29
error
24165
#24165: *394 connect() failed (111: Connection refused) while connecting to upstream, client: 10.105.201.43, server: 10.3.7.7, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9007", host: "10.3.7.7"
注意代码的存放位置
这里有两点需要注意，一个是
root
指令不要放在 location 外边，这里是纯 PHP 解析，如果放到外边，请求的时候总会报一个本地找不到的错误：
:21:51
crit
23563
#23563: *347 realpath() "/data/www/liql" failed (2: No such file or directory) while logging request, client: 10.105.201.43, server: 10.3.7.7, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9006", host: "10.3.7.7"
这个时候把
指令放到 location 内部就不会报这个错误了。
另外注意，代码是存放在 PHP 所在主机上的，而非 Nginx 所在主机，因为
结尾的请求都是通过 fast_cgi 解析的，而非 Nginx，这里千万不要用传统的 http 代理来理解了。
所以这个地方的处理流程应该是这样的：
www.example.com
路由到www.example.com/index.php
加载nginx的fast-cgi模块
fast-cgi监听127.0.0.1:9006地址
www.example.com/index.php请求到达127.0.0.1:9000
php-fpm 监听127.0.0.1:9000
php-fpm 接收到请求，启用worker进程处理请求
php-fpm 在给定的root地址下解析PHP源码，将结果返回给nginx
nginx将结果通过http返回给浏览器
这样，就能很清晰地解析整个处理链路了。
本文实验探索的主要意义在于，在这种基础之下，我们就可以摒弃掉以往处理 PHP 业务场景的固化思维，从而将 Nginx 这层网关像处理 Java 应用那样一般，集中对 PHP 应用进行处理了，以实现集中化管理，更加便于横向扩展与运维。
#nginx
上次更新:
2024/04/25, 22:08:24
最近更新
01
学习周刊-总第156期-2024年第17周
04-25
02
基于langchaingo实现知识库对接本地模型ollama的分步探索
04-19
03
学习周刊-总第155期-2024年第16周
更多文章>
Theme by
Vdoing
| Copyright © 2017-2024
浙ICP备18057030号
跟随系统
浅色模式
深色模式
阅读模式