服务发现需PHP自行集成，核心是注册中心心跳保活与本地缓存查询；Consul因JSON/REST易用、Web UI友好，开发阶段优于etcd和ZooKeeper；网关不应替代服务自治发现。服务发现不是PHP自带的功能，它是微服务架构里“让服务自己找到彼此”的机制——PHP服务启动时告诉注册中心“我在哪儿、还活着”，其他服务要调用它时，就去注册中心查“谁在线、谁健康、谁可连”。 这事儿PHP不干，得你动手集成；不做服务发现，服务地址就得硬编码，一扩容、一重启就断。
Consul注册服务：别只发一次，要带心跳
很多新手用 Guzzle 调 /v1/agent/service/register 注册完就以为结束了，结果服务挂了注册中心还不知道，消费者还在往死节点发请求。
- 必须配合定时心跳（比如每10秒发一次
/v1/agent/check/pass/xxx），或启用 Consul 的TTL检查模式 - 注册时一定要填
Check字段，否则 Consul 默认认为“无健康检查=永远健康” - FPM 模式下无法维持长连接，建议用
Redis缓存服务列表 + 后台脚本轮询刷新，别让每次请求都打 Consul
curl -X PUT http://consul:8500/v1/agent/service/register \
-d '{
"Name": "user-service",
"Address": "192.168.1.20",
"Port": 8080,
"Check": {
"HTTP": "http://192.168.1.20:8080/health",
"Interval": "10s",
"Timeout": "2s"
}
}'
PHP客户端查服务：别直接轮询，先本地缓存再过滤
每次调用前都 GET /v1/health/service/user-service？QPS 上千时 Consul 就成瓶颈了，而且网络抖动会导致返回空列表。
- 把查询结果缓存在
Swoole\Table或APCu里，设置 5–10 秒 TTL - 返回的实例列表里带
Status: "passing"才算可用，"warning"和"critical"必须剔除 - 别忘了做负载均衡：轮询（
round-robin）适合均质节点，随机（random）更简单但可能不均，Swoole 协程下推荐用原子计数器实现线程安全轮询
etcd注册 vs Consul：选错注册中心会卡住你的调试节奏
etcd 的 HTTP 接口是 v2/v3 双版本，PHP 里用 cURL 调 v3 需要 Protobuf 序列化，而 Consul 全是纯 JSON + REST，上手快、报错明、文档全。
- 开发阶段优先选 Consul：Web UI 可视化强，
curl一行就能验证注册/查询逻辑 - etcd 更适合已上 Kubernetes 的环境（它本来就是 K8s 底座），但 PHP 项目单独搭 etcd，运维成本和调试复杂度明显更高
- 别用 ZooKeeper：PHP 官方无稳定 ZK 客户端，社区 SDK 多年不维护，
zookeeper_connect()在 PHP 8+ 已废弃
API网关接管发现？小心自治性反被锁死
用 Kong 或 Nginx + Lua 做网关统一转发，PHP 服务
确实不用管发现逻辑了——但代价是：跨语言调用变麻烦、灰度发布难控制、故障定位绕三层（客户端 → 网关 → 服务）。
- 小团队或混合技术栈（PHP + Go + Python），建议 PHP 服务**自己集成发现逻辑**，哪怕只是轻量版（如基于 Redis 的简易注册表）
- 网关只做路由和鉴权，服务发现仍由各服务自主完成，网关从 Consul 拉取后端列表并热更新——这才是松耦合
- 千万别让网关替 PHP 服务做健康检查：网关看到的是 TCP 连通性，PHP 服务真正的 DB 连接失败、内存溢出等，只有服务自身最清楚
