Eventos
Campeonato mundial de DataViz de Power BI
14 feb, 16 - 31 mar, 16
Con 4 posibilidades de entrar, podrías ganar un paquete de conferencia y convertirlo en el Live Grand Finale en Las Vegas
Saber másEste explorador ya no se admite.
Actualice a Microsoft Edge para aprovechar las características y actualizaciones de seguridad más recientes, y disponer de soporte técnico.
Nota
Esta no es la versión más reciente de este artículo. Para la versión actual, consulte la versión de .NET 9 de este artículo.
Advertencia
Esta versión de ASP.NET Core ya no se admite. Para obtener más información, consulte la directiva de compatibilidad de .NET y .NET Core. Para la versión actual, consulte la versión de .NET 9 de este artículo.
Importante
Esta información hace referencia a un producto en versión preliminar, el cual puede sufrir importantes modificaciones antes de que se publique la versión comercial. Microsoft no proporciona ninguna garantía, expresa o implícita, con respecto a la información proporcionada aquí.
Para la versión actual, consulte la versión de .NET 9 de este artículo.
El equilibrio de carga del lado cliente es una característica que permite a los clientes gRPC distribuir la carga de forma óptima entre los servidores disponibles. En este artículo se describe cómo configurar el equilibrio de carga del lado cliente para crear aplicaciones gRPC escalables y de alto rendimiento en .NET.
El equilibrio de carga del lado cliente requiere lo siguiente:
Grpc.Net.Client
, versión 2.45.0 o posterior.El equilibrio de carga del lado cliente se configura cuando se crea un canal. Los dos componentes que se deben tener en cuenta al usar el equilibrio de carga son los siguientes:
Las implementaciones integradas de solucionadores y equilibradores de carga se incluyen en Grpc.Net.Client
. El equilibrio de carga también se puede extender escribiendo solucionadores personalizados y equilibradores de carga.
Las direcciones, las conexiones y otro estado del equilibrio de carga se almacenan en una instancia de GrpcChannel
. Se debe reutilizar un canal al realizar llamadas de gRPC para que el equilibrio de carga funcione correctamente.
Nota
Algunas configuraciones de equilibrio de carga usan la inserción de dependencias (DI). Las aplicaciones que no usan DI pueden crear una instancia de ServiceCollection.
Si una aplicación ya tiene configuración de inserción de dependencias, como un sitio web de ASP.NET Core, los tipos deben registrarse con la instancia de inserción de dependencia existente. GrpcChannelOptions.ServiceProvider
se configura obteniendo IServiceProvider de la DI.
El solucionador se configura mediante la dirección con la que se crea un canal. El esquema URI de la dirección especifica el solucionador.
Scheme | Tipo | Descripción |
---|---|---|
dns |
DnsResolverFactory |
Resuelve las direcciones consultando al nombre de host los registros de las direcciones DNS. |
static |
StaticResolverFactory |
Resuelve las direcciones que ha especificado la aplicación. Se recomienda si una aplicación ya conoce las direcciones a las que llama. |
Un canal no llama directamente a un URI que coincida con un solucionador. En su lugar, se crea un solucionador coincidente y se usa para resolver las direcciones.
Por ejemplo, al usar GrpcChannel.ForAddress("dns:///my-example-host", new GrpcChannelOptions { Credentials = ChannelCredentials.Insecure })
:
dns
se asigna a DnsResolverFactory
. Se crea una nueva instancia de un solucionador DNS para el canal.my-example-host
y obtiene dos resultados: 127.0.0.100
y 127.0.0.101
.127.0.0.100:80
y 127.0.0.101:80
para crear conexiones y realizar llamadas de gRPC.DnsResolverFactory
crea un solucionador diseñado para obtener direcciones de un origen externo. La resolución DNS se usa normalmente para equilibrar la carga en las instancias de pod que tienen servicios sin periféricos de Kubernetes.
var channel = GrpcChannel.ForAddress(
"dns:///my-example-host",
new GrpcChannelOptions { Credentials = ChannelCredentials.Insecure });
var client = new Greet.GreeterClient(channel);
var response = await client.SayHelloAsync(new HelloRequest { Name = "world" });
El código anterior:
dns:///my-example-host
.
dns
se asigna a DnsResolverFactory
.my-example-host
es el nombre de host que se va a resolver.dns:///my-example-host:8080
configura las llamadas gRPC que se enviarán al puerto 8080.SayHello
: my-example-host
.El rendimiento es importante al equilibrar la carga. La latencia de resolución de direcciones se elimina de las llamadas de gRPC almacenando en caché las direcciones. Se invocará un solucionador al realizar la primera llamada a gRPC, y las llamadas posteriores usarán la memoria caché.
Las direcciones se actualizan automáticamente si se interrumpe una conexión. La actualización es importante en escenarios donde las direcciones cambian en el entorno de ejecución. Por ejemplo, en Kubernetes, un pod reiniciado hace que el solucionador de DNS se actualice y obtenga la nueva dirección del pod.
De forma predeterminada, se actualiza un solucionador DNS si se interrumpe una conexión. El solucionador DNS también puede actualizarse opcionalmente en un intervalo periódico. Esto puede ser útil para detectar rápidamente nuevas instancias de pod.
services.AddSingleton<ResolverFactory>(
sp => new DnsResolverFactory(refreshInterval: TimeSpan.FromSeconds(30)));
El código anterior crea un DnsResolverFactory
con un intervalo de actualización y lo registra con inserción de dependencias. Para más información sobre el uso de un solucionador configurado de forma personalizada, consulte Configuración de resoluciones personalizadas y equilibradores de carga.
StaticResolverFactory
proporciona un solucionador estático. Este solucionador:
var factory = new StaticResolverFactory(addr => new[]
{
new BalancerAddress("localhost", 80),
new BalancerAddress("localhost", 81)
});
var services = new ServiceCollection();
services.AddSingleton<ResolverFactory>(factory);
var channel = GrpcChannel.ForAddress(
"static:///my-example-host",
new GrpcChannelOptions
{
Credentials = ChannelCredentials.Insecure,
ServiceProvider = services.BuildServiceProvider()
});
var client = new Greet.GreeterClient(channel);
El código anterior:
StaticResolverFactory
. La fábrica ya conoce dos direcciones: localhost:80
y localhost:81
.static:///my-example-host
. El esquema static
se asigna a un solucionador estático.GrpcChannelOptions.ServiceProvider
con el proveedor de servicios de DI.En este ejemplo se crea un nuevo ServiceCollection para la DI. Supongamos que una aplicación ya tiene la DI configurada, como un sitio web de ASP.NET Core. En ese caso, los tipos se deben registrar con la instancia de DI existente. GrpcChannelOptions.ServiceProvider
se configura obteniendo IServiceProvider de la DI.
Se especifica un equilibrador de carga en un service config
mediante la colección ServiceConfig.LoadBalancingConfigs
. Dos equilibradores de carga se integran y se asignan a los nombres de configuración del equilibrador de carga:
Nombre | Escribir | Descripción |
---|---|---|
pick_first |
PickFirstLoadBalancerFactory |
Intenta conectarse a direcciones hasta que se realiza correctamente una conexión. Todas las llamadas de gRPC se realizan a la primera conexión correcta. |
round_robin |
RoundRobinLoadBalancerFactory |
Intenta conectarse a todas las direcciones. Las llamadas de gRPC se distribuyen entre todas las conexiones correctas utilizando una lógica round robin. |
service config
es una abreviatura de configuración de servicio y se representa por el tipo ServiceConfig
. Hay un par de maneras en que un canal puede obtener un service config
con un equilibrador de carga configurado:
service config
cuando se crea un canal con GrpcChannelOptions.ServiceConfig
.service config
para un canal. Esta característica permite que un origen externo especifique cómo sus llamadores deben realizar el equilibrio de carga. El hecho de que un solucionador admita la resolución de un service config
depende de la implementación del solucionador. Deshabilite esta característica con GrpcChannelOptions.DisableResolverServiceConfig
.service config
, o el service config
no tiene un equilibrador de carga configurado, el canal predeterminado es PickFirstLoadBalancerFactory
.var channel = GrpcChannel.ForAddress(
"dns:///my-example-host",
new GrpcChannelOptions
{
Credentials = ChannelCredentials.Insecure,
ServiceConfig = new ServiceConfig { LoadBalancingConfigs = { new RoundRobinConfig() } }
});
var client = new Greet.GreeterClient(channel);
var response = await client.SayHelloAsync(new HelloRequest { Name = "world" });
El código anterior:
RoundRobinLoadBalancerFactory
en el service config
.SayHello
: DnsResolverFactory
crea un solucionador que obtiene las direcciones del nombre de host my-example-host
.Un canal debe saber si las llamadas gRPC se envían mediante la seguridad de transporte. http
y https
ya no forman parte de la dirección, el esquema ahora especifica un solucionador, por lo que Credentials
debe configurarse en las opciones de canal al usar el equilibrio de carga.
ChannelCredentials.SecureSsl
- Las llamadas de gRPC deben protegerse con Seguridad de la capa de transporte (TLS). Equivalente a una dirección https
.ChannelCredentials.Insecure
- Las llamadas de gRPC no usan la seguridad de transporte. Equivalente a una dirección http
.var channel = GrpcChannel.ForAddress(
"dns:///my-example-host",
new GrpcChannelOptions { Credentials = ChannelCredentials.Insecure });
var client = new Greet.GreeterClient(channel);
var response = await client.SayHelloAsync(new HelloRequest { Name = "world" });
El generador de cliente gRPC se puede configurar para usar el equilibrio de carga:
var builder = WebApplication.CreateBuilder(args);
builder.Services
.AddGrpcClient<Greeter.GreeterClient>(o =>
{
o.Address = new Uri("dns:///my-example-host");
})
.ConfigureChannel(o => o.Credentials = ChannelCredentials.Insecure);
builder.Services.AddSingleton<ResolverFactory>(
sp => new DnsResolverFactory(refreshInterval: TimeSpan.FromSeconds(30)));
var app = builder.Build();
El código anterior:
El equilibrio de carga del lado cliente es extensible:
Resolver
para crear un solucionador personalizado y resolver direcciones desde un nuevo origen de datos.LoadBalancer
para crear un equilibrador de carga personalizado con un nuevo comportamiento de equilibrio de carga.Importante
Las API que se usan para extender el equilibrio de carga del lado cliente son experimentales. Pueden cambiar sin previo aviso.
Un solucionador:
Resolver
y lo crea un ResolverFactory
. Cree un solucionador personalizado implementando estos tipos.public class FileResolver : PollingResolver
{
private readonly Uri _address;
private readonly int _port;
public FileResolver(Uri address, int defaultPort, ILoggerFactory loggerFactory)
: base(loggerFactory)
{
_address = address;
_port = defaultPort;
}
public override async Task ResolveAsync(CancellationToken cancellationToken)
{
// Load JSON from a file on disk and deserialize into endpoints.
var jsonString = await File.ReadAllTextAsync(_address.LocalPath);
var results = JsonSerializer.Deserialize<string[]>(jsonString);
var addresses = results.Select(r => new BalancerAddress(r, _port)).ToArray();
// Pass the results back to the channel.
Listener(ResolverResult.ForResult(addresses));
}
}
public class FileResolverFactory : ResolverFactory
{
// Create a FileResolver when the URI has a 'file' scheme.
public override string Name => "file";
public override Resolver Create(ResolverOptions options)
{
return new FileResolver(options.Address, options.DefaultPort, options.LoggerFactory);
}
}
En el código anterior:
FileResolverFactory
implementa ResolverFactory
. Se asigna al esquema file
y crea instancias de FileResolver
.FileResolver
implementa PollingResolver
. PollingResolver
es un tipo base abstracto que facilita la implementación de un solucionador con lógica asincrónica invalidando ResolveAsync
.ResolveAsync
file:///c:/addresses.json
se convierte en c:\addresses.json
.Un equilibrador de carga:
LoadBalancer
, y lo crea un LoadBalancerFactory
. Cree un equilibrador de carga y una fábrica personalizados implementando estos tipos.Subchannel
.SubchannelPicker
. El canal usa internamente el selector para elegir direcciones al realizar llamadas de gRPC.El SubchannelsLoadBalancer
es:
LoadBalancer
.Subchannel
a partir de las direcciones.public class RandomBalancer : SubchannelsLoadBalancer
{
public RandomBalancer(IChannelControlHelper controller, ILoggerFactory loggerFactory)
: base(controller, loggerFactory)
{
}
protected override SubchannelPicker CreatePicker(List<Subchannel> readySubchannels)
{
return new RandomPicker(readySubchannels);
}
private class RandomPicker : SubchannelPicker
{
private readonly List<Subchannel> _subchannels;
public RandomPicker(List<Subchannel> subchannels)
{
_subchannels = subchannels;
}
public override PickResult Pick(PickContext context)
{
// Pick a random subchannel.
return PickResult.ForSubchannel(_subchannels[Random.Shared.Next(0, _subchannels.Count)]);
}
}
}
public class RandomBalancerFactory : LoadBalancerFactory
{
// Create a RandomBalancer when the name is 'random'.
public override string Name => "random";
public override LoadBalancer Create(LoadBalancerOptions options)
{
return new RandomBalancer(options.Controller, options.LoggerFactory);
}
}
En el código anterior:
RandomBalancerFactory
implementa LoadBalancerFactory
. Se asigna al nombre de directiva random
y crea instancias de RandomBalancer
.RandomBalancer
implementa SubchannelsLoadBalancer
. Crea un RandomPicker
que selecciona aleatoriamente un subcanal.Los solucionadores y equilibradores de carga personalizados deben registrarse con inserción de dependencias (DI) cuando se usan. Hay dos opciones:
GrpcChannelOptions.ServiceProvider
.var services = new ServiceCollection();
services.AddSingleton<ResolverFactory, FileResolverFactory>();
services.AddSingleton<LoadBalancerFactory, RandomLoadBalancerFactory>();
var channel = GrpcChannel.ForAddress(
"file:///c:/data/addresses.json",
new GrpcChannelOptions
{
Credentials = ChannelCredentials.Insecure,
ServiceConfig = new ServiceConfig { LoadBalancingConfigs = { new LoadBalancingConfig("random") } },
ServiceProvider = services.BuildServiceProvider()
});
var client = new Greet.GreeterClient(channel);
El código anterior:
ServiceCollection
y registra nuevas implementaciones de equilibrador de carga y solucionador.ServiceCollection
se integra en IServiceProvider
y se establece en GrpcChannelOptions.ServiceProvider
.file:///c:/data/addresses.json
. El esquema file
se asigna a FileResolverFactory
.service config
es random
. Asigna a RandomLoadBalancerFactory
.HTTP/2 multiplexa varias llamadas en una sola conexión TCP. Si gRPC y HTTP/2 se usan con un equilibrador de carga de red (NLB), la conexión se reenvía a un servidor y todas las llamadas de gRPC se envían a ese servidor. Las demás instancias de servidor del NLB están inactivas.
Los equilibradores de carga de red son una solución común para el equilibrio de carga, ya que son rápidos y ligeros. Por ejemplo, Kubernetes usa de forma predeterminada un equilibrador de carga de red para equilibrar las conexiones entre las instancias de pod. Sin embargo, los equilibradores de carga de red no son eficaces para distribuir la carga cuando se usan con gRPC y HTTP/2.
gRPC y HTTP/2 pueden equilibrar la carga de forma eficaz mediante un proxy del equilibrador de carga de la aplicación o el equilibrio de carga del lado cliente. Ambas opciones permiten que las llamadas de gRPC individuales se distribuyan entre los servidores disponibles. Decidir entre el equilibrio de carga del lado cliente y el proxy es una opción arquitectónica. Cada uno de las opciones tiene ventajas y desventajas.
Proxy: las llamadas de gRPC se envían al proxy, el proxy toma una decisión de equilibrio de carga y la llamada de gRPC se envía al punto de conexión final. El proxy es responsable de conocer los puntos de conexión. El uso de un proxy agrega:
Equilibrio de carga del lado cliente: el cliente gRPC toma una decisión de equilibrio de carga cuando se inicia una llamada a gRPC. La llamada a gRPC se envía directamente al punto de conexión final. Al usar el equilibrio de carga del lado cliente:
Comentarios de ASP.NET Core
ASP.NET Core es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios:
Eventos
Campeonato mundial de DataViz de Power BI
14 feb, 16 - 31 mar, 16
Con 4 posibilidades de entrar, podrías ganar un paquete de conferencia y convertirlo en el Live Grand Finale en Las Vegas
Saber más