Microservicios. Gestión de datos entre servicios

¿Qué es un Microservicio?

Con una arquitectura monolítica, esta es una forma de construir servidores en un servidor monolítico.

monoliticServer

Todo el código necesario para implementar nuestra aplicación dentro de una única base de código y desplegamos esa base de código como una unidad discreta.

Una arquitectura monolítica contiene

1
Routing
2
Middlewares
3
Business Logic
4
Database access

para implementar todas las unidades funcionales de nuestra aplicación

Arquitectura de microservicios.

microservices

Con esta arquitectura de microservicios, ahora separamos todas estas unidades funcionales diferentes y las envolvemos dentro de sus propios servicios personalizados.

Un microservicio contiene

1
Routing
2
Middlewares
3
Business Logic
4
Database access

para implementar una unidad funcional de nuestra aplicación

Gestión de datos entre servicios

Este es el gran problema de los microservicios. Cuando decimos gestión de datos, nos referimos a la forma en que almacenamos datos dentro de un servicio y cómo comunicamos esos datos entre diferentes servicios.

database

Siempre que hagamos uso de microservicios, crearemos una base de datos independiente para cada servicio.

neverOtherDatabase

Por qué una base de datos por servicio

Queremos que cada servicio funcione independientemente de otros servicios
El esquema/estructura de la base de datos puede cambiar inesperadamente
Algunos servicios pueden funcionar de manera más eficiente con diferentes tipos de bases de datos (sql vs nosql)

databasemonolitic

Si queremos mostrar información sobre esos productos probablemente tengamos que hacer una consulta a la colección de productos. En una arquitectura monolítica al funcionalidad que muestra los productos ordenados por un usuario en particular accederá a las tres fuentes de información.

DATABASE MS

¿Cómo podríamos obtener de alguna manera la información requerida para implementar la funcionalidad del Servicio D sin acceder a estas bases de datos?

No permitiremos que estos servicios interactúen con las bases de datos de los otros servicios. Es por eso que la gestión de datos entre servicios puede ser realmente desafiante.

betweenServices

Sync
Service communicate with each other using direct request
Async
Service communicate with each other using events

Comunicación Síncrona en Microservicios

Conceptualmente fácil de entender
El servicio D no necesitará una base de datos
Crea dependencias entre los servicios.
Si alguna petición entre servicios falla, la petición general falla
La petición total es tan rápida como la petición anidada más lenta
Puede introducir fácilmente peticiones de web

En la comunicación sincrona hay algunas ventajas, pero también hay muchas desventajas operativas de gran tamaño.

Comunicación Asíncrona de Microservicios

Primera vía

EventBus1 EventBus4

Conceptually not easy to understand
Service D won’t need a database
Introduces a dependency between services
If any inter-service request fails, the overall request fails
The entire request is only as fast as the slowest request
Can easy introduce webs of requests

Segunda vía (una forma alocada de almacenar datos en Microservicios)

service

database

Crear un producto

Crear un usuario

Pedir un producto

El servicio D no tiene dependencias de otros servicios.
El servicio D será extremadamente rápido.
Duplicación de datos.
Difícil de entender

Próximamente crearé una publicación donde veremos como crear microservicios con NodeJS y React. Seguiremos esta segunda vía para crear los microservicios y almacenar la información. Este es un tema que no hemos visto en Google Cloud Microservices.

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!