Patrones de diseño para bases de datos / Habr

Existen varios patrones de diseño de servicios en la nube. Creo que muchos han oído hablar del mismo Sidecar o Ambassador. Las plantillas están diseñadas para resolver problemas específicos y las dos plantillas que se analizarán en el artículo de hoy también son necesarias para una tarea específica: trabajar con bases de datos.

Un DBMS es una parte integral de cualquier aplicación moderna seria. En consecuencia, al diseñar una aplicación, puede surgir la pregunta de cuál es la mejor manera de que los servicios interactúen con la base de datos: proporcionando acceso compartido a una base de datos, o cada microservicio debería tener su propia base de datos. Veremos dos plantillas diseñadas para resolver este problema: base de datos compartida y base de datos por microservicio. Comencemos con la base de datos compartida.

bases generales

En primer lugar, cuando hablemos de esta plantilla y de la siguiente, nos referiremos a que utilizamos una arquitectura de microservicio, es decir, nuestra aplicación que estamos desarrollando consta de muchos servicios separados que interactúan entre sí. Al mismo tiempo, todavía necesitamos guardar los datos para su posterior procesamiento. Entonces, si estamos desarrollando una tienda en línea, obviamente necesitamos guardar información sobre pedidos, clientes, disponibilidad de productos en stock, etc.

Es posible que tengamos diferentes requisitos para las bases de datos utilizadas y el almacenamiento de datos. Entonces, a menudo, en algunos casos la mejor opción es una base de datos relacional, en otros casos, NoSQL es más adecuado, por ejemplo, para almacenar datos complejos no estructurados.

Al mismo tiempo, la lógica de las solicitudes en sí puede ser diferente. A veces, las consultas necesitan combinar datos que pertenecen a varios servicios. Por ejemplo, encontrar clientes en una región específica y sus últimos pedidos requiere combinar clientes y pedidos.

Pero en una arquitectura de microservicios, la ideología es que los servicios deben estar ligeramente acoplados para que puedan desarrollarse, implementarse y escalarse independientemente unos de otros.

Por otro lado, como mencionamos anteriormente, algunas transacciones deben utilizar datos de múltiples servicios. Por lo tanto, al realizar un pedido, debemos asegurarnos de que el nuevo pedido no exceda el límite de crédito del cliente. Otras transacciones comerciales deben actualizar los datos pertenecientes a múltiples servicios.

Como solución a los problemas enumerados anteriormente, puede utilizar una base de datos compartida para varios servicios con una estructura de datos común. Con este enfoque, cada servicio tendrá libre acceso a los datos pertenecientes a otros servicios mediante transacciones locales según la regla ACID (atomicidad, consistencia, aislamiento, durabilidad).

Veamos cómo se puede implementar en la práctica el patrón de base de datos compartida. Los servicios TicketService y UserService tienen acceso a las tablas de cada uno. Por ejemplo, TicketService puede utilizar la siguiente transacción ACID para garantizar que un nuevo pedido no viole el límite de crédito del cliente:

BEGIN TRANSACTION

…

SELECT TICKET_TOTAL

 FROM TICKETS WHERE USER_ID = ?

…

SELECT CREDIT_LIMIT

FROM USERS WHERE USER_ID = ?

…

INSERT INTO TICKETS …

…

COMMIT TRANSACTION

Como todos los demás patrones, también existen ventajas y desventajas y, en consecuencia, situaciones en las que es preferible utilizarlos.

Los beneficios de utilizar el patrón de base de datos compartida son que el desarrollador utiliza transacciones simples y familiares para garantizar la coherencia de los datos. Además, es más fácil trabajar con una única base de datos y es más fácil realizar un seguimiento de los cambios en los datos.

Pero esta plantilla también tiene una serie de desventajas que limitan su uso. Por tanto, el desarrollador del servicio TicketService debe coordinar los cambios de esquema con los desarrolladores de otros servicios que acceden a las mismas tablas.

Además, dado que todos los servicios acceden a la misma base de datos, pueden interferir entre sí. Por ejemplo, si una transacción UserService de larga duración mantiene un bloqueo en la tabla TICKET, TicketService se bloqueará.

Por último, es posible que una base de datos no cumpla con los requisitos de almacenamiento de datos y acceso a todos los servicios.

Una alternativa al patrón de base de datos compartida es la base de datos por servicio.

Cada servicio según la base de datos

Esta plantilla propone abandonar el uso de una base de datos común y en su lugar crear cada servicio su propia base de datos, con la que nadie más trabaja. De esta manera podemos proporcionar un acoplamiento flexible entre servicios.

La idea principal del patrón Base de datos por servicio es que los microservicios no tienen acceso a la base de datos de los servicios vecinos y se comunican entre sí a través de REST o mediante un intermediario de mensajes. De esta manera, nuestros microservicios se vuelven verdaderamente independientes del almacenamiento y pueden desarrollarse en paralelo.

Las principales ventajas de este patrón son el débil acoplamiento de servicios. Los cambios en la base de datos utilizada por un servicio no afectan a otros servicios como es el caso del patrón de base de datos compartida.

De esta manera, nuestros servicios pueden utilizar aquellos DBMS que mejor se adapten a ellos. Por ejemplo, un servicio puede utilizar la búsqueda elástica, un segundo NoSQL, un tercer SQL, si la lógica empresarial lo requiere.

Este patrón hereda sus principales desventajas de la ideología de la propia arquitectura de microservicios. Por tanto, la realización de transacciones comerciales que abarquen varios servicios es una tarea difícil que requiere un estudio por separado. Y realizar cambios en la lógica de consulta también requiere trabajo.

También tenemos dificultades para administrar múltiples bases de datos en nuestra aplicación. Por ejemplo, si se utilizan PostgreSQL, NoSQL y Elastic, necesitaremos especialistas familiarizados con todas estas bases de datos.

Conclusión

En este artículo, analizamos dos patrones relacionados con el funcionamiento de microservicios y bases de datos. Cada uno de ellos tiene sus propias ventajas y desventajas y es más aplicable para resolver una determinada gama de problemas.