He intentado que el equilibrio de carga de GRPC funcione en mi aplicación Java implementada en un clúster de Kubernetes, pero no he tenido demasiado éxito. No parece haber demasiada documentación sobre esto, pero a partir de ejemplos en línea puedo ver que ahora debería poder usar '.defaultLoadBalancingPolicy("round_robin")' al configurar ManagedChannel (en versiones posteriores de GRPC Java lib) .

Para ser más específico, estoy usando la versión 1.34.1 de las bibliotecas GRPC Java. Creé dos aplicaciones Spring Boot (v2.3.4), una llamada grpc-sender y otra llamada grpc-receiver.

grpc-sender actúa como un cliente GRPC y define un ManagedChannel (Netty) como:

 @Bean public ManagedChannel greetingServiceManagedChannel() { String host = "grpc-receiver"; int port = 6565; return NettyChannelBuilder.forAddress(host, port) .defaultLoadBalancingPolicy("round_robin") .usePlaintext().build(); }

Entonces grpc-receiver actúa como el servidor GRPC:

 Server server = ServerBuilder.forPort(6565) .addService(new GreetingServiceImpl()).build();

Estoy implementando estas aplicaciones en un clúster de Kubernetes (que se ejecuta localmente en minikube por el momento) y he creado un servicio para la aplicación grpc-receiver como un servicio sin cabeza, de modo que se pueda lograr el equilibrio de carga de GRPC.

Para probar las solicitudes fallidas, hago dos cosas:

• elimine uno de los pods de grpc-receiver durante la ejecución de una prueba; por ejemplo, cuando solicité a grpc-sender que envíe, digamos, 5000 solicitudes a grpc-receiver. Grpc-sender detecta que se eliminó el pod y actualiza su lista de pods receptores, y enruta las solicitudes futuras a los nuevos pods. Como era de esperar, algunas de las solicitudes que estaban en vuelo durante la destrucción del pod fallan con el estado GRPC NO DISPONIBLE.
• tenga alguna lógica simple en grpc-receiver que genere un número aleatorio y si ese número aleatorio está por debajo, digamos, 0.2, devuelva Grpc Status INTERNAL en lugar de OK.

Con los dos anteriores, puedo obtener una proporción de las solicitudes durante una ejecución de prueba para fallar. Ahora lo que estoy tratando de hacer que funcione el mecanismo de reintento de GRPC. Al leer la escasa documentación, estoy haciendo lo siguiente:

 return NettyChannelBuilder.forAddress(host, port) .defaultLoadBalancingPolicy("round_robin") .enableRetry() .maxRetryAttempts(10) .usePlaintext().build();

Sin embargo, esto parece no tener ningún efecto y no puedo ver que las solicitudes fallidas se vuelvan a intentar.

Veo que esto todavía está marcado como una característica de @ExperimentalApi, entonces, ¿debería funcionar como se esperaba y se ha implementado?

Si es así, ¿hay algo obvio que me estoy perdiendo? ¿Algo más que deba hacer para que los reintentos funcionen?

¿Alguna documentación que explique cómo hacer esto con más detalle?

Muchas gracias de antemano...