Migración de una aplicación monolítica de backend a una arquitectura de microservicios - 2ª parte

Compartir por correo electrónico
Imagen destacada de la aplicación de migración

Encuentre la primera parte del artículo en siguiendo este enlace

En el artículo de la primera parte, hemos explicado cómo identificar los candidatos a microservicios extrayendo los artefactos de la arquitectura por capas del código existente de una aplicación monolítica. Varios enfoques abordan este primer paso, aunque no abordan el paso de materialización o completan este paso manualmente. Aunque los clusters recuperados ayudan a entender la MSA de destino, el código fuente debe ser transformado para ajustarse al estilo de la MSA (basado en servicios, comunicación orientada a mensajes, etc.). En esta segunda parte, explicaremos la materialización del código fuente existente a uno que implemente el MSA identificado mediante un enfoque de transformación ad hoc.

Concretamente, el objetivo del paso de materialización es transformar el código fuente monolítico existente para crear microservicios funcionales que se ajusten a
la arquitectura de microservicios recuperada, conservando la lógica de negocio de la aplicación. Con respecto a las aplicaciones monolíticas que siguen la arquitectura de objetos
orientado, la dificultad del paso de materialización es transformar las dependencias OO presentes entre los grupos de clases identificados en MSA-
dependencias de tipo (es decir, servicios). Además, estas transformaciones deben respetar los principios de refactorización (es decir, preservar la lógica del negocio) sin degradar el rendimiento del sistema global. Sin embargo, a pesar de la importancia del segundo paso de la migración, y hasta donde sabemos, no se ha propuesto ningún enfoque para automatizarlo.
En este artículo, proponemos un enfoque sistemático para transformar una aplicación OO del estilo monolítico a uno MSA basado en un conjunto de patrones de transformación. Este conjunto de patrones de transformación crea mecanismos de comunicación basados en microservicios que conservan la semántica del monolito, al tiempo que se ajustan a los principios del MSA (por ejemplo, basados en mensajes y orientados a datos). Además, proponemos un proceso automatizado, y una herramienta, que aplica nuestro enfoque de transformación sistemática.

Transformación del código fuente OO hacia uno MSA

La MSA identificada en el paso de recuperación de la arquitectura se materializa en el paso de transformación. Esto implica convertir el código fuente orientado a objetos en código fuente MSA. Cada clúster de clases recuperado se despliega en su propio microservicio durante este paso (es decir, encapsulación de microservicios). Sin embargo, las clases de borde tienen, por definición, dependencias con clases pertenecientes a otro clúster. Estas dependencias estructurales directas entre las clases de diferentes microservicios se denominan violaciones de encapsulación de microserviciosy deben ser manejados antes de que un microservicio pueda ser completamente encapsulado.

Figura 5: Las dependencias a nivel de clase en los clústeres candidatos a microservicios del modelo de pivote
Figura 1: Las dependencias a nivel de clase en los clústeres candidatos a microservicios del modelo de pivote

De hecho, todas las violaciones deben ser manejadas por métodos de refactorización que convierten todas las dependencias de tipo OO en dependencias de tipo MS antes de que se pueda generar un microservicio. Durante este paso, se considera la característica operativa de un MSA para utilizar la comunicación orientada a mensajes entre diferentes microservicios. En otras palabras, las invocaciones de métodos entre clases pertenecientes a diferentes clusters (por ejemplo, las llamadas a métodos entre DisplayManager y ContentProvider) deben restringirse a un conjunto de interfaces proporcionadas y requeridas que definen tanto los servicios web que proporciona como los que consume. Además, las llamadas de comunicación entre procesos (IPC) entre microservicios se limitan a la comunicación basada en valores. En otras palabras, sólo se intercambian primitivas y datos serializados entre microservicios. Sin embargo, una llamada procedimental en un sistema OO puede pasar referencias a objetos entre el objeto invocador y el invocado. Para encapsular los microservicios, hay que resolver el mecanismo de compartición de instancias entre los candidatos a microservicio.
Además de estas dependencias OO explícitas, deben abordarse las dependencias implícitas entre clusters para encapsular completamente los candidatos a microservicio. El mecanismo de herencia y el manejo de excepciones son los dos principales mecanismos OO implícitos que deben abordarse. En particular, una violación de la herencia se define como una clase que tiene una superclase que pertenece a otro clúster (por ejemplo, entre Mensaje y Contenido). La violación del manejo de excepciones se define como una clase
lanzar una excepción que es capturada por una clase que pertenece a otro grupo. Ambos mecanismos OO deben ser abordados y transformados en dependencias de tipo MS.
Por último, la MSA generada tras la etapa de transformación debe cumplir dos características operativas adicionales:

  1. Los microservicios deben ejecutarse en su propio proceso
  2. Deben poder desplegarse automáticamente

Para ajustarse a estas características operativas, cada microservicio debe definir un proyecto independiente que debe ser configurado para su despliegue en la nube. Ambas características deben abordarse durante la generación del código fuente de cada microservicio.

MonoToMicro: Un enfoque de refactorización semiautomática

Ilustración del enfoque de refactorización semiautomática
Figura 2: Proceso de transformación con la herramienta MonoToMicro

En este trabajo, proponemos una forma sistemática de transformar una aplicación OO monolítica en una aplicación MSA con un conjunto de patrones de transformación. El propósito de este enfoque es transformar el código fuente monolítico orientado a objetos en un MSA encapsulando los clusters descubiertos durante el paso de migración inicial. Para ello, definimos un proceso compuesto por cuatro pasos que se presentan en Figura 2 que consisten en:

  1. Detección de violaciones de encapsulación,
  2. Saneamiento de las violaciones de la encapsulación,
  3. Embalaje de microservicios,
  4. Despliegue y contenedorización de microservicios

Detección de violaciones de la encapsulación

Cada clúster de clases recuperado se encapsula en su propio microservicio para materializar los candidatos a microservicio recuperados desde la fuente de software orientado a objetos. Por otro lado, la encapsulación impide las dependencias OO entre clusters (es decir, las violaciones de la encapsulación). Por lo tanto, deben transformarse en dependencias de tipo MS. Sin embargo, antes de que la transformación pueda tener lugar, estas violaciones de la encapsulación deben ser identificadas. Para facilitar la detección de estas violaciones de encapsulación, se propone un conjunto de reglas de violación de encapsulación para analizar el monolito:

  • (Regla 1): si un método de un clúster invoca un método perteneciente a una clase de otro clúster, se trata de una violación de invocación de método.
  • (Regla 2): si un método de un clúster accede a un atributo perteneciente a una clase de otro clúster, se trata de una violación de acceso.
  • (Regla 3): si una clase de un clúster contiene una referencia a una clase de otro clúster, se trata de una violación de instancia.
  • (Regla 4): si una clase de un clúster hereda una clase perteneciente a otro clúster, se trata de una violación de la herencia.
  • (Regla 5): si un método de un cluster lanza, atrapa o declara una excepción definida en otro cluster, entonces es una violación de excepción lanzada.

Estas reglas se aplican a la representación AST del código fuente OO.
Inicialmente, la descripción de la arquitectura de destino se utiliza para dividir los nodos AST que representan las clases en la fuente OO en grupos. A continuación, cada nodo es
se analizan en busca de referencias a nodos de clase que pertenezcan a otro clúster utilizando las reglas de detección antes mencionadas. Una vez detectadas todas las infracciones, se puede proceder a la resolución de las mismas.

Saneamiento de las violaciones de la encapsulación

Las violaciones detectadas en el paso anterior deben ser curadas mediante reglas de transformación para encapsular los microservicios. Estas transformaciones deben sanar completamente o reducir una violación a un tipo solucionable. Anteriormente, la identificación de la violación de la encapsulación cubría:

  1. Invocación de métodos
  2. Acceso a los atributos
  3. Gestión de instancias
  4. Herencia
  5. Gestión de excepciones

En este artículo, presentamos un conjunto de reglas de transformación para curar las violaciones de encapsulación identificadas en el primer paso. En particular, separamos estas violaciones en dos categorías: explícitas e implícitas. Como regla general, los microservicios deben ofuscar su estructura interna y su comportamiento mientras exponen una interfaz claramente definida. Las violaciones que rompen esta regla se consideran explícitas (por ejemplo, acceso a atributos, manejo de instancias e invocación de métodos). Mientras que las violaciones implícitas están relacionadas con la dependencia implícita entre microservicios causada por el mecanismo OO (por ejemplo, la herencia y el manejo de excepciones).

Empaquetado y despliegue de un MSA

Una vez generado el código fuente del MSA, hay que empaquetarlo y hacerlo desplegable. En el paso el enfoque de refactorización semiautomática, se empaquetan los microservicios libres de violaciones. Para ello, cada microservicio tiene su propio proyecto donde se genera el código fuente. A continuación, se construyen automáticamente las estructuras de archivos y las dependencias del proyecto. Los proyectos de microservicios son entonces contenedorizados en el paso de resolución de violaciones de encapsulación generando imágenes instanciables. Se crea un archivo de descripción de imagen para cada microservicio. También se crea un archivo de composición, que organiza y entrega todos los microservicios al mismo tiempo.
En este trabajo, nos concentramos en los dos primeros pasos de la fase de transformación, que comprenden los principales obstáculos científicos señalados anteriormente,
y dejar los dos últimos pasos para la aplicación, ya que comprenden más obstáculos técnicos.

Para continuar...

Referencias

[1] Allier, S., Sadou, S., Sahraoui, H.A., Fleurquin, R.: From object-oriented applications to component-oriented applications via component-oriented architecture. En: 9th Working IEEE/IFIP Conference on Software Architecture, WICSA 2011, Boulder, Colorado, USA, June 20-24, 2011. pp. 214- IEEE Computer Society (2011). https://doi.org/10.1109/WICSA.2011.35, https://doi.org/10.1109/WICSA.2011.35
[2] Alshara, Z., Seriai, A., Tibermacine, C., Bouziane, H., Dony, C., Shatnawi, A.: Migración de grandes aplicaciones orientadas a objetos a aplicaciones basadas en componentes: transformación de la instanciación y la herencia. En: International Conference on Generative Programming: Concepts and Experiences, GPCE pp. 55-64. ACM (2015). https://doi.org/10.1145/2814204.2814223,https://doi.org/10.1145/2814204.2814223
[3] Alshara, Z., Seriai, A., Tibermacine, C., Bouziane, H., Dony, C., Shatnawi, A.: Materialización de la arquitectura recuperada del código fuente orientado a objetos en lenguajes basados en componentes. En: Tekinerdogan, B., Zdun, U., Babar, M.A. (eds.) Software Architecture - 10th European Conference, ECSA 2016, Copenhague, Dinamarca, 28 de noviembre - 2 de diciembre de 2016, Proceedings. Lecture Notes in Computer Science, vol. 9839, pp. 309-325 (2016). https://doi.org/10.1007/978-3-319-48992-6 23, https://doi.org/10.1007/978-3-319-48992-6 23
[4] Amiri, M.J.: Object-Aware Identification of Microservices. En: 2018 IEEE SCC. pp. 253-256. IEEE (jul 2018). https://doi.org/10.1109/SCC.2018.00042,
https://ieeexplore.ieee.org/document/8456428/
[5] Baresi, L., Garriga, M., De Renzis, A.: Identificación de microservicios mediante el análisis de interfaces. En: De Paoli, F., Schulte, S., Broch Johnsen, E. (eds.) Service-
Orientación y computación en la nube. pp. 19-33. Springer International Publishing, Cham (2017) Materializing Microservice-Oriented Architecture 25
[6] Baskarada, S., Nguyen, V., Koronios, A.: Architecting microservices: Oportunidades y desafíos prácticos. Journal of Computer Information Systems 60, 428 -436 (2020)
[7] Birkmeier, D., Overhage, S.: On component identification approaches - classification, state of the art, and comparison. En: Lewis, G.A., Poernomo, I., Hofmeister, C. (eds.) Component-Based Software Engineering, 12th International Symposium, CBSE 2009. Lecture Notes in Computer Science, vol. 5582, pp. 1-18. Springer (2009). https://doi.org/10.1007/978-3-642-02414-6 1, https://doi.org/10.1007/978-3-642-02414-6 1
[8] Chardigny, S., Seriai, A.: Proceso de recuperación de la arquitectura del software basado en el código fuente orientado a objetos y en la documentación. En: Babar, M.A., Gorton, I. (eds.) Software Architecture, 4th European Conference, ECSA 2010, Copenhague, Dinamarca, 23-26 de agosto de 2010. Actas. Lecture Notes in Computer Science,
vol. 6285, pp. 409-416. Springer (2010). https://doi.org/10.1007/978-3-642-15114-9 35, https://doi.org/10.1007/978-3-642-15114-9 35
[9] Chardigny, S., Seriai, A., Tamzalit, D., Oussalah, M.: Extracción impulsada por la calidad de una arquitectura basada en componentes de un sistema orientado a objetos. En: 12th European Conference on Software Maintenance and Reengineering, CSMR 2008, April 1-4, 2008, Athens, Greece. pp. 269-273.IEEE Computer Society (2008). https://doi.org/10.1109/CSMR.2008.4493324, https://doi.org/10.1109/CSMR.2008.4493324
[10] Chen, R., Li, S., Li, Z.: From Monolith to Microservices: A Dataflow-Driven Approach. Proceedings - Asia-Pacic Software Engineering Conference, APSEC pp.
466-475 (2018). https://doi.org/10.1109/APSEC.2017.53
[11] De Alwis, A.A.C., Barros, A., Polyvyanyy, A., Fidge, C.: Function-splitting heuristics for discovery of microservices in enterprise systems. En: Pahl, C., Vukovic, M., Yin, J., Yu, Q. (eds.) Service-Oriented Computing. pp. 37-53. Springer International Publishing, Cham (2018)
[12] Ducasse, S., Pollet, D.: Reconstrucción de la arquitectura del software: A process-oriented taxonomy. IEEE Transactions on Software Engineering 35(4), 573-591 (2009). https://doi.org/10.1109/TSE.2009.19
[13] Fan, C., Ma, S.: Migrating Monolithic Mobile Application to Microservice Architecture: An Experiment Report. En: 2017 IEEE AIMS. pp. 109-112 (jun 2017).
https://doi.org/10.1109/AIMS.2017.23
[14] Francesco, P.D., Malavolta, I., Lago, P.: Investigación sobre la arquitectura de microservicios: Tendencias, enfoque y potencial de adopción industrial. En: 2017 IEEE ICSA. pp.
21-30 (2017). https://doi.org/10.1109/ICSA.2017.24
[15] Fritzsch, J., Bogner, J., Zimmermann, A., Wagner, S.: From monolith to microservices: Una clasificación de los enfoques de refactorización. CoRR abs/1807.10059 (2018), http://arxiv.org/abs/1807.10059
[16] Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Longman Publishing Co., Inc., USA (1995)
[17] Gysel, M., Kolbener, L., Giersche, W., Zimmermann, O.: Cortador de servicios: Un enfoque sistemático para la descomposición de servicios. En: Aiello, M., Johnsen, E.B., Dustdar, S., Georgievski, I. (eds.) Service-Oriented and Cloud Computing. pp. 185-200.Springer International Publishing, Cham (2016)
[18] Jin, W., Liu, T., Zheng, Q., Cui, D., Cai, Y.: Extracción de microservicios orientada a la funcionalidad basada en la agrupación de trazas de ejecución. En: 2018 IEEE ICWS. pp. 211-218 (julio de 2018). https://doi.org/10.1109/ICWS.2018.00034
[19] Levcovitz, A., Terra, R., Valente, M.T.: Towards a technique for extracting microservices from monolithic enterprise systems. CoRR abs/1605.03175 (2016), http://arxiv.org/abs/1605.03175
[20] Lewis, J., Fowler, M.: Microservicios: una definición de este nuevo término arquitectónico (2014), https://martinfowler.com/articles/microservices.html
[21] Mazlami, G., Cito, J., Leitner, P.: Extracción de microservicios de arquitecturas de software monolíticas. En: 2017 IEEE ICWS. pp. 524-531. IEEE (jun 2017). https://doi.org/10.1109/ICWS.2017.61, http://ieeexplore.ieee.org/document/8029803/
[22] Monaghan, B.D., Bass, J.M.: Redening legacy: A technical debt perspective. En: Morisio, M., Torchiano, M., Jedlitschka, A. (eds.) Product-Focused Software Process Improvement. pp. 254-269. Springer International Publishing, Cham (2020)
[23] Newman, S.: Construyendo microservicios: diseñando sistemas de grano fino. O'Reilly Media (2019)
[24] Nunes, L., Santos, N., Rito Silva, A.: From a monolith to a microservices architecture: Un enfoque basado en contextos transaccionales. En: Bures, T., Duchien, L., Inverardi, P. (eds.) Software Architecture. ECSA 2019. pp. 37-52. Springer International Publishing, Cham (2019)
[25] Pahl, C., Jamshidi, P.: Microservicios: Un estudio de mapeo sistemático. En: Actas del 6º CLOSER - Volumen 1 y 2. p. 137-146. CLOSER 2016, SCITEPRESS - Publicaciones de Ciencia y Tecnología, Lda, Setubal, PRT (2016). https://doi.org/10.5220/0005785501370146, https://doi.org/10.5220/0005785501370146
[26] Ponce, F., Marquez, G., Astudillo, H.: Migración de la arquitectura monolítica a los microservicios: Una revisión rápida. En: 2019 38th International Conference
de la Sociedad Chilena de Informática (SCCC). pp. 1-7 (2019). https://doi.org/10.1109/SCCC49216.2019.8966423
[27] Richardson, C.: Microservices Patterns. O'Reilly Media (2018)
[28] Selmadji, A., Seriai, A.D., Bouziane, H.L., Dony, C., Mahamane, R.O.: Rearchitecting oo software into microservices. En: Kritikos, K., Plebani, P., de Paoli,
F. (eds.) Service-Oriented and Cloud Computing. pp. 65-73. Springer International Publishing, Cham (2018)
[29] Selmadji, A., Seriai, A.D., Bouziane, H.L., Mahamane, R., Zaragoza, P., Dony, C.: Del estilo de arquitectura monolítica al de microservicios basado en un enfoque semiautomático. 2020 IEEE International Conference on Software Architecture (ICSA) pp. 157-168 (2020)
[30] Soldani, J., Tamburri, D.A., Van Den Heuvel, W.J.: The pains and gains of microservices: Una revisión sistemática de la literatura gris. Journal of Systems and Software 146, 215-232 (2018). https://doi.org/https://doi.org/10.1016/j.jss.2018.09.082, https://www.sciencedirect.com/science/article/pii/S0164121218302139
[31] Terra, R., Valente, M., Bigonha, R.: An approach for extracting modules from monolithic software architectures. En: . pp. 1-8 (01 2012)
[32] Waseem, M., Liang, P., Shahin, M.: A systematic mapping study on microservices architecture in devops. Journal of Systems and Software 170 (2020). https://doi.org/https://doi.org/10.1016/j.jss.2020.110798, https://www.sciencedirect.com/science/article/ pii/S01641220302053
[33] Zaragoza, P., Seriai, A., Bouziane, H., Shatnawi, A., Derras, M.: Refactoring monolithic object-oriented source code to materialize microserviceoriented architecture. En: Proceedings of the 16th International Conference on Software Technologies - ICSOFT,. pp. 78-89. INSTICC, SciTePress (2021). https://doi.org/10.5220/0010557800780089

Más ...

Ir arriba