Introducció
El 7 de març, RedHat (properament IBM)
L'objectiu és fer de Java la plataforma líder per al desplegament de Kubernetes i el desenvolupament d'aplicacions sense servidor, proporcionant als desenvolupadors un enfocament unificat del desenvolupament tant en estils reactius com imperatius.
Si mireu
Es promet una velocitat molt alta de llançament d'aplicacions i un baix consum de memòria. Aquí teniu les dades del lloc web del desenvolupador:
Temps des de l'inici fins a la primera resposta (s):
Configuració
RESTA
REST+JPA
Quarkus+GraalVM
0.014
0.055
Quarkus+OpenJDK
0.75
2.5
Pila nativa del núvol tradicional*
4.3
9.5
Consum de memòria (Mb):
Configuració
RESTA
REST+JPA
Quarkus+GraalVM
13
35
Quarkus+OpenJDK
74
130
Pila nativa del núvol tradicional*
140
218
Impressionant, no?
*No he trobat cap informació sobre aquesta pila de tecnologia, podem suposar que es tracta d'una mena de Spring Boot amb un kit de carrosseria addicional.
Hola món!
L'aplicació més senzilla escrita en Quarkus es veuria així:
@Path("/hello")
public class GreetingResource {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String hello() {
return "hello";
}
}
És literalment una classe i n'hi ha prou! Podeu executar l'aplicació utilitzant Maven en mode de desenvolupament:
mvn compile quarkus:dev
…
$ curl http://localhost:8080/hello
hello
La diferència amb una aplicació normal és que no hi ha cap classe d'aplicació! Quarkus admet la recàrrega en calent, de manera que podeu canviar la vostra aplicació sense reiniciar-la, fent que el desenvolupament sigui encara més ràpid.
Que segueix? Podeu afegir un servei a un controlador mitjançant una anotació
@ApplicationScoped
public class GreetingService {
public String greeting(String name) {
return "Hello " + name + "!";
}
}
Controlador:
@Path("/hello")
public class GreetingResource {
@Inject
GreetingService service;
@GET
@Produces(MediaType.TEXT_PLAIN)
@Path("/{name}")
public String greeting(@PathParam("name") String name) {
return service.greeting(name);
}
}
$ curl http://localhost:8080/hello/developer
Hello developer!
Tingueu en compte que Quarkus utilitza anotacions estàndard de marcs familiars: CDI i JAX-RS. No cal aprendre res de nou si heu treballat abans amb CDI i JAX-RS, és clar.
Treballant amb la base de dades
S'utilitzen anotacions Hibernate i JPA estàndard per a entitats. Igual que amb els controladors REST, cal escriure un mínim de codi. N'hi ha prou amb indicar les dependències al fitxer de muntatge, afegir anotacions @Entity
i configureu la font de dades a application.properties.
Tots. No hi ha fitxers sessionFactory, persistence.xml ni cap altre servei. Escrivim només el codi que es necessita. Tanmateix, si cal, podeu crear un fitxer persistence.xml i configurar la capa ORM de manera més fina.
Quarkus admet la memòria cau d'entitats, col·leccions per a relacions d'un a molts i consultes. A primera vista sembla genial, però ho és locals memòria cau, per a un node de Kubernetes. Aquells. Les memòria cau dels diferents nodes no estan sincronitzades entre si. Espero que això sigui temporal.
Execució de codi asíncron
Com s'ha esmentat anteriorment, Quarkus també admet l'estil de programació reactiva. El codi de l'aplicació anterior es pot escriure d'una altra forma.
@Path("/hello")
public class GreetingResource {
@GET
@Produces(MediaType.TEXT_PLAIN)
@Path("/{name}")
public CompletionStage<String> greeting(@PathParam("name") String name) {
return CompletableFuture.supplyAsync(() -> {
return "Hello " + name + "!";
});
}
}
El codi asíncron també es pot transferir al servei, el resultat serà el mateix.
Proves
Les proves per a les aplicacions Quarkus es poden escriure en JUnit4 o JUnit5. A continuació es mostra un exemple de prova per a un punt final, està escrit amb RestAssured, però es pot utilitzar un altre marc:
@QuarkusTest
public class GreetingResourceTest {
@Test
public void testGreetingEndpoint() {
String uuid = UUID.randomUUID().toString();
given()
.pathParam("name", uuid)
.when().get("/hello/{name}")
.then()
.statusCode(200)
.body(is("Hello " + uuid + "!"));
}
}
L'anotació @QuarkusTest us indica que executeu l'aplicació abans d'executar proves. La resta és codi familiar per a tots els desenvolupadors.
Aplicació específica de la plataforma
Com que Quarkus està estretament integrat amb GraalVM, és possible generar codi específic per a la plataforma. Per fer-ho, cal instal·lar GraalVM i especificar la variable d'entorn GRAALVM_HOME. Més lluny
mvn package -Pnative
Curiosament, l'aplicació generada es pot provar. I això és important perquè l'execució del codi natiu pot diferir de l'execució a la JVM. L'anotació @SubstrateTest executa el codi d'aplicació específic de la plataforma. La reutilització del codi de prova existent es pot fer mitjançant l'herència; com a resultat, el codi per provar una aplicació depenent de la plataforma tindrà aquest aspecte:
@SubstrateTest
public class GreetingResourceIT extends GreetingResourceTest {
}
La imatge generada es pot empaquetar a Docker i executar-se a Kubernetes o OpenShift, descrit en detall a
Kit d’eines
El framework Quarkus es pot utilitzar amb Maven i Gradle. Maven és totalment compatible, a diferència de Gradle. Malauradament, de moment Gradle no admet la generació d'un projecte buit; hi ha informació detallada al lloc web
Extensions
Quarkus és un framework extensible. Actualment hi ha una comanda
Conclusió
Al meu entendre, Quarkus està força en línia amb les tendències de l'època. El desenvolupament de codi de backend és cada cop més fàcil, i aquest marc simplifica i accelera encara més el desenvolupament del servei afegint suport natiu per a Docker i Kubernetes. Un gran avantatge és el suport integrat per a GraalVM i la generació d'imatges dependents de la plataforma, que permet que els serveis s'iniciïn molt ràpidament i ocupin poc espai de memòria. I això és molt important en el nostre temps de passió massiva pels microserveis i l'arquitectura sense servidor.
Lloc oficial -
Font: www.habr.com