Resumen Técnico: Reconstrucción de Arquitectura Distribuida de Proyectos de Microservicios Políglotas y de Multi-Repositorio

Planteamiento del Problema

El artículo identifica dos desafíos primarios en el mantenimiento de una documentación arquitectónica precisa para sistemas de microservicios:

1. Heterogeneidad Tecnológica: Los proyectos de microservicios suelen emplear diversos lenguajes de programación, marcos de trabajo (frameworks) y convenciones de codificación. Los enfoques actuales de análisis estático están frecuentemente limitados a tecnologías específicas (por ejemplo, Java Spring) o requieren capas de abstracción complejas e independientes del lenguaje (por ejemplo, ReSSA) que imponen altas barreras de implementación para soportar nuevos lenguajes.
2. Restricciones de Multi-Repositorio: Muchas arquitecturas de microservicios se desarrollan en entornos de "multi-repo", donde los servicios se mantienen en repositorios separados por equipos independientes. Las herramientas de reconstrucción existentes generalmente asumen la disponibilidad de un código fuente monolítico, requiriendo que todo el sistema sea analizado de forma centralizada. Este enfoque anula los beneficios de acoplamiento débil de los microservicios, ya que incluso cambios menores en un solo servicio requieren el reanálisis de todo el sistema, lo que hace que la integración en los pipelines de CI/CD individuales de cada servicio sea poco práctica.

Además, aunque existen soluciones de análisis dinámico (por ejemplo, OpenTelemetry), estas requieren sistemas en ejecución. El análisis estático es preferible para la integración en los flujos de trabajo de desarrollo y para el análisis de repositorios sin despliegue, pero faltan herramientas de reconstrucción estática robustas y de propósito general.

Metodología

Los autores proponen ModARO (MODular Architecture Reconstruction Orchestrator), un framework para la reconstrucción de arquitectura estática basado en los siguientes conceptos centrales:

1. Extractores Modulares

En lugar de un único algoritmo universal, el framework utiliza extractores: funciones modulares y sin estado (stateless) escritas para inspeccionar y modificar entidades de modelo basadas en tecnologías específicas (por ejemplo, Docker Compose, Java Spring).

• Modelo de Ejecución: Los extractores aceptan una entidad de modelo como entrada, la modifican y devuelven el resultado. No tienen estado global; los datos se pasan exclusivamente a través del modelo.
• Registro: Los extractores registran un Esquema JSON que define los tipos de entidades específicas que pueden procesar.
• Flexibilidad: Los extractores pueden invocar herramientas externas o librerías de terceros, permitiendo la integración de herramientas de análisis estático existentes (por ejemplo, envolviendo ReSSA) o lógica personalizada.

2. El Algoritmo de Reconstrucción

El framework emplea un algoritmo recursivo para orquestar la ejecución de los extractores:

• Inicialización: Se crea una entidad de modelo de alto nivel basada en la configuración (por ejemplo, la ruta del repositorio).
• Ejecución Iterativa: El algoritmo itera a través de los extractores registrados. Si una entidad coincide con el esquema del extractor, se pasa una copia al mismo.
• Resolución de Conflictos y Agregación: Los cambios realizados por los extractores se aplican. Si múltiples extractores modifican el mismo campo en una sola pasada, se detectan conflictos y se lanzan errores. Los cambios no conflictivos (por ejemplo, añadir elementos a arreglos) se fusionan.
• Recursión: El proceso se repite hasta que no se crean nuevas entidades y no se producen más modificaciones. Las sub-entidades se procesan de forma recursiva.
• Seguimiento de Estado: A cada entidad se le asigna un UUID para evitar que los extractores se ejecuten varias veces sobre la misma entidad, evitando bucles infinitos.

3. Reconstrucción de Arquitectura Distribuida

Para soportar entornos de multi-repo, el framework permite la reconstrucción distribuida:

• Ejecución Independiente: Cada repositorio ejecuta el proceso de reconstrucción de forma independiente dentro de su propio pipeline de CI/CD, produciendo un archivo de modelo (JSON).
• Agregación: Estos archivos de modelo se agregan posteriormente en una vista de arquitectura unificada. El algoritmo de agregación realiza una unión recursiva de objetos JSON.
  • Escalares: Los valores escalares conflictivos (cadenas, números) disparan errores para asegurar la integridad de los datos.
  • Arreglos: Los arreglos se fusionan mediante la formación de una unión de contenidos. Los elementos primitivos idénticos se deduplican; los objetos compatibles (por ejemplo, microservicios con nombres/versiones coincidentes) se fusionan.
• Vinculación Retroactiva: Para manejar dependencias entre servicios sin un acoplamiento estrecho, los extractores pueden definir vínculos basados en características observables (por ejemplo, dominio, puerto, endpoint) en lugar de IDs o URIs fijos. Estos vínculos se resuelven solo después de la agregación del modelo, lo que permite que los extractores operen sin conocimiento de los servicios remotos.

4. Framework de API

El artículo proporciona una API para simplificar el desarrollo de extractores, centráéndose en tres operaciones clave:

1. Escaneo de árboles de directorios para archivos/carpetas específicos (usando patrones glob).
2. Extracción de datos de contenidos de archivos (usando expresiones regulares para velocidad, con planes para el análisis completo de gramática).
3. Inyección de datos en el modelo.

Contribuciones Clave

• Framework ModARO: Una implementación de código abierto de una herramienta de reconstrucción de arquitectura basada en análisis estático y modular.
• Modelo de Reconstrucción Distribuida: Un enfoque novedoso que permite que los repositorios de microservicios se analicen de forma independiente y se agreguen posteriormente, preservando el principio de acoplamiento débil de los microservicios.
• Arquitectura de Extractores Extensible: Un diseño que reduce la barrera para soportar nuevas tecnologías al permitir que los desarrolladores escriban extractores específicos sin modificar un motor central o crear abstracciones complejas independientes del lenguaje.
• Mecanismo de Vinculación Retroactiva: Un método para definir relaciones entre servicios basados en características dinámicas en lugar de identificadores estáticos, facilitando el análisis distribuido.

Resultados y Aplicaciones

El artículo describe el diseño y los algoritmos del framework y señala su aplicación exitosa en escenarios específicos:

• Generación de Gráfos de Dependencia: El co-financiador de los autores, Swordfish Computing, utilizó el framework para generar grafos de dependencia para sus proyectos de microservicios. El proceso de agregación fusionó automáticamente las dependencias compartidas (por ejemplo, versiones de librerías idénticas) en entradas únicas, resultando en grafos más compactos e interpretables.
• Casos de Uso Potenciales: Los autores sugieren que el framework podría utilizarse para recopilar salidas de herramientas de heurística y de "code smell", detectar problemas de configuración o agregar reportes de pruebas dentro de los pipelines de construcción.

Significado y Reivindicaciones

El artículo posiciona a ModARO como una solución práctica a las limitaciones de las herramientas de análisis estático actuales, que a menudo no logran soportar entornos políglotas y de multi-repositorio.

• Practicidad: Al priorizar un enfoque modular sobre un único algoritmo universal, el framework busca ser más viable para una amplia gama de arquitecturas con menores barreras de implementación.
• Integración en el Flujo de Trabajo: La naturaleza distribuida del enfoque permite que la reconstrucción de la arquitectura se integre directamente en los pipelines de CI/CD de cada servicio, apoyando la naturaleza compositiva del desarrollo de microservicios.
• Estático vs. Dinámico: Los autores argumentan que, si bien el análisis dinámico es maduro, el análisis estático es mejor para los flujos de trabajo de desarrollo y el análisis de repositorios donde el despliegue del sistema no es factible.

Los autores reconocen que el trabajo es un diseño e implementación de un framework, y planean trabajos futuros para definir un esquema de modelo estándar, evaluar el framework en proyectos del mundo real y explorar APIs estándar de análisis de código.