Contenido


Desarrollo rápido de aplicaciones (parte 5): uso de patrones de operaciones para obtener resiliencia

Comments

Tabla de contenidos

Introducción
Gestión de la complejidad de las operaciones
Patrón de Registro de servicio
Patrones de ID de correlación y Agregador de registros
Patrón de Interruptor de circuito
Patrón de enlace
Patrón de mamparo
Como obtener y mantener la resiliencia
Ingeniería del caos
Qué hacer a continuación

Introducion

En esta serie de 6 partes sobre el desarrollo de aplicaciones de microservicios, presentamos el contexto para la definición de un proyecto piloto basado en la nube que resulte ideal para las necesidades actuales y posibilite la preparación para una decisión de adopción de nube de largo plazo.

En la parte 5, examinaremos los patrones de operaciones disponibles para la implementación de su aplicación de microservicios.

Estas son las partes de la serie:

  • Visión general de los microservicios (parte 1), después de una contextualización de las presiones empresariales que exigen una entrega y un desarrollo más rápidos de aplicaciones, y de la presentación de las etapas del proceso que un equipo debe enfrentar al transformar una aplicación monolítica específica.
  • Diseño de una arquitectura con microservicios (parte 2), que presenta las capacidades comunes de una arquitectura para el rápido desarrollo de aplicaciones a partir de microservicios. Usted necesitará estas capacidades, ya sea que esté transformando una aplicación monolítica o desarrollando una aplicación nativa de la nube.
  • Implementación de una aplicación de microservicios (parte 3), que proporciona un método para la implementación de su propio proyecto de microservicios.
  • Uso de patrones de desarrollo de microservicios (parte 4), que presenta los patrones de desarrollo comunes que están disponibles para la implementación de aplicaciones de microservicios.
  • Uso de patrones de operaciones de microservicios para obtener resiliencia (esta entrada de blog), que presenta los patrones de operaciones comunes para la obtención de resiliencia en las aplicaciones de microservicios.
  • Webinar: Desarrollo rápido de aplicaciones con microservicios (parte 6)

Gestión de la complejidad de las operaciones

Aunque el modelo de microservicios acelera el proceso de cambio e implementación de un único servicio en una aplicación, también complica la implementación general de la aplicación e incrementa el esfuerzo de gestión y mantenimiento del conjunto de servicios, en comparación con lo que supondría una aplicación monolítica correspondiente.

Los patrones de operaciones para microservicios, que se desarrollaron originalmente para la gestión de aplicaciones convencionales, se aplican a lo que podemos denominar lado de las operaciones del conjunto de prácticas conocido como DevOps.

Patrón de Registro de servicio

El patrón de Registro de servicio permite cambiar la implementación de los microservicios derivados y también proporciona opciones de variación de la ubicación de servicio en diferentes etapas del proceso de DevOps. Esto se logra al evitar codificar de manera rígida los extremos de microservicios específicos. Sin un Registro de servicio, la aplicación pasaría rápidamente a enfrentar dificultades a medida que los cambios en el código empezaran a propagarse a través de la cadena de llamada de los microservicios.

Patrones de ID de correlación y Agregador de registros

Los patrones de ID de correlación y Agregador de registros proporcionan un mejor aislamiento, posibilitando a la vez una depuración más fácil de los microservicios. El patrón de ID de correlación permite realizar un seguimiento de la propagación a través de varios microservicios desarrollados en diversos lenguajes. El patrón de Agregador de registros complementa el patrón de ID de correlación al permitir que registros de diferentes microservicios se agreguen a un solo registro, posibilitando búsquedas conjuntas. Estos patrones admiten una depuración eficiente y comprensible de los microservicios, independientemente de la cantidad o de la profundidad de servicios en cada pila de llamadas.

Patrón de Interruptor de circuito

El patrón de Interruptor de circuito ayuda a evitar pérdidas de tiempo en la gestión de fallas derivadas, cuando se sabe que las fallas están ocurriendo. Para lograrlo, se establece una sección de código de "interruptor de circuito" en las llamadas de servicios para detectar si un servicio derivado presenta fallas, lo cual permite evitar llamarlo. El beneficio de este enfoque es que cada llamada falla rápidamente en el caso de desaceleraciones. Es posible proporcionar una mejor experiencia general a los usuarios e evitar la gestión deficiente de recursos tales como los subprocesos y grupos de conexiones si se sabe que las llamadas derivadas van a fallar

Los interruptores de circuito permiten que el código del usuario verifique si hay dependencias externas disponibles antes de realizar una conexión efectiva al sistema externo. Además, supervisan cuáles servicios han fallado y, con base en umbrales, deciden si se debe utilizar o no determinado servicio. El Interruptor de circuito también oculta la complejidad del código de usuario final. Mantiene las estadísticas ocultas y proporciona respuestas sencillas (disponible o no disponible).

Es posible establecer un interruptor de circuito en cualquier lugar entre un consumidor y un proveedor de API. Sin embargo, si el interruptor de circuito se establece más cerca del consumidor, se logra un mejor cumplimiento de la exigencia de falla rápida de DevOps:

Patrón de enlace

Al permitir un estado "parcialmente habilitado" en los estados de interrupción, el Patrón de enlace mejora la limitación de las aplicaciones implementadas.

Se puede introducir una limitación al preguntar si un componente puede gestionar más trabajo antes de la asignación de dicho trabajo. Un componente demasiado ocupado puede solicitar que los clientes lo eviten hasta que sea capaz de gestionar más solicitudes.

Patrón de mamparo

El Patrón de mamparo evita que las fallas de una de las partes de un sistema interrumpan todo el sistema. El término procede de las embarcaciones. Cada embarcación se divide en compartimientos independientes para evitar que una única brecha en el casco inunde toda la embarcación; de esta manera, solo se inunda un mamparo.

La implementación de este patrón puede adoptar varias formas, según el tipo de falla que se desea aislar. Por ejemplo, se puede limitar la cantidad de llamadas simultáneas a componentes específicos. De esta manera, se limita la cantidad de recursos (normalmente, subprocesos) que esperan una respuesta de un componente.

Como obtener y mantener la resiliencia

Un aspecto clave de la arquitectura de microservicios es que cada microservicio cuenta con un ciclo de vida propio. Cada microservicio es controlado y operado por un equipo autónomo. Diferentes equipos pueden desarrollar, implementar y gestionar sus respectivos microservicios, siempre y cuando mantengan la compatibilidad de API. En combinación con las herramientas de integración e implementación continuas, esta agilidad permite que las aplicaciones se implementen decenas o centenas de veces al día.

Obtener resiliencia en el proceso de iterar un microservicio y una aplicación de microservicios requiere la inducción de fallas.

Ingeniería del caos

Al facilitar la realización de ensayos para identificar deficiencias sistémicas, la ingeniería del caos enfrenta la incertidumbre de los sistemas distribuidos a escala.

Los ensayos de ingeniería del caos presentan cuatro pasos:

  1. Definir como "estado estable" un resultado de sistema cuantificable que indique un comportamiento normal.
  2. Hipotetizar que este estado estable continuará tanto en el grupo de control como en el grupo experimental.
  3. Introducir variables que reflejen eventos del mundo real, como fallas de servidor, errores de unidad de disco duro, interrupciones en las conexiones de red, etc.
  4. Tratar de refutar la hipótesis al buscar una diferencia en el estado estable entre el grupo de control y el grupo experimental.

Cuanto más difícil sea interrumpir el estado estable, más confiable será el comportamiento del sistema. Toda deficiencia observada se convierte en un objetivo de mejora, lo cual suele impedir que el comportamiento se manifieste en el sistema a gran escala.

La automatización también es la clave para las pruebas de resiliencia. Marcos como Gremlin y herramientas como Simian Army Chaos Monkey aseguran que las aplicaciones puedan tolerar fallas de instancia aleatorias.

Chaos Monkey

Chaos Monkey es el primer elemento del Simian Army del equipo técnico de Netflix. Chaos Monkey finaliza de manera aleatoria instancias de máquina virtual y contenedores que se ejecutan en determinado entorno.

Gremlin

Este marco permite probar de manera sistemática la lógica de recuperación de fallas en microservicios, de manera independiente del lenguaje de programación y de la lógica empresarial de los microservicios.

Gremlin aprovecha el hecho de que los microservicios se unen de manera poco rígida y solo interactúan entre sí en una red. Gremlin intercepta la interacción de los microservicios en la red (por ejemplo, llamadas de API de REST) y las manipula para simular una falla en el llamador (por ejemplo, respuesta HTTP 503 o restauración del a conexión TCP). Al observar a partir de la red cómo los demás microservicios reaccionan a esta falla, es posible realizar afirmaciones sobre el comportamiento de la aplicación integral durante la falla. En entornos de producción, la introducción de fallas de Gremlin puede limitarse únicamente a usuarios sintéticos, haciendo que los usuarios reales no se vean afectados.

Qué hacer a continuación:

Roland Barcia

Arquitecto principal de solución


Recursos para Descargar


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Big data y analytics
ArticleID=1051529
ArticleTitle=Desarrollo rápido de aplicaciones (parte 5): uso de patrones de operaciones para obtener resiliencia
publish-date=10272017