Vert.x

Caractéristiques

Vert.x se distingue par un modèle simple de simultanéité, il permet une réécriture d'un code comme une application mono-thread. Chaque thread représente une boucle événementielle utilisable par le serveur.


Architecture de Vert.x

Verticle

  • Une entité propre

  • Une unité de déploiement de Vert.x

  • Exécute un traitement isolé, déclenché à la réception d'un évènement

  • 1 Verticle est :

    • Les paquets de code qui transitent et qui sont utilisés dans Vert.x sont appelés Verticles. Un Verticle peut être écrit en plusieurs langages : Javascript, Ruby, Java, Groovy ou Python. Il exécute un traitement isolé et est déclenché lorsqu’il reçoit un évènement. Deux verticles ne se connaissent pas mutuellement, elles sont toutes les deux isolées, ce qui veut dire que chacune ne connaisse pas le code de l'autre, nous allons voir comment elles se communiquent ensemble.

    Vert.x Instance

  • Verticles : Isolation des classloaders et non-partage des variables globales

  • Les Verticles communiquent via un système de messages

  • Ecrire toute votre code dans une seule thread

  • Enlève des problèmes de programmation concurrente

    • Les verticles circulent à l’intérieur d’une instance Vert.x. Une instance Vert.x s’exécute dans sa propre instance de la JVM. Il peut y avoir beaucoup de verticles exécutant dans une instance Vert.x unique à un moment donné. Vert.x assure que chaque verticle est exécuté par un seul et unique thread, il n’y a pas d’échanges de verticles donc pas de souci de concurrence, ça change pas mal de choses pour un développeur Java ou Ruby, ce qui veut dire qu'il y a moins de problèmes à gérer.

    Event Loop

  • En attente pour des évènements puis les envoie aux handlers

  • Chaque verticle est assigné à un event loop

    • Règle d'or : NE JAMAIS BLOQUER UN EVENT LOOP !

    Dans une instance Vert.x, il y a une gestion d'un petit nombre de threads, correspondant au nombre de threads aux noyaux disponibles sur le serveur. Nous appelons ces threads des events loops

    Event Bus

  • Caractérise le système nerveux de Vert.x

  • Permet aux verticles de communiquer entre eux

  • Il y a 3 types d’évènements

    • Le bus événementiel (Event bus), représenté comme un tunnel, est le système de communication principal pour les verticles, en effet, chaque verticle étant isolée et n'ayant pas connaissance de l'existence des autres, utilise leur communication via un event bus.

    Que nous somems dans une même instance vert.x ou dans une autre, les verticles peuvent communiquer entre eux vers l'aide de messages via un event bus. La communication par messages implique au système une montée en charge sur les différents coeurs disponibles tout en écrivant le code des verticles en mono-thread.

    Workers

  • Représente une autre forme de Verticle

  • Permet de faire des traitements longs et bloquants

  • Worker verticles ne sont pas assignés à un event loop !

    • Malheureusement, nous ne pouvons pas tout rendre 100% asynchrone, pour exemple dans un verticle nous devons jamais bloquer un event loop.

    Parfois, nous avons besoin de faire des traitements qui peuvent être bloquants.
    Exemple : Lorsque nous faisons une connexion à une base de données comme JDBC ou encore faire un simple serveur web qui ne nécessite pas beaucoup de connexions, ces traitements vont bloquer notre event loop.

    Vert.x propose de créer des verticles qui sont des workers, un worker est juste une pool de threads. Dans un worker, il est accepté de faire des opérations qui peuvent bloquer la thread.

    Modules


    Exemple de nommage des modules

  • Vert.x modulaire

  • Paquet de verticles en des modules ré-utilisables

  • Similaire au système de module de Node.js

  • Vert.x dispose d’une liste de modules Vert.x

    • Vert.x a l'utilité d'être également modulaire. À l’instar de node.js, vos projets sont exportables sous forme de modules, appellés mods. Ces modules deviennent alors utilisables par d’autres projets Vert.x, ils peuvent donc communiquer ensemble via un mécanisme d’event bus, ils deviennent alors des busmods.

    Le système d'éventbus est partout dans la vision de Vert.x, ainsi il permet une communication entre les différents mods mais il permet aussi aux différents verticles de communiquer lorsqu'ils sont isolés. Ce qui caractérise les projets Vert.x scalables.