cómo se comunican los servicios en microservicios

Cuando sus servidores comienzan a "pelear": ¿Cómo hablan en voz baja los microservicios?

Imagínese esto: ensambla un sofisticado brazo robótico, con los servos en cada articulación perfectamente sintonizados. Pero cuando das una orden, tus dedos se mueven, pero tu muñeca no responde, porque no se comunican correctamente en absoluto. Esto no es una falla de hardware, es un problema con la "conversación".

En el mundo de los microservicios, cada uno de sus módulos funcionales es como estos servos independientes. Todos hacen su trabajo, pero si no se comunican bien, todo el sistema puede volverse rígido y lento. ¿Cómo pueden estos "pequeños servicios" dispersos hablar elegantemente para que la máquina funcione sin problemas?

La pregunta nunca es "debemos comunicarnos", sino "cómo comunicarnos"

Al principio mucha gente pensó: ¿No sería mejor dejar que los servicios realicen llamadas directas (llamadas sincrónicas)? Sencillo y directo. Pero prueba esto: cuando diez servos necesitan coordinarse para completar una acción de agarre al mismo tiempo, y uno de ellos responde lentamente, ¿el resto se quedará esperando? El sistema se volverá como engranajes oxidados y su eficiencia caerá en picado.

Más a menudo, los servicios se convierten en una maraña de interdependencias. Cuando se cambia un formato de datos, varias funciones informan de errores al mismo tiempo, como por ejemplo derribar accidentalmente una fila de fichas de dominó. ¿Crees que esta máquina puede seguir siendo flexible?

Deje que los mensajes fluyan en lugar de hacer esperar a los servicios

Más tarde cambiamos nuestra forma de pensar: ¿por qué dejar que el servicio "hable" en tiempo real? Es mejor dejarles simplemente dejar notas, dejar la información que debe procesarse en un "buzón" compartido (cola de mensajes) y luego dedicarse a sus propios asuntos. Si necesita el servicio de esta noticia, consígalo cuando esté libre.

Por ejemplo, si un microservicio que registra la ubicación actualiza las coordenadas, no necesita notificar al servicio de planificación de rutas de inmediato. Simplemente coloca las nuevas coordenadas en el "buzón". El servicio de planificación obtiene esta información a su conveniencia y luego calcula con calma el siguiente paso. De esta forma, un retraso temporal en un único servicio no provocará la caída de toda la cadena. De repente, el sistema sintió como si estuviera respirando.

Algunos podrían preguntar: “¿No significa esto que es posible que los datos no estén actualizados?”

Es cierto, pero ese es exactamente el punto: la mayoría de los sistemas mecánicos no requieren una sincronización absoluta en tiempo real. Su servo tiene un retraso físico de varios milisegundos desde que recibe el comando hasta que lo ejecuta. Los retrasos breves en los datos entre microservicios, siempre que el diseño lo permita, suelen ser mucho mejores que el retraso general causado por la espera. Es como si no necesitara que el sensor de visión retroalimentara 1000 veces por segundo para ajustar el brazo, tal vez 100 veces por segundo sea lo suficientemente suave y más confiable.

No todas las conversaciones tienen que ser íntimas: encontrar los límites adecuados

Dividir responsabilidades de microservicios es como dividir áreas funcionales de módulos mecánicos. Un microservicio que solo es responsable del control del par no tiene que preocuparse por cómo otro servicio calcula el ángulo. Se comunican a través de interfaces claramente definidas (como un protocolo de datos simple), como dos ingenieros que se comunican con dibujos estándar.

De esta manera, cuando es necesario actualizar o reparar un servicio, puede "derribarlo" individualmente sin tener que cerrar toda la línea de producción. La resiliencia del sistema surge de este diálogo poco acoplado.

Cuando una conversación sale mal: cómo “reintentar” y “comprometerse” con gracia

Incluso los mejores mecanismos de comunicación pueden encontrar interferencias. Jitter de la red, cargas transitorias: es como ruido en un circuito. El diseño inteligente de microservicios anticipa estos obstáculos en el camino.

Por ejemplo, utilice un "mecanismo de reintento" pero con una estrategia de retroceso. Si una llamada falla, no vuelvas a intentarlo inmediatamente diez veces como loco, ya que eso empeorará las cosas. En su lugar, espere un segundo, luego dos segundos y extienda gradualmente el intervalo para que el sistema tenga tiempo de recuperarse. O bien, prepare un "plan de degradación": cuando no se puedan obtener los datos más recientes del servicio principal, primero utilice los datos antiguos aceptables almacenados en caché localmente para mantener las operaciones básicas, mientras registra el problema y lo soluciona posteriormente.

Este tipo de pensamiento de diseño permite que el sistema se adapte de manera flexible en lugar de romperse frágilmente ante la incertidumbre.

Observando el “pulso” de las conversaciones: visualización y seguimiento

Si no puede ver cómo se comunican los servicios entre sí, no podrá hablar de ello. Es como depurar un sistema mecánico sin lecturas de sensores. Necesitamos darle a cada llamada entre servicios un "ID de seguimiento" único para que funcione como un hilo a lo largo de toda la cadena de procesamiento.

De esta manera, cuando la respuesta de una acción se ralentiza, puede seguir este hilo y localizar rápidamente qué "enlace de diálogo" tiene el cuello de botella: ¿el servicio de conversión de coordenadas es lento o la cola de comandos está bloqueada? Los problemas se vuelven transparentes y las soluciones se vuelven precisas.

Entonces, volvamos a la escena del principio.

Que su brazo robótico pueda moverse con flexibilidad depende no solo de la calidad de cada servo (microservicio) en sí, sino también de si se ha establecido entre ellos un mecanismo de diálogo confiable, asincrónico, claramente delimitado y observable. No es magia, es una filosofía de ingeniería: diseñar conexiones flexibles pero confiables para construir un todo más fuerte y evolutivo.

Al final, una buena comunicación de microservicios facilitará los sistemas complejos. Funciona silenciosamente, como un conjunto de engranajes exquisitos. No se puede escuchar la fricción ruidosa y solo se ve la acción de salida suave. Y este es el lenguaje común de todos los sistemas fiables.

Explore más posibilidades para que los componentes del sistema colaboren sin problemas,kpotenciaContinúe concentrándose en la profundidad de la tecnología subyacente.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en la tecnología de accionamiento modular,kpotenciaintegra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas. Kpower ha brindado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.