6. @FlorianBoulay#devoxxFr
Résumé de Vert.x
Quelques caractéristiques :
➔
Polyglote : tous langages tournant sur la JVM
➔
Scalable : API utilisant des IO non bloquantes et
asynchrone.
➔
Évenementielle
➔
Rapide, très léger
➔
Construit au dessus de Netty
Ce talk est sur la version 2.1
8. @FlorianBoulay#devoxxFr
Création d'un serveur HTTP
public class Server extends Verticle {
public void start() {
vertx.createHttpServer().requestHandler(new Handler<HttpServerRequest>() {
public void handle(HttpServerRequest req) {
req.response()
.putHeader("content-type", "text/html")
.end("<html><body><h1>Hello from vert.x!</h1></body></html>");
}
}).listen(8080);
}
}
9. @FlorianBoulay#devoxxFr
Création d'un serveur HTTP
Java 8
public class Server extends Verticle {
public void start() {
vertx.createHttpServer().requestHandler(req -> {
req.response()
.putHeader("content-type", "text/html")
.end("<html><body><h1>Hello from vert.x!</h1></body></html>");
}).listen(8080);
}
}
Code asynchrone basé sur des callback. Modèle
inspiré de Node.js. Callback hell possible.
10. @FlorianBoulay#devoxxFr
Création d'un serveur HTTP
Javascript
var vertx = require('vertx');
vertx.createHttpServer().requestHandler(function(req) {
request.response.putHeader("content-type", "text/html")
req.response.end("<html><body><h1>Hello from vert.x!
</h1></body></html>");
}).listen(8080)
var vertx = require('vertx');
vertx.createHttpServer().requestHandler(function(req) {
var file = req.path() === '/' ? 'index.html' : req.path();
req.response.sendFile('webroot/' + file);
}).listen(8080)
11. @FlorianBoulay#devoxxFr
Création d'un serveur HTTP
Node.js
var http = require("http");
var server = http.createServer(function(request, response) {
response.writeHead(200, {"Content-Type": "text/html"});
response.write("<html><body><h1>Hello from vert.x!</h1></body></html>");
response.end();
});
server.listen(8080);
var vertx = require('vertx');
vertx.createHttpServer().requestHandler(function(req) {
var file = req.path() === '/' ? 'index.html' : req.path();
req.response.sendFile('webroot/' + file);
}).listen(8080)
var http = require("http");var server = http.createServer(function(request, response) { response.writeHead(200, {"Content-Type": "text/html"}); response.write("<!DOCTYPE "html">"); response.write("<html>"); response.write("<head>"); response.write("<title>Hello World Page</title>"); response.write("</head>"); response.write("<body>"); response.write("Hello
World!"); response.write("</body>"); response.write("</html>"); response.end();}); server.listen(80);
12. @FlorianBoulay#devoxxFr
Verticle – intro
✔
Point d'entrée de l'application
✔
Plusieurs verticles sont possibles
✔
Packaging d'un ou plusieurs verticle en
module
✔
Les modules sont les « libs » de Vert.x
13. @FlorianBoulay#devoxxFr
Verticle – Thread model (1)
➢
Chaque verticle est exécuté par un unique
thread à un instant donné
➢
Programmation d'un verticle comme une
application mono threadé
Règle d'or : ne pas bloquer l'event loop
(thread exécutant un verticle)
14. @FlorianBoulay#devoxxFr
Verticle – Thread model (2)
➢
Pour appeler des librairies bloquantes, il faut
les faire s'exécuter dans un worker verticle
➢
Rend compatible toutes les librairies existantes
bloquantes
15. @FlorianBoulay#devoxxFr
Verticle – communication (1)
✔
Communications via l'event bus entre Verticle
de la même JVM ou entre JVM
✔
Différents types supportés : pour être
compatible tout langage, JSON est un bon
format
✔
Modèle proche des acteurs
✔
Communication possible vers le browser !!
16. @FlorianBoulay#devoxxFr
Verticle – communication (2)
// send a message
EventBus eb = vertx.eventBus();
eb.send("verticle.address", "hello world");
// receive a message
Handler<Message<String>> myHandler = message -> {
System.out.println("I received a message " + message.body());
message.reply("This is a reply");
};
eb.registerHandler("verticle.address", myHandler);
21. @FlorianBoulay#devoxxFr
Moteur de template – Vert.x (2)
✔
Vert.x est uniquement un client et un serveur
HTTP
✔
API de bas niveau permettant d'écrire du code
dans une réponse HTTP ou d'envoyer un fichier
statique HTML
// HTML envoyé dans la réponse
req.response()
.putHeader("content-type", "text/html")
.end("<html><body><h1>Hello from vert.x!</h1></body></html>");
// Envoi d'un fichier statique
req.response().sendFile("webroot/index.html");
29. @FlorianBoulay#devoxxFr
Class loaders – Tomcat (1)
➢
Les webapp dans Tomcat ont un unique class
loader
➢
Toutes les classes, et tous les champs statiques
sont utilisables à tout moment
➢
Simple, mais problèmes liés aux threads
possibles
30. @FlorianBoulay#devoxxFr
Class loaders – Vert.x (2)
➢
Vert.x crée un class loader par instance de
Verticle
➢
Impossible d'avoir des données calculées ou
cachées statiques (ex: LoadingCache Guava)
31. @FlorianBoulay#devoxxFr
Class loaders – Vert.x (3)
Alternatives :
✔
shared data : maps et sets globaux contenant
des data immutables
✔
Cache externe type Memcache, Redis
✔
Interroger un Verticle faisant office de cache
34. @FlorianBoulay#devoxxFr
Librairies avec IO bloquantes
➢
Les librairies avec IO bloquantes (JDBC,
Lecture de fichier…) doivent être isolées dans
des worker Verticle
➢
Certaines peuvent être remplacées, ex : JDBC
par le module Mysql Postgresql asynchrone
37. @FlorianBoulay#devoxxFr
Déploiement – Tomcat (1)
➔
Peu de typologies possibles avec Tomcat : 1
war (ou webapp explosée) sur un serveur ayant
Tomcat installé
➔
Plus scalable avec une webapp stateless
➔
Application avec état difficilement scalable
38. @FlorianBoulay#devoxxFr
Déploiement – Vert.x (2)
Possibilités au niveau le plus fin, le Verticle :
✔
Une application autonome avec tous les
Verticle en mode stateless sur chaque serveur.
✔
Chaque Verticle dans sa JVM. Communiquant
ensemble via l'event bus
✔
Un mix des 2, avec High Availibility
39. @FlorianBoulay#devoxxFr
Déploiement – Vert.x (3)
Possibilité au niveau applicatif :
✔
Une application peut être lancée en ligne de
commande avec la commande vertx
✔
Une application peut être packagé et être
lancée avec un java -jar
✔
Déploiement à partir du code
Facile
42. @FlorianBoulay#devoxxFr
Sessions
➢
Si votre appli est stateful il faudra externaliser
l'état, via un cache par exemple
➢
Si l'appli est stateless, il ne devrait pas y avoir
de problème
➢
Si il y a de l'authentification via cookie, il
faudra la recoder.