推荐使用Yarp反向代理实现gRPC负载均衡：客户端直连Yarp网关，由其转发并轮询健康后端实例，无需修改客户端代码，支持HTTP/2、TLS、健康检查与权重路由。
在 .NET 中实现 gRPC 客户端的负载均衡，核心思路是：不依赖服务端（如 gRPC 的内置服务发现），而是通过客户端工厂（GrpcChannel + HttpClient）结合支持负载均衡的 HTTP 客户端基础设施来完成。.NET 6+ 原生推荐使用 gRPC 客户端工厂（GrpcClientFactory） + IHttpClientFactory + 支持负载均衡的 HttpMessageHandler（如 Yarp.ReverseProxy 或第三方库如 Polly + Microsoft.Extensions.Http.Resilience），或直接对接服务注册中心（如 Consul、Nacos）+ 自定义 HttpMessageHandler。
用 HttpClientFactory + 负载均衡 Handler 实现基础轮询
.NET 的 IHttpClientFactory 是 gRPC 客户端工厂的底层支撑。你可以为 gRPC 通道配置一个带负载能力的 HttpMessageHandler，比如基于 SocketsHttpHandler 扩展实现 DNS 轮询，或使用 Yarp 作为反向代理网关统一做负载均衡（更推荐）。
- 不建议手动轮询多个地址创建多个
GrpcChannel——难以复用连接、无法自动故障剔除 - 推荐方式：把后端多个 gRPC 服务实例注册到 Yarp（或 Nginx/Envoy），客户端只连 Yarp 的单个地址，由它转发并负载
- 若必须客户端直连，可用
Microsoft.Extensions.Http.Resilience配置重试 + 熔断，再配合自定义DelegatingHandler实现简单轮询（需自行维护 endpoint 列表和健康状态）
注册 gRPC 客户端工厂（AddGrpcClient）
在 Program.cs 中启用 gRPC 客户端工厂，并关联已配置好的命名 HttpClient：
builder.Services.AddGrpcClient(options => { options.BaseAddress = new Uri("https://yarp-gateway/"); // 指向网关，不是真实服务地址 }) .ConfigurePrimaryHttpMessageHandler(() => new SocketsHttpHandler { // 可选：禁用 DNS 缓存，便于快速感知服务变更（仅开发/测试） PooledConnectionLifetime = TimeSpan.FromMinutes(2) });
注意：AddGrpcClient 会自动绑定到 IHttpClientFactory，所以你只需确保该命名 client 已注册（或用默认 client）。
用 Yarp 实现服务端负载均衡（推荐生产用）
Yarp 是微软开源的高性能反向代理，天然支持 gRPC（HTTP/2 + TLS），且提供健康检查、权重路由、负载策略（轮询、最少连接等）：
- 在网关项目中配置
ReverseProxyOptions，添加多个 gRPC 后端集群（如grpc-servers） - 每个集群可配置多个 endpoint（
https://svc1:5001,https://svc2:5001），Yarp 自动轮询并探测健康状态 - 客户端只需调用
https://yarp-gateway/Greeter/SayHello，Yarp 透传并负载 - 无需修改客户端代码，零侵入，运维友好
进阶：集成 Consul/Nacos 实现动态服务发现
若需客户端直连且支持服务发现，可编写自定义 HttpMessageHandler：
- 监听 Consul 的服务列表变更（通过 Health API 或 Watch）
- 维护一个健康的 endpoint 缓存池（如
ConcurrentBag） - 在
SendAsync中按策略（随机/轮询/加权）选取 endpoint，并替换request.RequestUri - 搭配
Polly处理连接失败并触发重新发现 - 注意：需确保 TLS 主机名匹配（gRPC over TLS 要求 SNI 和证书 CN 匹配），建议用通配符证书或关闭主机验证（仅测试）
基本上就这些。对大多数场景，用 Yarp 做统一网关是最简单、稳定、可观测的方案；客户端工厂本身不内置负载逻辑，它的价值在于生命周期管理、拦截器注入和与 DI 深度集成。别试图在 GrpcChannel 层自己搞负载——交给基础设施更靠谱。
