Depuración de monolitos frente a microservicios.

Las aplicaciones, tradicionalmente, se han desarrollado como "monolitos". Este término describe cómo se compila y entrega el código de la aplicación. Los monolitos se compilan y / o empaquetan en un solo binario, o un paquete de código, y se implementan como una sola unidad. Esa única unidad contiene cientos, a veces miles de líneas de código. La funcionalidad incluida en ese artefacto desplegable es la mayoría, si no todas, las funciones de la aplicación.
Diagrama monolito
Este método de entrega de software ha sido eclipsado en los últimos cinco años por la arquitectura de microservicio . Los microservicios contrastan con los monolitos en que cada microservicio está estrechamente "limitado". Realiza una función esencial de una aplicación, y nada más. Todas las interacciones con microservicios se rigen por el contrato que expone, en forma de una API. La forma más común de esto es una pequeña colección de puntos finales compatibles con REST.
Diagrama de microservicios
Las diferencias operativas entre monolitos y microservicios son más evidentes cuando se resuelve un fallo. Los monolitos son convenientes porque todo el código está agrupado. Es fácil rastrear una solicitud al código a lo largo de todo su ciclo de vida. Esto puede comenzar con un botón en una página web y moverse a través de una "pila" de funciones que conducen a una consulta de base de datos. Todo lo que los sistemas de depuración y registro necesitan reunir e informar sobre el comportamiento de la aplicación se concentra en un solo implementable.
Los microservicios no están convenientemente agrupados. Se distribuyen por diseño. Cada microservicio se implementa de forma independiente. Las solicitudes pueden fluir a través de muchos microservicios a medida que pasan datos de un cliente a otro. Depurar un problema, como los datos mal formados y las excepciones, o los problemas de rendimiento, como los tiempos de respuesta lentos, es más complejo.
¿Cómo un equipo descompone un monolito en un conjunto de microservicios, sin perder la capacidad de responder a los problemas operativos? Vamos a averiguar.

Cómo depurar microservicios

El término "depuración" evoca imágenes específicas en la mente de los desarrolladores. Si se siente más cómodo en un IDE como Visual Studio o Eclipse, es probable que tenga imágenes de puntos de interrupción y rastros de pila corriendo por su cabeza. Esta forma interactiva de depuración es extremadamente útil en entornos DEV.
Las situaciones extremas pueden requerir depuradores remotos en otros entornos, tal vez incluso en producción. Sin embargo, esta es la excepción y no la regla. Adjuntar depuradores remotos requiere configuración adicional y, a veces, privilegios elevados. Puede sorprender que la depuración remota no sea necesariamente la forma más eficiente de localizar problemas.

El papel del registro y el informe de errores

La depuración de aplicaciones de microservicio modernas y distribuidas se realiza mejor con un registro efectivo Este es un método reactivo de depuración que proporciona visibilidad del comportamiento de una aplicación. Se terminaron los días de registro y, a continuación, la búsqueda manual de archivos de texto masivos.
El registro es la mejor manera de depurar, por lo que las prácticas de registro adecuadas son el primer lugar para comenzar a mejorar su capacidad de depuración. Sus desarrolladores no pueden depurar el comportamiento que no pueden ver. Inclínate hacia "demasiada información" al iniciar sesión. El espacio en disco es barato y sus registros pueden rodar cada treinta días aproximadamente. No tenga miedo de grabar todo lo que hacen sus servicios.
El registro es más efectivo cuando se combina con una herramienta de informe de fallas , que mostrará la línea exacta de código donde ocurrió el error, haciendo que el proceso de depuración sea mucho más rápido.
Cada función de cada microservicio debe ser instrumentada. No es suficiente registrar errores en un bloque catch. Necesitará un registro informativo de los puntos de entrada y salida de las funciones para poder medir el tiempo que demoran en ejecutarse. Cada registro debe incluir el contexto suficiente para comprender de dónde proviene, incluido el nombre de la función y el nombre del usuario, cuando corresponda.

Cómo rastrear microservicios

Cada microservicio tendrá su propio conjunto de registros. Las solicitudes se pasan, al estilo "hot-potato", de un servicio a otro. Un solo clic en un botón en una página web puede resultar en una cascada de solicitudes que fluyen a través de varios microservicios.
Pero, ¿cómo hace un seguimiento de esa solicitud a través de todos esos servicios?
La solución más sencilla es generar un ID de "correlación" único que siga todas las solicitudes. Hay varias formas de implementar esta solución. Un servicio "perimetral" que inicia interacciones con todos los microservicios internos puede generar la ID. Alternativamente, los microservicios pueden generar la identificación en cualquier llamada que no tenga una identificación.
Todos sus microservicios deben tener la capacidad de aceptar la ID e incluirla en su registro. Esto unirá las solicitudes, sin importar cuántos "saltos" haya entre los servicios. El ID se incluirá en todos los registros que se correlacionan con esa solicitud. La búsqueda de una identificación en los registros combinados debe devolver todas las llamadas relacionadas con esa solicitud. El contexto de una identificación depende de usted. Puede ser cualquier cosa; una acción generada por el usuario, un trabajo programado o una llamada a una API pública.

Pasos para mejorar la depuración y el rastreo

Si no está registrando mucho, o en absoluto, ese es su punto de partida. La capacidad de depuración de su equipo dependerá de la integridad de sus registros. Los apagones pasados ​​son una excelente fuente de orientación sobre cómo y qué registrar. Use postmortems incidentes para preguntar: “¿Qué datos necesitamos para detectar esta interrupción? ¿Cómo podemos incluir eso en el registro estandarizado? ”Use tantos informes de incidentes como sea posible para desarrollar patrones de registro generalizados.
Aplique sus nuevos patrones de registro a sus prácticas de desarrollo. Revísalos regularmente, y discútelos en revisiones de códigos. Implemente patrones de registro básicos al incluir verificaciones de código estático en su canalización de integración continua. Los analizadores de calidad de código pueden configurarse para buscar el código de registro faltante. La prueba de su código para patrones de registro puede evitar que se implementen funciones no registradas.
La búsqueda de registros en múltiples archivos y bases de datos es difícil. Siempre que sea posible, todos sus registros deben ir a una única base de datos. Los marcos de registro más populares admiten la redirección del registro a una base de datos o un punto final HTTP. Mantener todos los datos de registro en una única ubicación simplificará en gran medida la tarea de depuración y seguimiento.

Marcos y herramientas para la depuración y el rastreo.

Marcos de registro

Una de las mejores maneras de estandarizar su enfoque de registro es usar un marco. Los marcos de registro están entre el software de código abierto más antiguo y más común, por lo que encontrar algunos para elegir no es complicado. Cada lenguaje y marco popular tiene al menos uno, generalmente dos o más marcos de registro que se dirigen a ellos. Log4J (Java) NLog (.NET) y Node-Loggly (Nodo) son solo algunos ejemplos. El "derecho" para usted dependerá de sus necesidades. Las consideraciones clave incluyen:
  • Limpieza del código: ¿es fácil de leer el código de registro?
  • Rendimiento: ¿el registro causa la latencia u otros problemas de rendimiento?
  • Familiaridad: ¿su equipo ya tiene experiencia con un marco particular?
Trabaja con tus desarrolladores para calificar estas y otras consideraciones que puedas imaginar por impacto. Use esa prioridad para crear una lista corta de marcos que puedan funcionar. Si dos están clasificados juntos, intente hacer un horneado. Desarrolle un pico utilizando ambos marcos y ejecute algunas pruebas de rendimiento.

Bases de datos de registro

Los registros se pueden almacenar en archivos y bases de datos relacionales. Muchos de los marcos de registro mencionados anteriormente admiten ambos. Las bases de datos especializadas denominadas bases de datos de series de tiempo (TSDB) se adaptan mejor a la recopilación de telemetría.
Los datos de registro se utilizan para capturar eventos. Los registros, una vez registrados, nunca se modifican. Las TSDB están optimizadas para datos que solo se agregan y llegan en orden cronológico. El registro de eventos de aplicaciones es un caso de uso central para las bases de datos de series de tiempo. Hay varios TSDB de código abierto disponibles, incluidos Prometheus y Kibana (la "K" en el clásico "ELK stack").
Algunos TSDB incluyen herramientas de visualización de datos basadas en la web que pueden usarse para consultar registros. Grafana es una herramienta de visualización dedicada que funciona con la mayoría de las TSDB. La mejor combinación de TSDB y herramientas de soporte dependerá de los requisitos operacionales de TSDB y de los requisitos de capacidades para depurar y rastrear sus aplicaciones.

Herramientas de monitoreo

Las herramientas de Application Performance Monitoring (APM) como Raygun APM solucionarán problemas de rendimiento en entornos de microservicio con un agente ligero.
En la siguiente captura de pantalla de Raygun, puede ver una traza lenta que causa un problema, luego Raygun muestra la línea de código.
código de llamas

¿Cómo puede hacerse más fácil la depuración de microservicios?

El nuevo mundo valiente de los microservicios trae consigo tanto potencia como mayor complejidad. Los microservicios de depuración y rastreo son diferentes de los monolitos y, por lo tanto, deben tratarse de manera diferente.
Los microservicios se despliegan y operan de manera independiente. Esto distribuye las fuentes de registro a través de muchos servicios individuales, en lugar de solo uno. Un buen registro es la mejor fuente de datos para solucionar problemas, depurar y rastrear microservicios.
Cree prácticas de registro sólidas y estandarizadas en sus equipos de desarrollo. Use las revisiones de código y las herramientas de calidad de código para hacer cumplir esos estándares. Las bases de datos y herramientas de código abierto y comercial completan una estrategia completa para mantener sus microservicios en buen estado y sus sistemas en funcionamiento.
¿Se pregunta cómo puede supervisar los microservicios para detectar problemas de rendimiento? Las Raymun APM están diseñadas teniendo en cuenta las prácticas modernas de desarrollo. Vea cómo la plataforma Raygun puede ayudar a mantener el rendimiento de la arquitectura de microservicio.