• Introducción

• Flujo de procesamiento entre servicios

• Sicronización de datos

Introducción

Las arquitecturas basadas en microservicios deben ser diseñadas para estar muy débilmente acoplados, aquí es donde entra la arquitecta basada en eventos. En EDA los productores no tienen ningún conocimiento de los consumidores que están suscritos  para recibir sus eventos, igualmente los consumidores no tienen conocimiento de los generadores, ellos simplemente estás suscritos a un topic y reciben los eventos sin importar de donde provengan(si que es necesario conocer la estructura del evento). Esta idea encaja perfectamente en la arquitectura basada en microservicios.

Podemos encontrar tres escenarios en los que podemos usar EDA en microservicios:

Flujo de procesamiento entre servicios

Este es el escenario mas claro y que mejor encaja para introducir el EDA en los microservicios. Consiste en utilizar los eventos para la comunicación directa entre microservicios, de la misma manera que normalmente se usarían peticiones REST.  Los microservicios usaran un  middleware que proporcionará el canal de enviar y recibir los eventos. Se podrá utilizar mas de un Broker para ayudar a la escalabilidad del sistema. Es importante que los distintos Brokers pueden escalar y adaptarse a los requerimientos de los distintos microservicios para el correcto funcionamiento de todo el sistema, de nos ser así nos encontraremos con un cuello de botella y es posible que perdamos información. 

A continuación podemos ver un ejemplo de la utilización de EDA en el flujo de procesamiento:

Open

Sicronización de datos

El desacople de los microservicios debe incluir el desacople de sus modelos de datos y persistencia de datos, esto ayuda a que cada servicio actue de una manera mas independiente y evitar problemas al compartir bases de datos.  El problema de esta división es que los datos a menudo deben ser accesible desde diferentes servicios, podemos abordar esto mediante peticiones REST pero generará latencia debido al tiempo extra de peticiones y nos generará dependencias entre los servicios, ya que los servicios que almacenan la información deberían estar siempre disponibles y en el caso de caída, arrastraran al resto por estas dependencias generadas. EDA hace posible esta sincronización de datos, haciendo que los servicion de mantienen los datos lancen eventos con cada actualización y los servicios que consuman esos datos deberán suscribirse a dichos eventos. De esta manera los servicios podrán mantener una replica local o cache de la información necesaria. Esta replica no tiene porque ser exactamente igual, ya que se podrá procesar el evento y guardar solo la información que convenga. Ademas hemos eliminado la dependencia entre ambos servicios, a pesar de que el servicio que contiene la información este caído, el otro podrá seguir ofreciendo respuestas con su información local.

A continuación podemos ver un esquema de la sincronizacion de datos:

Open