Em uma postagem anterior, falamos sobre como os serviços em nuvem se tornaram um padrão não escrito para o fornecimento de serviços de TI. É fácil adivinhar que as empresas que ainda desejam ganhar dinheiro com aplicativos de usuários devem se adaptar e criar novos produtos, levando em consideração a abordagem nativa da nuvem. No entanto, para os desenvolvedores, essa é definitivamente uma notícia positiva, pois o uso de tecnologias em nuvem abre enormes novas oportunidades para eles. O principal é poder descartá-los corretamente.
Quando um aplicativo solicita um ambiente
Se você já leu o
guia de tecnologia em nuvem, provavelmente se lembrará de que a tecnologia de virtualização é uma das “fontes mágicas” de nuvens. Graças a isso, o desenvolvedor praticamente não precisa pensar nos parâmetros dos servidores nos quais seu aplicativo funcionará. Por que gastar tempo nisso se um hypervisor ou contêiner configurado corretamente pode configurar uma máquina com quase todas as características que um aplicativo precisa para funcionar?
O desenvolvimento dessa idéia é a abordagem Infraestrutura como código (IAC). Sua essência é permitir que desenvolvedores ou serviços operacionais usem as mesmas abordagens usadas durante a fase de desenvolvimento para manter a infraestrutura. Permite preparar antecipadamente unidades comuns de controle de software e integrar facilmente esses componentes em novos projetos.
Os recursos dos datacenters modernos já nos permitem avançar para a linguagem declarativa do gerenciamento de infraestrutura. Idealmente, o aplicativo deve administrar o pool de recursos que ocupa no datacenter. Isso permitirá que o desenvolvedor não fique bloqueado nas limitações associadas ao processo de trabalhar com a infraestrutura, quando for necessário solicitar e projetar com antecedência ou se os mesmos componentes da infraestrutura forem repetidos em projetos diferentes.
De fato, o desenvolvedor ou engenheiro faz uma solicitação de recebimento, que contém a configuração da máquina virtual (kernel, memória, rede, modelo etc.), então o gerenciador de ambiente virtual cria a máquina independentemente ou cria uma nova instância de banco de dados ou inicia o serviço pré-instalado, de acordo com as configurações em arquivo Essa abordagem é uma salvação real ao trabalhar com big data e redes neurais. Os aplicativos associados a essas tecnologias, em alguns casos, exigem quantidades dinamicamente variáveis de memória e energia do processador.
Por exemplo, para treinar uma rede, é necessário "dirigir" centenas de gigabytes de informações através dela, e as nuvens possibilitam obter a capacidade necessária para isso mediante solicitação. Após a conclusão do treinamento, os recursos são retornados ao pool de provedores e o desenvolvedor não precisa pensar em como levá-los ou em como configurar o aplicativo de uma maneira diferente, para que continue a trabalhar com uma quantidade menor de capacidade.
Monólito vs. caos ordenado
Devido ao fato de as nuvens poderem se adaptar de forma flexível às necessidades do desenvolvedor, isso teoricamente simplifica outra tarefa - o problema de dimensionar aplicativos. Por que teoricamente?
Infelizmente, a tarefa de dimensionar aplicativos não é linear. Para que o aplicativo possa lidar com grandes cargas durante períodos de pico de atendimento (ou computação), não basta apenas fornecer mais memória e potência do processador. Absolutamente todo aplicativo tradicional tem um limite, após o qual não é mais capaz de "digerir" novos recursos e demonstrar um aumento de desempenho. O problema neste caso não são os recursos, mas a arquitetura da maioria dos programas.
Esse problema é especialmente grave para aplicativos com uma arquitetura monolítica, que na verdade são arquivos binários únicos. As vantagens dessa abordagem são óbvias: aplicações monolíticas são bastante simples e lineares. Todos os cenários de comportamento do usuário podem ser previstos, rastreados e, se necessário, depurados.
No entanto, essa simplicidade tem um preço. Em primeiro lugar, esses são os problemas de dimensionamento mencionados acima. Em algum momento, até o aplicativo monolítico mais atencioso deixa de funcionar com mais eficiência de uma atualização para a configuração do servidor em que está sendo executado.
Em segundo lugar, um aplicativo monolítico não é tão fácil de transferir para novos servidores e isso pode exigir uma recompilação completa do programa.
Em terceiro lugar, é difícil manter e desenvolver esse aplicativo. Qualquer turno de atualização requer a montagem completa de todo o programa, e um erro em um dos blocos de código pode resultar na queda de todo o sistema.
Em busca de idéias sobre como resolver esses problemas, outro conceito foi desenvolvido - arquitetura orientada a serviços (SOA). Isso implica que o aplicativo seja dividido em vários módulos, cada um dos quais fornece aos outros algum tipo de funcionalidade. Os módulos interagem entre si por meio de um conjunto de serviços da web e podem acessar independentemente um ou seus próprios bancos de dados.
Essa abordagem realmente simplifica o suporte do programa e não transforma sua atualização "no trabalho de um sapador", na qual não há espaço para erro; mas ele também tem suas falhas. O principal é o problema de escalar o desenvolvimento de tais aplicativos. À medida que o programa cresce, torna-se cada vez mais difícil "inserir" novos recursos nos pacotes 5-10 originalmente aprovados pelo arquiteto. Seu número está crescendo, o que se transforma em problemas de suporte.
Microsserviço como elemento de evolução de aplicativos
A evolução da SOA levou à idéia da arquitetura de microsserviço, usada no design de aplicativos em nuvem. Conceitualmente, as idéias de ambas as abordagens são extremamente semelhantes, e alguns arquitetos nem sequer destacam a arquitetura de microsserviço como um paradigma separado, considerando-o um caso especial de SOA.
A arquitetura de microsserviço implica que o aplicativo não consiste em um pequeno número de módulos grandes, mas em muitas partes independentes. Ao contrário de um monólito, em um aplicativo de microsserviço, você pode usar vários métodos para a interação de componentes entre si. O sistema não possui um único estado predeterminado. Em vez disso, cada componente funciona "de acordo com a situação": assim que recebe um evento, ele começa a funcionar. Isso permite uma arquitetura muito flexível e independente.
Ao mesmo tempo, o número de serviços no aplicativo de microsserviço muda constantemente - alguns são adicionados, outros são excluídos. Na nova abordagem, qualquer microsserviço pode ser substituído e uma cadeia de microsserviços incorporada a ele. Outros serviços continuam a funcionar de forma estável, porque não estão diretamente relacionados. Esta é a evolução natural do programa. Graças a isso, desenvolvedores e arquitetos têm a oportunidade de mudar rapidamente algo para responder às mudanças nos requisitos de negócios e superar os concorrentes.
Além de aumentar a velocidade da atualização de atualizações, o uso da arquitetura de microsserviço permite um gerenciamento descentralizado. A equipe responsável pelo desenvolvimento de um serviço tem o direito de determinar sua arquitetura interna e seus recursos. Essa abordagem, a propósito, agora está sendo implementada pelo Conselho de Arquitetura do Sberbank no Bloco de Tecnologia.
Ao mesmo tempo, sentando-se para desenvolver seu aplicativo em nuvem, você não deve se apressar em esmagá-lo rapidamente em seus elementos constituintes. O principal oponente de uma abordagem tão impensada é Martin Fowler; ele é um dos autores da idéia de arquitetura de microsserviço. É mais fácil usar inicialmente uma abordagem monolítica e depois estimular a evolução do aplicativo de uma maneira "natural", concentrando-se na quebra de gargalos e na adição de funções adicionais.
Como resultado, podemos formular a seguinte regra: a tarefa do programador ao trabalhar com a arquitetura de microsserviços não é apenas dividir o aplicativo no número máximo de componentes, mas distinguir deliberadamente entre a responsabilidade pelo recebimento e processamento de dados.
Quatro detalhes
Além das muitas vantagens óbvias, a arquitetura de microsserviço tem suas próprias características, que devem ser levadas em consideração ao desenvolver seu aplicativo em nuvem. Em particular, para dar suporte à operação de um aplicativo como esse, é necessário manter constantemente requisitos aumentados para a qualidade do gerenciamento de APIs internas.
Quando um dos componentes altera sua interface, ele deve oferecer suporte à compatibilidade com versões anteriores, a fim de suportar a versão anterior de sua própria API. Se essa regra for observada, você poderá alternar dinamicamente da versão antiga para a nova sem falhas. Se o suporte para a versão anterior da API não for resolvido, isso ameaça, na melhor das hipóteses, a perda de parte da funcionalidade do aplicativo e, na pior das hipóteses, travamentos permanentes em sua operação.
A segunda característica importante dos aplicativos de microsserviço é a dificuldade de encontrar erros neles. Se um aplicativo escrito em lógica monolítica ou SOA travar, não será difícil encontrar a origem do problema. Em um aplicativo que consiste em muitos serviços, a busca pela causa do bug pode demorar muito tempo, pois os dados do usuário costumam passar por vários microsserviços e é difícil determinar qual deles trava. Ao mesmo tempo, o processo de busca de erros deve ser realizado com muito cuidado: qualquer refatoração malsucedida pode levar a uma falha no módulo de trabalho e, além do problema inicial, o desenvolvedor receberá um segundo.
O terceiro detalhe importante que deve ser levado em consideração ao desenvolver um aplicativo em nuvem é a maneira como seus componentes interagem entre si. Como na SOA, os serviços usam serviços da Web para troca de dados, mas padrões de interação, como streaming, CQRS, sourcing de eventos, apareceram na arquitetura do microsserviço. Normalmente, os desenvolvedores esperam que o tempo de resposta entre a solicitação e a resposta no aplicativo seja bastante pequeno. Em um sistema distribuído, nem se pode confiar no fato de que a resposta virá.
Além disso, na arquitetura de aplicativos em nuvem, os microsserviços usam vários bancos de dados que são mais adequados para solucionar seus problemas específicos. Por exemplo, as grades podem ler rapidamente, mas dificilmente conseguem lidar com um grande número de operações de alteração de dados. Essa base é adequada para a manutenção de contas de depósito - elas raramente mudam. Outro tipo de operação é o processamento; pode haver dezenas de alterações em cada mapa nele todos os dias e, pelo contrário, há poucas leituras de dados.
Por fim, o quarto fato que você precisa lembrar ao desenvolver um aplicativo em nuvem é que a arquitetura de microsserviço se concentra principalmente no uso de serviços sem estado. Nesse caso, não vá ao extremo. Alguns serviços, se necessário, ainda podem fornecer suporte estatal se a lógica comercial exigir, e devem ser projetados com cuidado especial.
Por exemplo: se o usuário solicitar um empréstimo, o sistema que recebeu o aplicativo deverá salvar esse estado para transferi-lo para outros serviços. Mas o serviço responsável por encontrar informações no arquivo interno dos históricos de crédito pode não salvar seu estado e esquecer os dados em que nome de usuário procurou alguns minutos atrás - de qualquer maneira, depois de um momento, uma nova solicitação chegará a ele (embora nesse processo possa comportamento de serviço diferente).
Todos os exemplos e práticas descritos acima já são usados ativamente pelos líderes do setor global de TI. Por exemplo, a Netflix é pioneira no desenvolvimento da arquitetura de microsserviços. A empresa lançou muitos aplicativos de código aberto, bibliotecas e uma estrutura para monitorar, balancear e registrar aplicativos de microsserviço.