Netty (5/6) : Étude de cas ; existant

[Laurent Caillette]

Nous avons vu les aspects principaux du modèle de programmation de
Netty, et quelques produits basés sur ce socle technique. Maintenant
que se passe-t-il quand on utilise directement Netty ?


== Étude de cas : tout remplacer par Netty

Nous parlons d'un projet utilisant la quincaillerie suivante :
- Simple (serveur HTTP embarqué ultra-léger).
- Apache HTTP Client notamment pour les tests.
- Jetty et CometD (serveur HTTP et WebSockets).

Ce projet commence à voir le bout du tunnel de la migration vers
Netty. À l'heure actuelle :
- Le code critique repose sur Netty.
- L'application est de nouveau déployable sur l'infrastructure de
production, sans perte de fonctionnalité.
- Les tests de charge montrent une nette amélioration des performances.



=== L'existant

Le projet à migrer s'apparente à une place de marché électronique pour
une centaine de participants. L'application est mono-serveur, et les
clients sont en pur Java. Les clients téléchargent la dernière version
de leur code auprès du serveur. Le serveur reçoit et émet des
commandes de mise à jour via le protocole WebSocket. L'architecture du
serveur s'inspire du modèle de programmation "LMAX"
http://martinfowler.com/articles/lmax.html
: au cours d'une journée, l'état du serveur est défini par la
succession des commandes reçues. Toutes les données utilisées lors des
traitements résident en mémoire vive, donc il n'y a pas de latence
liée à l'accès à une base de données. De ce fait il est possible de
sérialiser tous les traitements, et de s'affranchir des problèmes de
concurrence d'accès.

L'architecture LMAX vise à utiliser la puissance de la machine jusqu'à
la dernière goutte. Avec un serveur haut-de-gamme et une carte réseau
qui contourne la pile TCP du système, l'architecture LMAX permet de
traiter plusieurs millions de messages par seconde. Même sans utiliser
tous leurs trucs, en s'inspirant de leur solution on peut
raisonnablement espérer consommer un millier de message par seconde
avec un seul serveur.

L'architecture LMAX comporte un autre attrait rarement évoqué : le
code applicatif est beaucoup plus simple, puisqu'il ne fait rien qui
touche aux entrées-sorties et ne gère pas la concurrence d'accès. Par
contre il faut réinventer quelques habitudes de programmation.



=== Simple

"Simple"
http://www.simpleframework.org
est une bibliothèque Java pour embarquer un serveur HTTP ultra léger
et performant, qui supporte notamment un rendu asynchrone. Simple
prétend supporter des charges un peu plus élevées que Jetty ou Tomcat.
Le code et l'interface programmatique de Simple sont une merveille de
concision. Simple fait parfaitement ce qu'il prétend faire. Par
contre, si on veut des WebSockets ou un client HTTP, là il faut
envisager d'autres solutions.

Simple est embarqué dans le client Java de l'application à migrer. Il
fournit une façade HTTP pour l'automatisation de certains traitements
par l'utilisateur.


=== Apache HTTP Client

"Apache HTTP Client"
https://hc.apache.org/httpcomponents-client-4.5.x
est un des sous-projets de Apache HTTP Commons. HTTP Commons est un
ensemble de bibliothèques pour faire tout ce qui est humainement
concevable à partir des standards autour de HTTP. Apache HTTP Client
est utilisé principalement dans des tests, pour torturer le serveur
HTTP par exemple.

L'interface programmatique bloquante de HTTP Client commence à dater.
Le principe reste celui du conteneur qui ne donne qu'un accès très
limité à sa cinématique interne ; en comparaison Netty donne une
impression de liberté très appréciable. Apache HTTP Client ne fournit
pas de client WebSocket.

Il faut mentionner le sous-projet "HTTP Async Client"
https://hc.apache.org/httpcomponents-asyncclient-4.1.x
qui fournit comme son nom l'indique des primitives asynchrones.


=== Jetty

"Jetty"
http://www.eclipse.org/jetty
a longtemps été considéré comme le conteneur Web rapide et léger
ridiculisant des poids lourds comme WebLogic et Tomcat. De plus Jetty
a été le premier socle technique à fournir un client HTTP asynchrone.

Jetty est un bon produit, mais sa simplicité initiale s'est évanouie
avec le support des dernières versions de la norme des Servlets.

Jetty fournit un client HTTP asynchrone, réutilisable par les
WebSockets. Malheureusement il ne supporte pas les proxies HTTP, ce
qui est rédhibitoire compte tenu du type de clients auquel s'adresse
le projet de notre étude de cas.


=== CometD

"CometD"
https://cometd.org
est une implantation du protocole Bayeux pour pousser des messages du
serveur vers le client. Bayeux décrit un mécanisme de
publication-abonnement hiérarchique et impose un format de messages
basé sur JSON. CometD supporte plusieurs types de transport, dont les
WebSockets. Jetty est le conteneur recommandé pour CometD. CometD
fournit un client Java et un client JavaScript.

CometD fait ce qu'il prétend faire, mais s'avère très encombrant si on
souhaite :
- Des WebSockets pour le transport et rien d'autre.
- Maîtriser la sérialisation des données transmises.
- Supporter l'authentification à 2 facteurs.


Dans le prochain et dernier épisode, nous verrons le bilan d'un
passage au tout-Netty.