Soyons en contact
02-04-2017 - 07:29 — 02-04-2017 - 10:01
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:
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:
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 :