Microservices com o mesmo banco de dados

5

Eu tenho um aplicativo monolítico em um servidor e quero dividi-lo em vários microsserviços.

Por causa disso, no momento, eu tenho que usar o mesmo banco de dados para todos os microservices e cada microsserviço acessando apenas suas próprias tabelas.

Então, minha pergunta é como eu posso reutilizar a conexão com o banco de dados entre os microservices e ainda manter o independente um do outro, porque em algum momento no futuro eu posso querer que alguns deles usem outro banco de dados.

Faço esta pergunta porque acho que é uma sobrecarga fazer uma nova conexão com o banco de dados para cada microsserviço se todos usarem o mesmo banco de dados, porque uma lógica de página única pode usar mais de 10-20 microsserviços.

    
por Alexandru Șerban 28.04.2016 / 09:45
fonte

3 respostas

4

O fato de esses processos diferentes usarem conexões separadas é (principalmente) irrelevante.

A preocupação comum é que abrir e fechar uma conexão é dispendioso em termos de tempo e recursos da CPU. Com muitos bancos de dados, essa preocupação é inválida por causa do pool de conexões: há uma sobrecarga na primeira vez que você se conecta ao banco de dados, mas na próxima vez que precisar fazer uma consulta dentro do mesmo processo, uma conexão existente é reutilizada, mesmo se no código, você explicitamente fechou a conexão.

O que acontecerá no seu caso é que você pagará o custo de abrir vinte conexões na primeira vez em que vinte microservices começarem depois, por exemplo, o servidor será reinicializado. Feito isso, cada serviço reutilizará as conexões já abertas antes.

O que seria um problema é se você tiver muito de microservices acessando o banco de dados, ou se o banco de dados, por um motivo determinado, não puder aceitar muitas conexões. Como você está falando de vinte microsserviços, não me preocuparei; por exemplo, “o SQL Server permite um máximo de 32.767 conexões de usuário.” ( source ) Se você usa um banco de dados mais exótico ou um banco de dados que tem uma configuração exótica ou se cada serviço precisa, por algum motivo, abrir muitas conexões de uma só vez, isso pode se tornar um problema.

    
por 28.04.2016 / 11:21
fonte
1

Os microsserviços são processos separados, por isso não podem compartilhar conexões de banco de dados.

Você divide um aplicativo em microsserviços para escalabilidade, resiliência e desenvolvimento mais fácil com equipes grandes. Para esses benefícios, você precisa pagar um preço no desempenho (por instância) e em uma infraestrutura mais complexa. Provavelmente, o custo de seus microsserviços terem que se comunicar uns com os outros pela rede é maior do que o custo de ter que gerenciar pools separados de conexões de banco de dados.

Se os benefícios esperados não forem maiores que os custos, simplesmente não o faça. Os microsserviços são ótimos para alguns casos de uso, mas não são de forma alguma uma bala de prata e, em certos casos, os benefícios serão superados pelas desvantagens.

    
por 28.04.2016 / 11:10
fonte
0

Na verdade, existem padrões que defendem bancos de dados separados de casos e bancos de dados compartilhados.

Um único banco de dados é mais simples de operar e um desenvolvedor usa transações ACID familiares e diretas para impor a consistência dos dados. Por outro lado, um desenvolvedor trabalhando, por exemplo, no OrderService, precisará coordenar as alterações de esquema com os desenvolvedores de outros serviços que acessam as mesmas tabelas. Esse acoplamento e coordenação adicional retardarão o desenvolvimento.

Mais informações no link

    
por 17.06.2017 / 00:46
fonte