While considering moving a http client/service call to using gRpc, I'm looking at load balancing solutions. We currently have each client manages a list of server names (for one service VIP) and connection pools. The server names changes from time to time, so each client has it's logic to maintain the server names list and http connection pools.
If move to using gRpc, I think the easiest change regarding LB might be to let client fill the server names list to gRpc as Subchannels of a Channel to the service VIP. So that client sends request to one Channel and get requests well load balanced. Once there is changes in the client server names list, the client Application layer code goes to update Subchannels in gRpc again. While I'm not sure if that's a do-able or ok approach that doesn't violate gRpc design? managing one Channel for each server name might be a solution, but that possibly won't work well with gRpc retries-policy, because we hope the retry request issued by retries-policy hit another server name of the server-names list. Since current client self-managed server names idea works in existing env, we hope we don't have to setup new roll like lookaside load balancer in the cluster only for the purpose to using gRpc. Does this idea make sense? Thanks a lot! -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/e894bad2-f3a8-4a7d-9a56-93a7f8f09fafn%40googlegroups.com.
