Se uma arquitetura de microsserviço precisa de um banco de dados separado por microsserviço, é muito caro e incontrolável. Por que precisamos disso?

Eu li sobre microsserviços e me parece ilógico criar um banco de dados separado por serviço apenas para obter isolamento. Eu posso conseguir o mesmo usando apenas serviços da web e um único banco de dados. Por que precisamos disso? O que separa o banco de dados está fora de discussão. Ou eu estou completamente errado? Você pode me guiar nisso?

Por que precisamos disso?

Você não

Criar um banco de dados separado para cada serviço ajuda a reforçar os limites do domínio, mas é apenas uma abordagem. Não há nada impedindo que todos os seus serviços compartilhem o mesmo banco de dados.

Desde que seus serviços se comportem e não façam coisas inesperadas com os dados pertencentes a outros serviços, você estará bem.

Não sei o que você lê, mas você deve estar ciente de que existem muitas opiniões diferentes sobre a arquitetura de microsserviços. Aqui está uma boa postagem no blog sobre o assunto.

Eu já vi pessoas se referirem a essa ideia em parte, trivialmente, como "cada microsserviço deve possuir e controlar seu próprio banco de dados e dois serviços não devem compartilhar um banco de dados". A ideia é boa: não compartilhe um único banco de dados entre os serviços, pois você enfrenta conflitos como padrões concorrentes de leitura / gravação, conflitos de modelo de dados, desafios de coordenação etc.

Mas um único banco de dados nos oferece muitas garantias e conveniências: transações ACID, local único para procurar, bem entendido (tipo?), Um local para gerenciar etc.

A jornada para microsserviços é exatamente isso: uma jornada . Será diferente para cada empresa. Não há regras rígidas e rápidas, apenas trocas.

A parte mais difícil dos microsserviços: seus dados

Como Dan Wilson responde, você realmente não precisa disso. Os microsserviços são a novidade e, como todas as novidades, as pessoas as usam em muitos lugares, mesmo quando não oferecem muito valor.

Os microsserviços permitem implantar e dimensionar independentemente as coisas em um nível "micro". Essa granularidade oferece vários benefícios técnicos e ainda mais benefícios não técnicos, pois permite separar melhor as equipes de desenvolvimento, liberar conforme necessário, em vez de um grande release, experimentar novas tecnologias ou processos isoladamente, etc. Ter um banco de dados compartilhado mata muito disso por causa da dependência do banco de dados. Se você não pode implantar seu serviço sem se preocupar com os dados de outros serviços, você perdeu.

O que separa o banco de dados está fora de discussão. Ou eu estou completamente errado?

Dito isto, você também está completamente errado.

Quando você trabalha na nuvem, os bancos de dados são baratos. Geralmente livre! Claro, o servidor custa dinheiro, mas não estamos falando de um servidor individual por microsserviço (pelo menos, não a princípio). Um único servidor com vários bancos de dados (lógicos) é bom, desde que você seja diligente em evitar consultas entre bancos de dados (que introduzem dependências que prejudicam "independentemente implementável e escalável"). Inferno, consultas entre bancos de dados são impossíveis em alguns serviços de banco de dados em nuvem, como o SQL do Azure. Você nem precisa ser diligente lá ...

E até vi microsserviços em que eles compartilhavam um banco de dados, mas cada serviço tinha seu próprio esquema. Novamente, você precisa ser diligente para evitar consultas que ultrapassem os limites de dados.

Muitos lugares não são tão diligentes. Eles têm desenvolvedores de nível de entrada, ou pessoas que não valorizam a abordagem de microsserviços, ou têm maus líderes de equipe ou têm pressão na linha do tempo que faz com que as pessoas tomem atalhos.

Ter um banco de dados separado é a maneira mais limpa de aplicar essa dissociação que permite a independência do serviço, mas não é a única. E não é que caro - especialmente quando você compará-lo com a hora / salário gasto tentando impor limites de dados em um banco de dados compartilhado.

Por que precisamos disso?

O enorme benefício dos microsserviços - e, mais amplamente, da SOA - é o alto nível de abstração dos internos - não apenas a implementação, mas também as tecnologias que estão sendo usadas. Por exemplo, se um sistema é desenvolvido na forma de cinco microsserviços por cinco equipes, uma equipe pode decidir mudar para uma pilha tecnológica completamente diferente (por exemplo, da pilha da Microsoft para a LAMP) sem sequer pedir a opinião de outras equipes.

Veja Amazon AWS ou Twilio. Você sabe se os serviços deles são implementados em Java ou Ruby? Eles usam Oracle ou PostgreSQL ou Cassandra ou MongoDB? Quantas máquinas eles usam? Você se importa com isso? em outras palavras, essas opções tecnológicas afetam a maneira como você usa esses serviços? ... E o mais importante, se eles forem para um banco de dados diferente, você teria que alterar seu aplicativo cliente de acordo?

Agora, o que acontece se dois serviços usam o mesmo banco de dados? Aqui está uma pequena parte dos problemas que podem surgir:

• A equipe que desenvolve o serviço 1 deseja passar do SQL Server 2012 para o SQL Server 2016. No entanto, a equipe 2 conta com um recurso descontinuado que foi removido no SQL Server 2016.

• O Serviço 1 é um enorme sucesso. Hospedar o banco de dados em duas máquinas (mestre e failover) não é mais uma opção. Mas dimensionar o cluster para várias máquinas requer estratégias como sharding. Enquanto isso, a equipe 2 está feliz com a escala atual e não vê razão para mudar para outra coisa.

• O serviço 1 deve passar para UTF-8 como codificação padrão. O Serviço 2, no entanto, está satisfeito com o uso do Code Page 1252 Windows Latin 1.

• O serviço 1 decide adicionar um usuário com um nome específico. No entanto, esse usuário já existe, criado há alguns meses pela segunda equipe.

• O Serviço 1 precisa de muitos recursos diferentes. O Serviço 2 é um componente altamente crítico e precisa manter os recursos do banco de dados no mínimo para reduzir o risco de ataques.

• O serviço 1 requer 15 TB de espaço em disco; a velocidade não é importante; portanto, os discos rígidos comuns estão perfeitamente bem. O Serviço 2 requer no máximo 50 GB, mas precisa acessá-lo o mais rápido possível, o que significa que os dados devem ser armazenados em um SSD.

• ...

Toda pequena escolha afeta a todos. Toda decisão precisa ser tomada de forma colaborativa, por pessoas de todas as equipes. É necessário fazer acordos. Compare isso com uma total liberdade para fazer o que quiser em um contexto de SOA.

é muito [...] incontrolável.

Então você está fazendo errado. Suponho que você esteja implantando manualmente .

Não é assim que as coisas devem ser feitas. Você precisa automatizar a implantação de máquinas virtuais (ou contêineres do Docker) que executam o banco de dados. Depois de automatizados, a implantação de dois servidores ou vinte servidores ou dois mil servidores não é muito diferente.

A coisa mágica sobre bancos de dados isolados é que é extremamente gerenciável . Você já tentou gerenciar um enorme banco de dados usado por dezenas de equipes? É um pesadelo. Cada equipe tem solicitações específicas e, assim que você toca em algo, isso afeta alguém. Com um banco de dados associado a um aplicativo, o escopo se torna muito restrito, o que significa que há muito menos coisas em que pensar.

Se um banco de dados enorme requer administradores de sistema especializados, os bancos de dados usados ​​por apenas uma equipe podem ser gerenciados por essa equipe (o DevOps também trata disso), liberando o tempo dos administradores de sistema.

é muito caro

Definir custo.

Os custos de licenciamento dependem do banco de dados. Na era da computação em nuvem, tenho certeza de que todos os principais players redesenharam seu licenciamento para acomodar o contexto em que, em vez de um grande banco de dados, existem muitos pequenos. Caso contrário, considere mudar para um banco de dados diferente. A propósito, existem muitos de código aberto.

Se você está falando sobre o poder de processamento, tanto as máquinas virtuais quanto os contêineres são compatíveis com a CPU, e eu não diria que um banco de dados enorme consome menos CPU do que muitos pequenos fazendo o mesmo trabalho.

Se o seu problema for a memória, as máquinas virtuais não são uma boa opção para você. Recipientes são. Você poderá estender quantos quiser, sabendo que eles não consumirão mais RAM do que o necessário. Embora o consumo total de memória seja maior para muitos bancos de dados pequenos em comparação com um único grande, suponho que a diferença não seja muito importante. YMMV.

Dependendo do que você considera "caro".

Um banco de dados não precisa necessariamente ser um servidor de banco de dados comercial caro (acho que a Oracle) não precisa necessariamente ser um caso de fome de recursos. Dependendo de quais são seus requisitos, você pode usar o banco de dados SQLite ou mesmo o sistema de arquivos como um armazenamento de dados persistente.

Todos esses serviços também podem compartilhar uma única instância / servidor de banco de dados e ter apenas esquemas isolados por serviço.

O argumento principal aqui é que o serviço precisa possuir e controlar seus dados. Como isso é alcançado, é uma questão de escolha e detalhes técnicos.

A melhor maneira de um serviço possuir e controlar seus dados é ter seu próprio banco de dados "pessoal". Isso permite total liberdade de escolha da evolução da tecnologia e do esquema de dados. A única maneira de qualquer outro serviço acessar dados pertencentes a um serviço é solicitando os dados de um serviço. Dessa forma, se a representação interna de dados precisar ser alterada, ela poderá ser alterada facilmente e nenhum outro serviço será interrompido.

Então, para recapitular. Não é necessariamente caro ter um banco de dados por serviço nem é necessário. É simplesmente uma decisão que você precisa tomar em algum momento ao desenvolver microsserviços. Cada uma das opções tem suas implicações e limitações. Estude-os e faça sua própria escolha.