Um guia para microsserviços Java. Parte 2: Implantação e Teste

Tradução e adaptação de microsserviços Java: um guia prático . Link para a primeira parte do guia . Qualquer programa Java do lado do servidor e, portanto, qualquer microsserviço, é apenas um arquivo com extensão .jar ou .war. Há uma coisa excelente sobre o ecossistema Java, ou melhor, sobre a JVM: você só precisa escrever código Java uma vez e ele pode ser executado em praticamente qualquer sistema operacional, desde que você não tenha compilado seu código com uma versão mais recente do Java que a sua. versão da JVM de destino. É importante entender isso, especialmente quando se trata de tópicos como Docker, Kubernetes ou (rufar os tambores!) A nuvem. Por que? Vejamos diferentes cenários de implantação.

Exemplo minimalista de implantação de microsserviço Java

Continuemos com o exemplo do banco. Portanto, temos um arquivo monobank.jar (monolith) e nosso recém-extraído Riskengine.jar (o primeiro microsserviço de verificação de risco). Vamos supor também que ambos os aplicativos, como qualquer outro aplicativo no mundo, precisem de um arquivo .properties. No nosso caso, conterá apenas a URL e as credenciais do banco de dados. Uma implantação mínima pode consistir em dois diretórios parecidos com isto: Primeiro:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Segundo:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Isso deixa a questão em aberto: como os arquivos .properties e .jar chegarão ao servidor? Infelizmente, pode haver muitas respostas.

Como usar ferramentas de compilação, SSH e Ansible para implantar microsserviços Java

Conselhos enfadonhos, mas não menos excelentes sobre como implantar microsserviços Java... Na verdade, exatamente da mesma forma que os administradores de sistema implantaram qualquer programa de servidor Java nas empresas nos últimos 20 anos. Esta é a mistura:

• sua ferramenta de construção favorita (Maven, Gradle)
• bom e velho SSH/SCP para copiar .jars para servidores
• Scripts Bash para gerenciar scripts e servidores de implantação
• ou melhor ainda: alguns scripts Ansible.

É claro que isso não é adequado para inovadores que precisam de uma nuvem “respiratória”, servidores com balanceamento de carga automático e assim por diante. Isso é muito chato da velha escola. No entanto, funciona!

Como usar o Docker para implantar microsserviços Java

Voltemos à doce agonia da escolha. Há alguns anos, o Docker entrou em cena e, com ele, a conteinerização. Se você nunca trabalhou com isso, aqui está uma breve descrição voltada para usuários finais e desenvolvedores:

• Um container (simplificado) é parecido com a boa e velha máquina virtual, porém “mais leve”. Se você não tiver certeza do que significa “mais fácil” neste contexto, verifique esta resposta no Stackoverflow .
• O contêiner garante sua própria portabilidade. Ou seja, funciona em qualquer lugar. Parece familiar, não é?

É engraçado que, dada a portabilidade e compatibilidade retroativa da JVM, esse recurso não pareça uma vantagem tão grande. Você pode simplesmente baixar o JVM.zip em qualquer Raspberry Pi (ou mesmo em um telefone celular), extraí-lo e executar qualquer arquivo .jar. A situação muda em linguagens como PHP ou Python, onde as incompatibilidades de versão ou configurações de implantação são mais complexas. Ou se seu aplicativo Java depender de muitos outros serviços instalados (com os números de versão corretos): por exemplo, um banco de dados Postgres ou um armazenamento de valor-chave Redis. Portanto, a principal vantagem do Docker para microsserviços Java, ou mais precisamente para aplicações Java, é esta: a capacidade de configurar ambientes homogeneizados de testes ou integração usando ferramentas como Testcontainers . Desenvolvimentos complexos são mais fáceis de instalar. Pegue o software de fórum Discourse . Você pode instalá-lo com uma única imagem Docker, e essa contém tudo que você precisa, desde o software Discourse escrito em Ruby, até um banco de dados Postgres, até Redis e a pia da cozinha. Se suas implantações forem semelhantes ou você quiser executar um pequeno banco de dados Oracle, experimente o Docker. Então, para resumir, em vez de apenas olhar o arquivo .jar, você agora:

• agrupar seu arquivo jar em uma imagem Docker
• envie esta imagem para um registro Docker privado
• puxe e execute esta imagem em sua plataforma de destino
• ou copie a imagem do Docker diretamente para o seu sistema de produção e execute-a.

Como usar Docker Swarm ou Kubernetes para implantar microsserviços Java

Digamos que você decida experimentar o Docker. Cada vez que você implanta um microsserviço Java, você cria uma imagem Docker que agrupa seu arquivo .jar. Digamos que você tenha alguns desses microsserviços Java e queira implantá-los em várias máquinas (em um cluster). Surge a pergunta: como gerenciar esse cluster? Executar contêineres Docker, verificar desempenho, implantar atualizações, dimensionar o sistema (brrr)? Duas respostas possíveis para esta pergunta são Docker Swarm e Kubernetes. Entrar em detalhes sobre ambas as opções tornaria este tutorial já longo demais, mas achamos importante mencionar que ambas as opções dependem, em última análise, de você escrever arquivos YAML (consulte Histórias de recuo do Yaml ) para gerenciar seu cluster. Se você quiser saber quais sentimentos isso evoca na prática, basta digitar uma consulta semelhante na busca do Twitter. Portanto, o processo de implantação de seus microsserviços Java agora é mais ou menos assim:

• Configurando e gerenciando Docker Swarm/Kubernetes
• Todas as etapas para Docker (veja acima)
• Escreva e execute YAML até seus olhos sangrarem até que tudo funcione.

Como testar microsserviços Java

Digamos que você decida implementar microsserviços em produção. Como podemos testar a integração de n microsserviços durante o desenvolvimento agora? Como você pode ver se todo o fluxo de trabalho está funcionando, e não apenas partes dele? Na prática, você pode usar um dos três métodos:

1. Com um pouco de trabalho (se você estiver usando frameworks como Spring Boot), você pode combinar todos os seus microsserviços em uma classe de inicialização e carregar todos os microsserviços usando uma única classe Wrapper.java - dependendo se você tem memória suficiente em sua máquina para execute todos os seus microsserviços.
2. Você pode copiar as configurações do Docker Swarm ou Kubernetes localmente.
3. Apenas não execute mais testes de integração localmente. Em vez disso, implante um ambiente DEV/TEST dedicado. Isso é algo que algumas equipes realmente fazem quando sucumbem ao incômodo das configurações de microsserviços locais.

Além disso, além de seus microsserviços Java, você provavelmente também precisará de um agente de mensagens em execução (como ActiveMQ ou RabbitMQ) ou talvez um servidor de e-mail ou qualquer outro componente de mensagens que seus microsserviços Java precisem para se comunicarem entre si. Isso leva a uma subestimação significativa da complexidade do lado do DevOps. Dê uma olhada nas Bibliotecas de Teste de Microsserviços, elas podem aliviar essa dor. De qualquer forma, essa complexidade nos leva aos problemas gerais dos microsserviços, dos quais falaremos agora. Na parte final , abordaremos questões gerais sobre microsserviços Java.