La arquitectura de microservicios (en inglés, Micro Services Architecture, MSA) es una aproximación para el desarrollo de software que consiste en construir una aplicación como un conjunto de pequeños servicios, los cuales se ejecutan en su propio proceso y se comunican con mecanismos ligeros (normalmente una API de recursos HTTP). Cada servicio se encarga de implementar una funcionalidad completa del negocio. Cada servicio es desplegado de forma independiente y puede estar programado en distintos lenguajes y usar diferentes tecnologías de almacenamiento de datos.
Se suele considerar la arquitectura de microservicios como una forma específica de realizar una arquitectura orientada a servicios.
En el mundo real, no todas las implementaciones de este estilo de arquitecturas siguen las mismas características, pero la mayor parte de las arquitecturas de microservicios tienen la mayor parte de las siguientes características:
Cuando tratamos con problemas complejos, es necesario tratar con el problema de manejar procesos de negocio que involucran a varios servicios. Hay dos formas de abordar este tipo de problemas: Orquestación y coreografía.
Veamos un ejemplo de un sistema en el que cuando doy de alta un cliente tengo que:
La estrategia a tomar con un mecanismo de orquestación sería que el servicio cliente contenga la lógica de control y en la creación este se comunicaría con el Banco de puntos de fidelidad, el Servicio de correo postal y el Servicio de correo electrónico a través de una serie de llamadas petición/respuesta. Por tanto el Servicio Cliente realiza el seguimiento de las tareas y sabe si el proceso se ha completado sin problemas. El problema de este enfoque es que el Servicio de Cliente se puede convertir en una autoridad de gobierno central demasiado fuerte donde toda la lógica gira alrededor de él.
La estrategia a tomar con un mecanismo de coreografía sería informar a cada parte del sistema de su trabajo, y dejarlos trabajar en los detalles, como los bailarines en un ballet que se encuentran en su camino y reaccionan ante otros a su alrededor. Para ello el servicio cliente emitiría un mensaje asincrónico cuando se crea un cliente. Así el Servicio de Correo Electrónico, el Servicio Postal, y el Banco de puntos de Fidelidad, solo es necesario que se suscriban a esos eventos y reaccionar en consecuencia. Si algún otro servicio necesita llegar a la creación de un nuevo cliente, simplemente tiene que subscribirse a los eventos y hacer su trabajo cuando sea necesario. Este diseño implica que se necesita de trabajo adicional para asegurarnos de que se han sucedido las cosas correctas. Por ejemplo, saber si el banco de puntos de fidelidad tuvo un error y por alguna razón no estableció correctamente los puntos. Para solucionar este problema, normalmente es necesario crear un sistema de monitoreo que refleje explícitamente la vista del proceso de negocio, y a su vez, haga un seguimiento de lo que cada uno de los servicios realiza como entidad independiente que le permite ver excepciones mapeadas al flujo de proceso más explícito.
En general, los sistemas que utilizan el enfoque del tipo coreografía, están débilmente acoplados, son más flexibles y más susceptibles de cambiar. Sin embargo, es necesario realizar el trabajo extra de monitorear y seguir los procesos a través de los límites del sistema.
El enfoque de microservicios esta sujeto a críticas por una serie de problemas:
La arquitectura introduce complejidad adicional y nuevos problemas a resolver, como latencia en la red, formato de los mensajes, equilibrado de carga y tolerancia a fallos.
Una aplicación compuesta por un número de microservicios tiene que acceder a su propio ecosistema, lo que puede crear complejidad innecesaria. Este tipo de complejidad puede reducirse estandarizando el mecanismo de acceso. La Web, considerada como un sistema, estandarizó el mecanismo de acceso a través de mantener el mismo sistema de acceso entre el navegador y los recursos de aplicación sobre los últimos 20 años. Utilizando el número de sitios web indexados por Google, se creció desde 26 millones de páginas en 1998 a alrededor de 60 trillones de páginas individuales en 2015 sin necesitar cambiar el mecanismo de acceso. La Web en sí misma es un ejemplo de cómo la complejidad inherente a un sistema tradicional de software monolítico puede superarse.
Escribe un comentario o lo que quieras sobre Arquitectura de microservicios (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)