Una arquitectura de microservicios puede aislar fallas a través de límites de servicio bien definidos. Pero como en todos los sistemas distribuidos, existe una mayor probabilidad de problemas a nivel de red, hardware o aplicación. Cualquier componente puede no estar disponible temporalmente para sus consumidores debido a las dependencias del servicio. Para minimizar el impacto de las interrupciones parciales, necesitamos crear servicios tolerantes a fallas que puedan responder correctamente a ciertos tipos de interrupciones.
Basado en la experiencia de consultoría y desarrollo de Node.js de RisingStack, este artículo presenta las tecnologías y patrones arquitectónicos más comunes para construir y ejecutar sistemas de microservicios de alta disponibilidad.
Si no está familiarizado con los patrones de este artículo, no significa necesariamente que esté haciendo algo mal. Siempre hay un costo adicional para construir un sistema confiable.
Actualización: Este artículo hace varias referencias a Trace, la plataforma de monitoreo Node.js de RisingStack. En octubre de 2017, Trace se fusionó con la solución APM de Keymetrics. ¡Haga clic aquí para probarlo!
Riesgos de la arquitectura de microservicios
Una arquitectura de microservicios traslada la lógica de la aplicación a los servicios y utiliza una capa de red para comunicarse entre ellos. La comunicación a través de una red en lugar de llamadas de memoria introduce latencia y complejidad adicionales en el sistema, lo que requiere la colaboración entre múltiples componentes físicos y lógicos. La mayor complejidad de los sistemas distribuidos conduce a una mayor probabilidad de fallas específicas de la red. Los #microservicios le permiten lograr una degradación elegante del servicio porque los componentes se pueden configurar para fallar individualmente.
Una de las mayores ventajas de una arquitectura de microservicios sobre una arquitectura monolítica es que los equipos pueden diseñar, desarrollar e implementar sus servicios de forma independiente. Tienen plena propiedad del ciclo de vida de sus servicios. Esto también significa que los equipos no tienen control sobre las dependencias de su servicio, ya que es más probable que lo administre un equipo diferente. Con las arquitecturas de microservicios, debemos recordar que los servicios del proveedor pueden no estar disponibles temporalmente debido a interrupciones en los lanzamientos, configuraciones y otros cambios, ya que están controlados por otros y los componentes se mueven independientemente unos de otros.
degradación elegante del servicio
Una de las mayores ventajas de una arquitectura de microservicios es que puede aislar las fallas y lograr una degradación ordenada del servicio cuando los componentes fallan individualmente. Por ejemplo, durante una interrupción de la aplicación para compartir fotos, es posible que los clientes no puedan cargar fotos nuevas, pero aún pueden buscar, editar y compartir fotos existentes.
Los microservicios por sí solos fallan (en teoría)
En la mayoría de los casos, es difícil lograr este tipo de degradación elegante del servicio, porque las aplicaciones en un sistema distribuido dependen unas de otras y es necesario aplicar varios tipos de lógica de conmutación por error (algunas de las cuales se describirán más adelante en este artículo) para prepárese para fallas e interrupciones temporales.
Los servicios dependen unos de otros y fallan juntos sin lógica de conmutación por error.
gestión del cambio
El equipo de confiabilidad del sitio de Google descubrió que alrededor del 70% de las interrupciones se debieron a cambios en los sistemas en tiempo real. Cuando cambia algo en su servicio, implemente una nueva versión de su código o cambie alguna configuración, siempre existe la posibilidad de fallar o introducir nuevos errores.
En una arquitectura de microservicios, los servicios dependen unos de otros. Es por eso que debe minimizar las fallas y limitar su impacto negativo. Para hacer frente a los problemas que surgen con los cambios, puede implementar una estrategia de gestión de cambios e implementaciones automatizadas.
Por ejemplo, cuando implementa código nuevo o cambia alguna configuración, debe aplicar gradualmente esos cambios a un subconjunto de sus instancias, monitorearlas e incluso revertirlas automáticamente si nota que la implementación está afectando negativamente sus métricas clave.
Gestión de cambios: implementación continua
Otra solución podría ser ejecutar dos entornos de producción. Siempre implementa solo en uno de ellos y solo apunta el balanceador de carga al nuevo después de verificar que la nueva versión funciona como se esperaba. Esto se denomina implementación azul-verde o rojo-negro.
Revertir el código no es algo malo. No debe dejar un código roto en producción y luego averiguar qué salió mal. Siempre revierta sus cambios si es necesario. Cuanto antes mejor.
Comprobación de estado y equilibrio de carga
Las instancias se inician, reinician y detienen constantemente debido a fallas, implementaciones o escalado automático. Los hace temporal o permanentemente no disponibles. Para evitar problemas, su balanceador de carga debe omitir las instancias en mal estado de la ruta porque no pueden satisfacer las necesidades de los clientes o subsistemas.
El estado de una instancia de aplicación se puede determinar a través de la observación externa. Puede hacer esto llamando repetidamente al punto final GET /health o autoinformándose. Las soluciones modernas de descubrimiento de servicios recopilan continuamente información de estado de las instancias y configuran balanceadores de carga para enrutar el tráfico solo a componentes en buen estado.
autosanación
La autorreparación puede ayudar a restaurar aplicaciones. Podemos hablar de autorreparación cuando una aplicación puede realizar los pasos necesarios para recuperarse de un estado corrupto. En la mayoría de los casos, lo implementa un sistema externo que supervisa el estado de las instancias y las reinicia si se han dejado en un estado corrupto durante un período de tiempo prolongado. La recuperación automática es excelente en la mayoría de los casos, pero en algunos casos puede causar problemas al reiniciar constantemente las aplicaciones. Esto puede suceder cuando su aplicación no puede proporcionar un estado de salud positivo debido a una sobrecarga o tiempos de espera de conexión de la base de datos.
La implementación de soluciones avanzadas de autorreparación que estén preparadas para situaciones sutiles, como la pérdida de conexiones de bases de datos, puede ser complicada. En este caso, deberá agregar lógica adicional a su aplicación para manejar casos extremos y permitir que los sistemas externos sepan que no es necesario reiniciar la instancia de inmediato.
conmutación por error de caché
Los servicios a menudo fallan debido a problemas de red y cambios en nuestros sistemas. Sin embargo, la mayoría de estas interrupciones son temporales debido a la recuperación automática y al equilibrio de carga avanzado, y debemos encontrar una solución para mantener nuestros servicios en funcionamiento durante estas fallas. Aquí es donde el almacenamiento en caché de conmutación por error puede ayudar y proporcionar los datos necesarios para nuestra aplicación.
Las memorias caché de conmutación por error generalmente usan dos fechas de vencimiento diferentes; la más corta indica cuánto tiempo puede usar la memoria caché en condiciones normales y la más larga indica cuánto tiempo puede usar los datos almacenados en la memoria caché durante una falla.
caché de conmutación por error
Vale la pena mencionar que solo debe usar el almacenamiento en caché de conmutación por error cuando servir datos obsoletos es mejor que nada.
Para configurar el almacenamiento en caché y el almacenamiento en caché de conmutación por error, puede usar encabezados de respuesta estándar en HTTP.
Por ejemplo, con el encabezado max-age, puede especificar la cantidad máxima de tiempo que un recurso se considera nuevo. Con el encabezado stale-if-error, puede determinar cuánto tiempo se debe servir un recurso desde la memoria caché en caso de falla.
Los balanceadores de carga y CDN modernos ofrecen varios comportamientos de almacenamiento en caché y conmutación por error, pero también puede crear una biblioteca compartida de soluciones de confiabilidad estándar para su empresa.
lógica de reintento
En algunos casos, no podemos almacenar datos en caché o queremos cambiarlos, pero nuestra operación eventualmente fallará. En estos casos, podemos volver a intentar nuestras operaciones porque podemos esperar que el recurso se recupere después de un tiempo, o que nuestro balanceador de carga envíe nuestra solicitud a una instancia saludable.
Se debe tener cuidado al agregar lógica de reintento a aplicaciones y clientes, ya que una gran cantidad de reintentos puede empeorar las cosas e incluso impedir la recuperación de la aplicación.
En un sistema distribuido, un reintento del sistema de microservicio puede desencadenar muchas otras solicitudes o reintentos e iniciar un efecto en cascada. Para minimizar el impacto de los reintentos, debe limitar el número de reintentos y utilizar un algoritmo de retroceso exponencial para aumentar continuamente la demora entre reintentos hasta alcanzar el límite máximo.
Dado que los reintentos los inicia el cliente (navegador, otro microservicio, etc.), y el cliente no se da cuenta del error hasta que se procesa la solicitud o después, debe preparar su aplicación para manejar la idempotencia. Por ejemplo, cuando vuelve a intentar una compra, no debe cobrar dos veces al cliente. El uso de una clave idempotente única para cada transacción ayuda con los reintentos.
Limitadores de velocidad y deslastre de carga
La limitación de velocidad es una técnica que define cuántas solicitudes puede recibir o procesar un cliente o una aplicación en particular durante un período de tiempo. Por ejemplo, con la limitación de velocidad, puede filtrar los clientes y los microservicios que causan picos de tráfico, o puede asegurarse de que su aplicación no se sobrecargue hasta que el ajuste de escala automático no pueda salvarla.
También puede bloquear el tráfico de menor prioridad, proporcionando suficientes recursos para transacciones críticas.
Un limitador de velocidad puede frenar los picos de tráfico
Un tipo diferente de limitador de velocidad se denomina limitador de solicitudes concurrentes. Es útil cuando tiene terminales costosos a los que no se debe llamar durante más tiempo que el especificado, pero aún desea atender el tráfico.
Las flotas que utilizan reductores de carga pueden garantizar que siempre haya suficientes recursos disponibles para atender transacciones críticas. Reserva algunos recursos para solicitudes de alta prioridad y no permite que transacciones de baja prioridad utilicen todos estos recursos. El descargador toma decisiones basadas en el estado general del sistema, no en los tamaños de depósito de solicitudes de usuarios individuales. Los desinstaladores ayudan a que su sistema se recupere porque mantienen las funciones principales en funcionamiento mientras experimenta un evento en curso.
Para obtener más información sobre los limitadores de velocidad y las trituradoras de carga, recomiendo consultar el artículo de Stripe.
Fracasa rápido e independiente
En una arquitectura de microservicios, queremos que nuestros servicios fallen de forma rápida e independiente. Para aislar problemas de nivel de servicio, podemos usar el patrón de mamparo. Puede leer más sobre los mamparos más adelante en esta publicación de blog.
También queremos que nuestros componentes fallen rápidamente porque no queremos esperar a que se agoten las instancias rotas. No hay nada más frustrante que colgar solicitudes y una interfaz de usuario que no responde. Esto no solo es un desperdicio de recursos, sino que también arruina la experiencia del usuario. Nuestros servicios están encadenados, por lo que debemos tener especial cuidado para prevenir operaciones pendientes hasta que estos retrasos hayan concluido.
Lo primero que le viene a la mente es aplicar un tiempo de espera detallado a cada llamada de servicio. El problema con este enfoque es que realmente no se puede saber cuál es un buen valor de tiempo de espera, ya que las fallas de la red y otros problemas en algunos casos solo afectan una o dos operaciones. En este caso, probablemente no desee denegar las solicitudes si solo se agota el tiempo de espera de algunas de ellas.
Podemos decir que implementar el paradigma fail-fast en microservicios mediante el uso de tiempos de espera es un antipatrón y debe evitarlo. En lugar de tiempos de espera, puede aplicar un patrón de interruptor de circuito que depende de las estadísticas de éxito/fallo de las operaciones.
Dividir
Los mamparos se utilizan en la industria para dividir los barcos en secciones, de modo que las secciones puedan sellarse en caso de rotura del casco.
El concepto de mamparas se puede aplicar al desarrollo de software para aislar recursos.
Al aplicar el patrón de mamparo, podemos proteger los recursos limitados para que no se agoten. Por ejemplo, si tenemos dos operaciones que se comunican con la misma instancia de base de datos con un número limitado de conexiones, podemos usar dos grupos de conexiones en lugar de compartir. Debido a esta separación cliente-recurso, las operaciones que agotan el tiempo de espera o comprometen en exceso el grupo no provocarán que todas las demás operaciones se detengan.
Una de las razones principales por las que se hundió el Titanic fue que sus mamparos estaban diseñados para permitir que el agua se filtrara a través de las cubiertas superiores desde la parte superior de los mamparos, sumergiendo todo el casco.
Mamparas en Titanic (no funcionaron)
interruptor automático
Para limitar la duración de una operación, podemos usar un tiempo de espera. Un tiempo de espera evita que se cuelguen las operaciones y mantiene la capacidad de respuesta del sistema. Sin embargo, el uso de tiempos de espera estáticos y ajustados en la comunicación de microservicios es un antipatrón porque estamos en un entorno altamente dinámico y es casi imposible encontrar el límite de tiempo correcto que funcione bien en cada situación.
En lugar de usar tiempos de espera estáticos pequeños y específicos de la transacción, podemos usar interruptores automáticos para manejar los errores. Los disyuntores llevan el nombre de componentes electrónicos del mundo real porque se comportan de la misma manera. Puede proteger los recursos con disyuntores y ayudarlos a recuperarse. Son muy útiles en sistemas distribuidos donde las fallas repetitivas pueden tener un efecto de bola de nieve y derribar todo el sistema.
Cuando un tipo particular de error ocurre varias veces en un corto período de tiempo, se abre el disyuntor. Un disyuntor abierto bloquea otras solicitudes, al igual que un disyuntor real detiene el flujo de electrones. Los interruptores automáticos generalmente se cierran después de un cierto período de tiempo para permitir suficiente espacio para que se reanuden los servicios subyacentes.
Recuerde que no todos los errores deben activar el disyuntor. Por ejemplo, es posible que desee omitir los problemas del lado del cliente, como las solicitudes con códigos de respuesta 4xx, pero incluir fallas del lado del servidor 5xx. Algunos disyuntores también se pueden dejar entreabiertos. En este estado, el servicio envía la primera solicitud para verificar la disponibilidad del sistema, mientras falla otras solicitudes. Si la primera solicitud tiene éxito, devuelve el disyuntor al estado cerrado y permite que fluya el tráfico. De lo contrario, permanece abierto.
Cortacircuitos
prueba fallida
Debe probar continuamente su sistema en busca de problemas comunes para asegurarse de que su servicio pueda soportar varias fallas. Debe realizar pruebas de fallas con frecuencia para preparar a su equipo para incidentes.
Para las pruebas, puede usar un servicio externo que identifique grupos de instancias y finalice aleatoriamente una instancia en ese grupo. Con esto, puede estar preparado para una falla de una sola instancia, pero incluso puede cerrar una región completa para simular una interrupción del proveedor de la nube.
Una de las soluciones de prueba más populares es la herramienta de resiliencia ChaosMonkey de Netflix.
Otero
Implementar y ejecutar un servicio confiable no es fácil. Requiere mucho esfuerzo de su parte y le cuesta dinero a su empresa.
La confiabilidad tiene muchas capas y facetas, por lo que es importante encontrar la mejor solución para su equipo. Debe tener en cuenta la confiabilidad en su proceso de toma de decisiones comerciales y asignar suficiente presupuesto y tiempo para ello.
puntos clave
-
Los entornos dinámicos y los sistemas distribuidos, como los microservicios, aumentan las posibilidades de falla.
-
Los servicios deben fallar individualmente, lo que permite una degradación elegante para mejorar la experiencia del usuario.
-
El 70% de las interrupciones son causadas por cambios, revertir el código no es algo malo.
-
Fracasa rápida e independientemente. Los equipos no tienen control sobre las dependencias de sus servicios.
-
Los patrones arquitectónicos y las técnicas como el almacenamiento en caché, los mamparos, los disyuntores y los limitadores de velocidad ayudan a crear microservicios confiables.
| Este artículo : https://jiagoushi.pro/designing-microservices-architecture-failure#google_vignette | ||
| Discusión: Knowledge Planet [Chief Architect Circle] o agregue la trompeta de WeChat [ca_cto] o agregue el grupo QQ [792862318] | ||
| sin publico |
【jiagoushipro】 【Super Arquitecto】 Brillante explicación gráfica y detallada de la metodología de la arquitectura, la práctica de la arquitectura, los principios técnicos y las tendencias técnicas. Te estamos esperando, por favor escanea y presta atención. |
|
| Trompeta WeChat |
[ca_cea] Comunidad de 50,000 personas, discutiendo: arquitectura empresarial, computación en la nube, big data, ciencia de datos, Internet de las cosas, inteligencia artificial, seguridad, desarrollo completo, DevOps, digitalización. |
|
| grupo QQ |
[285069459] Intercambio en profundidad de arquitectura empresarial, arquitectura empresarial, arquitectura de aplicaciones, arquitectura de datos, arquitectura técnica, arquitectura de integración, arquitectura de seguridad. Y diversas tecnologías emergentes como big data, cloud computing, Internet de las Cosas, inteligencia artificial, etc. Únase al grupo QQ para compartir valiosos informes y productos secos. |
|
| numero de video | [Super arquitecto] Comprenda rápidamente los conceptos, modelos, métodos y experiencias básicos relacionados con la arquitectura en 1 minuto. 1 minuto al día, la estructura es familiar. |
|
| planeta del conocimiento | [Círculo de arquitectos en jefe] Pregunte a los grandes nombres, póngase en contacto con ellos o comparta información privada. | |
| Himalaya | [Super arquitecto] Aprenda sobre la última experiencia de arquitectura e información de tecnología negra en la carretera o en el automóvil. | [Momentos inteligentes, el Sr. Arquitectura les hablará de tecnología negra] |
| planeta del conocimiento | Conoce más amigos, lugar de trabajo y chat técnico. | Knowledge Planet【Lugar de trabajo y tecnología】 |
| Harry | https://www.linkedin.com/in/architect-harry/ | |
| grupo de LinkedIn | Grupo de arquitectura de LinkedIn | https://www.linkedin.com/groups/14209750/ |
| Weibo | 【Súper Arquitecto】 | momento inteligente |
| bilibili | 【Súper Arquitecto】 | |
| Tik Tok | 【cea_cio】Super Arquitecto | |
| trabajador rapido | 【cea_cio_cto】Super Arquitecto | |
| pequeño libro rojo | [cea_csa_cto] Súper Arquitecto | |
| sitio web | CIO (director de información) | https://cio.ceo |
| sitio web | CIO, CTO y CDO | https://cioctocdo.com |
| sitio web | Arquitecto práctica compartida | https://arquitecto.pub |
| sitio web | Compartir el desarrollo de la nube del programador | https://pgmr.cloud |
| sitio web | Comunidad de arquitectos jefe | https://jiagoushi.pro |
| sitio web | Plataforma de desarrollo y desarrollo de aplicaciones. | https://apaas.dev |
| sitio web | Red de información sobre el desarrollo | https://xinxi.dev |
| sitio web | súper arquitecto | https://jiagou.dev |
| sitio web | Formación técnica empresarial | https://peixun.dev |
| sitio web | Libro del programador | https://pgmr.pub |
| sitio web | chat de desarrollador | https://blog.developer.chat |
| sitio web | Colección CPO | https://cpo.trabajo |
| sitio web | jefe de seguridad | https://cso.pub |
| sitio web | CIO genial | https://cio.cool |
| sitio web | información de CDO | https://cdo.fyi |
| sitio web | Información de CXO | https://cxo.pub |
Gracias por su atención, reenvío, me gusta y ver.