CODEWITHSUNDEEP
javaload-balancinggrpc
Mahesh
Mahesh

Reputation: 312

GRPC client side load balancing : One of node goes down

For Grpc service client side load balancing is used.

Channel creation 

ManageChannelBuilder.forTarget("host1:port,host2:port,host3:port").nameResolverFactory(new CustomNameResolverProvider()).loadBalancerFactory(RoundRobinBalancerFactory.getInstance()).usePlaintText(true).build();

Use this channel to create stub.

Problem

If one of the service [host1] goes down then whether stub will handle this scenario and not send any further request to service [host1] ?

As per documentation at https://grpc.io/blog/loadbalancing

A thick client approach means the load balancing smarts are implemented in the client. The client is responsible for keeping track of available servers, their workload, and the algorithms used for choosing servers. The client typically integrates libraries that communicate with other infrastructures such as service discovery, name resolution, quota management, etc.

So is it the responsibility of ManagedChannel class to maintain list of active server or application code needs to maintain list of active server list and create instance of ManagedChannel every time with active server list ?

Test Result

As per test if one of the service goes down there is no impact on load balancing and all request are processed correctly.

So can it be assumed that either stub or ManagedChannel class handle active server list ?

Answer with documentation will be highly appreciated.

Upvotes: 2

Views: 2424

Answers (1)

Eric Anderson
Eric Anderson

Reputation: 26474

Load Balancers generally handle nodes going down. Even when managed by an external service, nodes can crash abruptly and Load Balancers want to avoid those nodes. So all Load Balancer implementations for gRPC I'm aware of avoid failing calls when a backend is down.

Pick First (the default), iterates through the addresses until one works. Round Robin only round robins over working connections. So what you're describing should work fine.

I will note that your approach does have one downfall: you can't change the servers while the process is running. Removing broken backends in one thing, but adding new working backends is another. If your load is ever too high, you may not be able to address the issue by adding more workers because even if you add more workers your clients won't connect to them.

Upvotes: 4

Related Questions