19 de setembro em Moscou o primeiro encontro temático HUG (Highload++ User Group), dedicado a microsserviços. Houve a apresentação “Operação de microsserviços: o tamanho é importante, mesmo se você tiver Kubernetes”, na qual compartilhamos a vasta experiência da Flant na operação de projetos com arquitetura de microsserviços. Em primeiro lugar, será útil para todos os desenvolvedores que estão pensando em usar esta abordagem em seus projetos atuais ou futuros.
Apresentando (50 minutos, muito mais informativo que o artigo), bem como o trecho principal dele em forma de texto.
NB: Vídeo e apresentação também estão disponíveis no final deste post.
Introdução
Normalmente uma boa história tem começo, enredo principal e resolução. Este relatório assemelha-se mais a um prelúdio, e ainda por cima trágico. Também é importante observar que ele fornece uma visão externa dos microsserviços. operacional.
Começarei por este gráfico, cujo autor (em 2015) Martin Fowler:
Mostra como, no caso de uma aplicação monolítica que atinge determinado valor, a produtividade começa a declinar. Os microsserviços são diferentes porque a produtividade inicial com eles é menor, mas à medida que a complexidade aumenta, a degradação da eficiência não é tão perceptível para eles.
Acrescentarei a este gráfico para o caso de uso do Kubernetes:
Por que um aplicativo com microsserviços é melhor? Porque tal arquitetura apresenta requisitos sérios para a arquitetura, que por sua vez são perfeitamente atendidos pelos recursos do Kubernetes. Por outro lado, algumas dessas funcionalidades serão úteis para um monólito, especialmente porque o monólito típico de hoje não é exatamente um monólito (os detalhes estarão mais adiante no relatório).
Como você pode ver, o gráfico final (quando aplicativos monolíticos e de microsserviços estão na infraestrutura com Kubernetes) não é muito diferente do original. A seguir falaremos sobre aplicativos operados com Kubernetes.
Microsserviços úteis e prejudiciais
E aqui está a ideia principal:
O que é uma normal arquitetura de microsserviços? Deve trazer benefícios reais, aumentando a eficiência do seu trabalho. Se voltarmos ao gráfico, aqui está:
Se você ligar para ela útil, então do outro lado do gráfico haverá prejudicial microsserviços (interfere no trabalho):
Voltando à “ideia principal”: devo confiar na minha experiência? Desde o início deste ano tenho procurado 85 projetos. Nem todos eram microsserviços (cerca de um terço a metade deles tinham essa arquitetura), mas ainda é um número grande. Nós (empresa Flant), como terceirizados, conseguimos ver uma grande variedade de aplicações desenvolvidas tanto em pequenas empresas (com 5 desenvolvedores) quanto em grandes (~500 desenvolvedores). Um benefício adicional é que vemos esses aplicativos funcionando e evoluindo ao longo dos anos.
Por que microsserviços?
Para a questão sobre os benefícios dos microsserviços existe do já mencionado Martin Fowler:
- limites claros de modularidade;
- implantação independente;
- liberdade de escolha de tecnologias.
Conversei muito com arquitetos e desenvolvedores de software e perguntei por que eles precisam de microsserviços. E fiz minha lista de expectativas deles. Aqui está o que aconteceu:
Se descrevermos alguns dos pontos “nas sensações”, então:
- limites claros dos módulos: aqui temos um monólito terrível, e agora tudo estará bem organizado nos repositórios Git, nos quais tudo está “nas prateleiras”, o quente e o suave não se misturam;
- independência de implantação: seremos capazes de implementar serviços de forma independente para que o desenvolvimento seja mais rápido (publicar novos recursos em paralelo);
- independência de desenvolvimento: podemos dar este microsserviço a uma equipe/desenvolvedor, e aquele a outro, graças ao qual podemos desenvolver mais rapidamente;
- боmaior confiabilidade: se ocorrer degradação parcial (um microsserviço em cada 20 quedas), apenas um botão deixará de funcionar e o sistema como um todo continuará funcionando.
Arquitetura de microsserviço típica (prejudicial)
Para explicar por que a realidade não é o que esperamos, apresentarei coletivo uma imagem de uma arquitetura de microsserviços baseada na experiência de muitos projetos diferentes.
Um exemplo seria uma loja online abstrata que vai competir com a Amazon ou pelo menos com a OZON. Sua arquitetura de microsserviço é assim:
Por uma série de razões, esses microsserviços são escritos em plataformas diferentes:
Como cada microsserviço deve ter autonomia, muitos deles precisam de banco de dados e cache próprios. A arquitetura final é a seguinte:
Quais são as suas consequências?
Fowler também tem isso — sobre o “pagamento” pelo uso de microsserviços:
E veremos se nossas expectativas foram atendidas.
Limites claros dos módulos...
Mas quantos microsserviços realmente precisamos consertar?implementar a mudança? Será que conseguimos descobrir como tudo funciona sem um rastreador distribuído (afinal, qualquer solicitação é processada por metade dos microsserviços)?
Existe um padrão "“, e aqui acabou sendo um pedaço de sujeira distribuído. Para confirmar isso, aqui está uma ilustração aproximada de como são as solicitações:
Independência de implantação...
Tecnicamente, isso foi alcançado: podemos implementar cada microsserviço separadamente. Mas na prática é preciso levar em conta que sempre rola muitos microsserviços, e precisamos levar em conta a ordem de sua implementação. No bom sentido, geralmente precisamos testar em um circuito separado se estamos lançando o lançamento na ordem correta.
Liberdade para escolher tecnologia...
Ela é. Basta lembrar que a liberdade muitas vezes beira a ilegalidade. É muito importante aqui não escolher tecnologias apenas para “brincar” com elas.
Independência do desenvolvimento...
Como fazer um loop de teste para toda a aplicação (com tantos componentes)? Mas você ainda precisa mantê-lo atualizado. Tudo isso leva ao fato de que número real de circuitos de teste, que podemos em princípio conter, acaba sendo mínimo.
Que tal implantar tudo isso localmente?. Acontece que muitas vezes o desenvolvedor faz seu trabalho de forma independente, mas “ao acaso”, pois é obrigado a esperar até que o circuito esteja livre para testes.
Dimensionamento separado...
Sim, mas é limitado na área do SGBD utilizado. No exemplo de arquitetura dado, Cassandra não terá problemas, mas MySQL e PostgreSQL terão.
Боmaior confiabilidade...
Na realidade, não apenas a falha de um microsserviço muitas vezes prejudica o funcionamento correto de todo o sistema, mas também há um novo problema: tornar cada microsserviço tolerante a falhas é muito difícil. Como os microsserviços utilizam tecnologias diferentes (memcache, Redis, etc.), para cada uma é preciso pensar em tudo e implementar, o que, claro, é possível, mas requer enormes recursos.
Mensurabilidade de carga...
Isto é muito bom.
A "leveza" dos microsserviços...
Não só temos enormes sobrecarga de rede (as solicitações de DNS estão se multiplicando, etc.), mas também devido às muitas subconsultas que iniciamos replicar dados (armazenar caches), 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:
- Muito provavelmente precisaremos de um barramento de mensagens.
- Como fazer um backup consistente no momento certo? O único real opção é desligar o tráfego para isso. Mas como fazer isso na produção?
- Se falamos em apoiar várias regiões, então organizar a sustentabilidade em cada uma delas é uma tarefa que exige muita mão-de-obra.
- Surge o problema de fazer mudanças centralizadas. Por exemplo, se precisarmos atualizar a versão do PHP, precisaremos nos comprometer com cada repositório (e existem dezenas deles).
- O crescimento da complexidade operacional é, de imediato, exponencial.
O que fazer com tudo isso?
Comece com um aplicativo monolítico. A experiência de Fowler que quase todos os aplicativos de microsserviços bem-sucedidos começaram como um monólito que se tornou muito grande e depois quebrou. Ao mesmo tempo, quase todos os sistemas construídos como microsserviços desde o início, mais cedo ou mais tarde, enfrentaram sérios problemas.
Outro pensamento valioso é que para um projeto com arquitetura de microsserviços ter sucesso é preciso conhecer muito bem e área de assunto, e como fazer microsserviços. E a melhor maneira de aprender uma área temática é fazer um monólito.
Mas e se já estivermos nesta 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 crescido demais (quando esgotamos a oportunidade de adquirir recursos adicionais para ele), nós o cortamos, então neste caso acontece a história oposta: quando microsserviços excessivos não ajudam mais, mas atrapalham - corte o excesso e amplie!
Por exemplo, para a imagem coletiva discutida acima...
Livre-se dos microsserviços mais questionáveis:
Combine todos os microsserviços responsáveis pela geração de frontend:
... em um microsserviço, escrito em uma linguagem/estrutura (moderna e normal, como você pensa):
Terá um ORM (um DBMS) e primeiro alguns aplicativos:
... mas em geral você pode transferir muito mais para lá, obtendo 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 escalá-las separadamente.
resumindo
Olhe para o quadro geral. Muitas vezes, todos esses problemas com microsserviços surgem porque alguém assumiu a tarefa, mas quis “brincar com microsserviços”.
Na palavra “microsserviços” a parte “micro” é redundante.. Eles são “micro” apenas porque são menores que um enorme monólito. Mas não pense neles como algo pequeno.
E para uma reflexão final, voltemos ao gráfico original:
Uma nota escrita nele (canto superior direito) resume-se ao fato de que as competências da equipe que faz o seu projeto são sempre primordiais — eles 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 com certeza será fatal.
Vídeos e slides
Vídeo do discurso (~50 minutos; infelizmente não transmite as inúmeras emoções dos visitantes, que determinaram em grande parte o clima da reportagem, mas é assim):
Apresentação do relatório:
PS
Outras reportagens em nosso blog:
- «» (Dmitry Stolyarov; 28 de maio de 2018 na RootConf);
- «» (Dmitry Stolyarov; 7 de novembro de 2017 no HighLoad++);
- «» (Dmitry Stolyarov; 6 de junho de 2017 na RootConf);
- «» (Dmitry Stolyarov; 8 de novembro de 2016 no HighLoad++);
- «» (Dmitry Stolyarov; 31 de maio de 2016 na RootConf).
Você também pode estar interessado nas seguintes publicações:
- «";
- «";
- «".
Fonte: habr.com