patterns - shared database microservices
¿Microservicios con base de datos compartida? utilizando múltiples ORM''s? (2)
Estoy aprendiendo sobre microservicios y voy a construir un proyecto con una arquitectura de microservicios.
La cuestión es que uno de mis compañeros de equipo quiere usar una base de datos para todos los servicios, compartiendo todas las tablas para que "los datos no se repitan", cada servicio se construiría con diferentes marcos e idiomas como django y rieles que usan ORM muy diferentes. normas
¿Cuál sería el enfoque correcto? Dado que creo que trabajar con una base de datos implicaría una gran cantidad de "piratería" de los ORM para que funcionen correctamente.
En general, un microservicio debe ser responsable de sus propios datos. Ese es un escenario mundial perfecto.
En la práctica, algunos de los servicios pueden estar altamente relacionados entre sí. Por ejemplo, los servicios CustomerShippingDetails y CustomerShoppingCheckout pueden acceder a la misma información: la dirección del cliente. ¿Cómo resolvería un problema de proporcionar la dirección del cliente al servicio de pago del cliente? Si el servicio de pago consulta los detalles de compra directamente, se rompe el acoplamiento entre los servicios. Otra opción es introducir una base de datos compartida.
Siempre tendrá que haber algún tipo de compromiso en la arquitectura. Lo que se sacrifica es una decisión arquitectónica que depende en gran medida del panorama general (el diseño de todo el sistema).
Al no tener demasiados detalles sobre su sistema, me gustaría ir con un enfoque mixto. Es decir, tener una base de datos compartida para servicios que se ocupan de la lógica de negocios similar. De modo que CustomerShippingDetails y CustomerShoppingCheckout pueden compartir una base de datos. Pero un StoreItemsDetails tendría una base de datos separada.
Puede encontrar más información sobre el patrón de base de datos compartida para microservicios en Microservice Architecture .
No es probable que se beneficie de una arquitectura de microservicios si todos los servicios comparten las mismas tablas de base de datos. Esto se debe a que efectivamente está acoplando estrechamente los servicios. Si una tabla de base de datos cambia, todos los servicios tendrán que cambiar.
Debe comprender que la razón principal de una arquitectura de microservicios es reducir las dependencias entre los equipos de desarrollo y permitirles avanzar de forma independiente con los lanzamientos rápidos.
Aquí hay una cita de Werner Vogels, el CTO de Amazon (Amazon fue pionero en la arquitectura de estilo de los microservicios):
Para nosotros, la orientación al servicio significa encapsular los datos con la lógica empresarial que opera con los datos, con el único acceso a través de una interfaz de servicio publicada. No se permite el acceso directo a la base de datos desde fuera del servicio, y no hay intercambio de datos entre los servicios.