2-1 consul与健康检查：获取健康实例逻辑分析
多实例场景
在微服务架构中，同一服务通常部署多个实例以实现高可用。通过 Monorepo 的优势，可以快速复制一个 user 微服务实例：
配置多实例
| 配置项 | user（实例1） | user1（实例2） |
|---|---|---|
| 服务端口 | 40001 | 40002 |
| 健康检查端口 | 3000 | 3001 |
| package.json 名称 | @remote/user | @remote/user1 |
| Consul Service ID | user-service | user-service-1 |
关键点：每个实例必须有唯一的 Service ID 和不同的端口。
Consul 注册验证
启动两个实例后，在 Consul UI 中可以看到两个 user-service 实例。通过 Gateway 发起请求时，Consul 会随机分配到其中一个实例。
当前架构的问题
Gateway 启动
└── OnModuleInit 中获取 Consul Service → 创建 gRPC Client（固定）
└── 后续所有请求都走这个固定的 Client
└── 如果该 Service 实例 down 掉 → 请求失败
text
核心问题：Client 在服务启动时就固定了，即使后端实例不可用也不会自动切换。
解决思路
需要实现动态的 Client 管理机制：
1. 检查当前 Client 是否健康
├── 健康 → 继续使用
└── 不健康 → 从 Consul 获取最新的健康 Service 列表
2. 获取新 Service 后再次进行健康检查
3. 只有确认健康的 Service 才创建对应的 gRPC Client
4. 通过 Client 调用 gRPC 服务方法
text
实现要点
| 要点 | 说明 |
|---|---|
| 定时健康检查 | 定期检查当前 Client 对应的服务是否可用 |
| 动态 Client 切换 | 发现不健康时自动切换到其他健康实例 |
| Consul 服务发现 | 每次切换时从 Consul 获取最新的健康实例列表 |
| 避免固定绑定 | 不要在生命周期钩子中固定 Service，应保持动态 |
参考资源
- Consul Service Discovery - 服务发现机制
- gRPC Health Checking Protocol - gRPC 健康检查协议
↑