Consul 是 HashiCorp 推出的一站式开源工具，内置服务注册与发现、健康检查、Key/Value 存储及多数据中心支持，无需依赖 ZooKeeper 等外部组件。
Consul 是微服务架构中实现服务发现最常用的一站式方案，它不依赖 ZooKeeper 或 Etcd 等额外组件，自身就具备服务注册、健康检查、KV 存储和多数据中心能力。配置 Consul 实现微服务集群发现，核心在于三件事：搭建高可用 Consul 集群、让服务自动注册到 Consul、让调用方能动态发现并路由到可用实例。
Consul 集群必须是 Server + Client 混合部署
一个生产可用的 Consul 集群至少需要 3 个 Server 节点（满足 Raft 选举最低要求），它们之间通过 8300 端口（gossip）和 8301/8302（RPC）通信；Client Agent 则部署在每台运行微服务的机器上，轻量无状态，只负责把本地服务注册信息转发给 Server。
- Server 节点建议跨物理机或可用区部署，避免单点故障；不要在一台机器上启动多个 Server（仅测试可用）
- Client Agent 必须与微服务同宿主机或同 Pod（K8s 场景下推荐 DaemonSet），否则无法准确上报本机 IP 和端口
- 所有节点需统一指定 datacenter 名称（如
dc1），这是服务发现的逻辑边界，跨数据中心需显式配置 WAN join
C# 微服务注册要带健康检查和元数据
ASP.NET Core 项目需引入 Consul NuGet 包（如 Consul 或 Microsoft.Extensions.DependencyInjection 生态适配库），在 Program.cs 中注册服务时，不能只填 IP+端口，还要声明健康检查路径和自定义标签。
- 健康检查必须是 HTTP GET 接口（如
/health），且返回 200 状态码；Consul 会定期轮询该端点判断服务存活 - 服务名（
ServiceName）应全局唯一，建议按业务域命名（如order-service），避免用随机 ID - 可添加
Tags（如["v1", "prod"]）或Meta字典（如{"env":"staging","region":"sh"}），后续可通过标签做灰度路由或分组筛选
服务消费者要用 DNS 或 HTTP API 做动态发现
调用方不应硬编码目标服务地址，而应通过 Consul 提供的两种标准方式获取实时列表：
-
DNS 方式：直接解析
service-name.service.consul（如user-service.service.consul），Consul 内置 DNS 服务器会返回全部 healthy 实例的 A 记录，天然支持客户端负载均衡 -
HTTP API 方式：GET
http://consul-server:8500/v1/health/service/user-service?passing，响应中包含所有通过健康检查的实例 IP、Port、Tags 等字段，适合需要精细控制路由逻辑的场景 - 无论哪种方式，都建议配合重试和熔断（如 Polly 库），因为服务列表可能随时变化，网络抖动也可能导致短暂不可达
API 网关是服务发现的天然聚合层
前端请求不直连后端微服务，而是先经过网关（如 Ocelot、YARP 或 Envoy），由网关统一从 Consul 拉取服务列表并做反向代理——这既解耦了客户端，又便于集中管控认证、限流、日志等横切关注点。
- Ocelot 可通过
ConsulConfigurationProvider自动监听服务变更，无需重启即可更新路由表 - 网关本身也应作为服务注册到 Consul，方便被其他系统（如监控平台）发现和探活
- 若使用 Kubernetes，可考虑 Consul Connect 模式，通过 sidecar 注入实现透明 TLS 和细粒度服务网格策略
