【云原生技术】API 网关主动探测的通常是“域入口”（srpcgw），不是直接探测后端 Pod，也不是通过 srpcsrv/Consul 来判域健康

1) Consul 在这个流程里干了什么活？

在你们这套架构里，Consul 主要做三件事（都发生在"每个域/集群自己的 Consul"里）：

1. 服务注册表（Service Registry）

   记录"某个服务当前有哪些实例"。

   • 在容器集群里实例就是 Pod IP:Port
   • 在物理机域里实例就是 物理机 IP:Port

2. 健康状态来源（Health State）

   对每个实例维护健康状态（passing/warning/critical），并把不健康实例从可用列表中排除（至少在查询健康服务时会过滤）。

3. 服务发现查询入口（Discovery API）

   srpcsrv 在选址时向 Consul 查询：

   • "给我 users 的健康实例列表"
   • "给我 icms 的健康实例列表"
     然后 srpcsrv 才能在这些实例里做 LB 并返回一个目标给 srpcgw。

简化一句：Consul 不转发业务流量；它提供"有哪些实例 + 哪些健康"的权威清单。

---

2) 你们的 3 个条件（路由条件集合）怎么理解？

你给的条件是：

• srpcgw-cfg.configmap 里的 usersKey: true
• 是否是 icms 服务
• 是否请求了 users 方法（后两者通常不变）

可以把它理解成 srpcgw 的一个路由判定表达式：

当且仅当同时满足：

1. usersKey == true
2. isIcmsService == true
3. isUsersMethod == true

→ 路由到 users

否则 → 路由到 icms

其中：

• usersKey 是你们人工/配置开关，用来快速切换
• "是否 icms 服务 / 是否 users 方法"更像是请求匹配条件（由请求的服务名、方法名、交易码映射出来），所以一般不会变

---

3) 故障：集群断掉 vs srpc 出问题断掉，在 API 处显示一样吗？

从 API 网关"只看探测目标是否可用"的角度，经常会表现得很像：都可能是"这个域不可用/请求失败/超时"。

但本质上是两类故障，是否能在 API 处区分，取决于 API 网关探测的是什么、以及是否有分层指标：

• 集群断掉/网络不可达：通常表现为连接失败、DNS 失败、超时等（更偏"不可达"）
• srpcgw/srpc 链路故障 （比如 srpcgw 进程挂了、卡死、线程池满、但端口还在）：
  • 如果 API 只做 TCP 探测，可能仍"看起来活着"，但业务大量 5xx/超时
  • 如果 API 探测的是 srpcgw 的 HTTP /health 且健康逻辑足够严格，就能更早发现"虽活但不可服务"

所以结论是：可能一样，也可能不一样；要看你们 API 网关的健康检查实现与展示粒度（是否区分 connect error / timeout / 5xx / 健康探测失败 等）。

---

4) API 网关在"探测周期/阈值/超时"窗口，主动向谁探测？

按你前面判断"应该是探测 srpcgw"，那通常就是：

• API 网关对每个域配置一个或多个探测目标 （最常见就是该域的 srpcgw 地址，可能是 VIP/域名/一组实例）
• 按周期发起 TCP 探测 或 HTTP 探测（如 GET /health）
• 配置超时（timeout）与连续失败阈值（failureThreshold）
• 达到阈值就把该域标为 down 并摘除一段时间

也就是说：API 网关主动探测的通常是"域入口"（srpcgw），不是直接探测后端 Pod，也不是通过 srpcsrv/Consul 来判域健康。