Arquitectura de referencia de microservicios

Objetivos, características y beneficios

La arquitectura de microservicios se basa en el enfoque de servicios pequeños: servicios independientes y sencillos que se ejecutan en procesos autónomos y se comunican a través de mecanismos ligeros, generalmente API. Estos servicios se construyen alrededor de capacidades de negocio y son desplegables de manera independiente mediante procesos completamente automatizados.

La evolución y el despliegue independiente de los servicios permiten acelerar los tiempos de puesta en producción. Además, los ciclos de desarrollo y despliegue pueden ser independientes entre servicios y equipos dentro de la organización.

Los principales objetivos de las arquitecturas de microservicios son: 

• Simplificar el desarrollo de un componente software.
• Facilitar el desarrollo y despliegue de un componente software.
• Reducir el coste de mantenimiento de las aplicaciones.
• Fomentar la reutilización de código.
• Reducir el solapamiento entre componentes.
• Reducir el tiempo de pruebas.
• Minimizar los errores.
• Servicios actualizados.
• Independencia tecnológica de sistemas y módulo funcionales.

Las características más importantes y beneficios de la arquitectura de microservicios son:

• Entrega continua: Permite a los desarrolladores constantemente desplegar nuevas funcionalidades.
• Servicios pequeños: Son componentes software de pequeño tamaño lo que facilita su evolución, comprensión y mantenimiento.
• Despliegues independientes: El despliegue de un microservicio no depende del despliegue de ningún otro componente del sistema.
• Servicios escalables: Los microservicios pueden escalarse de forma manual o automática. El escalado engloba escalado horizontal y vertical.
• Autonomía de los equipos: Permite a los equipos ser independientes. Un equipo puede enfocarse en adquirir conocimiento sobre el negocio que maneja su microservicio y aislarse del negocio que gestiona el resto del sistema. 
• Versionado: Los microservicios permiten exponer varias versiones de la misma funcionalidad, simplificando el despliegue de nuevas funcionalidades sin impactar en los consumidores existentes.
• Disponibilidad: Los microservicios tienen una alta disponibilidad y no dejan de prestar servicio ni siquiera cuando se están actualizando o recuperando de un error. 
• Autonomía: Cada dominio de negocio tiene autonomía en la toma de decisiones y construcción de servicios.
• Adopción de nuevas tecnologías: Se facilita la adopción de nuevas tecnologías al independizar servicios por áreas de negocio o dominios, ya que cada uno puede elegir la tecnología más adecuada a sus necesidades.

Principios

Partiendo de los principios generales definidos en la arquitectura global de contexto y que aplican en su totalidad a la arquitectura de microservicios, estos poseen una serie de principios específicos que se listan a continuación:

• Independencia y responsabilidad única
• Orientado a servicios

(*) Puede consultarse el listado de Principios Tecnológicos Generales.

Independencia y responsabilidad única

Los microservicios deben ser independientes unos de otros. Esta independencia debe mantenerse tanto a nivel de negocio como a nivel técnico. 

• Nivel de negocio: Un microservicio debe poner el foco en solo un elemento del negocio y encargarse de toda la gestión relativa a ese elemento. Es decir, debe tener solo una responsabilidad dentro del conjunto del sistema. Ejemplos de posibles elementos de negocio dentro de la ADA: interesados, trámites, subvenciones, presupuestos, etc.  
• Nivel técnico: Cada microservicio debe tener su propio ciclo de vida y poder actualizarse, levantarse y pararse sin afectar al resto del sistema. El nivel de independencia debe ser tal, que cualquier elemento del sistema debe de poder comunicarse con un microservicio sin necesidad de saber en qué tecnología, lenguaje o framework está implementado.

Orientado a servicios

El objetivo de un microservicio es prestar un servicio y compartir el resultado de dicho servicio con el exterior. Por ello, los microservicios deben diseñarse para publicar servicios que pueden ser síncronos (API REST) o asíncronos (eventos). 

Componentes

Para la correcta implantación de una arquitectura de microservicios se debe contar con los siguientes componentes:

• Servicio de descubrimiento de servicios.
• Balanceador de carga.
• Módulo de seguridad.
• Configuración centralizada.
• Colector de observabilidad.
• Módulo de resiliencia.  
   

Sistema de descubrimiento

Para garantizar el principio de independencia dentro de una arquitectura de microservicios, estos deben desplegarse usando mecanismos que permitan a los servicios descubrirse unos a otros.  

Mediante este mecanismo los servicios se registran con un único endpoint basado en DNS que les permite comunicarse unos con otros. El microservicio que quiera acceder a ese servicio no necesita saber en qué IP está desplegado o cuantos pods están disponibles para ese servicio, ya que el servicio de autodescubrimiento soluciona ese problema automáticamente asignando una url interna para su consumo interno. 

Balanceador de carga

Un balanceador de carga permite repartir la carga de trabajo entre instancias que estén corriendo de un mismo servicio. Este componente identifica en tiempo real, que instancia es la más adecuada para responder a una petición, garantizando un nivel de rendimiento estable en el cluster. El balanceador de carga gestiona el tráfico si se añaden o eliminan instancias del servicio.  

Módulo de seguridad

Todos los microservicios deben incorporar un módulo común de seguridad que permita gestionar la seguridad de forma unificada. Este módulo estará integrado con las especificaciones definidas en la arquitectura de seguridad. 

Configuración centralizada

Para facilitar la adaptación de los microservicios a cualquier circunstancia que pueda producirse en tiempo real, la configuración de los microservicios debe estar centralizada y ser independiente del código desplegado. Los microservicios, además, deben garantizar que pueden aceptar cambios de configuración en caliente sin necesidad de reinicio. 

Colector de observabilidad

La observabilidad es el grado en el que comprendemos el estado interno o la condición de un sistema complejo basándonos solo en el conocimiento de sus salidas externas. Cuanto más observable sea un componente software, más rápida y precisa será su respuesta ante cualquier tipo de problema.

La observabilidad se basa en la generación, recolección y análisis de métricas, trazas y log: 

• Métricas: Las métricas permiten gestionar la salud individual de un componente software. 
• Trazas: Analizan el estado de una petición y nos permite comprobar si estas peticiones navegan correctamente a través de los diferentes componentes software.
• Logs: Mensajes que dan información variada sobre un componente software.

Un componente software debe cuidar la observabilidad en todo su ciclo de vida:

• En el desarrollo: Implantando componentes reutilizables y desarrollados expresamente para la ADA que le permitan generar trazas, métricas y log estandarizados y que se acojan a las normas y pautas definidas por la ADA.
• En el despliegue: Integrando el microservicio con los agentes centralizados que recogen las trazas, métricas y logs y los distribuye a las plataformas de monitorización.
• Durante el uso: Definiendo alertas y configurando cuadros de mandos que permitan a los responsables de calidad verificar el correcto funcionamiento de los componentes software en tiempo real.

Módulo de resiliencia

Para garantizar la resiliencia de los microservicios deben implementar una serie de medidas que garanticen la gestión de reintentos, circuit breaker y gestión de códigos de error entre otras. Este módulo, define mediante configuración qué debe hacer un microservicio si detecta que un componente externo con el que se comunica ha dejado de funcionar correctamente, la respuesta al servicio está tardando más de lo normal, o reintentar la ejecución si obtiene un error técnico.

Cada microservicio es responsable de realizar la configuración requerida en función de los servicios dependientes a los que invoca, y ajustar los parámetros a las necesidades técnicas y de negocio. 

Patrones de arquitectura y diseño

A continuación, se describen el conjunto de patrones de arquitectura y diseño aplicables a arquitecturas de microservicios. Para cada proyecto o necesidad, aplicarán un conjunto de patrones u otros.  

La utilización de estos patrones son la solución para garantizar que la arquitectura cumpla con los principios ya descritos usando para ello los componentes definidos en el apartado anterior. 

Patrones para el diseño de microservicios

Los patrones que se indican a continuación permitirán a los desarrolladores tener unas directrices para descomponer las funcionalidades de negocio en microservicios e indicar qué negocio abordará cada microservicio. 

Decompose by subdomain

Este patrón define los servicios según la estrategia de diseño dirigido al dominio (DDD). El modelado basado en dominios consiste en identificar y representar en el software los conceptos y reglas del negocio que se encuentran bajo el dominio de un problema. El objetivo es crear una representación del dominio que sea lo más cercana posible a la realidad y que permita a los desarrolladores comprender y trabajar con el problema de la forma más efectiva.  

La diferencia entre el modelado basado en DDD y el tradicional es que, el tradicional construía un modelo único que a menudo resultaba ser rígido y enrevesado cuando la complejidad del negocio era elevada. El modelado basado en DDD permite definir modelar el negocio como un conjunto de subdominios cada uno con su propio modelo. De esta forma permite partir de una definición simple a una más compleja centrada en un dominio.

Como cada subdominio corresponde con un ámbito de conocimiento o negocio dentro del proyecto, este modelado permite definir el conjunto de microservicios que solucionan ese problema. Permitiendo tener equipos diferentes, cada uno especializado en un ámbito del negocio que trabajan de forma independiente. 

Principios que aplican: 

• Design Driven Development
• Independencia y responsabilidad única
• Simplicidad

Referencia: Pattern: Decompose by subdomain

Patrones para la comunicación entre microservicios

Remote Procedure Invocation

Este patrón permite la comunicación entre dos microservicios usando el patrón de invocación a procedimiento remoto (RPI).  

En este mecanismo un cliente en un dominio envía una petición a un servicio que se encuentra en otro dominio (microservicio) y espera a que este le envíe una respuesta. Habitualmente este tipo de comunicación es síncrona y bloquea al cliente mientras espera la respuesta, aunque hoy en día puede volverse asíncrono usando programación reactiva y estilos de programación no bloqueante.

Este patrón se basa en el uso de protocolos de comunicación estándares basados en HTTP y en el intercambio de objetos JSON. Los protocolos de comunicación autorizados son REST, gRPC, GraphQL y WebSocket.  

Para implementar este patrón se utilizará siempre que sea posible la estrategia API-First frente a CODE-First. Para gRPC y GraphQL se utilizarán los lenguajes de definición de contrato diseñados para estas tecnologías, para REST se recomienda utilizar la especificación OpenAPI en su versión 3 o superior. 

Principios que aplican:

• API First & Open API
• Orientado a servicios

Referencia: 

• Pattern: Remote Procedure Invocation (RPI)
• gRPC
• GraphQL
• OpenAPI    

Messaging

Para una comunicación asíncrona entre microservicios se utilizará el patrón mensajería. Este patrón se basa en la generación de eventos asíncronos que se enviarán a un message broker. El beneficio de este patrón con respecto a su homólogo síncrono es que no bloquea al cliente y permite desacoplar completamente al productor (servicio) con el consumidor (cliente).  

Dado que este desacoplamiento entre productor y consumidor puede generar incoherencia en los datos se recomienda usar una aproximación de contrato primero usando para ello AsyncAPI, una especificación similar a OpenAPI pero orientada a generar contratos en eventos asíncronos.  

Principios que aplican:

• Desacoplamiento de componentes
• API First & Open API
• Orientado a servicios

Referencia: 

• Pattern: Messaging
• AsyncAPI        
   

Patrones para el descubrimiento de servicios

3rd party registration

Este patrón delega el registro automático de servicios en un componente tercero que es el responsable de registrar y eliminar instancias de servicios del service registry global.  

Cuando la instancia del servicio se inicie, el registrador registra el servicio en el service registry. Asimismo, cuando el servicio finaliza, el registrador elimina el servicio del service registry. 

Principios que aplican: 

• Desacoplamiento de componentes 

Referencia:

• Pattern: 3rd Party Registration

Patrones para la resiliencia de microservicios

Circuit breaker

En un sistema distribuido, cuando un servicio hace una llamada síncrona a otro servicio existe un permanente riesgo de fallo. Como el cliente y el servicio están en procesos separados, un servicio puede no responder a tiempo la solicitud de un cliente porque está caído por fallo o mantenimiento o por existir problemas en la red que ralentizan o hagan imposible la comunicación. Dado que habitualmente el cliente está bloqueado mientras espera la respuesta, cualquier problema en un servicio puede generar un fallo en cascada en todo el sistema.

Este tipo de problemas se gestiona mediante la combinación de una serie de mecanismos: 

• Indisponibilidad de la red: Estableciendo timeouts que impidan el bloqueo indefinido de un cliente al no obtener respuesta del servicio.
• Limitación de peticiones a un servicio: Limitando el número de peticiones por segundo que puede recibir un servicio para evitar que se sature y deje de funcionar correctamente.
• Implementación del patrón circuit breaker. 

Este patrón mide el número de peticiones procesadas y establece la relación de error aceptable en los servicios invocados. Cuando se sobrepasa esta relación, se abre el circuito y se interviene redireccionando las peticiones al servicio que no está disponible y actuando antes de que se produzca el error. Periódicamente el circuit breaker controla si el servicio vuelve a estar disponible. Cuando el servicio está disponible de nuevo, cierra el circuit breaker y dejar que el sistema funcione con normalidad. 

Principios que aplican: 

• Resiliencia sobre recuperación

Referencia:

• Pattern: Circuit Breaker

Patrones para la transaccionalidad de microservicios

Saga

El patrón Saga permite mantener la consistencia de datos en una transacción lógica compuesta por varios microservicios o componentes que actúan mediante una cadena de llamadas entre ellos. Este patrón representa una secuencia de transacciones locales donde, cada transacción local actualiza información dentro de un mismo microservicio.

Asociado a esta transacción lógica definida mediante una Saga, se definen las operaciones de compensación en caso de que se produzca algún error o comportamiento no esperado en una transacción local de un microservicio.

Existen dos tipos de patrones Sagas: 

• Orquestados: Este tipo de Saga se caracteriza por tener una pieza central que controla todo el flujo de la petición. Los diferentes pasos del flujo no conocen nada del proceso y al finalizar vuelven a la pieza central que decide qué siguiente paso toca ahora.
• Coreografiados: Este tipo de Saga se caracteriza por no tener pieza central, y los microservicios realizan una coreografía de operaciones, enviando un evento cuando termina cada transacción local, que lo recibe el siguiente servicio en realizar una operación en la transacción lógica.

La elección de implementar el patrón Saga como orquestado como coreografiado es una decisión de diseño que deberá analizarse para cada caso de uso. 

Principios que aplican: 

• Desacoplamiento de componentes

Referencia:

• Pattern: Saga

Patrones para el acceso a datos

API Composition

Cuando un microservicio quiere acceder a un dato que no le pertenece, este patrón invoca mediante llamada a una API al microservicio dueño de los datos que queremos consultar. Para la correcta ejecución de este patrón es necesario saber qué información del modelo de datos de un microservicio puede ser consultada por otro componente software (ya sea microservicio o de otro tipo) y publicar una API que permita acceder a esa información.

Este patrón contempla la posibilidad de que un microservicio necesite llamar a varios microservicios para obtener toda la información que necesita y componerla en un único objeto con el que pueda operar. El servicio que hace las invocaciones a las APIs se llama API composer y debe diseñarse con mucho cuidado para que el flujo de invocaciones no afecte al rendimiento. 

Principios que aplican: 

• Desacoplamiento de componentes

Referencia:

• Pattern: API Composition

Command Query Responsibility Segregation (CQRS)

El patrón CQRS se utiliza en casos en los que sea necesario separar las responsabilidades de acceso y actualización de los datos.  

Existe una base de datos de lectura basada en vistas que está asociada a tecnologías que permiten realizar accesos y búsquedas de forma eficiente (Elasticsearch, Mongo, Redis, …). Este modelo de datos mantendrá una réplica de solo lectura de esa información que necesitamos consultar, estando asociado únicamente a operaciones de tipo GET (select).

Por otro lado, el modelo de escritura utilizará bases de datos propietarias de los datos donde se realizarán las operaciones POST, PUT o DELETE (create, update o delete).

Al existir dos modelos distintos de consulta y comandos, surge la necesidad de mantener actualizados los datos del modelo de lectura, realizándose para este caso una proyección de los datos. Usualmente se implementa mediante un enfoque orientado a eventos el envío de la información creada o actualizada a un tópico para realizar esa proyección, y existe un componente consumidor que gestiona esos eventos para crear o actualizar la información del modelo de lectura a partir de los datos actualizados del evento. 

Principios que aplican:

• Fuente única de verdad
• Desacoplamiento de componentes

Referencia:

• Pattern: Command Query Responsibility Segregation (CQRS)

Patrones para el acceso a api externas

API Gateway

Un API Gateway es un servicio que hace de enlace entre los microservicios y el resto de clientes que los consumen. Este servicio es el responsable, entre otras cosas, de enrutar las peticiones para que lleguen al destino, pudiéndose añadir adicionalmente políticas para gestionar la seguridad y adaptar la petición y la respuesta.

El API Gateway tiene mapeados todos los servicios y enruta la petición para que llegue a destino. Cuando la respuesta del servicio llega quien primero la recoge es el API Gateway, el cual, entre otras acciones, se asegura de que la respuesta recibida sea segura antes de enrutarla al microservicio que la solicitó. 

Principios que aplican:

• API First & Open API
• Orientado a servicios

Referencia:

• API Gateway

Backend For Frontends (BFF)

El patrón Backend For Frontends (BFF) es una especialización del patrón API Gateway donde se genera una API de experiencia por cada canal dedicado o cliente/aplicación. De esta forma, cada canal tiene una API especializada con las adaptaciones y agregaciones de información necesarias para cada uno de los canales: web, movil, internet, etc.

Las aplicaciones clientes, por tanto, solo deben interactuar con una única API en lugar de con todos los microservicios existentes de negocio, además estando las peticiones y respuestas optimizadas para las aplicaciones frontend específicas. 

Principios que aplican:

• Desacoplamiento de componentes
• API First & Open API
• Orientado a servicios

Referencia:

• Backends for frontends

Patrones de testing

Service Integration Contract Test

Cuando un microservicio se comunica con un servicio externo deben definirse tests de integración que permitan validar que el contrato establecido entre el proveedor y el consumidor puede ser entendido por ambas partes.  

Este patrón verifica que la forma en que el proveedor publica el contrato cumple con las expectativas del consumidor. Para un servicio REST este tipo de prueba verifican que el proveedor publica un servicio con: 

• Un método HTTP válido y un path.
• Cabeceras válidas, en caso de que las haya.
• Un body válido, en caso de que lo haya.
• Devuelva una respuesta con un código de respuesta, cabeceras y body y válidos.

Es importante recordar que este patrón no valida el negocio del servicio que consulta el cliente sino solo verifica que la comunicación pueda establecerse

Principios que aplican:

• Calidad del servicio

Referencia:

• Pattern: Service Integration Contract Test

Service component test

Una vez verificadas las comunicaciones, hay que comprobar además que cada componente que interviene en el proceso funciona correctamente. Como sería muy costoso y complicado verificar toda la funcionalidad en una prueba end-to-end, el patrón anterior se combina con el patrón Service component test para garantizar el funcionamiento del sistema de una forma fácil y rápida de implementar.  

Este patrón crea un test para los componentes y los entrelaza en los tests de integración y tests end-to-end que sean de obligada implementación. Por tanto, verifican el comportamiento de un servicio aisladamente, remplazando las dependencias externas con stubs que simulan ese comportamiento.  

Principios que aplican:

• Calidad del servicio

Referencia:

• Pattern: Service Component Test

Patrones de seguridad

Access Token

Este patrón centraliza la gestión de la seguridad en el API Gateway generando para todas las peticiones que provengan del exterior un token que se envía a los microservicios y que les permite gestionar individualmente el acceso a sus servicios e implementar listas de controles de acceso (ACL).

El funcionamiento de este patrón es el siguiente:

1. Un servicio externo quiere hacer una solicitud a un servicio. Para ello manda unas credenciales. Estas credenciales pueden variar según el servicio que está haciendo la petición.
2. El API Gateway recoge la petición, analiza las credenciales y comprueba que el usuario tiene permisos para acceder a la url que solicita. Cuando verifica que todo está correcto y que el usuario puede acceder, genera un token JWT donde se incluye información de contexto de seguridad del usuario.
3. El API Gateway elimina de la petición las credenciales enviadas por el cliente e inyecta en la petición el token generado. Este token además de proporcionar al microservicio información sobre quien manda la petición, tiene una duración definida y determina el tiempo que dura la sesión.

Principios que aplican:

• Calidad del servicio
• Zero Trust

Referencia:

• Pattern: Access token

Patrones de observabilidad

Application metrics

Las métricas permiten analizar si el funcionamiento de un microservicio es correcto. Este patrón instrumenta un servicio que se encarga de enviar las métricas generadas por el microservicio al colector de métricas para su análisis.

Principios que aplican:

• Calidad del servicio
• Resiliencia sobre recuperación
• Visibilidad & Trazabilidad

Referencia:

• Pattern: Application metrics

Audit logging

El propósito de este patrón es recoger las acciones de los usuarios. Un log de auditoría se usa para ayudar a los responsables de calidad a seguir el funcionamiento de un microservicio y detectar un comportamiento sospechoso. 

Cada log identifica al usuario, la acción que está realizando y el objeto de negocio. 

Principios que aplican:

• Calidad del servicio
• Resiliencia sobre recuperación
• Visibilidad & Trazabilidad

Referencia:

• Pattern: Audit logging

Distributed tracing

Este patrón permite seguir el recorrido de una petición a través de todos los servicios por los que pasa, permitiendo ver los servicios internos y externos con los que la petición ha interaccionado.

Principios que aplican:

• Calidad del servicio
• Resiliencia sobre recuperación
• Visibilidad & Trazabilidad

Referencia:

• Pattern: Distributed tracing

Exception tracking

Cuando se produce una excepción, es importante identificar la causa raíz. Una excepción es un síntoma de que algo no marcha bien en un servicio. La forma tradicional de visualizar las excepciones es mirando los logs, sin embargo, una aproximación mejor es usar un servicio de seguimiento de excepciones.

Este patrón configura un servicio para reportar excepciones que permite hacer seguimiento de las excepciones duplicadas, alertas generadas y gestionar el manejo de excepciones.

Principios que aplican:

• Calidad del servicio
• Resiliencia sobre recuperación
• Visibilidad & Trazabilidad

Referencia:

• Pattern: Exception tracking

Health check API

Este patrón implementa, publicando un endpoint, un mecanismo para que un microservicio pueda comunicar al resto de servicios si está preparado para recibir peticiones.

Principios que aplican:

• Calidad del servicio
• Resiliencia sobre recuperación
• Visibilidad & Trazabilidad

Referencia:

• Pattern: Health check API

Log aggregation

Este patrón recoge los logs distribuidos en diferentes microservicios y los muestra unificados para facilitar el seguimiento y el mantenimiento de las aplicaciones.

Principios que aplican:

• Calidad del servicio
• Resiliencia sobre recuperación
• Visibilidad & Trazabilidad

Referencia:

• Pattern: Log aggregation

Patrones de despliegue

Deploy a service as container

Este patrón propone desplegar un microservicio como un contenedor.

Principios que aplican:

• Despliegues en producción rápidos
• Agilidad
• Green Cloud/Sostenibilidad
• Desacoplamiento de componentes
• Software Libre/Open Source
• Automatización en todas las capas
• Escalabilidad bajo demanda
• Resiliencia sobre recuperación
• Visibilidad & Trazabilidad
• Orientado a servicios

Referencia:

• Pattern: Service instance per container

Service mesh

El patrón Service mesh permite gestionar la cantidad de tráfico que le llega a un microservicio cuando ha sido desplegado en un entorno productivo. De esta forma, para servicios críticos, puede establecerse la cantidad de tráfico que le llega al servicio y escalonar el acceso al mismo después de un despliegue. Así, parte del tráfico irá al nuevo despliegue y el resto al despliegue antiguo. Así si hay un problema no afectará a todos los usuarios y podrá volverse al despliegue anterior simplemente redirigiendo el tráfico.

Principios que aplican:

• Despliegues en producción rápidos
• Agilidad
• Green Cloud/Sostenibilidad
• Desacoplamiento de componentes
• Software Libre/Open Source
• Automatización en todas las capas
• Escalabilidad bajo demanda
• Resiliencia sobre recuperación
• Visibilidad & Trazabilidad
• Orientado a servicios

Referencia:

• Pattern: Service mesh

Serverless deployment

En este patrón de despliegue, la infraestructura toma el código y levanta el servicio directamente sin necesidad de un servidor como intermediario para ejecutar el código del microservicio o función.

Principios que aplican:

• Despliegues en producción rápidos
• Agilidad
• Green Cloud/Sostenibilidad
• Desacoplamiento de componentes
• Software Libre/Open Source
• Automatización en todas las capas
• Escalabilidad bajo demanda
• Resiliencia sobre recuperación
• Visibilidad & Trazabilidad
• Orientado a servicios

Referencia:

• Pattern: Serverless deployment

Sidecar

El patrón sidecar desacopla el core de negocio con la lógica adicional desplegando en un solo nodo dos contenedores relacionados.

El primero de estos contenedores contiene la lógica propia del microservicio sin la cual no puede funcionar. El sidecar contiene aspectos funcionales o técnicos que aplican al servicio en otro contenedor adicional.

Principios que aplican:

• Despliegues en producción rápidos
• Agilidad
• Green Cloud/Sostenibilidad
• Desacoplamiento de componentes
• Software Libre/Open Source
• Automatización en todas las capas
• Escalabilidad bajo demanda
• Resiliencia sobre recuperación
• Visibilidad & Trazabilidad
• Orientado a servicios

Referencia:

• Pattern: Sidecar

Pila tecnológica

Escenarios de aplicación

A continuación, se van a mostrar una serie de escenarios de aplicación donde se puede utilizar la arquitectura de microservicios. 

Publicación de microservicios con comunicación síncrona

Escenario

Se van a definir dos microservicios donde uno va a publicar un servicio REST y el otro lo va a consumir teniendo en cuenta que puede fallar la comunicación entre ellos.

Descripción

• MS 1: Consume el servicio publicado por MS 2 usando un cliente REST para ello. Para gestionar una posible pérdida del servicio de MS 2, se configurará el patrón circuit breaker para proporcionar un comportamiento por defecto si MS2 no responde. 
• MS 2: Publica usando una implementación API-First un servicio basado en el protocolo REST para ello y   una caché Redis para optimizar el servicio.

Patrones

• API-First 
• Circuit Breaker

Publicación de microservicios con comunicación asíncrona

Escenario

Se van a definir dos microservicios que se comunicarán utilizando el patrón Pub-Sub, donde uno va a publicar un evento actuando como productor y otro lo va a consumir actuando como consumidor

Descripción

• MS1: Publica un evento en el broker de mensajería actuando como productor. El evento tiene un contrato definido usando AsyncAPI. 
• MS2: Microservicio que implementa un consumidor, utilizando el broker de mensajería para obtener los eventos publicados por MS1 y los procesa. Gracias al contrato definido con AsyncAPI, el consumidor conoce la definición de los mensajes que va a consumir.

Patrones

• Messaging

Publicación de API para su consumo por el Front

Escenario

Se va a implementar un microservicio que publica una API REST para que sea consumida por cualquier componente del Front.

Descripción

• MS 1: Se diseña un servicio usando para ello el patrón API-First y publicando el servicio en el API Gateway. El servicio que se va a publicar está securizado y el acceso al mismo se hará mediante el patrón Access Token con ayuda del API Gateway. Se va a utilizar una caché para optimizar el servicio.

Patrones

• API Gateway
• API-First
• Access Token
• Caché

Composición de servicios con coreografia

Escenario

Definición de una transacción distribuida entre tres microservicios usando para ello el patón SAGA coreografiado. 

Descripción

• MS 1: Inicia una transacción generando un evento que mandará los datos de inicio de transacción a al broker de mensajería a un topic concreto. Entre los metadatos de la transacción se mandará el instante de inicio para poder garantizar un orden.        
  Se diseñará un consumidor que esté siempre revisando un topic concreto para ver si recibe orden de realizar una compensación para una transacción fallida.
• MS 2: Constará de un consumidor que estará leyendo del topic donde ha escrito MS 1 con los datos que inician la transición. Se creará un productor que, después de haber procesado la transacción, genere un evento a un topic para que la transacción pueda seguir su camino.         
  Se creará un consumidor que siempre estará revisando un topic concreto para ver si recibe orden de realizar una compensación para una transacción fallida. Se creará un productor que mandará los datos de su compensación al MS 1 que inició la transacción.
• MS 3: Constará de un consumidor que estará leyendo del topic donde ha escrito MS 2 con los datos que inician la transacción.         
  Se creará un productor que mandará los datos de su compensación al MS 2 que inició la transacción si fuese necesario al fallar la transacción.

Patrones

• SAGA (Coreografiado)

Microservicio con telemetría

Escenario

Definición de un microservicio que genere y envíe telemetría a través de un colector a la infraestructura de observabilidad definida.

Descripción

• MS 1: Se diseñará un microservicio con la configuración necesaria para que se active la generación de métricas, logs y trazas, configurando el envío a través de un colector de la plataforma de observabilidad.

El colector a su vez tendrá debidamente configurado para cada caso los sistemas destino a los que deben enviar la información recolectada, integrándose con los distintos componentes de observabilidad que analizarán la información recogida.

Patrones

• Application metrics
• Audit logging
• Distributed tracing
• Exception traking
• Health check API
• Log aggregation        
   

Referencias

• Referencias técnicas:
  • Patrones de microservicios
  • gRPC
  • GraphQL
  • OpenAPI
  • AsyncAPI
  • OpenTelemetry
  • Kubernetes
  • Spring Boot