PHP 与 Laravel 服务部署前如何规划？环境、容量与依赖清单

环境划分：从开发到生产，每一层都有明确目标

很多团队在部署 Laravel 项目时，只区分了开发环境和生产环境，这种做法在单人项目或原型阶段可以接受，但一旦涉及多人协作、持续交付或客户验收，问题就会集中爆发：测试环境的数据被开发脚本污染、生产配置意外被提交、性能测试结果不可复现。

合理的环境划分至少需要四个层级：

• **开发环境**：每个开发者独立运行，使用本地数据库和缓存服务。Laravel 的 `.env` 文件在这里管理本地配置，不需要提交到版本控制。建议使用 Docker Compose 统一 PHP、Nginx、MySQL 和 Redis 的版本，避免“在我机器上能跑”的争议。PHP 版本应和生产环境一致，例如生产用 PHP 8.2，开发环境就不该用 8.1 或 8.3。
• **测试环境**：用于自动化测试和人工冒烟测试。这个环境的数据应来自生产环境的脱敏副本，或者使用工厂生成的模拟数据。关键点是：测试环境的数据库连接字符串、队列驱动、邮件驱动必须和开发环境隔离，避免测试邮件误发给真实用户。
• **预发布环境**：这是最容易被省略的环境。预发布环境的配置、依赖版本、硬件规格应尽量复制生产环境。部署流水线在合并到主分支后，先部署到预发布环境运行集成测试和压力测试，通过后再上线。Laravel 的 `APP_ENV` 在这里设置为 `staging`，同时关闭 `APP_DEBUG`，模拟真实生产行为。
• **生产环境**：核心原则是“最小化变更”。PHP 扩展、Composer 依赖、系统包都应该通过基础设施即代码（如 Ansible 或 Terraform）声明式管理，不允许手动登录服务器修改配置。生产环境的 `.env` 文件通过密钥管理服务（如 AWS Secrets Manager 或 HashiCorp Vault）分发，不写入磁盘明文。

环境之间的数据流动必须单向：生产数据可以脱敏后流向预发布和测试环境，但测试数据绝对不能反向流入生产。实践中，很多事故源于开发人员将测试环境的数据库连接指向了生产库，导致批量误操作。解决方案是在数据库连接配置中显式校验 `APP_ENV`，如果环境不匹配则拒绝连接。

容量估算：不依赖公式，依赖业务场景

容量估算没有万能公式，因为每个 Laravel 项目的瓶颈不同。有的项目是 CPU 密集型（如图片处理），有的是 I/O 密集型（如数据库查询），有的是内存密集型（如队列任务处理）。正确的做法是先识别瓶颈，再估算容量。

以下是一个可操作的估算流程：

1. **确定峰值并发用户数**：不是注册用户数，而是同一时间发起请求的用户数。可以通过现有日志、业务预期或同类系统参考值来估算。例如一个面向内部员工的管理系统，500 人使用，峰值并发可能在 50 到 100 之间；一个面向公众的电商小程序，峰值并发可能是注册用户的 5% 到 10%。
2. **分析每个请求的资源消耗**：在开发环境中使用 Xdebug 或 Tideways 对核心接口做性能剖析。重点关注数据库查询次数、内存分配量和执行时间。一个典型的 Laravel 接口，如果包含 10 次以上 Eloquent 查询且未使用懒加载，单次请求内存可能超过 50MB。
3. **计算最低配置**：假设一个 PHP-FPM 进程消耗 40MB 内存，处理一个请求需要 200ms，那么一个 2 核 4GB 的云服务器，在 PHP-FPM `pm.max_children` 设置为 50 的情况下，理论上可以支撑每秒 250 个请求（50 进程 / 0.2 秒）。但实际要考虑数据库连接池、Redis 连接数、磁盘 I/O 等瓶颈，所以建议将理论值打 30% 到 50% 的折扣。
4. **预留缓冲空间**：生产环境的 CPU 和内存使用率建议保持在 60% 以下，超过 80% 时应触发扩容告警。对于 Laravel 队列，如果使用 Horizon，需要单独为队列进程分配服务器，避免队列任务抢占 Web 请求的资源。

需要特别注意的是：Laravel 的 `php artisan optimize` 命令会缓存配置、路由和视图，显著降低每次请求的启动开销。在生产环境部署脚本中必须执行此命令，否则每个请求都会重新加载所有服务提供者，内存消耗会增加 30% 到 50%。

依赖清单：不仅仅是 Composer

Laravel 项目的依赖远不止 `composer.json` 里列出的包。一份完整的依赖清单应该包含四个层次：

• **系统级依赖**：PHP 版本（建议 8.1 以上）、PHP 扩展（如 `pdo_mysql`、`mbstring`、`xml`、`curl`、`gd` 或 `imagick`、`redis`、`opcache`）、Web 服务器（Nginx 或 Apache）、进程管理器（Supervisor 用于队列和调度器）。如果使用 Laravel Octane，还需要 Swoole 或 RoadRunner 扩展。这些依赖必须在部署文档中明确版本号，例如“PHP 8.2.15 + Nginx 1.24 + Supervisor 4.2”。
• **应用级依赖**：Composer 包（包括 `laravel/framework`、`laravel/horizon`、`laravel/sanctum` 等）、前端构建产物（Vite 或 Mix 生成的静态文件）、数据库迁移文件。需要注意的是，Composer 的 `--no-dev` 参数必须在生产部署时使用，避免将开发工具包（如 `nunomaduro/collision`、`barryvdh/laravel-ide-helper`）部署到生产环境。
• **中间件依赖**：数据库（MySQL 8.0 或 MariaDB 10.6 以上）、缓存（Redis 6.x 或 Memcached）、队列驱动（Redis 或 SQS）、会话驱动（Redis 或数据库）、日志服务（文件或 ELK）。每个中间件的连接参数、超时设置、重试策略都需要在 `.env` 中独立配置。
• **外部服务依赖**：邮件服务（SMTP 或 API）、对象存储（如 AWS S3 或 MinIO）、第三方 API（支付、短信、地图）。这些服务的 API 密钥、端点地址和限流策略必须记录在部署检查清单中。

一个常见的问题是：Laravel 的调度器（`php artisan schedule:run`）依赖服务器上的 Cron 服务。很多团队部署了应用却忘记配置 Cron 条目，导致定时任务完全不执行。部署脚本中应该包含一条 `* * * * * php /path/to/artisan schedule:run >> /dev/null 2>&1` 的 Cron 配置。

网络拓扑：分层隔离与流量走向

PHP 与 Laravel 服务的网络拓扑设计遵循“分层隔离”原则，不推荐将所有服务部署在同一台服务器上。

一个典型的四层拓扑如下：

• **负载均衡层**：使用 Nginx 或 HAProxy 作为反向代理，负责 SSL 终止、流量分发和健康检查。所有外部请求首先到达这一层。如果使用 Laravel Octane，负载均衡器需要支持长连接保持。
• **应用层**：PHP-FPM 进程或 Octane 工作进程运行在此层。多个应用实例应部署在不同的服务器或容器中，通过负载均衡器分发请求。应用服务器不应直接对外暴露端口，只接受来自负载均衡层的请求。
• **数据层**：包括 MySQL 主从集群、Redis 哨兵或集群、对象存储服务。应用服务器通过内网连接数据层，不经过公网。数据库连接字符串应使用内网 IP 或服务发现名称。
• **队列与调度层**：独立的服务器或容器运行 Laravel Horizon 和 Cron 调度器。队列任务从 Redis 中拉取，处理结果写入数据库或触发事件。这一层与数据层直接通信，不与 Web 请求层共享资源。

网络隔离的关键点在于：应用服务器不能直接访问公网数据库，队列服务器不能暴露 SSH 端口，负载均衡器应配置 IP 白名单。Laravel 的 `config/session.php` 中的 `secure` 选项在生产环境必须设置为 `true`，确保 Cookie 仅通过 HTTPS 传输。

对于中小型项目（并发低于 500），可以将应用层和队列层合并部署，但必须使用 `pm.max_children` 和 Horizon 的 `maxProcesses` 参数限制资源占用，避免队列任务耗尽 PHP-FPM 进程池。

责任边界：谁负责什么，部署前必须明确

部署前的责任划分直接影响故障响应速度和运维效率。以下是一个经过多次项目验证的责任矩阵：

• **开发团队**：负责应用代码、Composer 依赖、数据库迁移、环境变量模板（`.env.example`）、部署脚本（Deployer 或 GitHub Actions）。开发团队需要提供一份部署检查清单，包括 PHP 扩展列表、系统包列表、配置文件路径和启动命令。
• **运维团队**：负责服务器初始化、系统级依赖安装、网络配置、监控告警（如 Prometheus + Grafana）、日志收集（如 ELK Stack）、备份策略。运维团队需要提供中间件的连接信息和访问权限。
• **双方共同**：负责容量规划、压力测试、回滚方案、灾难恢复演练。部署前应进行一次完整的回滚演练：从生产环境回滚到上一个版本，验证数据库迁移的回滚脚本是否正常工作。

一个常见但危险的误区是：开发团队认为运维团队会自动处理所有系统依赖，运维团队认为开发团队会在代码中处理好所有配置。结果往往是部署时发现缺少 PHP 扩展、Redis 未启动或队列驱动配置错误。解决方法是：在 CI/CD 流水线中加入环境检查步骤，使用 `php -m` 检查扩展列表，使用 `composer check-platform-reqs` 验证平台要求。

在实际项目中，SystemDo 曾经处理过一个案例：客户的生产服务器 PHP 版本是 7.4，但 Laravel 项目要求 8.1，导致部署后首页 500 错误。事后分析发现，开发团队在本地使用了 Laravel Sail（默认 PHP 8.1），运维团队按照旧文档安装了 PHP 7.4，双方都没有在部署前核对 PHP 版本。这个问题的根本原因是缺少一份双方共同维护的环境依赖清单。

部署前自检清单

结合以上五个方面，整理一份可执行的部署前自检清单：

1. 环境变量：`APP_ENV=production`、`APP_DEBUG=false`、`APP_URL` 正确。
2. PHP 版本：与 `composer.json` 中 `require` 字段匹配。
3. PHP 扩展：运行 `php -m` 核对清单，确保 `opcache` 已启用。
4. Composer 依赖：运行 `composer install --no-dev --optimize-autoloader`。
5. 数据库迁移：运行 `php artisan migrate --force`，确认无挂起的迁移。
6. 缓存优化：运行 `php artisan optimize`。
7. 文件权限：`storage/` 和 `bootstrap/cache/` 目录对 Web 服务器用户可写。
8. Cron 配置：添加调度器条目。
9. 队列配置：启动 Supervisor 进程，确认 Horizon 正常运行。
10. 日志配置：`LOG_CHANNEL` 设置为 `daily` 或 `syslog`，避免日志文件无限增长。
11. 监控告警：配置 PHP-FPM 状态页面、Horizon 监控页面、MySQL 慢查询日志。
12. 回滚方案：确认数据库迁移回滚脚本可用，保留上一个版本的代码包。

这份清单不是一次性的，每次部署前都应该逐项检查。建议将其集成到 CI/CD 流水线的最后阶段，任何一项失败都阻止部署继续。

总结

PHP 与 Laravel 服务的部署规划不是一次性的技术动作，而是一个持续的过程。环境划分决定了团队协作的效率，容量估算决定了服务的稳定性，依赖清单决定了部署的可重复性，网络拓扑决定了安全性，责任边界决定了故障响应速度。这五个方面缺一不可，任何一个环节的疏忽都可能导致线上事故。

对于计划部署 Laravel 项目的团队，建议在项目启动阶段就建立环境规范和部署流程，而不是等到上线前才匆忙准备。一个经过充分规划的部署方案，可以在项目生命周期内节省大量故障排查时间。