Composer仅是PHP依赖管理工具，不提供负载均衡能力；实现分布式调度需叠加Docker+Consul/Nginx等运行时架构，通过服务发现、反向代理和健康检查动态分发请求。
Composer 本身不提供分布式调度或负载均衡能力——它只是 PHP 的依赖管理工具，不是服务编排器或流量分发器。想实现“分布式调度+负载均衡”，必须在 Composer 之上叠加运行时架构层（如 Docker + Consul/Nginx + 多实例服务），而不是靠改 composer.json 或调用某个 composer 命令。
为什么不能直接用 Composer 做负载均衡
Composer 的职责仅限于：解析依赖、下载包、生成自动加载映射、执行脚本钩子（如 post-install-cmd）。它没有网络监听、请求路由、健康检查、服务注册/发现等能力。
常见误解是把 composer install 在多台机器上执行，就等于“分布式部署”——这只是复制了代码和依赖，没解决请求如何分发、状态如何同步、故障如何转移的问题。
- 执行
composer install是构建阶段动作，发生在容器镜像构建或部署前 - 真正承担请求的是运行时进程（如 PHP-FPM + Nginx、Swoole HTTP server、Laravel Octane 等）
- 负载均衡必须作用于这些运行时进程的入口端，而非依赖安装环节
Docker Compose + Nginx 实现基础集群负载均衡
这是最轻量、可落地的 PHP 微服务集群方案，适用于中小流量场景。核心是让多个 PHP 应用实例暴露相同内部端口，由 Nginx 反向代理做轮询分发。
关键点：
-
docker-compose.yml中定义多个相同服务的副本（deploy: replicas: 3），每个副本启动独立容器 - Nginx 容器通过 Docker 内置 DNS 名称（如
php-app）访问服务名，Docker 自动做 DNS 轮询（非严格负载均衡，但够用） - 若需更精准策略（如 least_conn、ip_hash），必须用显式 upstream 配置，且将 PHP 实例设为固定名称或用额外服务发现机制
- 务必关闭 PHP 的
opcache.revalidate_freq=0或设为合理值，避免多实例间配置热更新不一致
示例片段（Nginx 配置部分）：
upstream php_backend {
least_conn;
server php-app-1:9000;
server php-app-2:9000;
server php-app-3:9000;
}
Consul + Registrator 实现动态服务发现与健康感知
当 PHP 实例数量动态伸缩（如基于 CPU 触发扩容）、或需要自动剔除故障节点时，静态 Nginx upstream 就不够用了。此时需引入服务注册中心。
实操要点：
- 每个 PHP 容器启动时，由
registrator自动向Consul注册自身 IP+端口+健康检查路径（如/health） - Nginx 需配合
nginx-consul-template或 OpenResty +lua-resty-consul，定时拉取 Consul 中健康的php-app实例列表并重写 upstream - PHP 应用必须暴露真实健康接口（返回
200 OK且无延迟），不能只依赖进程存活 -
Consul的advertise_addr必须填宿主机可路由的 IP，否则注册进来的地址无法被 Nginx 访问
容易被忽略的三个硬性前提
无论用哪种方式，以下三点不满足，负载均衡就是假象：
- 所有 PHP 实例必须共享同一套外部状态：Session 存 Redis、文件上传走对象存储（如 MinIO）、缓存统一用
Redis Cluster或Memcached，不能依赖本地文件或内存 - 数据库连接池需支持连接复用和故障自动重连，
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION必须开启，否则错误静默导致请求卡死 - 日志不能只打到
stdout就完事——要用monolog+gelf或logstash统一收集，否则排查某次请求在哪台实例上失败会极其困难
