Cuando sus microservicios comienzan a discutir: cómo los disyuntores mantienen tranquilo su sistema Spring Boot

Imagínese este escenario. A las tres de la madrugada, tu teléfono empieza a vibrar de repente. No es un despertador, sino una serie de notificaciones de alarma: cierto servicio central no funciona, lo que provoca una reacción en cadena como de dominó, que está derribando todo el sistema. Saltaste de la cama y miraste las deslumbrantes curvas rojas en el panel de monitoreo. Sólo había un pensamiento en tu mente: ¿Por qué no se detuvo por sí solo?

Esta es probablemente la vida diaria de una arquitectura de microservicio sin disyuntores. En el mundo distribuido creado por Spring Boot, los servicios realizan llamadas y envían mensajes todos los días. La mayoría de las veces todo va bien. Hasta que un día, uno de los servicios empezó a responder lentamente, o simplemente dejó de responder debido a la presión de la base de datos, fluctuaciones de la red o simplemente un error oculto en el código.

¿Qué pasará en este momento? El otro servicio no sabe que está mal y sigue enviando solicitudes. Las solicitudes se acumulan en colas, los subprocesos se ocupan y los recursos se agotan gradualmente. Una falla en el servicio se propaga como una enfermedad infecciosa y eventualmente paraliza todo el sistema. Se llama “efecto avalancha”; suena profesional, pero parece una pesadilla técnica.

¿Qué es exactamente un disyuntor?

Puedes pensar en ello como ese interruptor de seguridad en la caja eléctrica de tu casa. Cuando el circuito está sobrecargado o en cortocircuito, se "disparará" y cortará activamente la corriente para evitar que el cable se sobrecaliente o incluso se incendie. En los microservicios, un disyuntor hace casi lo mismo: cuando detecta que la tasa de falla de un servicio excede un umbral, automáticamente se "enciende" y corta las solicitudes de ese servicio.

Las solicitudes posteriores ya no se envían al servicio fallido, sino que se descartan rápidamente o se devuelve una respuesta de respaldo preestablecida (alternativa). El tráfico principal del sistema está protegido y ya no se ve obstaculizado por el fallo de un ramal. El disyuntor realiza periódicamente una prueba "medio abierta", intentando en secreto enviar una solicitud o dos al servicio de destino para ver si se recupera. Si se restablece, el disyuntor se "cierra" automáticamente y el tráfico reanuda su flujo normal.

Todo el proceso no requiere que usted intervenga manualmente a las tres de la madrugada. Sucede de forma automática, tranquila y racional.

¿Por qué los proyectos Spring Boot lo necesitan específicamente?

Porque Spring Boot facilita el desarrollo de microservicios. Algunas líneas de anotaciones, una clase de inicio y un servicio en línea. Esta comodidad también hace que sea más fácil para todos crear redes complejas de llamadas de servicio. Pero la otra cara de la conveniencia es que también existen vínculos más vulnerables.

El disyuntor aquí no desempeña una "función", sino un "pensamiento resiliente". Reconoce que es probable que se produzcan fallos y ya no persigue la ilusión de una disponibilidad del 100%, sino que diseña sistemas que aún pueden mantener las funciones básicas cuando se producen fallos parciales. Es posible que su aplicación de comercio electrónico no pueda completar transacciones cuando el servicio de pago no esté disponible temporalmente, pero al menos aún se pueden utilizar funciones como la exploración de productos y la adición a carritos de compras. En lugar de una página de error completamente en blanco o un tiempo de espera prolongado, los usuarios ven "El sistema de pago está ocupado, inténtelo de nuevo más tarde".

existirkpotencia¿Qué hemos visto en la práctica técnica?

Algunos cambios muy prácticos. Por ejemplo, el sistema de gestión backend de un cliente originalmente tuvo una respuesta lenta del servicio de pedidos durante el período de promoción, lo que provocó que la interfaz de gestión se atascara por completo y el servicio de atención al cliente no pudiera atender ninguna consulta. Después de acceder a la política de disyuntores, la interfaz de administración bloqueará automáticamente algunas solicitudes de consultas no principales cuando la carga del servicio de pedidos sea alta y priorizará el procesamiento de reembolsos y las consultas de pedidos de los clientes. La interfaz puede ser un poco más lenta, pero nunca se bloqueará por completo.

Otro escenario común son las llamadas API de terceros. Los servicios meteorológicos, los servicios de mapas y las puertas de enlace de SMS no son elementos que usted mantenga, pero confíe en ellos. Su inestabilidad es tu inestabilidad. La configuración del disyuntor le permite establecer un tiempo de espera claro y una cantidad de fallas. Una vez que el servicio de terceros no cumple con los requisitos, el sistema cambia automáticamente a datos almacenados en caché o valores predeterminados estáticos en lugar de esperar sin cesar.

¿Cómo empezar a pensar en esto?

Si aún no lo ha hecho, comience con uno de los servicios más sensibles. Pregúntese: si este servicio es lento o no funciona, ¿qué se verá afectado? ¿Qué servicios que lo llaman deberían protegerse?

La configuración en sí no es complicada. En el ecosistema Spring Boot, existen bibliotecas maduras para implementar el patrón de disyuntor. Principalmente debe decidir sobre algunos parámetros: ¿Cuántas veces dentro de un período de tiempo se considera un "fracaso"? Después de activar el disyuntor, ¿con qué frecuencia intenta comprobar si se ha restablecido el servicio? ¿Qué debería devolver la respuesta alternativa: un simple mensaje de error o un conjunto de datos almacenados en caché ligeramente desactualizados pero utilizables?

No existen respuestas estándar para estas decisiones y depende de lo que su empresa pueda tolerar. Los servicios financieros y los servicios de navegación de contenidos obviamente tienen tolerancias diferentes.

Poco a poco, descubrirá que este diseño cambia la forma de pensar de su equipo. Todo el mundo empezó a hablar de "límites de fracaso", no sólo de "límites funcionales". El contrato entre servicios, además de "qué devolver en caso de éxito", también incluye "cómo afrontar el fracaso". La resiliencia del sistema está entretejida en él poco a poco.

Di algo así como un fragmento de una novela.

En el centro de datos, a altas horas de la noche, sólo las luces indicadoras de los servidores parpadean regularmente. El servicio A envía una solicitud al servicio B, como de costumbre. Pero esta vez no hubo respuesta. Espera, tiempo de espera. El disyuntor añadió silenciosamente un tic a su contador. En el quinto fallo, "saltó" ligeramente. Las solicitudes posteriores son como un arroyo que se topa con una compuerta y gira tranquilamente hacia otro camino. Sin alarmas, sin pánico. El proceso principal continúa como si nada hubiera pasado. Sólo una pequeña nota en el gráfico de seguimiento registra este breve aislamiento.

Después del amanecer, el ingeniero revisó los registros y encontró el pico de CPU del servicio B durante ese período. La causa de la falla fue encontrada y reparada. Y cuando todo esto sucede, la mayoría de los usuarios ni siquiera notan nada inusual. El sistema se hizo cargo de sí mismo.

Probablemente así debería ser la tecnología: tranquila, consciente de sí misma y equilibrada en la tormenta.

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.