Olá a todos! Este é o segundo post da nossa série sobre Quarkus - hoje falaremos sobre compilação nativa.
é uma pilha Java adaptada para . Embora certamente haja muito mais a fazer aqui, fizemos um bom trabalho em vários aspectos, incluindo a otimização da JVM e de uma série de estruturas. Um dos recursos do Quarkus que atraiu cada vez mais interesse dos desenvolvedores é sua abordagem abrangente e contínua para transformar código Java em arquivos executáveis para um sistema operacional específico (a chamada “compilação nativa”), semelhante a C e C++, onde tal compilação geralmente ocorre no final de um ciclo de construção, teste e implantação.
E embora a compilação nativa seja importante, como mostraremos a seguir, deve-se notar que o Quarkus funciona muito bem na máquina Java mais comum, o OpenJDK Hotspot, graças às melhorias de desempenho que implementamos em toda a pilha. Portanto, a compilação nativa deve ser considerada como um bônus adicional que pode ser usado conforme desejado ou necessário. Na verdade, o Quarkus depende muito do OpenJDK quando se trata de imagens nativas. E o modo dev, calorosamente aceito pelos desenvolvedores, garante testes quase instantâneos de alterações devido aos recursos avançados de execução dinâmica de código implementados no Hotspot. Além disso, ao criar imagens GraalVM nativas, a biblioteca de classes OpenJDK e os recursos HotSpot são usados.
Então, por que você precisa de compilação nativa se tudo já está perfeitamente otimizado? Tentaremos responder a esta pergunta abaixo.
Vamos começar pelo óbvio: a Red Hat tem ampla experiência na otimização de JVMs, stacks e frameworks durante o desenvolvimento de projetos , Incluindo:
- O primeiro servidor de aplicativos a trabalhar na nuvem na plataforma .
- O primeiro servidor de aplicativos para execução em computadores .
- O primeiro servidor de aplicativos a ser executado .
- Uma variedade de projetos em execução em dispositivos .
Temos lidado com os desafios de executar aplicativos Java na nuvem e em dispositivos com recursos limitados (leia-se: IoT) há muitos anos e aprendemos a aproveitar ao máximo a JVM em termos de desempenho e otimização de memória. Como muitos outros, há muito tempo trabalhamos com compilação nativa de aplicações Java através , , e ainda e estamos bem conscientes dos prós e contras desta abordagem (por exemplo, o dilema de escolher entre a universalidade de “construir uma vez – executar em qualquer lugar” e o facto de as aplicações compiladas serem mais pequenas e executarem mais rapidamente).
Por que é importante considerar esses prós e contras? Porque em algumas situações a sua proporção torna-se decisiva:
- Por exemplo, em ambientes sem servidor/orientados por eventos onde em tempo real (hard ou soft) para ter tempo de responder aos eventos. Ao contrário dos serviços persistentes de longa duração, aqui a duração de uma inicialização a frio aumenta criticamente o tempo de resposta a uma solicitação. A JVM ainda leva um tempo significativo para inicializar e, embora isso possa ser reduzido em alguns casos por métodos puros de hardware, a diferença entre um segundo e 5 milissegundos pode ser a diferença entre a vida e a morte. Sim, aqui você pode brincar criando uma reserva quente de máquinas Java (o que, por exemplo, fizemos com ), mas isso por si só não garante que haverá JVMs suficientes para processar solicitações à medida que a carga aumenta. E do ponto de vista económico, esta provavelmente não é a opção mais correta.
- Além disso, há outro aspecto que aparece frequentemente: multilocação. Apesar de as JVMs terem chegado muito próximas dos sistemas operacionais em suas capacidades, elas ainda não são capazes de fazer o que estamos tão acostumados no Linux - isolar processos. Portanto, a falha de um thread pode derrubar toda a máquina Java. Muitas pessoas tentam contornar essa desvantagem dedicando uma JVM separada para cada aplicação de usuário, a fim de minimizar as consequências de uma falha. Isso é bastante lógico, mas não se adapta bem ao dimensionamento.
- Além disso, para aplicações orientadas para nuvem, um indicador importante é a densidade de serviços no host. Transição para metodologia , microsserviços e Kubernetes aumentam o número de máquinas Java por aplicação. Ou seja, por um lado, tudo isto proporciona elasticidade e fiabilidade, mas ao mesmo tempo aumenta também o consumo de memória base em termos de serviço, sendo que alguns destes gastos nem sempre são estritamente necessários. Os arquivos executáveis compilados estaticamente se beneficiam aqui devido a várias técnicas de otimização, como a eliminação de código morto de baixo nível, quando a imagem final inclui apenas as partes das estruturas (incluindo o próprio JDK) que o serviço realmente usa. Portanto, a compilação nativa do Quarkus ajuda a colocar instâncias de serviço densamente no host sem comprometer a segurança.
Na verdade, os argumentos acima já são suficientes para compreender a justificativa da compilação nativa do ponto de vista dos participantes do projeto Quarkus. No entanto, há outra razão, não técnica, mas também importante: nos últimos anos, muitos programadores e empresas de desenvolvimento abandonaram o Java em favor de novas linguagens de programação, acreditando que o Java, juntamente com as suas JVMs, pilhas e frameworks, tornou-se demasiado com fome de memória, muito lento, etc.
Porém, o hábito de usar a mesma ferramenta para resolver qualquer problema é . Às vezes é melhor dar um passo atrás e procurar outra coisa. E se o Quarkus faz as pessoas pararem e pensarem, isso é bom para todo o ecossistema Java. Quarkus representa uma visão inovadora de como construir aplicações mais eficientes, tornando o Java mais relevante para novas arquiteturas de aplicações como serverless. Além disso, devido à sua extensibilidade, espera-se que o Quarkus tenha todo um ecossistema de extensões Java, aumentando significativamente o número de frameworks que darão suporte à compilação nativa em aplicações prontas para uso.
Fonte: habr.com