Resistencia y alta disponibilidad en microservicios

Enfrentarse a errores inesperados es uno de los problemas más difíciles de resolver, sobre todo en un sistema distribuido. Gran parte del código que escriben los desarrolladores implica controlar excepciones y esto también es donde se dedica más tiempo a las pruebas. El problema es más importante que escribir código para controlar los errores. ¿Qué ocurre cuando se produce un error en la máquina en la que se está ejecutando el microservicio? No solo necesita detectar este error de microservicio (un problema difícil por sí solo), sino que también necesita algo para reiniciar el microservicio.

Un microservicio debe ser resistente a errores y poder reiniciar a menudo en otra máquina para obtener disponibilidad. La resiliencia también depende del estado que se guardó en nombre del microservicio, desde donde el microservicio puede recuperar este estado y si el microservicio puede reiniciarse con éxito. Es decir, debe haber resistencia en la funcionalidad de proceso (el proceso puede reiniciarse en cualquier momento), así como resistencia en el estado o los datos (sin pérdida de datos y los datos permanecen coherentes).

Los problemas de resistencia se combinan durante otros escenarios, como cuando se producen errores durante una actualización de la aplicación. El microservicio, que trabaja con el sistema de implementación, debe determinar si puede continuar avanzando a la versión más reciente o revertir a una versión anterior para mantener un estado coherente. Preguntas como si hay suficientes máquinas disponibles para seguir avanzando y cómo recuperar versiones anteriores del microservicio deben tenerse en cuenta. Este enfoque requiere que el microservicio emita información de estado para que la aplicación general y el orquestador puedan tomar estas decisiones.

Además, la resistencia está relacionada con el comportamiento de los sistemas basados en la nube. Como se mencionó, un sistema basado en la nube debe adoptar errores y debe intentar recuperarse automáticamente de ellos. Por ejemplo, en caso de errores de red o contenedor, las aplicaciones cliente o los servicios cliente deben tener una estrategia para reintentar el envío de mensajes o para reintentar solicitudes, ya que en muchos casos los errores en la nube son parciales. En la sección Implementación de aplicaciones resistentes de esta guía se explica cómo controlar errores parciales. Describe técnicas como reintentos con retroceso exponencial o el patrón Circuit Breaker en .NET mediante bibliotecas como Polly, que ofrece una gran variedad de directivas para controlar este tema.

Gestión de la salud y diagnóstico en microservicios

Puede parecer obvio y a menudo se pasa por alto, pero un microservicio debe notificar su estado y diagnóstico. De lo contrario, hay poca información desde la perspectiva de las operaciones. La correlación de eventos de diagnóstico en un conjunto de servicios independientes y el manejo de las desviaciones del reloj de las máquinas para comprender el orden de los eventos es un desafío. De la misma manera que interactúa con un microservicio a través de protocolos y formatos de datos acordados, es necesario normalizar cómo registrar eventos de salud y diagnóstico que, en última instancia, terminan en un almacén de eventos para consulta y visualización. En un enfoque de microservicios, es clave que los distintos equipos acepten un único formato de registro. Debe haber un enfoque coherente para ver los eventos de diagnóstico en la aplicación.

Exámenes de salud

El estado es diferente de los diagnósticos. El estado trata de cuando el microservicio informa sobre su estado actual para que se tomen las medidas oportunas. Un buen ejemplo es colaborar con los mecanismos de actualización e implementación para mantener la disponibilidad. Aunque un servicio podría estar en mal estado debido a un bloqueo de proceso o reinicio de la máquina, es posible que el servicio siga funcionando. Lo último que necesita es empeorarlo realizando una actualización. El mejor enfoque es realizar una investigación primero o permitir que el microservicio se recupere. Los eventos de mantenimiento de un microservicio permiten tomar decisiones fundamentadas y, de hecho, ayudan a crear servicios de recuperación automática.

En la sección Implementación de comprobaciones de estado en ASP.NET Servicios principales de esta guía, se explica cómo usar una nueva biblioteca de ASP.NET HealthChecks en los microservicios para que puedan notificar su estado a un servicio de supervisión para realizar las acciones adecuadas.

También tiene la opción de usar una excelente biblioteca de código abierto denominada AspNetCore.Diagnostics.HealthChecks, disponible en GitHub y como paquete NuGet. Esta biblioteca también realiza comprobaciones de estado, con un giro inesperado, gestiona dos tipos de comprobaciones:

• Vivacidad: Comprueba si el microservicio está vivo, es decir, si es capaz de aceptar solicitudes y responder.
• Preparación: comprueba si las dependencias del microservicio (base de datos, servicios de cola, etc.) están listas, por lo que el microservicio puede hacer lo que se supone que debe hacer.

Uso de flujos de eventos de diagnóstico y registros

Los registros proporcionan información sobre cómo se ejecuta una aplicación o servicio, incluidas las excepciones, las advertencias y los mensajes informativos simples. Normalmente, cada registro tiene un formato de texto con una línea por evento, aunque a menudo las excepciones también muestran el seguimiento de la pila en varias líneas.

En aplicaciones monolíticas basadas en servidor, puede escribir registros en un archivo en disco (un archivo de registro) y, a continuación, analizarlo con cualquier herramienta. Dado que la ejecución de la aplicación se limita a un servidor fijo o una máquina virtual, normalmente no es demasiado complejo analizar el flujo de eventos. Sin embargo, en una aplicación distribuida en la que se ejecutan varios servicios en muchos nodos de un clúster de orquestador, la posibilidad de correlacionar eventos distribuidos es un desafío.

Una aplicación basada en microservicios no debe intentar almacenar el flujo de salida de eventos o archivos de registro por sí mismo, ni siquiera intentar administrar el enrutamiento de los eventos a un lugar central. Debe ser transparente, lo que significa que cada proceso solo debe escribir su flujo de eventos en una salida estándar que será recogida por la infraestructura del entorno de ejecución. Un ejemplo de estos enrutadores de flujo de eventos es Microsoft.Diagnostic.EventFlow, que recopila flujos de eventos de varios orígenes y los publica en sistemas de salida. Esto puede incluir una salida estándar sencilla para un entorno de desarrollo o sistemas en la nube como Azure Monitor y Azure Diagnostics. También hay buenas plataformas y herramientas de análisis de registros de terceros que pueden buscar, alertar, informar y supervisar registros, incluso en tiempo real, como Splunk o Middleware.

Orquestadores que administran la información de salud y diagnóstico

Al crear una aplicación basada en microservicios, debe tratar la complejidad. Por supuesto, un único microservicio es sencillo de tratar, pero docenas o cientos de tipos y miles de instancias de microservicios es un problema complejo. No solo se trata de crear la arquitectura de microservicios; también necesita alta disponibilidad, direccionabilidad, resistencia, mantenimiento y diagnósticos si tiene previsto tener un sistema estable y cohesivo.

Figura 4-22. Una plataforma de microservicios es fundamental para la administración del estado de una aplicación

Los problemas complejos que se muestran en la figura 4-22 son difíciles de resolver por usted mismo. Los equipos de desarrollo deben centrarse en resolver problemas empresariales y crear aplicaciones personalizadas con enfoques basados en microservicios. No deben centrarse en resolver problemas complejos de infraestructura; Si lo hicieran, el costo de cualquier aplicación basada en microservicios sería enorme. Por lo tanto, hay plataformas orientadas a microservicios, denominadas orquestadores o clústeres de microservicios, que intentan resolver los problemas difíciles de crear y ejecutar un servicio y usar recursos de infraestructura de forma eficaz. Este enfoque reduce las complejidades de la creación de aplicaciones que usan un enfoque de microservicios.

Los diferentes orquestadores pueden parecer similares, pero los diagnósticos y las comprobaciones de estado que ofrece cada uno de ellos difieren en las características y el estado de madurez, a veces en función de la plataforma del sistema operativo, como se explica en la sección siguiente.

Recursos adicionales

• La aplicación Twelve-Factor. XI. Registros: tratar los registros como flujos de eventos
  https://12factor.net/logs

• Repositorio de GitHub de la biblioteca de diagnóstico EventFlow de Microsoft.
  https://github.com/Azure/diagnostics-eventflow

• ¿Qué es Azure Diagnostics?
  https://dori-uw-1.kuma-moon.com/azure/azure-diagnostics

• Conexión de equipos Windows al servicio Azure Monitor
  https://dori-uw-1.kuma-moon.com/azure/azure-monitor/platform/agent-windows

• Registrar lo que quiere decir: Uso del bloque de registro semántico
  https://dori-uw-1.kuma-moon.com/previous-versions/msp-n-p/dn440729(v=pandp.60)

• Splunk Sitio oficial.
  https://www.splunk.com/

• Middleware Sitio oficial.
  https://middleware.io/

• Clase EventSource API para el seguimiento de eventos para Windows (ETW)
  https://dori-uw-1.kuma-moon.com/dotnet/api/system.diagnostics.tracing.eventsource