Si estas utilizando la arquitectura de microservicios y quieres mejorar el diseño de tu aplicación creo que te puee interesar leer este artículo donde ejemplifico algunos patrones de diseño.
En el desarrollo de aplicaciones empresariales, es recomendable utilizar microservicios en lugar de una arquitectura monolítica. Aunque hay casos en los que una arquitectura monolítica es más adecuada, como para aplicaciones de baja latencia, en la mayoría de los casos, especialmente para aplicaciones Java en la nube, la arquitectura de microservicios ofrece una solución más efectiva.
Entonces, echemos un vistazo a lo que son los microservicios y los patrones de diseño más relevantes para ellos.
¿Qué es Arquitectura de Microservicios?
La arquitectura de microservicios se basa en el dominio de negocios y es una colección de pequeños servicios autónomos. En una arquitectura de microservicios, todos los componentes son autocontenidos y se centran en una sola capacidad empresarial.
¿Por qué es importante considerar la arquitectura de microservicios en lugar de utilizar una arquitectura monolítica? A continuación, se describen cuatro conceptos principales que destacan la importancia de la arquitectura de microservicios sobre la arquitectura monolítica.
- Mayor visibilidad: la arquitectura de microservicios proporciona una mejor visibilidad de los servicios.
- Mayor resiliencia: mejora la resiliencia de nuestra red de servicios.
- Reducción del tiempo de producción: reduce el tiempo de entrega desde la idea hasta el producto final.
- Reducción de costos: reduce el costo total del diseño, implementación y mantenimiento de los servicios de TI.
9 Patrones de Diseño con Microservicios.
Ahora que tienes conocimiento de qué es la arquitectura de microservicios y por qué es importante considerarla para construir aplicaciones que puedan ser escalables y manejar tráfico real, vamos a revisar los principios fundamentales de los microservicios y los patrones de diseño que puedes utilizar para resolver problemas comunes asociados con esta arquitectura.
Los principios en los que se basa la arquitectura de microservicios son los siguientes:
- Escalabilidad
- Flexibilidad
- Independencia y autonomía
- Gobernanza descentralizada
- Resiliencia
- Aislamiento de fallos.
- Entrega continua a través de DevOps
Mientras seguimos los principios mencionados anteriormente, puede haber otros obstáculos en los que los desarrolladores puedan caer, y para evitar esto, podemos usar patrones de diseño en una arquitectura de microservicios.
En este artículo, vamos a analizar 9 patrones de diseño principales que se enumeran a continuación.
- Database per Microservice
- Event Sourcing
- CQRS
- BFF
- API Gateway
- Strangler.
- Circuit Breaker
- Externalized Configuration
- Consumer-Driven Contract Tracing
Patrón Database per Microservice Pattern
El diseño de bases de datos está evolucionando rápidamente y hay numerosos obstáculos que superar al desarrollar una solución basada en microservicios. La arquitectura de bases de datos es uno de los aspectos más importantes de los microservicios.
¿Cuál es la mejor manera de almacenar datos y dónde deben almacenarse?
Existen dos opciones principales para organizar las bases de datos al utilizar la arquitectura de microservicios.
- Base de datos por servicio
- Base de datos compartida
Base de datos por servicio
La idea detrás de este patrón es simple. Cada microservicio tiene su propio almacenamiento de datos (ya sea un esquema completo o una tabla). Los demás servicios no pueden acceder a los repositorios de datos que no controlan. Una solución así ofrece muchas ventajas.
El almacenamiento de datos individual es fácil de escalar. Además, el microservicio encapsula los datos del dominio. Como resultado, comprender el servicio y sus datos como un todo es mucho más sencillo, lo que resulta especialmente importante para los nuevos miembros del equipo de desarrollo.
Ellos necesitarán menos tiempo y esfuerzo para comprender adecuadamente la sección de la que son responsables. La principal desventaja de este servicio de base de datos es que se necesita un mecanismo de protección contra fallos en caso de que la comunicación falle.
Bases de datos compartidas
Utilizar una base de datos compartida es un patrón a evitar en una arquitectura de microservicios. Sin embargo, su uso puede ser cuestionable en algunos casos. El problema radica en que al emplear una base de datos compartida, los microservicios pierden su capacidad de escalar, ser robustos e independientes. Por lo tanto, es poco común que los microservicios utilicen una base de datos compartida.
Cuando se considera que una base de datos común es la mejor opción para un proyecto de microservicios, es necesario cuestionar si realmente se necesitan los microservicios. Tal vez, un enfoque monolítico sería más adecuado. En cuanto a cómo funciona una base de datos compartida, su uso en una arquitectura de microservicios no es común. En algunos casos, se podría utilizar temporalmente mientras se migra de un enfoque monolítico a uno de microservicios. La ventaja fundamental de una base de datos compartida es la gestión de transacciones, ya que no es necesario distribuirlas entre los servicios.
Patrón Event Sourcing Pattern
El patrón de Event Sourcing es responsable de proporcionar una nueva secuencia ordenada de eventos, la cual se puede utilizar para reconstruir el estado de la aplicación. Para hacer esto, se debe registrar cada cambio en el estado de la aplicación. La idea principal detrás de Event Sourcing es que cualquier cambio en el estado de una entidad debe ser capturado por el sistema.
En lugar de almacenar el estado actual de un objeto, se almacena una serie de eventos que cambian el estado. Cada vez que el estado de un objeto cambia, se agrega un nuevo evento a la secuencia. Esto se considera una acción atómica. Al reproducir la secuencia de eventos, se puede reconstruir el estado actual de una entidad.
En la arquitectura de microservicios impulsada por eventos, se utiliza una especie de base de datos llamada almacenamiento de eventos para registrar y hacer un seguimiento de todos los eventos. Además de ser una base de datos, este almacenamiento de eventos funciona como un intermediario de mensajes, permitiendo que los servicios se suscriban a eventos a través de una API.
Cada vez que se guarda un evento en la base de datos, el almacenamiento de eventos envía información sobre él a todos los suscriptores interesados. En resumen, el almacenamiento de eventos es la piedra angular de la arquitectura de microservicios basada en eventos.
Este patrón puede ser empleado en las siguientes situaciones:
- Es fundamental mantener el almacenamiento de datos actual
- No deben realizarse modificaciones en el código base de la capa de datos existente
- Las transacciones son esenciales para el éxito de la aplicación.
En consecuencia, como se ha discutido anteriormente, el event sourcing resuelve el reto de implementar una arquitectura orientada a eventos. Los microservicios que comparten bases de datos no pueden escalar de manera sencilla y la base de datos se convierte en un punto único de fallo. Los cambios en la base de datos podrían afectar varios servicios.
Patrón Command Query Segmentation (CQRS) Pattern
En el párrafo anterior se ha tratado el tema del event sourcing. En este apartado, se abordará el concepto de CQRS, el cual se puede desglosar en dos partes: comandos y consultas.
Los comandos son acciones que modifican el estado de un objeto o entidad, mientras que las consultas devuelven el estado actual de la entidad sin modificar nada.
En los sistemas de gestión de datos tradicionales, se presentan ciertos problemas, tales como el riesgo de conflicto de datos y la complejidad en la gestión del rendimiento y la seguridad, ya que los objetos son accesibles tanto para aplicaciones de lectura como de escritura.
Para solucionar estos problemas, se introduce el concepto de CQRS que se encarga de modificar el estado de una entidad o devolver resultados.
A continuación, se mencionan los beneficios de utilizar CQRS:
- Se reduce la complejidad del sistema al separar los modelos de consulta y comandos.
- Puede proporcionar múltiples vistas para propósitos de consulta.
- Puede optimizar el lado de lectura del sistema por separado del lado de escritura.
El lado de escritura del modelo maneja la persistencia de eventos y sirve como fuente de información para el lado de lectura. El modelo de lectura del sistema genera vistas materializadas de los datos, que suelen ser vistas altamente desnormalizadas.
Patrón Backend For Frontend (BFF)
Este patrón se emplea para determinar cómo se obtienen los datos entre el servidor y los clientes. Lo ideal es que el equipo de frontend sea el encargado de gestionar el BFF.
Un único BFF se encarga de manejar una única interfaz de usuario y nos ayuda a mantener el frontend simple y ver una vista de datos unificada a través del backend
¿Por qué se necesita BFF en nuestras aplicaciones de microservicios?
La razón principal de utilizar BFF en nuestras aplicaciones de microservicios es desacoplar la capa de frontend de la arquitectura de backend. Por ejemplo, si tenemos una aplicación móvil y una aplicación web que necesitan comunicarse con los servicios de backend en una arquitectura de microservicios, implementar un cambio en uno de los servicios de frontend requerirá la implementación de una nueva versión en lugar de simplemente actualizar el servicio existente.
Aquí es donde entra en juego la arquitectura de microservicios, que puede comprender lo que nuestras aplicaciones necesitan y cómo manejar los servicios. Utilizar BFF en la arquitectura de microservicios tiene varias ventajas, como aislar el backend de la aplicación del frontend y permitir la reutilización de código. Además, BFF funciona como un servidor proxy entre el cliente y otras API externas, servicios, etc., lo que puede aumentar la latencia si la solicitud debe pasar por otro componente.
Patrón API Gateway
La arquitectura de microservicios es ideal para aplicaciones grandes con múltiples aplicaciones de clientes y tiene como objetivo proporcionar un punto de entrada único para un grupo específico de microservicios.
La API Gateway se sitúa entre las aplicaciones de clientes y los microservicios y funciona como un proxy inverso que redirige las solicitudes del cliente a los servicios. Además de esto, la puerta de enlace de la API puede proporcionar otros servicios transversales como autenticación, terminación SSL y caché.
Se considera la arquitectura de API Gateway en lugar de la comunicación directa entre el cliente y el microservicio por varias razones.
- En primer lugar, la falta de una puerta de enlace aumentaría la superficie de ataque al exponer todos los microservicios al mundo exterior.
- En segundo lugar, las preocupaciones transversales como la autorización y el SSL deberían ser manejadas por cada microservicio si no hay una puerta de enlace, lo que aumenta el número de microservicios internos.
- En tercer lugar, sin una puerta de enlace, las aplicaciones de clientes estarían vinculadas a los microservicios internos y tendrían que comprender cómo los microservicios descomponen las diversas secciones de la aplicación.
Por último, pero no menos importante, la API Gateway de microservicios debe ser capaz de manejar fallas parciales. Si un microservicio no responde, la falla no debe afectar el rendimiento de toda la solicitud.
La API Gateway de microservicios tiene varias formas de lidiar con fallas parciales, como utilizar datos previamente almacenados en caché de una solicitud anterior, devolver un código de error para datos importantes y sensibles al tiempo, proporcionar un valor vacío y confiar en los valores de hardware más importantes.
Patrón Strangler
El patrón de diseño Strangler es una forma popular de transformar gradualmente una aplicación monolítica en microservicios, sustituyendo la funcionalidad antigua con un nuevo servicio. Una vez que el nuevo componente está listo, se «estrangula» el componente antiguo y se pone en uso el nuevo.
La interfaz de fachada, que sirve como la interfaz principal entre el sistema antiguo y otras aplicaciones y sistemas que lo llaman, es uno de los componentes más importantes del patrón Strangler.
Los sistemas externos podrán identificar el código asociado con una función específica, mientras que el código subyacente del sistema antiguo estará oculto por la interfaz de fachada. El patrón Strangler aborda este problema requiriendo que los desarrolladores proporcionen una interfaz de fachada que les permita exponer servicios y funciones individuales cuando se liberan del monolito.
Es importante comprender la calidad y la confiabilidad de su sistema, ya sea que esté trabajando con código heredado, iniciando el proceso de «estrangular» su sistema antiguo o ejecutando una aplicación recién contenerizada. Cuando algo sale mal, es necesario saber cómo llegó el sistema allí y por qué tomó ese camino.
Patrón Circuit Breaker Pattern
El patrón de diseño de Circuit Breaker Pattern resuelve los problemas de fallas en llamadas remotas o en llamadas que quedan sin respuesta por un tiempo determinado, lo que puede agotar recursos críticos y causar fallas en múltiples sistemas de la aplicación si hay muchos llamadores que no reciben respuesta de un proveedor.
Este patrón consiste en envolver una llamada de función protegida en un objeto de interruptor de circuito que monitorea los fallos. Cuando el número de fallos alcanza un nivel específico, el interruptor de circuito se activa y todas las llamadas posteriores resultan en un error o un mensaje de servicio diferente o predeterminado en lugar de realizar la llamada protegida.
Diferentes estados en el patrón del interruptor de circuito:
Cerrado – Cuando todo funciona bien de acuerdo con la forma normal, el interruptor de circuito permanece en este estado cerrado.
Abierto – Cuando el número de fallos en el sistema supera el umbral máximo, esto llevará a abrir el estado abierto. Esto dará un error para las llamadas sin ejecutar la función.
Medio abierto – Después de haber ejecutado el sistema varias veces, el interruptor de circuito pasará al estado medio abierto para verificar si aún existen problemas subyacentes.
Externalized Configuration
Con frecuencia, los servicios deben ser ejecutados en diferentes entornos y se requiere una configuración específica para cada entorno, como claves secretas y credenciales de la base de datos. Cambiar el servicio para cada entorno presenta desventajas, por lo que es necesario encontrar una manera de permitir que el servicio se ejecute en múltiples entornos sin modificaciones.
Para abordar esta necesidad, existe el patrón de configuración externalizada, que permite que todas las configuraciones de la aplicación, incluyendo credenciales de base de datos y ubicaciones de red, se externalicen.
Por ejemplo, el marco de Spring Boot habilita la configuración externalizada, lo que le permite leer la configuración desde muchas fuentes y cambiar la configuración especificada previamente en función del orden de lectura. Afortunadamente, FastAPI cuenta con soporte integrado para la configuración externalizada.
Consumer-Driven Contract Tracing
Cuando un equipo está construyendo múltiples servicios relacionados al mismo tiempo como parte de un esfuerzo de modernización, y tu equipo conoce el «lenguaje del dominio» del contexto acotado pero no las propiedades individuales de cada agregado y carga de evento, el enfoque de contratos impulsados por el consumidor puede ser efectivo.
Este patrón de microservicios resulta beneficioso para aplicaciones heredadas con modelos de datos extensos.
La implementación de este patrón de diseño aborda los siguientes problemas:
- Cómo añadir una API sin interrumpir a los clientes
- Cómo determinar quién está utilizando el servicio
- Cómo implementar ciclos de lanzamiento cortos mediante la entrega continua.
En una arquitectura impulsada por eventos, muchos microservicios exponen dos tipos de API:
- API RESTful sobre HTTP
- Basada en mensajes y HTTP. La API RESTful permite la integración sincrónica con estos servicios, así como amplias capacidades de consulta para los servicios que han recibido eventos de un servicio.
En resumen, el enfoque de contratos impulsados por el consumidor se utiliza a veces al descomponer una aplicación monolítica heredada.
Resumen
En este tutorial hemos cubierto los 9 patrones y principios de diseño de Microservicios más importantes. Además, se ha explorado qué es la arquitectura de Microservicios y sus patrones de diseño clave. La arquitectura de Microservicios y la computación en la nube están estrechamente relacionadas, ya que la arquitectura de Microservicios facilita el desarrollo y la implementación en la nube.
Asimismo, el uso de herramientas como Docker y Kubernetes hace que sea más sencillo escalar un Microservicio, lo que ha llevado a que cada vez más empresas migren a la arquitectura de Microservicios. Sin embargo, crear una solución de Microservicios que pueda funcionar en producción a largo plazo no es fácil, por lo que el conocimiento de los patrones de diseño de Microservicios más populares es fundamental para tener éxito.