Microservices dans TRQL

Dans TRQL — prononcez TRanQuiiiL — j'ai mis au point l'embryon d'une architecture à base de microservices. Cette architecture me semblait nécessaire pour répondre au découplage indispensable entre les tâches qui pouvaient être différées dans le temps et l'immédiateté requise par un site web performant. Par exemple, il n'est pas toujours indispensable d'attendre la connexion à un serveur SMTP pour l'envoi d'un mail : il est tout à fait envisageable de simplement enregistrer la demande d'envoi et de l'envoyer en fait plus tard, de manière groupée par exemple … une seule connexion avec plusieurs envois. Dans ce cas précis, qui n'est qu'un exemple parmi beaucoup d'autres, on peut donc mettre en place une structure distribuée fonctionnant sur la base de services qui feront le boulot quand ce sera nécessaire, sans impacter la performance du système général.

C'est ce qui a été mis en place dans le système de pulses de TRQL. Ce système fonctionne donc comme une série de requêtes : à chaque requête différente, un service différent est invoqué tandis que le centre de requêtes, lui, est le même pour tout le monde.

Voici quelques exemples de pareils services dans le cas de TRQL:

• Envoi de mail
• Demande de backup
• Demande de création d'archive (.zip)
• Demande de création de la structure standard d'un site web
• Envoi de lettres de rappel
• Emailing ou Newsletter
• Traitement d'erreur ou d'exception
• Nouvelles données requérant de nouvelles statistiques
• Échange de données entre sites (impliquant de larges volumes)
• Synchronisation de données entre différents systèmes
• Opérations nécessitant des calculs intensifs
• …

Toutes ces opérations sont donc envoyées à un même centre de traitement, chacune avec un identifiant propre et un type particulier : le type servant à identifier le service qui doit être invoqué (ex: envoi de mail = MAIL_TYPE), l'identifiant propre servant à informer le client du résultat de sa requête (mode asynchrone). En sus du type et de l'identifiant, un troisième paramètre est passé qui est un membre cargo qui peut contenir tout ce que le service à invoquer attend (ex: dans le cas d'un mail, le sujet, le corps du texte, le destinataire, etc.). Cette structure de paramétrage est commune à tous les services sans distinction et c'est cette structure commune — surtout le membre cargo — qui permet d'étendre le système au fur et à mesure des besoins de TRQL. Pour être clair, le centre de requêtes se fiche complètement du membre cargo, mais certainement pas le service invoqué ! On a donc affaire à une double forme de responsabilité : le client doit envoyer au centre de requêtes un type de service et son identifiant (en fait un identifiant et un moyen de callback) — voilà ce qui est de sa responsabilité pour dialoguer avec le centre de requêtes; ensuite il doit fournir le membre cargo dont le service fera usage lorsque ce dernier sera invoqué par le centre de requêtes (une forme de message broker).

Ainsi que je l'ai indiqué, cette architecture se prête extrêmement bien à toute évolution future : il est aisé de l'étendre à de nouveaux services. TRQL est ainsi passé sans refonte du système de 5 services de base à 62 services aujourd'hui sans que ces services aient été imaginés dès les premières lignes de programmation. Même l'invocation du service de requêtes peut être revu sans nécessiter la refonte du système.

Dans cette architecture il est important de comprendre que:

• une requête peut donner lieu à une réponse ou non
• une requête faite avant une autre ne sera pas nécessairement invoquée selon cet ordre
• toutes les requêtes sont faites avec la même structure mais le membre cargo offre tout le découplage nécessaire entre tous les services (il est différent de service à service)
• les requêtes en série doivent être lancées comme une chaîne de requêtes (un tableau de requêtes dont les résultats eux-mêmes sont enchaînés)
• chaque service peut être écrit dans le langage qui se prête le mieux à son implémentation (seule importe sa capacité à dialoguer avec ce qui l'invoque et ce à quoi il doit envoyer sa réponse)

L'architecture en question répond donc à nos exigences fondamentales que sont la performance et la flexibilité via découplage et extensibilité. Notez au passage que par découplage il faut envisager plusieurs points cruciaux :

• Découplage entre l'implémentation du service et son utilisation : une implémentation physique en Java et une utilisation en PHP, une implémentation en janvier et une utilisation en février seulement, une implémentation par l'équipe A et une utilisation par l'équipe B, une implémentation sur un serveur X et une utilisation au départ des serveurs Y et Z, etc.
• Découplage entre besoin et solution : des solutions peuvent être développées — et cela choquera sans doute les fondamentalistes de l'Agilité — avant que les besoins ne soient exprimés. Ce qui marche aussi dans l'autre sens avec des appels à des services qui ne sont pas encore développés (ce qui n'implique que la conscience que la requête n'aura pas de réponse … et de pouvoir en tenir compte sans que cela ne provoque de crash chez l'appelant)