La creación de sistemas escalables, mantenibles y resilientes requiere conocer importantes patrones de diseño, que son cada vez más frecuentes en la arquitectura de microservicios. Los microservicios, a diferencia de las arquitecturas monolíticas, dividen los grandes sistemas en servicios independientes más manejables que se conectan entre sí a través de una red. Sin embargo, esta naturaleza distribuida introduce complejidad en áreas como la comunicación, la gestión de datos y la coordinación de servicios.
La adopción de patrones de diseño de microservicios conocidos puede ayudar a mitigar estos problemas y mejorar significativamente la confiabilidad y eficacia de su sistema. En este artículo se tratan los 7 principales patrones de diseño de microservicios que todo desarrollador de software debe conocer.
1. Patrón de puerta de enlace API
API Gateway actúa como un punto de entrada único para todas las solicitudes de los clientes a los microservicios. En lugar de que los clientes interactúen directamente con múltiples servicios, API Gateway consolida estas solicitudes, las enruta a los microservicios apropiados y agrega respuestas. Simplifica la comunicación cliente-servidor y proporciona una forma de gestionar cuestiones transversales como la autenticación, el registro y la limitación de velocidad.
Beneficios:
✓ Control centralizado sobre el manejo de solicitudes/respuestas.
✓ Simplifica las interacciones del lado del cliente al abstraer la complejidad de los microservicios internos.
✓ Permite una implementación más sencilla de seguridad, almacenamiento en caché y limitación.
Ejemplo:
Uso de Express.js en Node.js para crear una puerta de enlace API básica:
import express from 'express'; import proxy from 'express-http-proxy'; const app = express(); // Forward requests to microservice A app.use('/serviceA', proxy('http://serviceA-url')); // Forward requests to microservice B app.use('/serviceB', proxy('http://serviceB-url')); app.listen(3000, () => { console.log('API Gateway running on port 3000'); });
2. Patrón de disyuntor
En una arquitectura de microservicios, las fallas en el servicio son inevitables. El patrón de disyuntor ayuda a prevenir fallas en cascada al monitorear las llamadas de servicio y detener llamadas adicionales a un servicio que falla cuando se alcanza un cierto umbral de falla. Una vez que se recupera el servicio, el disyuntor permite volver a realizar llamadas. Esto mejora la resiliencia del sistema y evita cargas innecesarias en servicios que ya tienen problemas.
Beneficios:
✓ Protege contra fallas en todo el sistema.
✓ Proporciona respuestas alternativas durante fallas.
✓ Mejora la solidez de la arquitectura de microservicios.
Ejemplo:
Usando la biblioteca zarigüeya en Node.js como disyuntor:
import CircuitBreaker from 'opossum'; import axios from 'axios'; const options = { timeout: 5000, errorThresholdPercentage: 50, resetTimeout: 30000, }; const circuitBreaker = new CircuitBreaker(() => axios.get('http://serviceB-url'), options); circuitBreaker.fire() .then(response => console.log(response.data)) .catch(err => console.log('Service B is down. Circuit is open.'));
3. Base de datos por patrón de servicio
Cada microservicio debe tener su propia base de datos dedicada, lo que permitirá a los equipos trabajar de forma independiente y reducirá el estrecho acoplamiento entre servicios. Este patrón de diseño garantiza que los microservicios puedan evolucionar de forma independiente sin verse afectados por cambios en un esquema de base de datos compartida.
Beneficios:
✓ Reduce la dependencia y la contención entre servicios.
✓ Facilita el escalado independiente y la evolución del esquema.
✓ Aísla la propiedad y la responsabilidad de los datos.
4. Patrón de saga
En una arquitectura distribuida, manejar transacciones que abarcan múltiples servicios puede ser un desafío. Saga Pattern gestiona transacciones distribuidas utilizando una serie de transacciones locales que se coordinan a través de múltiples servicios. Cada servicio ejecuta su transacción y desencadena la siguiente, con mecanismos de compensación para deshacer operaciones si algo sale mal.
Beneficios:
✓ Permite transacciones distribuidas consistentes sin un administrador de transacciones centralizado.
✓ Admite la coherencia final entre microservicios.
✓ Permite revertir operaciones incompletas cuando sea necesario.
Ejemplo:
En un sistema de comercio electrónico, el servicio de pedidos puede crear un pedido, el servicio de pagos procesa el pago y el servicio de inventario actualiza los niveles de existencias. Si el pago falla, las actualizaciones de pedidos y existencias deben revertirse, lo cual se maneja mediante transacciones de compensación.
5. Patrón de abastecimiento de eventos
El patrón de abastecimiento de eventos almacena el estado de un sistema como una secuencia de eventos. En lugar de guardar el estado actual en una base de datos, los microservicios almacenan eventos que representan cambios de estado. Al reproducir estos eventos, siempre se puede reconstruir el estado actual, lo que proporciona un seguimiento de auditoría completo y permite mecanismos de recuperación sofisticados.
Beneficios:
✓ Proporciona un seguimiento de auditoría claro de todos los cambios.
✓ Permite el análisis histórico reproduciendo eventos pasados.
✓ Facilita la reconstrucción del estado si es necesario.
Ejemplo:
En un sistema de contabilidad, eventos como "transacción creada", "transacción aprobada" y "transacción completada" se almacenan como eventos. El saldo actual se puede volver a calcular reproduciendo todos los eventos de la transacción.
6. Patrón CQRS (segregación de responsabilidad de consulta de comando)
El patrón CQRS separa las operaciones de lectura y escritura en diferentes modelos. Las operaciones de escritura son manejadas por el modelo de comando y las operaciones de lectura son manejadas por el modelo de consulta. Este patrón es particularmente útil para aplicaciones de alto rendimiento donde las lecturas son mucho más frecuentes que las escrituras.
Beneficios:
✓ Optimiza el rendimiento al segregar las preocupaciones de lectura/escritura.
✓ Admite diferentes estrategias de escalabilidad para lecturas y escrituras.
✓ Permite modelos flexibles adaptados a tareas específicas.
7. Patrón de higo estrangulador
El patrón Strangler Fig es una estrategia de migración gradual que le permite refactorizar o reemplazar partes de un monolito con microservicios. A medida que se agregan nuevas funciones, se construye como un microservicio. Con el tiempo, el monolito se reemplaza, servicio por servicio, sin interrumpir todo el sistema a la vez.
Beneficios:
✓ Proporciona una ruta no disruptiva para migrar de monolitos a microservicios.
✓ Reduce el riesgo de reescrituras completas del sistema.
✓ Permite la mejora incremental y la refactorización.
Ejemplo:
Puede comenzar extrayendo el componente de autenticación de usuario de una aplicación monolítica en un microservicio independiente mientras mantiene intactas otras partes del sistema. Con el tiempo, se trasladan más componentes a microservicios hasta que todo el sistema esté modularizado.
Conclusión
Hay muchas formas diferentes de abordar los problemas que surgen en los sistemas distribuidos cuando se utilizan principios de diseño de microservicios. Crear una arquitectura de microservicios confiable y escalable requiere comprender estos patrones, independientemente de sus objetivos: administrar datos entre servicios, mejorar la comunicación entre servicios o manejar errores con elegancia. Al abordar requisitos y compensaciones particulares, cada uno de estos patrones contribuye a la resiliencia y el rendimiento de sus microservicios.
Descargo de responsabilidad: Todos los recursos proporcionados provienen en parte de Internet. Si existe alguna infracción de sus derechos de autor u otros derechos e intereses, explique los motivos detallados y proporcione pruebas de los derechos de autor o derechos e intereses y luego envíelos al correo electrónico: [email protected]. Lo manejaremos por usted lo antes posible.
Copyright© 2022 湘ICP备2022001581号-3