{"id":74795,"date":"2020-03-20T20:42:21","date_gmt":"2020-03-20T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie"},"modified":"2020-03-20T20:42:21","modified_gmt":"2020-03-20T17:42:21","slug":"kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"Como o Quarkus une programa\u00e7\u00e3o imperativa e reativa","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Este ano, pretendemos desenvolver seriamente os temas de cont\u00eaineres, Java Nativa na Nuvem<\/a><\/noindex> e Kubernetes<\/a><\/noindex>. A continua\u00e7\u00e3o l\u00f3gica desses t\u00f3picos ser\u00e1 uma discuss\u00e3o sobre o framework Quarkus, j\u00e1 discutido<\/a><\/noindex> no Habr. O artigo de hoje n\u00e3o se concentra tanto na ess\u00eancia da \"Java subat\u00f4mica super-r\u00e1pida\", mas nas perspectivas que o Quarkus traz para o ambiente Enterprise.<\/p>\n

\"Como
\n
\nJava e JVM continuam extremamente populares, mas ao trabalhar com tecnologias sem servidor e microservi\u00e7os orientados para a nuvem, Java e outras linguagens para JVM est\u00e3o sendo usadas com menos frequ\u00eancia, pois ocupam muito espa\u00e7o na mem\u00f3ria e demoram para carregar, o que as torna pouco adequadas para uso com cont\u00eaineres de vida curta. Felizmente, essa situa\u00e7\u00e3o est\u00e1 come\u00e7ando a mudar gra\u00e7as ao Quarkus.
\n<\/a><\/noindex><\/p>\n

A Java subat\u00f4mica super-r\u00e1pida alcan\u00e7ou um novo n\u00edvel!<\/h3>\n

\n42 lan\u00e7amentos, 8 meses de trabalho da comunidade e 177 desenvolvedores incr\u00edveis resultaram no lan\u00e7amento em novembro de 2019 Quarkus 1.0<\/a><\/noindex>, uma vers\u00e3o que marca um marco importante no desenvolvimento do projeto e oferece uma s\u00e9rie de fun\u00e7\u00f5es e recursos incr\u00edveis (voc\u00ea pode ler mais sobre eles em an\u00fancio<\/a><\/noindex>).<\/p>\n

Hoje, vamos mostrar como o Quarkus une os modelos de programa\u00e7\u00e3o imperativa e reativa com uma \u00fanica estrutura reativa. Come\u00e7aremos com uma breve excurs\u00e3o pela hist\u00f3ria e, em seguida, analisaremos detalhadamente o que constitui o dualismo do n\u00facleo reativo do Quarkus e como Java<\/a><\/noindex>-desenvolvedores podem aproveitar essas vantagens.<\/p>\n

Microservi\u00e7os<\/a><\/noindex>, arquiteturas orientadas a eventos<\/a><\/noindex> e sem servidor<\/a><\/noindex>-fun\u00e7\u00f5es \u2013 tudo isso, hoje em dia, est\u00e1, por assim dizer, em alta. Recentemente, a cria\u00e7\u00e3o de arquiteturas orientadas para a nuvem tornou-se muito mais f\u00e1cil e acess\u00edvel, mas os problemas persistem \u2013 especialmente para os desenvolvedores Java. Por exemplo, no caso de fun\u00e7\u00f5es sem servidor e microservi\u00e7os, h\u00e1 uma necessidade urgente de reduzir o tempo de inicializa\u00e7\u00e3o, diminuir o consumo de mem\u00f3ria e tornar seu desenvolvimento mais conveniente e agrad\u00e1vel. Nos \u00faltimos anos, Java fez v\u00e1rias melhorias, como a funcionalidade ergonomics aprimorada para cont\u00eaineres, entre outras. No entanto, ainda assim, conseguir que o Java funcione corretamente em um cont\u00eainer continua sendo um desafio. Portanto, come\u00e7aremos examinando algumas das complexidades internas do Java, que se manifestam de forma particularmente aguda ao desenvolver aplica\u00e7\u00f5es Java orientadas a cont\u00eaineres.<\/p>\n

Primeiro, vamos olhar para a hist\u00f3ria.<\/p>\n

\"Como<\/p>\n

Fluxos e cont\u00eaineres<\/h3>\n

\nA partir da vers\u00e3o 8u131, o Java come\u00e7ou a oferecer um suporte razo\u00e1vel para cont\u00eaineres, gra\u00e7as a melhorias na funcionalidade de ergonomia. Em particular, agora a JVM sabe em quantos n\u00facleos de processador est\u00e1 sendo executada e pode ajustar pools de threads de acordo \u2013 geralmente, pools fork\/join. Sem d\u00favida, isso \u00e9 \u00f3timo, mas, digamos, temos uma aplica\u00e7\u00e3o web tradicional que utiliza servlets HTTP e \u00e9 executada em Tomcat, Jetty, etc. Como resultado, essa aplica\u00e7\u00e3o criar\u00e1 um thread separado para cada solicita\u00e7\u00e3o e permitir\u00e1 que essa thread fique bloqueada enquanto aguarda opera\u00e7\u00f5es de entrada\/sa\u00edda, por exemplo, ao acessar bancos de dados, arquivos ou outros servi\u00e7os. Ou seja, o tamanho de tal aplicativo depende n\u00e3o da quantidade de n\u00facleos dispon\u00edveis, mas do n\u00famero de solicita\u00e7\u00f5es simult\u00e2neas. Al\u00e9m disso, isso significa que quotas ou limites em Kubernetes sobre a quantidade de n\u00facleos n\u00e3o ser\u00e3o muito \u00fateis, e acabaremos enfrentando throttling.<\/p>\n

Exaust\u00e3o de mem\u00f3ria<\/h3>\n

\nAs threads s\u00e3o mem\u00f3ria. E as limita\u00e7\u00f5es de mem\u00f3ria dentro do cont\u00eainer n\u00e3o s\u00e3o uma panaceia. Comece a aumentar o n\u00famero de aplicativos e threads, e cedo ou tarde voc\u00ea enfrentar\u00e1 um crescimento cr\u00edtico na frequ\u00eancia de troca de contexto e, como resultado, uma degrada\u00e7\u00e3o no desempenho. Al\u00e9m disso, se o aplicativo utilizar frameworks de microservi\u00e7os tradicionais ou se conectar a bancos de dados, ou utilizar cache, ou de alguma outra forma gastar mem\u00f3ria, voc\u00ea definitivamente precisar\u00e1 de uma ferramenta que permita olhar dentro da JVM e ver como ela gerencia a mem\u00f3ria, sem que a pr\u00f3pria JVM seja prejudicada (por exemplo, XX:+UseCGroupMemoryLimitForHeap). E mesmo que, a partir do Java 9, a JVM tenha aprendido a entender cgroups e se adaptar adequadamente, a reserva e o gerenciamento de mem\u00f3ria continuam a ser quest\u00f5es bastante complicadas.<\/p>\n

Quotas e limites<\/h3>\n

\nCom o Java 11, o suporte a quotas de CPU foi introduzido (como PreferContainerQuotaForCPUCount). O Kubernetes tamb\u00e9m oferece suporte a limites e quotas. Sim, tudo isso faz sentido, mas, se o aplicativo novamente ultrapassar a quota designada, voltamos \u00e0 situa\u00e7\u00e3o em que o tamanho \u2013 assim como no caso de aplicativos Java tradicionais \u2013 \u00e9 determinado pelo n\u00famero de n\u00facleos, com a aloca\u00e7\u00e3o de uma thread separada para cada solicita\u00e7\u00e3o, ou seja, o benef\u00edcio de tudo isso se torna limitado.
\nAl\u00e9m disso, se utilizarmos quotas e limites ou fun\u00e7\u00f5es de escalonamento horizontal (scale-out) da plataforma subjacente ao Kubernetes, o problema n\u00e3o se resolve por si s\u00f3. Estamos apenas gastando mais recursos para resolver o problema original ou, no final, acabamos com um desperd\u00edcio de recursos. E se isso for um sistema de alta carga em uma nuvem p\u00fablica acess\u00edvel, quase certamente come\u00e7amos a usar mais recursos do que realmente precisamos.<\/p>\n

E o que fazer com tudo isso?<\/h3>\n

\nSe formos diretos, devemos usar bibliotecas e frameworks ass\u00edncronos e n\u00e3o bloqueantes de entrada e sa\u00edda, como o Netty, Vert.x<\/a><\/noindex> ou Akka. Eles s\u00e3o muito mais adequados para trabalhar em cont\u00eaineres devido \u00e0 sua natureza reativa. Com a entrada e sa\u00edda n\u00e3o bloqueantes, o mesmo thread pode lidar com v\u00e1rias requisi\u00e7\u00f5es simultaneamente. Enquanto uma requisi\u00e7\u00e3o aguarda resultados de entrada e sa\u00edda, o thread que a processa se libera e assume outra requisi\u00e7\u00e3o. Quando os resultados de entrada e sa\u00edda finalmente chegam, o processamento da primeira requisi\u00e7\u00e3o continua. Alternando o processamento de requisi\u00e7\u00f5es dentro do mesmo thread, \u00e9 poss\u00edvel reduzir o n\u00famero total de threads e diminuir o consumo de recursos para o processamento das requisi\u00e7\u00f5es.<\/p>\n

Com a entrada e sa\u00edda n\u00e3o bloqueantes, o n\u00famero de n\u00facleos se torna um par\u00e2metro crucial, pois \u00e9 isso que determina o n\u00famero de threads de entrada e sa\u00edda que podem ser executadas em paralelo. Quando utilizado corretamente, isso permite distribuir a carga de forma eficiente entre os n\u00facleos e lidar com cargas mais altas com menos recursos.<\/p>\n

Como, e \u00e9 tudo isso?<\/h3>\n

\nN\u00e3o, h\u00e1 mais. A programa\u00e7\u00e3o reativa ajuda a utilizar melhor os recursos, mas tamb\u00e9m tem seu custo. Em particular, o c\u00f3digo precisar\u00e1 ser reescrito de acordo com os princ\u00edpios de n\u00e3o bloqueio e evitar bloqueios de threads de entrada e sa\u00edda. E essa \u00e9 uma modelo de desenvolvimento e execu\u00e7\u00e3o completamente diferente. Embora existam muitas bibliotecas \u00fateis, isso ainda representa uma mudan\u00e7a radical na forma de pensar habitual.<\/p>\n

Primeiro, voc\u00ea precisa aprender a escrever c\u00f3digo que seja executado de forma ass\u00edncrona. Assim que voc\u00ea come\u00e7a a usar entrada e sa\u00edda n\u00e3o bloqueantes, \u00e9 necess\u00e1rio especificar claramente o que deve acontecer ao receber uma resposta para uma solicita\u00e7\u00e3o. Bloquear e esperar n\u00e3o \u00e9 mais uma op\u00e7\u00e3o. Em vez disso, voc\u00ea pode passar callbacks, usar programa\u00e7\u00e3o reativa ou continua\u00e7\u00e3o. Mas isso n\u00e3o \u00e9 tudo: para usar entrada e sa\u00edda n\u00e3o bloqueantes, voc\u00ea tamb\u00e9m precisa de servidores e clientes n\u00e3o bloqueantes, de prefer\u00eancia em todos os lugares. No caso do HTTP, \u00e9 simples, mas existem tamb\u00e9m bancos de dados, sistemas de arquivos e muito mais.<\/p>\n

E embora a reatividade total ofere\u00e7a m\u00e1xima efici\u00eancia, essa mudan\u00e7a pode ser dif\u00edcil de digerir na pr\u00e1tica. Portanto, a capacidade de combinar c\u00f3digo reativo e imperativo se torna uma condi\u00e7\u00e3o necess\u00e1ria para que:<\/p>\n

    \n
  1. Utilize os recursos de forma eficaz nas \u00e1reas mais carregadas do sistema de software;<\/li>\n
  2. Use um c\u00f3digo de estilo mais simples nas outras partes.<\/li>\n<\/ol>\n

    <\/p>\n

    Apresentamos o Quarkus<\/h3>\n

    \nNa verdade, essa \u00e9 a ess\u00eancia do Quarkus \u2013 combinar modelos reativos e imperativos em um \u00fanico ambiente de execu\u00e7\u00e3o.<\/p>\n

    A base do Quarkus \u00e9 formada pelo Vert.x e pelo Netty, sobre os quais \u00e9 utilizado uma gama de frameworks reativos e extens\u00f5es, projetados para ajudar o desenvolvedor. O Quarkus \u00e9 destinado \u00e0 constru\u00e7\u00e3o n\u00e3o apenas de microsservi\u00e7os HTTP, mas tamb\u00e9m de arquiteturas baseadas em eventos. Gra\u00e7as \u00e0 sua natureza reativa, ele funciona de maneira muito eficaz com sistemas de troca de mensagens (Apache Kafka, AMQP etc.).<\/p>\n

    O truque est\u00e1 em como usar o mesmo motor reativo tanto para c\u00f3digo imperativo quanto para c\u00f3digo reativo.<\/p>\n

    \"Como<\/p>\n

    Quarkus se destaca nesse aspecto. A escolha entre o imperativo e o reativo \u00e9 clara \u2013 usar um n\u00facleo reativo para ambos. E onde ele realmente ajuda \u00e9 com c\u00f3digo n\u00e3o bloqueante r\u00e1pido que processa quase tudo o que passa pelo ciclo de eventos (event-loop thread, tamb\u00e9m conhecido como IO thread). Mas se voc\u00ea tem aplicativos REST cl\u00e1ssicos ou aplicativos do lado do cliente, Quarkus tem uma modelo de programa\u00e7\u00e3o imperativa pronta para uso. Por exemplo, o suporte a HTTP em Quarkus \u00e9 constru\u00eddo com base em um mecanismo n\u00e3o bloqueante e reativo (Eclipse Vert.x e Netty). Todas as solicita\u00e7\u00f5es HTTP recebidas pelo seu aplicativo passam primeiro pelo ciclo de eventos (IO Thread) e, em seguida, s\u00e3o enviadas para a parte do c\u00f3digo que gerencia as solicita\u00e7\u00f5es. Dependendo do destino, o c\u00f3digo de gerenciamento de solicita\u00e7\u00f5es pode ser chamado dentro de uma thread separada (o chamado worker thread, utilizado em servlets e Jax-RS) ou pode utilizar o pr\u00f3prio thread de entrada e sa\u00edda (o chamado reactive route).<\/p>\n

    \"Como<\/p>\n

    Para conectores de sistemas de mensagem, s\u00e3o utilizados clientes n\u00e3o bloqueantes que operam sobre o motor Vert.x. Portanto, voc\u00ea pode enviar, receber e processar mensagens de forma eficaz a partir de sistemas de middleware de mensagens.<\/p>\n

    est\u00e1 escrito: Quarkus.io<\/a><\/noindex> um conjunto de bons tutoriais foi reunido para ajudar a come\u00e7ar a trabalhar com Quarkus:<\/p>\n