服务发现
API7 网关中的服务发现使用动态端点解析替代静态节点列表。无需手动更新上游服务的 IP 地址，你可以配置数据面查询服务注册中心并自动发现后端节点。
服务发现的工作原理
使用服务发现时，需要在上游配置中指定服务名称和发现类型，而不是使用静态 nodes 数组。
- 查询注册中心：数据面（DP）定期查询配置的服务注册中心，例如 Kubernetes API、Nacos 服务器或 Consul Agent。
- 获取端点：注册中心返回所请求服务的健康 IP 地址和端口列表。
- 本地缓存：数据面将这些端点缓存在内存中，以实现高性能路由。
- 更新节点：数据面根据获取的端点更新上游节点列表。
- 负载均衡：网关负载均衡器将传入请求分发到发现的节点。
支持的发现类型
API7 网关控制面支持将服务连接到以下服务注册中心：
- Kubernetes：直接查询 API 服务器，解析 Kubernetes Service 的端点。
- Nacos：与阿里巴巴 Nacos 注册中心集成，实现动态服务发 现。
- Consul：与 HashiCorp Consul Catalog 集成，实现动态服务发现。
静态节点与服务发现对比
| 特性 | 静态节点 | 服务发现 |
|---|---|---|
| 配置 | 手动（IP/端口） | 自动（服务名称） |
| 维护 | 高（节点变更时必须更新） | 低（自动更新） |
| 可扩展性 | 扩缩容时需要手动更新 | 支持即时扩缩容 |
| 环境 | 物理机、旧应用 | Kubernetes、微服务 |
配置字段
使用服务发现配置上游时，通常需要提供：
- 服务名称：注册中心特定的服务标识符。对于 Nacos，请使用
<registry_id>/<namespace>/<group>/<service_name>，例如<registry_id>/public/DEFAULT_GROUP/httpbin。Kubernetes DNS 名称并不是通用的服务发现标识符。 - 发现类型： 注册中心类型（
kubernetes、nacos或consul）。 - 命名空间选择器：对于 Kubernetes，用于筛选网关应监视的命名空间。
- 默认权重：注册中心未提供权重时，分配给已发现节点的权重。
服务注册中心状态
以下服务注册中心状态详情自 API7 企业版 3.10.9 起引入。此前的 3.10.x 版本仅报告 healthy、lost_connection 和 connecting 状态，且不返回 lost_connection_instances。
网关组的**服务注册中心（Service Registries）**页面显示每个服务注册中心的连接状态。网关实例会上报自己能否连接各个注册中心，控制面基于网关组内在线网关实例（即最近 60 秒内发送过心跳的实例）的上报结果汇总状态。
| 状态 | 含义 |
|---|---|
| 健康 | 上报过该注册中心的在线网关实例全部与其保持连接。 |
| 部分失去连接 | 其中部分网关实例与该注册中心失去连接。 |
| 失去连接 | 其中所有网关实例均与该注册中心失去连接。 |
| 正在连接 | 尚无在线网关实例上报该注册中心，或该注册中心未启用健康检查。 |
将鼠标悬停在部分失去连接或失去连接上，可以查看与该注册中心失去连接的网关实例，列表显示每个网关实例的主机名、实例 ID 和失去连接时间。
/api/gateway_groups/{gateway_group_id}/service_registries 相关接口返回相同的信息。status 字段的取值为 healthy、partially_lost_connection、lost_connection 或 connecting；lost_connection_instances 字段列出每个失去连接的网关实例的 instance_id、hostname 和 lost_since。
如需在网关实例与注册中心持续失去连接时收到通知，请创建事件为 Service Registry Lost Connection（注册中心连接异常）的告警策略，详见注册中心连接异常告警。
后续步骤
- 上游与负载均衡：配置后端目标和负载均衡算法。
- 在 Kubernetes 上部署 API7 企业版：部署支持 Kubernetes 服务发现的网关。