As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
atabase-per-service Padrão D
O acoplamento fraco é a principal característica de uma arquitetura de microsserviços, porque cada microsserviço individual pode armazenar e recuperar informações de seu próprio armazenamento de dados de forma independente. Ao implantar o database-per-service padrão, você escolhe os armazenamentos de dados mais adequados (por exemplo, bancos de dados relacionais ou não relacionais) para seus requisitos de aplicativos e negócios. Isso significa que os microsserviços não compartilham uma camada de dados, as alterações no banco de dados individual de um microsserviço não afetam outros microsserviços, os armazenamentos de dados individuais não podem ser acessados diretamente por outros microsserviços e os dados persistentes são acessados somente por APIs. A dissociação dos armazenamentos de dados também melhora a resiliência de seu aplicativo geral e garante que um único banco de dados não seja um único ponto de falha.
Na ilustração a seguir, bancos de dados da AWS diferentes são usados pelos microsserviços “Vendas”, “Cliente” e “Conformidade”. Esses microsserviços são implantados como funções da AWS Lambda e acessados por meio de uma API AWS Identity and Access Management do Amazon API Gateway. As políticas (IAM) garantem que os dados sejam mantidos em sigilo e não compartilhados entre os microsserviços. Cada microsserviço usa um tipo de banco de dados que atende aos seus requisitos individuais; por exemplo, “Vendas” usa o Amazon Aurora, “Cliente” usa o Amazon DynamoDB e “Compliance” usa o Amazon Relational Database Service (Amazon RDS) para SQL Server.
Você deve considerar o uso desse padrão se:
-
Um acoplamento fraco for necessário entre seus microsserviços.
-
Os microsserviços tiverem diferentes requisitos de conformidade ou segurança para seus bancos de dados.
-
Um controle mais granular do escalonamento for necessário.
Existem as seguintes desvantagens em usar o database-per-service padrão:
-
Pode ser difícil implementar transações e consultas complexas que abranjam vários microsserviços ou armazenamentos de dados.
-
Você precisa gerenciar vários bancos de dados relacionais e não relacionais.
-
Seus armazenamentos de dados devem atender a dois dos requisitos do teorema CAP
: consistência, disponibilidade ou tolerância à partição.
nota
Se você usar o database-per-service padrão, deverá implantar o Padrão de composição da API ou o Padrão CQRS para implementar consultas que abranjam vários microsserviços.
