C# 无内置服务发现，需用 Steeltoe、Consul.NET 或 K8s DNS 实现；须支持自动注册、健康检查、动态刷新与故障剔除，避免静态缓存或忽略注销。
服务发现不是 C# 自带能力，得靠第三方组件或自建逻辑
C# 本身不提供服务发现机制，.NET 运行时没有内置的注册中心、心跳检测或服务列表拉取功能。你得选一个支持 .NET 的服务发现方案，或者自己用 Consul / ETCD / Nacos 的 SDK 手动实现注册与发现逻辑。直接写 ServiceDiscovery.Register() 是跑不通的——这函数根本不存在。
- 主流选择是集成
Steeltoe（专为 .NET 生态设计，支持 Eureka/Consul/Nacos）或直接用Consul.NET+ 定时健康检查 - 若用 Kubernetes，可跳过客户端发现，改用 DNS + Headless Service，让
Dns.GetHostAddresses("orders-svc")直接解析出所有 Pod IP - 别在 Startup 中一次性读取服务列表就缓存到底——节点可能下线，必须配合
Watch或定期GET /v1/health/service/orders拉取最新状态
用 Steeltoe 实现自动注册和负载均衡调用
Steeltoe 是目前最贴近 Spring Cloud Eureka 体验的 .NET 方案，它能在应用启动时自动向注册中心注册，并把 HttpClient 包装成支持服务名寻址的客户端。
- 安装
Steeltoe.Discovery.ClientCore和对应实现包（如Steeltoe.Discovery.ConsulCore） - 在
Program.cs中调用builder.Services.AddDiscoveryClient()，并配置spring:cloud:discovery:service-name和注册中心地址 - 发起 HTTP 调用时，不用写
https://10.244.1.5:8080/api/order，而是用https://orders-service/api/order，由DiscoveryHttpMessageHandler解析服务名、选实例、重试失败节点 - 注意：默认轮询策略不带权重或故障剔除，高并发下需配合
LoadBalancerOptions启用响应时间加权或熔断
手动调用 Consul API 注册服务时容易漏掉健康检查
很多人只调一次 PUT /v1/agent/service/register 就以为完事了，结果服务挂了注册中心还不知道，流量继续打过去。
- 必须同时注册
check字段，比如用 HTTP 健康端点："check": { "http": "http://localhost:5000/health", "interval": "10s" } - 别用 TCP 检查（
"tcp": "localhost:5000"），.NET Kestrel 默认不暴露 TCP 健康端口，HTTP 更可控 - 注销不能只靠进程退出——要捕获
AppDomain.CurrentDomain.ProcessExit或IHostApplicationLifetime.ApplicationStopping，主动发PUT /v1/agent/service/deregister/{id} - 本地开发时 Consul Agent 若没开
-dev模式，ACL 默认拒绝写操作，会报错Unexpected response code: 403
K8s 环境下绕过客户端发现更简单，但要注意 DNS 缓存
在 Kubernetes 里，服务发现最轻量的方式就是放弃 SDK，靠集群 DNS + Headless Service，让 Service 不带 ClusterIP，直接返回后端 Pod 的 A 记录。
- 定义 Service 时设
clusterIP: None，然后用Dns.GetHostAddresses("orders-svc.default.svc.cluster.local")获取全部 Pod IP - .NET 的
Dns类默认有缓存（TTL 由 DNS 响应决定），但 Windows 上有时会无视 TTL，建议加一层内存缓存 + 定时刷新（比如每 30 秒重查） - 别直接用
HttpClient往 IP 列表轮询——没超时、没重试、没连接池复用；应该封装成HttpMessageHandler，内部做健康标记和连接池隔离 - 如果 Pod 数量超过 100，DNS 响应可能被截断（EDNS0 不支持），这时得切回基于 Endpoints API 的 Watch 机制
服务发现的关键不在“怎么连上”，而在“怎么及时感知变化”。注册、心跳、注销、缓存更新、DNS TTL、SDK 的重试策略——每个环节断掉，都会让请求静默失败。别假设注册成功就一劳永逸。
