Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
atabase-per-service Patrón D
El acoplamiento flexible es la característica principal de una arquitectura de microservicios, ya que cada microservicio individual puede almacenar y recuperar información de su propio almacén de datos de forma independiente. Al implementar el database-per-service patrón, usted elige los almacenes de datos más adecuados (por ejemplo, bases de datos relacionales o no relacionales) para sus requisitos empresariales y de aplicación. Esto significa que los microservicios no comparten una capa de datos, los cambios en la base de datos individual de un microservicio no afectan a otros microservicios, otros microservicios no pueden acceder directamente a los almacenes de datos individuales y solo las API acceden a los datos persistentes. La disociación de los almacenes de datos también mejora la resiliencia de la aplicación en general y garantiza que una única base de datos no pueda ser el único punto de fallo.
En la siguiente ilustración, los microservicios de “Ventas”, “Clientes” y “Cumplimiento” utilizan diferentes AWS bases de datos. Estos microservicios se implementan como AWS Lambda funciones y se accede a ellos a través de una API de Amazon API Gateway. AWS Identity and Access Management Las políticas (IAM) garantizan que los datos se mantengan privados y no se compartan entre los microservicios. Cada microservicio usa un tipo de base de datos que cumple con sus requisitos individuales; por ejemplo, “Ventas” usa Amazon Aurora, “Clientes” usa Amazon DynamoDB y “Cumplimiento” usa Amazon Relational Database Service (Amazon RDS) para SQL Server.
Debería considerar la posibilidad de utilizar este patrón si:
-
Se requiere un acoplamiento flexible entre sus microservicios.
-
Los microservicios tienen diferentes requisitos de cumplimiento o seguridad para sus bases de datos.
-
Se requiere un control más detallado del escalado.
El uso del database-per-service patrón presenta las siguientes desventajas:
-
Puede resultar difícil implementar transacciones y consultas complejas que abarquen varios microservicios o almacenes de datos.
-
Debe administrar varias bases de datos relacionales y no relacionales.
-
Sus almacenes de datos deben cumplir dos de los requisitos del teorema CAP
: consistencia, disponibilidad o tolerancia a las particiones.
nota
Si usa el database-per-service patrón, debe implementar Patrón de composición de API o implementar consultas que abarquen varios microservicios. Patrón CQRS
