Gerenciamento de dados descentralizado - encapsulando bancos de dados em microsserviços [fechado]

Recentemente, participei de um curso sobre design de software e houve uma discussão / recomendação recente sobre o uso de um modelo de 'microsserviços', em que os componentes de um serviço são separados em subcomponentes de microsserviço, o mais independentes possível.

Uma parte mencionada foi, em vez de seguir o modelo frequentemente visto de ter um único banco de dados com o qual todos os microsserviços conversam, você teria um banco de dados separado em execução para cada um dos microsserviços.

Uma explicação melhor e mais detalhada sobre isso pode ser encontrada aqui: http://martinfowler.com/articles/microservices.html na seção Gerenciamento de dados descentralizados

a parte mais saliente dizendo isso:

Os microsserviços preferem permitir que cada serviço gerencie seu próprio banco de dados, instâncias diferentes da mesma tecnologia de banco de dados ou sistemas de banco de dados totalmente diferentes - uma abordagem chamada Persistência Poliglota. Você pode usar a persistência poliglota em um monólito, mas ela aparece com mais frequência nos microsserviços.

Figura 4

Gosto desse conceito e, entre muitas outras coisas, vejo isso como uma forte melhoria na manutenção e em ter projetos com várias pessoas trabalhando neles. Dito isto, não sou de forma alguma um arquiteto de software experiente. Alguém já tentou implementá-lo? Quais benefícios e obstáculos você enfrentou?

Vamos falar de pontos positivos e negativos da abordagem de microsserviço.

Primeiros negativos. Ao criar microsserviços, você adiciona complexidade inerente ao seu código. Você está adicionando sobrecarga. Você está dificultando a replicação do ambiente (por exemplo, para desenvolvedores). Você está dificultando a depuração de problemas intermitentes.

Deixe-me ilustrar uma desvantagem real. Considere hipoteticamente o caso em que você tem 100 microsserviços chamados ao gerar uma página, cada um dos quais faz a coisa certa 99,9% do tempo. Mas 0,05% do tempo eles produzem resultados errados. E em 0,05% do tempo há uma solicitação de conexão lenta, onde, digamos, é necessário um tempo limite de TCP / IP para conectar-se e isso leva 5 segundos. Cerca de 90,5% das vezes o seu pedido funciona perfeitamente. Mas cerca de 5% das vezes você tem resultados errados e cerca de 5% das vezes sua página é lenta. E toda falha não reproduzível tem uma causa diferente.

A menos que você pense muito em ferramentas para monitorar, reproduzir etc., isso vai se tornar uma bagunça. Particularmente quando um microsserviço chama outro que chama outro com algumas camadas de profundidade. E uma vez que você tenha problemas, isso só piorará com o tempo.

OK, isso parece um pesadelo (e mais de uma empresa criou enormes problemas para si, seguindo esse caminho). O sucesso só é possível: você está claramente ciente da possível desvantagem e trabalha constantemente para resolvê-la.

Então, e a abordagem monolítica?

Acontece que um aplicativo monolítico é tão fácil de modularizar quanto os microsserviços. E uma chamada de função é mais barata e mais confiável na prática do que uma chamada RPC. Portanto, você pode desenvolver a mesma coisa, exceto que é mais confiável, corre mais rápido e envolve menos código.

OK, então por que as empresas adotam a abordagem de microsserviços?

A resposta é que, à medida que você escala, há um limite para o que você pode fazer com um aplicativo monolítico. Depois de tantos usuários, tantas solicitações e assim por diante, você chega a um ponto em que os bancos de dados não são dimensionados, os servidores da Web não conseguem manter seu código na memória e assim por diante. Além disso, as abordagens de microsserviço permitem atualizações independentes e incrementais do seu aplicativo. Portanto, uma arquitetura de microsserviço é uma solução para dimensionar seu aplicativo.

Minha regra pessoal é que ir do código em uma linguagem de script (por exemplo, Python) ao C ++ otimizado geralmente pode melhorar 1-2 ordens de magnitude no desempenho e no uso da memória. Indo para o outro lado de uma arquitetura distribuída adiciona uma magnitude aos requisitos de recursos, mas permite escalar indefinidamente. Você pode fazer uma arquitetura distribuída funcionar, mas é mais difícil.

Portanto, eu diria que se você está iniciando um projeto pessoal, fique monolítico. Aprenda a fazer isso bem. Não seja distribuído porque (Google | eBay | Amazon | etc) são. Se você desembarcar em uma grande empresa que é distribuída, preste muita atenção em como eles fazem o trabalho e não estrague tudo. E se você acabar tendo que fazer a transição, tenha muito, muito cuidado, porque você está fazendo algo difícil que é fácil de ficar muito, muito errado.

Divulgação, tenho quase 20 anos de experiência em empresas de todos os tamanhos. E sim, eu vi arquiteturas monolíticas e distribuídas de perto e pessoalmente. É com base nessa experiência que estou lhe dizendo que uma arquitetura de microsserviço distribuído é realmente algo que você faz porque precisa, e não porque é, de alguma forma, mais limpo e melhor.

Concordo plenamente com a resposta de btilly, mas só queria acrescentar outro ponto positivo para os microsserviços, que acho que é uma inspiração original por trás disso.

No mundo dos microsserviços, os serviços são alinhados aos domínios e são gerenciados por equipes separadas (uma equipe pode gerenciar vários serviços). Isso significa que cada equipe pode liberar serviços inteiramente separadamente e independentemente de quaisquer outros serviços (assumindo o controle de versão correto, etc.).

Embora isso possa parecer um benefício trivial, considere o contrário em um mundo monolítico. Aqui, onde uma parte do aplicativo precisa ser atualizada com frequência, afetará todo o projeto e quaisquer outras equipes que trabalhem nele. Você precisará introduzir agendamento, revisões, etc, etc., e todo o processo fica mais lento.

Quanto à sua escolha, além de considerar seus requisitos de dimensionamento, considere também as estruturas de equipe necessárias. Concordo com a recomendação da btilly de que você inicie o Monolithic e depois identifique mais tarde onde os microsserviços podem se tornar benéficos, mas esteja ciente de que a escalabilidade não é o único benefício.

Eu trabalhei em um local que possuía uma quantidade razoável de fontes de dados independentes. Eles colocaram todos eles em um único banco de dados, mas em esquemas diferentes que foram acessados ​​por serviços da web. A idéia era que cada serviço pudesse acessar apenas a quantidade mínima de dados necessária para executar seu trabalho.

Não havia muita sobrecarga em comparação com um banco de dados monolítico, mas acho que isso se deveu principalmente à natureza dos dados que já estavam em grupos isolados.

Os serviços da web foram chamados a partir do código do servidor da web que gerou uma página; portanto, isso é muito parecido com a arquitetura de microsserviços, embora possivelmente não seja tão micro quanto a palavra sugere e não seja distribuído, embora pudesse ter sido (observe que um WS chamou para obter dados de um serviço de terceiros; portanto, havia 1 instância de um serviço de dados distribuído). A empresa que fez isso estava mais interessada em segurança do que em escala, no entanto, esses serviços e os serviços de dados forneceram uma superfície de ataque mais segura, pois uma falha explorável em uma não daria acesso total a todo o sistema.

Roger Sessions, em seus excelentes boletins da Objectwatch, descreveu algo semelhante ao seu conceito de Software Fortresses (infelizmente os boletins não estão mais online, mas você pode comprar o livro dele).