Architecture distribuée en micro-services

Avec une architecture interne orientée connexion, si une application transmet des données au bus, un même serveur doit rester connecté pendant toute la durée de la transaction pour les recevoir, ce qui génère une mobilisation de ressources importante. De plus, les données doivent être reçues dans le bon ordre. Si la connexion est perdue, les données doivent être réémises.

Xbus constitue un ensemble de micro-services. Le protocole de communication entre les micro-services est orienté datagramme. Il s’agit d’un protocole sans état. Ainsi, les messages entrants peuvent être traités par différents serveurs sans que ceux-ci aient besoin de connaître le parcours de chaque message.

L’architecture interne orientée datagramme a facilité la mise en place d’une architecture distribuée. Il s’agit d’un système complexe constitué d’un ensemble de serveurs, les micro-services, qui effectuent des tâches simples et très spécialisées. Chaque micro-service détient un rôle qui lui est propre. Par exemple, le micro-service broker reçoit l’ensemble des messages Xbus tandis qu’un autre micro-service les achemine jusqu’à la bonne destination. Xbus comporte également des interfaces réparties avec la base de données utilisée, PostgreSQL. Chaque micro-service est connecté à une ou plusieurs interfaces de base de données.

Le choix du protocole orienté datagramme, de l’architecture distribuée et des interfaces de base de données réparties présentent plusieurs avantages :

• La montée en charge (« scalabilité ») : l’architecture distribuée permet de répartir la charge de chaque micro-service, par exemple du broker, sur plusieurs serveurs. Cette architecture ouvre la voie à une répartition géographique sur plusieurs datacenters, par exemple pour une société ou un organisme international.
• Les performances et la robustesse du système :

  1. L’architecture interne orientée datagramme permet aux messages d’être traités par différents micro-services au sein de Xbus et reçus par ceux-ci dans le désordre. Ainsi, l’arrêt d’un serveur n’entraîne pas systématiquement l’arrêt de la transmission ni la nécessité de relancer l’envoi depuis le début. Après une coupure réseau, la reprise des échanges est facilitée lors du redémarrage du serveur grâce au protocole orienté datagramme et à la rétention des messages en base de données, qui permet de les récupérer dès qu’on en a besoin. La transmission de messages asynchrone en est favorisée.

  2. La gestion des enveloppes volumineuses est simplifiée : le choix d’un protocole orienté datagramme facilite le streaming, c’est-à-dire l’envoi de chaque message en plusieurs morceaux même s’il y a déconnexion entre l’émetteur et le bus entre les différents envois. Les performances sont ainsi meilleures.

• La mise en œuvre d’interfaces optimisées pour chaque usage : le fait que Xbus comporte des interfaces réparties avec la base de données rend les appels à celle-ci plus flexibles. Les interfaces sont orientées usage, c’est-à-dire spécifiquement adaptées à chaque cas d’utilisation. Par exemple, l’interface dédiée au stockage des enveloppes est orientée flux, ce qui lui permet de stocker très rapidement des morceaux d’enveloppe reçus dans le désordre et de les renvoyer dans le bon ordre. On peut imposer à chaque interface des contrats adaptés aux usages, par exemple des garanties facilitant la résilience du système.

NATS a été choisi comme protocole réseau pour Xbus, ce qui facilite :

• La reconnexion des différents acteurs après une coupure réseau
• La gestion des dialogues
• La répartition de charge avec clusters
• La redondance