O que atrai tanto os desenvolvedores para microsserviços? Não há tecnologia revolucionária por trás deles; as vantagens sobre o monólito são bastante controversas. Somente a facilidade com que ferramentas modernas de desenvolvimento e implantação permitem criar sistemas para rodar em milhares de servidores. Propomos traçar o caminho para o momento presente, quando o desenvolvimento e a implantação de um sistema distribuído desse tipo são possíveis por um desenvolvedor. Sobre como os contêineres Linux, Docker e Kubernetes evoluíram, o papel que os contêineres Linux, Docker e Kubernetes têm desempenhado, diz Alexander Trekhlebov holonavt , arquiteto corporativo do Promsvyazbank, desenvolve software há mais de 15 anos. Começou com C ++ e depois mudou para Java. Recentemente, ele desenvolveu um back-end bancário na plataforma Spring Cloud.
Se recordarmos as primeiras implementações de execução de script (Java Script, VB Script) como parte da exibição de páginas em um navegador, essas foram sequências de instruções de thread único. O mesmo JavaScript - é uma tarefa única. Se o JS for executado em uma página da web e uma das instruções executáveis falhar ou atrasar, tudo o que acontece na página, todo o código será congelado. E você não pode fazer nada, basta fechar ou recarregar a página e, às vezes, o navegador ou todo o sistema operacional.
Claramente, não era muito conveniente. Especialmente quando você considera o fato de que multitarefa / multithreading já estava em todo lugar: processadores, sistemas operacionais, aplicativos (a menos que o primeiro sistema operacional para dispositivos móveis fosse de tarefa única) e JS ainda fosse de thread único. O que aconteceu então? Várias estruturas começaram a aparecer uma após a outra, de uma maneira ou de outra, resolvendo esse problema. Facebook fez reagir, o Google lançou Angular.
Frontend e backend de tempestade multitarefa
Como você cria multitarefa a partir de um sistema de tarefa única? Siga as instruções e se espalhe pelos diferentes fluxos, além de, é claro, monitorar esses fluxos. Certamente você ainda se lembra de que, em uma das versões do FB, apareceu repentinamente a capacidade de escrever simultaneamente uma mensagem e monitorar as alterações na fita. E se de repente a fita cair, as mensagens continuarão funcionando. Foi então que a primeira interface do usuário apareceu na interface modular do React. Com a ajuda da estrutura, a multitarefa começou a funcionar imediatamente.
O que tudo isso tem a ver com microsserviços? Quando a interface do usuário dos bancos da Internet começou a fornecer uma funcionalidade bastante ampla, o congelamento e, mais ainda, a queda do aplicativo, se tornou um evento chocante para os usuários. Afinal, uma coisa é quando o Facebook é ativado, e outra é quando você acaba de fazer um pagamento da hipoteca e os fundos da sua conta não aparecem, porque houve uma falha na forma dos saldos da conta.
Uma idéia simples surgiu: elementos independentes da interface do usuário que permitem que o Angular e o React sejam anexados a elementos de back-end igualmente independentes. Cada elemento de back-end independente é um microsserviço que pode ser dimensionado, aumentado após uma falha etc.
É importante criar corretamente a interface do usuário para que ela seja modificada, dependendo dos componentes de back-end disponíveis. Se algo não funcionar para você no back-end, você não mostra a funcionalidade correspondente na interface do usuário ou de alguma forma padrão - você pode alterar a cor da fonte para cinza ou exibir um prato vazio com a inscrição "As informações do saldo da conta não estão disponíveis. Ligue de volta amanhã ". Na verdade, essa combinação de elementos da interface do usuário com microsserviços ajuda a aumentar a confiabilidade e a escalabilidade gerais de um aplicativo bancário.
De Titanic a Docker
Na minha opinião, a principal razão pela qual os microsserviços se tornaram tão populares, apesar do consumo significativo de memória e da sobrecarga no poder da computação, é a decomposição. O restante, em geral, microsserviços não tem grandes vantagens sobre um monólito. Decomposição, no meu entendimento, é quando o funcional é dividido em certos blocos independentes para lançamento e implantação. Isso significa que, enquanto o restante dos blocos funciona, um pode ser atualizado, geralmente sem interromper seu trabalho (azul, verde - implantação), e criar uma instância adicional.
Todos esses tecnólogos não apareceram ontem nem anteontem. As soluções de computação distribuída foram desenvolvidas nos dias de mainframes porque a falta de recursos de computação surgiu quase imediatamente assim que esses recursos apareceram.
Eles começaram a descobrir como distribuir racionalmente tudo isso, por exemplo, cálculos gráficos nas estações Silicon Graphix. Tudo era caro, e essas soluções estavam disponíveis apenas para grandes organizações, sem mencionar os desenvolvedores individuais. As próprias estações e o software do servidor para elas eram muito caros, portanto os recursos correspondentes foram desenvolvidos para o kernel do Linux. Por exemplo - a computação gráfica dos computadores para as cenas do filme "Titanic", lançado em 1997, foi realizada em servidores com processadores Alpha executando o Linux. A maioria das soluções necessárias para a operação de sistemas distribuídos já foram desenvolvidas e testadas naquele momento. Mas ainda era difícil para um especialista usar todas essas tecnologias; a montagem, a entrega e o suporte de um sistema assim exigiam sérios custos de mão-de-obra.
No início, havia apenas servidores físicos que precisavam ser roteados de alguma forma; então, a era da virtualização começou, as máquinas virtuais apareceram, o trabalho ficou mais divertido, mas ainda assim iniciar e parar a máquina virtual continuava sendo uma ação que requer muitos recursos. E eu queria que isso acontecesse tão rápido quanto iniciar um processo dentro do sistema operacional. Um grande passo em direção ao lançamento da tecnologia "nas pessoas" foi associado ao advento dos contêineres Linux.
Um contêiner Linux é quase um processo do sistema, mas tem sua própria interface de rede e muito mais que o tornou quase como uma máquina virtual. Por que quase? Porque a máquina virtual aumenta em um ambiente bastante isolado. O contêiner Linux usa o sistema operacional pai, cada contêiner possui sua própria versão do sistema operacional Linux, mas as chamadas do sistema são transmitidas para o kernel do sistema operacional pai.
Isso tem suas vantagens - ao criar um contêiner LXC, você não precisa aumentar novamente o kernel. No entanto, trabalhar com contêineres LXC em sua forma original consumia muito tempo e era inconveniente. Na verdade, em algum momento, Docker apareceu. Essa decisão tomou todos os cuidados para implantar e gerenciar contêineres Linux, expondo uma interface mais conveniente.
O advento do Docker foi o impulso para a ampla disseminação da arquitetura de microsserviços. Sim, as tecnologias foram inventadas por um longo tempo, mas a possibilidade de seu uso conveniente apareceu apenas neste momento. Agora, usando o Docker, um desenvolvedor pode literalmente emparelhar várias máquinas virtuais e organizar um sistema de computação distribuído, além de atualizá-lo e escaloná-lo dinamicamente usando alguns comandos.
Assim, os recursos de decomposição permitiram a um amplo círculo de desenvolvedores transformar um monólito em um conjunto de microsserviços dentro de contêineres. No entanto, novas dificuldades surgiram aqui. Quando existem várias dúzias de contêineres e eles estão espalhados por vários servidores, é necessário gerenciá-los de alguma forma, acompanhá-los e executar sua orquestração. Soluções como Docker Swarm e Kubernetes já apareceram aqui. O desenvolvedor individual recebeu uma nova ferramenta poderosa.
Microsserviços em bancos
Qual é a situação dos microsserviços no setor bancário? Quantos, por exemplo, são necessários para dar suporte ao banco on-line? Há um bom exemplo: no Reino Unido, existe um banco totalmente digital - Monzo, sem back office, sem agências, sem site, é essencialmente tudo em um aplicativo móvel. Tudo começou com 40 microsserviços, depois o número aumentou para 300, agora mais.
Se você observar a implementação no Promsvyazbank, teremos sistemas com até 40 microsserviços implantados.
Paralelamente, estão sendo desenvolvidos sistemas de desenvolvimento que permitem o uso de poucas linhas de código para desenvolver os principais componentes do sistema de microsserviços, que podem ser escalados e atualizados com bastante simplicidade. Todos esses recursos são muito populares na construção de sistemas de aprendizado de máquina, na análise de grandes quantidades de dados em tempo real (Cloud Streaming, etc.).
Alexander Trekhlebov contará sobre sua experiência de desenvolvimento com base na arquitetura de microsserviços no relatório “Microservices - tolerância a falhas com base na modularidade de ponta a ponta” no 404 Internet Workers Festival , que será realizado de 6 a 7 de outubro de 2018 em Samara.