在 .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<Greeter.GreeterClient>(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<uri></uri>） 在
SendAsync中按策略（随机/轮询/加权）选取 endpoint，并替换
request.RequestUri搭配
Polly处理连接失败并触发重新发现 注意：需确保 TLS 主机名匹配（gRPC over TLS 要求 SNI 和证书 CN 匹配），建议用通配符证书或关闭主机验证（仅测试）
基本上就这些。对大多数场景，用 Yarp 做统一网关是最简单、稳定、可观测的方案；客户端工厂本身不内置负载逻辑，它的价值在于生命周期管理、拦截器注入和与 DI 深度集成。别试图在
GrpcChannel层自己搞负载——交给基础设施更靠谱。
