You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implementation ideas
One of my use cases, and I believe of many others, will involve multiple microservices to read and one(eventually multiple) to write.
Now, for this "write" microservice to scale vertically we need some kind of locking/synchronization between them all.
One of the solutions would be to implement a custom grpc load balancer to distribute the same "keys" to the same replicas of that same service.
This would imply changing the current grpc client to support multiple hosts instead of a single one.
A new property would be added(like quarkus.grpc.clients.hello.servers) where a list of server is identified. Then each implementation would register a load balancer to deal with those servers.
High level:
Add a new option to grpc client called "servers" (A comma delimited list of servers where the service is exposed (ex.: :,:,...))
Add new option to grpc client called "loadBalancer" which will map to defaultLoadBalancingPolicy to NettyChannelBuilder (default pick_first).
Servers will be resolver on DnsNameResolverProvider loaded by grpc core
Custom load balancers can be loaded with custom services (io.grpc.LoadBalancerProvider) just like PickFirstLoadBalancerProvider
The text was updated successfully, but these errors were encountered:
wouldn't using DnsNameResolver together with a list of servers be an overcomplication? My understanding is that the DnsNameResolver itself provides a list of addresses for a given URI.
I think loadBalancingPolicy would be a better name than loadBalancer for the policy
Maybe that resolver is not the best to be used. Idea is to have the following config quarkus.grpc.clients.hello.servers=localhost:9000,localhost:9001,localhost:9002,.... Perhaps this point is not even necessary.
This way we could send this list of servers to the load balancer and decide where to send the request.
Description
Custom grpc load balancer
Implementation ideas
One of my use cases, and I believe of many others, will involve multiple microservices to read and one(eventually multiple) to write.
Now, for this "write" microservice to scale vertically we need some kind of locking/synchronization between them all.
One of the solutions would be to implement a custom grpc load balancer to distribute the same "keys" to the same replicas of that same service.
This would imply changing the current grpc client to support multiple hosts instead of a single one.
A new property would be added(like quarkus.grpc.clients.hello.servers) where a list of server is identified. Then each implementation would register a load balancer to deal with those servers.
High level:
The text was updated successfully, but these errors were encountered: