一台跑着 Nginx 的系统下 CentOS 机器，后面挂两个 PHP-FPM 进程池，网站数据库单独扔在另一台装了 MySQL 8 的架构 Debian 上——这套东西撑住了我见过的大多数中小型网站。没什么玄乎的系统下，Linux 下的网站网站架构翻来覆去就那几层，只是架构每层选型不同，拼出来的系统下脾气也不一样。

最前面那层通常是网站 Nginx。它占资源少，架构并发连接处理得漂亮，系统下静态文件直接扔给它就行。网站我自己的架构博客就是 Nginx 直接吐 HTML，PHP 请求才转发给后端。系统下Apache 也有人用，网站模块多，架构.htaccess 方便，但高并发下内存吃得厉害。选哪个？看团队熟悉什么，别为了技术而技术。

server {  listen 80; server_name example.com; root /var/www/html; index index.php index.html; location / {  try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ {  fastcgi_pass unix:/run/php/php8.1-fpm.sock; include fastcgi_params; } }

这段配置我用了三年，没出过岔子。fastcgi_pass 指向 PHP-FPM 的 socket，比 TCP 端口少一层网络开销。PHP-FPM 的进程池要调，pm.max_children 设小了请求排队，设大了内存爆掉。我一般按 可用内存 / 单进程平均内存 来估，再留 20% 余量。

数据库这层最容易出事。MySQL 默认配置是给开发机用的，innodb_buffer_pool_size 只给 128M，生产环境跑起来磁盘 IO 直接拉满。调到物理内存的 50% 到 70%，查询速度立竿见影。有人图省事把数据库和 Web 塞同一台机器，流量一上来互相抢资源，最后一起挂。分开部署，哪怕只是两台低配 VPS，稳定性也好得多。

缓存是绕不开的。Redis 存 session 和热点数据，Memcached 做纯 KV 缓存，各有各的场子。我见过一个电商站，商品详情页每次查库，QPS 一过 200 数据库就喘。后来加了一层 Redis，同样的查询直接命中内存，数据库负载掉到十分之一。不是所有项目都需要缓存，但流量上来之后，没缓存基本等于裸奔。

文件存储得单独说。用户上传的图片、附件，别放 Web 目录里跟代码混着。挂一块独立的数据盘，或者用 NFS 共享给多台 Web 服务器。再讲究点就上对象存储，MinIO 自己搭或者用云厂商的 S3 兼容接口。好处是 Web 服务器可以随意增删，文件不丢。

负载均衡这步看规模。两台 Web 服务器用 Nginx 的 upstream 轮询就够了，配个 keepalived 做 VIP 漂移，前端感知不到后端挂了。再大就上 LVS 或者 HAProxy。我见过有人一上来就搞 Kubernetes，结果三个人的团队维护成本比业务本身还高。技术选型要匹配团队能力，不是越新越好。

监控和日志别等出事才补。Prometheus 抓 Node Exporter 和 MySQL Exporter 的指标，Grafana 画图，Zabbix 也行。日志用 ELK 或者更轻的 Loki + Promtail。有一次线上响应变慢，查 Grafana 发现磁盘 IO wait 飙高，定位到是备份脚本在高峰期跑，挪到凌晨就解决了。没监控的话，这种问题得靠猜。

安全层面，防火墙只开 80、443 和 SSH 端口，数据库端口绝不对外。SSH 禁用密码登录，用密钥。Web 目录权限设好，上传目录禁止执行 PHP。这些是底线，不是可选项。

整套架构没有标准答案。日 PV 几千的站，一台 2C4G 的 VPS 跑 Nginx + PHP + MySQL 绰绰有余。日 PV 百万的站，每层都要拆开、冗余、水平扩展。关键是知道每层在干什么，瓶颈可能出在哪，然后按需堆机器。别照搬大厂方案，那是给几千台机器准备的。