hared-database-per-service Padrão S - AWS Orientação prescritiva

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á.

hared-database-per-service Padrão S

No shared-database-per-service padrão, o mesmo banco de dados é compartilhado por vários microsserviços. Você precisa avaliar cuidadosamente a arquitetura do aplicativo antes de adotar esse padrão e evitar tabelas dinâmicas (tabelas únicas que são compartilhadas entre vários microsserviços). Todas as alterações no banco de dados também devem ser compatíveis com versões anteriores; por exemplo, os desenvolvedores só podem descartar colunas ou tabelas se os objetos não forem referenciados pelos versionamentos atuais e anteriores de todos os microsserviços.

Na ilustração a seguir, um banco de dados de seguros é compartilhado por todos os microsserviços e uma política do IAM fornece acesso ao banco de dados. Isso cria um acoplamento do tempo de desenvolvimento. Por exemplo, uma mudança no microsserviço “Vendas” precisa coordenar as mudanças de esquema com o microsserviço “Cliente”. Esse padrão não reduz as dependências entre as equipes de desenvolvimento e introduz o acoplamento de runtime porque todos os microsserviços compartilham o mesmo banco de dados. Por exemplo, transações de “Vendas” de longa duração podem bloquear a tabela “Cliente” e isso bloqueia as transações de “Cliente”.

hared-database-per-service Padrão S

Você deve considerar o uso desse padrão se:

  • Você não quiser muita refatoração da sua base de código existente.

  • Você impuser consistência de dados usando transações que fornecem atomicidade, consistência, isolamento e durabilidade (ACID).

  • Você deseja manter e operar somente um banco de dados.

  • Implementar o database-per-service padrão é difícil devido às interdependências entre seus microsserviços existentes.

  • Você não quiser redesenhar completamente sua camada de dados existente.