Thanks for the replies! the language I'm looking at right now is c#. I understand retry might not fully supported yet, while still hope I can understand the design correctly as the implementation will be there sooner or later which follows the design idea.
Thanks for explanation of how subchannels work with LB and name resolver. However, since the doc mentioned "Thick client" load balancing <https://grpc.io/blog/grpc-load-balancing/#thick-client> with gRpc is supported, any recommendation how can I have a client customized LB logic (for instance, server names grabbed from Zookeeper) work with gRpc client LB? I guess there is something Application code can notify LB about backend changes as well? like how name resolver does. If I plan to use something other than name resolver to manage backend servers list? thanks a lot! 在2020年10月22日星期四 UTC+8 上午1:44:24<[email protected]> 写道： > On Wednesday, October 21, 2020 at 1:27:27 AM UTC-7 [email protected] > wrote: > >> To ask my question in another word. If to build a "Thick client" load >> balancing <https://grpc.io/blog/grpc-load-balancing/#thick-client> with >> gRpc, the client is responsible to keep track of available servers. While >> when client detected available servers changed, how does it manages >> corresponding SubChannels under existing Channels? I searched around docs >> today again, didn't find APIs for that. I'm looking into csharp. Sorry if I >> overlooked something. >> >> The client's load balancer manages subchannels and shuts down old and > creates new subchannels if the backend servers changed (The name resolver > notifies the loadbalancer about the backend changes). The client RPC will > choose one of the current list of subchannels based on the load balancing > policy. You could use the grpc library built-in round-robin load balancer > if you don't have special requirement. > > > thanks a lot >> >> 在2020年10月19日星期一 UTC+8 下午8:07:33<li yabo> 写道： >> >>> 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/5ddecf3b-efec-492f-b641-2e2d41491f44n%40googlegroups.com.
