17370845950

服务发现需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 连接失败、内存溢出等，只有服务自身最清楚

真正难的从来不是“怎么注册”，而是“怎么确保注册信息始终可信”——健康检查路径是否真校验了 DB 连接？TTL 设置是否比服务 GC 周期短？缓存过期和刷新是否在并发下一致？这些细节没对齐，服务发现就会变成一个安静的雪崩触发器。