Em 19 de setembro, foi
realizado em Moscou
o primeiro mitog temático HUG (Highload ++ User Group), em Moscou, dedicado a microsserviços. O relatório "Operação de microsserviços: o tamanho é importante mesmo se você tiver o Kubernetes" foi entregue, no qual compartilhamos a vasta experiência da Flant em operar projetos com a arquitetura de microsserviços. Antes de tudo, será útil para todos os desenvolvedores que estão pensando em aplicar essa abordagem em seu projeto atual ou futuro.
Apresentamos o
vídeo com o relatório (50 minutos, muito mais informativo que o artigo), bem como o principal extrato dele em forma de texto.
Nota: Vídeo e apresentação também estão disponíveis no final desta publicação. 1. Introdução
Geralmente, uma boa história tem um enredo, um enredo principal e um desenlace. Este relatório é mais como um enredo e trágico. Também é importante observar que ele fornece uma visão da
operação dos microsserviços.
Vou começar com uma agenda desse tipo, cujo autor (em 2015)
foi Martin Fowler:
Mostra como, no caso de uma aplicação monolítica que atingiu um determinado valor, a produtividade do trabalho começa a diminuir. Os microsserviços diferem no fato de que a produtividade inicial com eles é menor, no entanto, à medida que a complexidade aumenta, a degradação da eficiência para eles não é tão perceptível.
Vou suplementar este gráfico para o caso de usar o Kubernetes:
Por que o aplicativo de microsserviço ficou melhor? Porque essa arquitetura apresenta requisitos sérios de arquitetura, que por sua vez são perfeitamente cobertos pelos recursos do Kubernetes. Por outro lado, parte dessa funcionalidade também será útil para o monólito, principalmente porque o monólito típico hoje não é exatamente um monólito (os detalhes serão detalhados no relatório).
Como você pode ver, o cronograma final (quando aplicativos monolíticos e microsserviços na infraestrutura do Kubernetes) não é muito diferente do original. A seguir, falaremos sobre aplicativos em execução usando o Kubernetes.
Microsserviço útil e prejudicial
E aqui a idéia principal:
O que é uma arquitetura
normal de microsserviço? Deve trazer benefícios reais, aumentando a eficiência do trabalho. Se você voltar ao gráfico, aqui está:
Se você considerar
útil , do outro lado do gráfico haverá um microsserviço
prejudicial (interfere no trabalho):
Voltando à “ideia principal”: vale a pena confiar em minha experiência? Desde o início deste ano, analisei
85 projetos . Nem todos eles eram microsserviços (aproximadamente um terço à metade deles possuía essa arquitetura), mas esse número ainda é grande. Nós (empresas da Flant), como terceirizadores, conseguimos ver uma ampla variedade de aplicativos desenvolvidos tanto em pequenas empresas (com 5 desenvolvedores) quanto em grandes (~ 500 desenvolvedores). Uma vantagem adicional é que vemos como esses aplicativos vivem e se desenvolvem ao longo dos anos.
Por que microsserviços?
Para a pergunta sobre os benefícios dos microsserviços, o já mencionado Martin Fowler tem uma
resposta muito específica :
- limites claros de modularidade;
- implantação independente;
- liberdade de escolha da tecnologia.
Conversei bastante com arquitetos e desenvolvedores de software e perguntei por que eles precisavam de microsserviços. E compilou sua lista de expectativas. Aqui está o que aconteceu:
Se você descrever "em sensações" alguns dos pontos, então:
- limites claros dos módulos: aqui temos um monólito terrível, e agora tudo será organizado de maneira clara nos repositórios Git, nos quais tudo está “nas prateleiras”, não misturado com quente e macio;
- Independência de implantação: poderemos implantar serviços de forma independente, para que o desenvolvimento acelere (publique novos recursos em paralelo);
- independência de desenvolvimento: podemos fornecer esse microsserviço para essa equipe / desenvolvedor e o outro, para que possamos desenvolver mais rapidamente;
- maior confiabilidade: se ocorrer degradação parcial (um microsserviço em 20 quedas), apenas um botão deixará de funcionar e o sistema como um todo continuará funcionando.
Arquitetura típica de microsserviço (prejudicial)
Para explicar por que, na realidade, nem tudo é como esperamos, apresentarei uma imagem
coletiva da arquitetura de microsserviços com base na experiência de muitos projetos diferentes.
Um exemplo seria uma loja online abstrata prestes a competir com a Amazon ou pelo menos a OZON. Sua arquitetura de microsserviço se parece com isso:
Por uma combinação de razões, esses microsserviços são gravados em plataformas diferentes:
Como cada microsserviço deve ter autonomia, muitos deles precisam de seu próprio banco de dados e cache. A arquitetura final é a seguinte:
Quais são as suas consequências?
Fowler
tem um artigo sobre esse assunto - sobre o "retorno" pelo uso de microsserviços:
E veremos se nossas expectativas são atendidas.
Limites claros dos módulos ...
Mas
quantos microsserviços realmente precisamos corrigir para implementar a alteração? Podemos até descobrir como tudo funciona sem um rastreador distribuído (afinal, qualquer solicitação é processada por metade dos microsserviços)?
Existe um padrão de "
grande pedaço de lama ", mas aqui temos um pedaço distribuído de lama. Para apoiar isso, aqui está um exemplo de como as consultas são:
Independência de implantação ...
Tecnicamente, isso foi alcançado: podemos rolar cada microsserviço separadamente. Mas, na prática, é necessário considerar que
muitos microsserviços sempre são
lançados e precisamos levar em consideração a
ordem de sua implantação . De uma maneira boa, geralmente precisamos testar em um circuito separado se estamos lançando a liberação na ordem correta.
Liberdade de escolha da tecnologia ...
Ela está lá. Vale lembrar que muitas vezes a liberdade limita-se à ilegalidade. É muito importante aqui não escolher tecnologias apenas para "brincar" com elas.
Independência de Desenvolvimento ...
Como fazer um circuito de teste para toda a aplicação (de tantos componentes)? Mas você ainda precisa mantê-lo atualizado. Tudo isso leva ao fato de que o
número real de loops de teste , que nós, em princípio, podemos conter,
é mínimo .
Mas para implantar tudo isso localmente? ... Acontece que muitas vezes o desenvolvedor faz seu trabalho de forma independente, mas aleatoriamente, porque ele precisa esperar até que o circuito para teste seja liberado.
Escala separada ...
Sim, mas é limitado na área do DBMS usado. No exemplo da arquitetura, Cassandra não terá problemas, mas o MySQL e PostgreSQL terão.
Mais confiabilidade ...
Não apenas isso, de fato, que a falha de um microsserviço geralmente interrompe o funcionamento correto de todo o sistema, também há um novo problema:
é muito difícil tornar cada microsserviço tolerante a falhas . Como os microsserviços usam tecnologias diferentes (memcache, Redis etc.), todos precisam pensar e implementar tudo, o que, é claro, é possível, mas requer enormes recursos.
Mensurabilidade da carga ...
Tudo é realmente bom com isso.
Leveza dos microsserviços ...
Não apenas tivemos grandes
sobrecargas de rede (consultas DNS, etc.), mas também por causa de muitas subconsultas, começamos a
replicar os dados (caches de armazenamento), o que levou a uma quantidade significativa de armazenamento.
E aqui está o resultado de atender às nossas expectativas:
Mas isso não é tudo!
Porque:
- Provavelmente precisamos de um barramento de mensagens.
- Como fazer um backup consistente no momento certo? A única opção real é desativar o tráfego para isso. Mas como fazer isso na produção?
- Se estamos falando em apoiar várias regiões, organizar a sustentabilidade em cada uma delas é uma tarefa muito demorada.
- Há um problema de fazer alterações centralizadas. Por exemplo, se precisamos atualizar a versão do PHP, precisamos nos comprometer com cada repositório (e existem dezenas deles).
- O aumento imediato da complexidade operacional é exponencial.
O que fazer com tudo isso?
Comece com um aplicativo monolítico . A experiência de Fowler
sugere que quase todos os aplicativos de microsserviços bem-sucedidos começaram com um monólito, que se tornou muito grande, após o qual foi quebrado. Ao mesmo tempo, quase todos os sistemas criados como microsserviços desde o início experimentaram sérios problemas mais cedo ou mais tarde.
Outro pensamento valioso é que, para que um projeto com arquitetura de microsserviço seja bem-sucedido, você deve conhecer muito bem
a área de assunto e como fazer microsserviços . E a melhor maneira de conhecer a área de assunto é criar um monólito.
Mas e se já estamos nessa situação?
O primeiro passo para resolver qualquer problema é concordar com ele e entender que é um problema que não queremos mais sofrer.
Se no caso de um monólito coberto de vegetação (quando não temos mais oportunidades de comprar recursos para ele), o cortamos, então nesse caso obtemos a história oposta: quando o microsserviço excessivo não ajuda mais, mas interfere -
diminua o excesso e aumente !
Por exemplo, para a imagem coletiva discutida acima ...
Livre-se dos microsserviços mais duvidosos:
Combine todos os microsserviços responsáveis por gerar o frontend:
... em um microsserviço, escrito em uma linguagem / estrutura (moderna e normal, como você pensa):
Ele terá um ORM (um DBMS) e primeiro alguns aplicativos:
... em geral, muito mais pode ser transferido para lá, tendo obtido o seguinte resultado:
Além disso, no Kubernetes, executamos tudo isso em instâncias separadas, o que significa que ainda podemos medir a carga e dimensioná-la separadamente.
Resumindo
Olhe para a foto mais ampla. Muitas vezes, todos esses problemas com microsserviços surgem devido ao fato de alguém ter realizado sua tarefa, mas que queria "executar microsserviços".
Na palavra "microsserviços", a parte "micro" é supérflua . Eles são "micro" apenas pelo fato de serem menores que um monólito enorme. Mas não pense neles como algo pequeno.
E para o pensamento final, de volta à programação original:
A nota escrita para ele
(canto superior direito) se resume ao fato de que as
habilidades da equipe que cria seu projeto são sempre primárias - elas desempenharão um papel fundamental na sua escolha entre microsserviços e um monólito. Se a equipe não tiver habilidades suficientes, mas começar a fazer microsserviços, a história será definitivamente fatal.
Vídeos e slides
Vídeo do discurso (~ 50 minutos; infelizmente, ele não transmite as inúmeras emoções dos visitantes, que determinaram amplamente o humor do relatório, mas como ele é):
Apresentação do relatório:
PS
Outros relatórios em nosso blog:
Você também pode estar interessado nas seguintes publicações: