¿Qué son los patrones de diseño de microservicios?

Estos patrones de arquitectura proporcionan soluciones estandarizadas para los retos cotidianos a los que se enfrentan los equipos de desarrollo al implementar sistemas informáticos distribuidos, incluida la comunicación de servicios, la coherencia de los datos, la tolerancia a fallos y la escalabilidad del sistema.

Muchas de las experiencias digitales en las que se basa el mundo son posibles gracias a los patrones de diseño de microservicios y se pueden ver en muchos casos de uso. Por ejemplo, si está viendo una serie en Netflix, está contratando cientos de servicios separados que trabajan juntos para entregar contenido, administrar perfiles de usuario y sugerir qué ver a continuación.

Del mismo modo, Amazon coordina el inventario, los pagos y los envíos a través de distintos servicios. En el sector financiero, los bancos y otras instituciones también se basan en patrones de diseño de microservicios para separar la gestión de riesgos y el servicio de atención al cliente, manteniendo el dinero seguro y accesible.

Según la encuesta de IBM Microservices in the Enterprise de 2021, el 88 % de las organizaciones afirman que los microservicios ofrecen muchos beneficios a los equipos de desarrollo. Estos beneficios incluyen un aumento del 20 % al 50 % en la productividad de los desarrolladores debido a una mejor organización del código, un mantenimiento más sencillo y ciclos de implementación más rápidos.

La arquitectura de microservicios es un método nativo de la nube que divide las aplicaciones en servicios independientes y poco acoplados que se implementan en contenedores gestionados por plataformas de orquestación como Kubernetes.

Cada servicio funciona de forma independiente con su propia pila tecnológica dedicada, incluyendo bases de datos dedicadas y modelos de gestión de datos. La comunicación entre servicios se produce a través de API REST, plataformas de transmisión de eventos, como Apache Kafka, y agentes de mensajes, mientras que los equipos diseñan servicios en torno a capacidades empresariales con límites claros denominados contextos acotados.

Este enfoque moderno para el desarrollo de software respalda la flexibilidad operativa requerida para las iniciativas modernas de transformación digital, como la automatización de DevOps y los pipelines CI/CD, la migración a la nube, la modernización de aplicaciones y la integración de inteligencia artificial (IA) .

Aunque los microservicios ofrecen ventajas significativas para las aplicaciones modernas, entender cuándo elegir esta arquitectura requiere compararla con los enfoques tradicionales.

La arquitectura monolítica crea una aplicación como una única unidad implementable donde todas las funciones empresariales están integradas y comparten la misma base de código, base de datos y tiempo de ejecución. La arquitectura de microservicios divide una aplicación en servicios más pequeños e independientes que se comunican a través de interfaces de programación de aplicaciones (API) bien definidas, cada una de las cuales tiene potencialmente su propia base de datos y ciclo de implementación.

La diferencia clave entre estos métodos de diseño es el acoplamiento: cuán estrechamente conectadas están las diferentes partes del sistema. Los monolitos tienen un alto acoplamiento interno pero una implementación sencilla, mientras que los microservicios tienen un acoplamiento suelto entre servicios pero requisitos de infraestructura de TI más complejos.

Los ingenieros de software suelen elegir la arquitectura monolítica para aplicaciones más pequeñas y sencillas, como las pequeñas empresas o las startups que buscan controlar los costes y acelerar el desarrollo. En escenarios complejos que requieren alta escalabilidad, resiliencia y flexibilidad (por ejemplo, plataformas de redes sociales, aplicaciones), los microservicios son la mejor opción.

A la hora de decidir qué enfoque adoptar, las organizaciones deben evaluar cada uno en función de sus requisitos específicos, incluido el tamaño del equipo, la complejidad de la aplicación, las necesidades de escalabilidad y los niveles de madurez de DevOps.

Más información sobre las diferencias entre la arquitectura monolítica y los microservicios.

Los patrones de diseño de microservicios se dividen en cinco áreas clave que proporcionan soluciones probadas que ayudan a los equipos a resolver los retos de la arquitectura distribuida:

1. Comunicación y descubrimiento de servicios
2. Gestión de datos y transacciones
3. Resiliencia y gestión de fallos
4. Arquitectura e integración
5. Evento y comunicación

Patrón de registro de servicios

El patrón de registro de servicios crea un directorio central donde los servicios registran sus endpoints y su estado, lo que elimina la necesidad de direcciones. Cuando los servicios necesitan comunicarse, consultan el registro para encontrar instancias de servidor disponibles. Por ejemplo, cuando un servicio de pago necesita ponerse en contacto con un servicio de inventario, comprueba el registro para localizar instancias de inventario en buen estado.

Patrón de puerta de enlace de API

Un patrón de puerta de enlace de API crea un único punto de entrada entre los clientes y varios microservicios de back-end. En lugar de que los clientes realicen llamadas separadas a diferentes servicios, la puerta de enlace de API recibe una solicitud, la enruta a los microservicios apropiados y combina las respuestas en un resultado.

Por ejemplo, al cargar la página de un producto, la puerta de enlace puede obtener simultáneamente detalles del producto, precios, inventario y reseñas de diferentes servicios. A continuación, devuelve toda esta información en una respuesta única y consolidada al cliente.

Patrón de descubrimiento de servicios

Un patrón de descubrimiento de servicios resuelve el reto de que los servicios se localicen entre sí en entornos dinámicos. A medida que los microservicios se amplían o se actualizan a una nueva versión, sus ubicaciones de red cambian constantemente. Los patrones de descubrimiento de servicios proporcionan mecanismos automatizados para que los servicios se registren y encuentren otros servicios con los que necesitan comunicarse, eliminando la necesidad de direcciones codificadas.

Patrón de base de datos por servicio

El patrón de base de datos por servicio garantiza que cada microservicio posea y gestione su propia base de datos, eliminando las dependencias de datos compartidas entre servicios. Este enfoque impide el acceso directo a datos entre servicios y reduce el acoplamiento, aunque requiere que los servicios se comuniquen a través de API cuando necesitan información de otras fuentes de información. Por ejemplo, en un sistema de planificación de recursos empresariales (ERP), el servicio de contabilidad gestiona los datos financieros independientemente de la base de datos de empleados del servicio de RR. HH.

Patrón Saga

Un patrón Saga gestiona transacciones que abarcan varios microservicios dividiéndolas en pasos coordinados. Cada servicio completa su transacción local y desencadena los próximos pasos de la cadena. Si algún paso falla, el patrón ejecuta automáticamente acciones para deshacer los pasos anteriores. Por ejemplo, al procesar un pedido en línea, si el pago falla después de reservar el inventario, la saga libera automáticamente los artículos reservados.

CQRS (patrón de segregación de responsabilidades de comando y consulta)

El patrón CQRS separa la modificación de datos (comandos) de la recuperación de datos (consultas) mediante el uso de modelos dedicados para cada uno. Esta división permite al sistema optimizar cada ruta de forma independiente, minimizando la contención de escritura en el lado de los comandos y reduciendo la latencia de las consultas en el lado de la lectura. En un sistema de comercio electrónico, la realización de un pedido utiliza el modelo de comando optimizado para escritura, mientras que la generación de un informe de ventas aprovecha el modelo de consulta optimizado para lectura.

Patrón de disyuntor

El patrón de disyuntor evita que los fallos en un servicio se propaguen por todo el sistema mediante la monitorización de las llamadas a los servicios posteriores y la detención de las solicitudes cuando se detectan fallos. Cuando un servicio deja de responder, el disyuntor se "dispara" y bloquea más llamadas, protegiendo los recursos del sistema y evitando fallos en cascada.

Por ejemplo, si un servicio de inventario deja de funcionar, el disyuntor impide que el servicio de pedidos realice repetidas solicitudes fallidas. Esto permite que el resto del sistema siga funcionando mientras proporciona respuestas alternativas a los clientes.

Patrón de mamparos

El patrón de mamparos aísla los recursos del sistema para evitar que los fallos en un área afecten a todo el sistema. Al igual que los compartimentos del casco de un barco, los mamparos separan diferentes funciones para que, si una falla, las demás sigan operativas. El patrón limita el número de solicitudes simultáneas o recursos asignados a servicios específicos.

Patrón de backend-for-frontend (BFF)

Un patrón backend-for-frontend (BFF) crea un servicio backend dedicado adaptado a cada interfaz front-end específica. Dado que las aplicaciones móviles tienen requisitos diferentes a los de las aplicaciones web (por ejemplo, pantallas más pequeñas, ancho de banda limitado, capacidades de rendimiento variables), el patrón BFF permite a los desarrolladores optimizar cada backend para su front end particular.

Patrones de entidad y agregado

Un patrón de entidad y agregado organiza los datos relacionados en unidades lógicas basadas en conceptos de diseño basado en dominios (DDD). Una entidad representa un objeto distinto con una identidad única, como una cuenta de cliente identificada por una dirección de correo electrónico. Un agregado combina entidades relacionadas que deben actualizarse juntas como una sola unidad.

Por ejemplo, en un sistema de comercio electrónico, un agregado de pedidos incluiría los detalles del pedido, las líneas de pedido y la información de envío, todo lo cual debe permanecer sincronizado cuando se producen cambios.

Patrón de higo estrangulador

Un patrón de higo estrangulador ayuda a gestionar el proceso de refactorización de una aplicación monolítica en una arquitectura de microservicios más fácil de mantener. Los nuevos microservicios se crean gradualmente junto al monolito existente, asumiendo lentamente la funcionalidad hasta que el sistema antiguo se reemplaza completamente. El nombre proviene de la metáfora de cómo una enredadera (microservicios) crece gradualmente alrededor de un árbol (la aplicación monolítica) y, con el tiempo, acaba estrangulándolo.

Patrón basado en eventos

Un patrón basado en eventos permite a los microservicios comunicarse de forma asíncrona mediante la publicación y el consumo de eventos en lugar de realizar llamadas de servicio directas. Cuando un servicio completa una acción, transmite un evento que otros servicios interesados pueden escuchar y responder en consecuencia. Este enfoque crea un acoplamiento flexible entre los servicios, lo que les permite operar de forma independiente sin dejar de coordinar sus actividades a través de un sistema de eventos compartido.

Patrón Sidecar

Un patrón Sidecar se refiere a implementar un contenedor secundario (el "sidecar") junto con una aplicación principal dentro del mismo entorno de ejecución. Este sidecar gestiona cuestiones transversales (por ejemplo, información de registro, monitorización, seguridad, observabilidad), ampliando la funcionalidad de la aplicación principal sin modificar su base de código.

Patrón Adapter de microservicios

Un patrón Adapter de microservicios permite la comunicación entre sistemas o interfaces incompatibles. Al igual que un adaptador de viaje le permite conectar su dispositivo a tomas de corriente extranjeras, los patrones Adapter se convierten entre diferentes formatos de datos, protocolos o API. Este patrón es beneficioso cuando se integra con sistemas heredados o servicios de terceros que utilizan diferentes estándares de comunicación.

Los patrones de diseño de microservicios son especialmente valiosos en sectores que requieren una alta escalabilidad, una lógica empresarial compleja y un rendimiento fiable del sistema. Los principales casos de uso incluyen:

• Las plataformas de comercio electrónico se basan en patrones de diseño de microservicios para gestionar el equilibrio de carga durante los eventos de ventas y gestionar el inventario complejo en varios almacenes. También coordinan las operaciones de pago, envío y servicio de atención al cliente en diferentes sistemas para mejorar los resultados empresariales y las experiencias del cliente.
• Los servicios de streaming utilizan patrones de microservicios para ofrecer contenido de forma global a la vez que gestionan las preferencias y recomendaciones de los usuarios, lo que les permite gestionar cargas masivas de usuarios simultáneos con un almacenamiento en búfer mínimo y experiencias personalizadas.
• Los servicios financieros implementan estos patrones para separar las operaciones comerciales, de gestión de riesgos, de autenticación y de cara al cliente, a la vez que mantienen el estricto cumplimiento normativo y los estándares de seguridad exigidos por las instituciones financieras.
• Los sistemas sanitarios utilizan estos patrones para integrar los registros de pacientes, la programación de citas y los sistemas de facturación, a la vez que mantienen el cumplimiento de la HIPAA y se conectan con varias API de dispositivos médicos en diferentes proveedores sanitarios.
• Las plataformas de redes sociales utilizan patrones de diseño de microservicios para escalar la mensajería, las fuentes de contenido y el procesamiento de medios de forma independiente, lo que les permite manejar miles de millones de interacciones de usuarios diariamente mientras mantienen un rendimiento receptivo en todas las características.

Los patrones de diseño de microservicios ofrecen buenas prácticas para gestionar los complejos sistemas distribuidos actuales y ofrecen estos beneficios:

• Reducción de la complejidad: los enfoques estandarizados y probados para los retos comunes conducen a resultados más predecibles, una resolución de problemas más sencilla y una incorporación más rápida al equipo.
• Agilidad y menor tiempo de comercialización: los equipos pueden desarrollar, implementar y escalar servicios de forma independiente, lo que reduce los cuellos de botella de coordinación y acelera la entrega de características.
• Mayor tolerancia a los fallos: las técnicas de aislamiento evitan que los fallos se propaguen en cascada por todo el sistema, lo que reduce significativamente el tiempo de inactividad y mejora la fiabilidad general del sistema.
• Mejora de la escalabilidad y la flexibilidad: las organizaciones pueden asignar recursos con precisión donde sea necesario y adaptarse rápidamente a los cambiantes requisitos empresariales sin grandes revisiones del sistema. Los equipos pueden desarrollar servicios en diferentes lenguajes de programación, como Java o Python, en función de las necesidades específicas.
• Eficiencia de costes: el escalado dirigido y la optimización de recursos, combinados con la capacidad de elegir pilas de tecnología óptimas para servicios específicos, dan como resultado sistemas más económicos.
• Diversidad tecnológica: los equipos pueden seleccionar las mejores herramientas y marcos para los requisitos específicos de cada servicio, lo que conduce a soluciones más eficientes y fáciles de mantener. Por ejemplo, puede seleccionar Java Spring Boot para microservicios empresariales para bases de datos como servicio (DBaaS) o Python para análisis de datos.

La selección de patrones adecuados depende de los requisitos específicos de su sistema y de las capacidades organizativas. El uso de un enfoque sistemático puede guiar estas decisiones en materia de arquitectura.

Comience con la puerta de enlace API y el descubrimiento de servicios antes de implementar patrones complejos como el abastecimiento de eventos o CQRS. Estos patrones básicos establecen la infraestructura de comunicación necesaria para implementaciones más sofisticadas.

Tenga en cuenta su experiencia con sistemas distribuidos, madurez operativa y prácticas DevOps. Los equipos nuevos en microservicios se benefician inicialmente de patrones más simples, mientras que los equipos experimentados pueden abordar patrones de coordinación más avanzados que requieren un conocimiento operativo más profundo.

Cada patrón introduce una complejidad que su equipo debe gestionar a largo plazo. La base de datos por servicio requiere estrategias de sincronización de datos. Los patrones basados en eventos necesitan una infraestructura de intermediario de mensajes. Asegúrese de tener la capacidad de admitir los patrones elegidos.

Comience con algunos servicios utilizando patrones básicos, gane experiencia y luego amplíe a medida que crezca su experiencia. Este enfoque incremental evita el exceso de ingeniería y permite aprender de las primeras implementaciones.