Situation actuelle
Nous mettons en œuvre (et maintenons maintenant) une application Web d'achat en ligne dans une architecture de microservices.
L'une des exigences est que l'entreprise doit être en mesure d'appliquer des règles sur ce que nos clients ajoutent à leur panier, afin de personnaliser leur expérience et la commande éventuelle. De toute évidence, un moteur de règles métier devait être mis en place, et nous avons implémenté un "microservice" spécifique pour cela (si nous pouvions encore l'appeler ainsi).
Au cours d'une année, ce moteur de règles est devenu de plus en plus complexe, nécessitant de plus en plus de données (par exemple le contenu du panier mais aussi des informations utilisateur, son rôle, ses services existants, certaines informations de facturation, etc.) pour pouvoir calculer ces règles.
Pour le moment, notre shopping-cart
microservice recueille toutes ces données à partir d'autres microservices. Même si une partie de ces données est utilisée par shopping-cart
, la plupart du temps, elle est principalement utilisée pour alimenter le moteur de règles.
De nouvelles exigences
Arrive maintenant le besoin d'autres applications / microservices pour réutiliser le moteur de règles pour des exigences similaires. Dans la situation actuelle, ils devraient donc transmettre le même type de données, appeler les mêmes microservices et constituer (presque) les mêmes ressources pour pouvoir appeler le moteur de règles.
En continuant ainsi, nous serons confrontés à plusieurs problèmes:
- tout le monde (appelant le moteur de règles) doit réimplémenter la récupération des données, même s'il n'en a pas besoin pour lui-même;
- les demandes adressées au moteur de règles sont complexes;
- en poursuivant dans cette direction, nous devrons transporter ces données tout autour du réseau pour de nombreuses demandes (pensez à μs A appelant μs B appelant le moteur de règles, mais A possède déjà certaines des données dont le moteur de règles a besoin);
shopping-cart
est devenu énorme en raison de toutes les données extraites;- J'en oublie probablement beaucoup…
Que pouvons-nous faire pour éviter ces problèmes?
Idéalement, nous éviterions d'ajouter plus de complexité au moteur de règles. Nous devons également nous assurer que cela ne devienne pas un goulot d'étranglement - par exemple, certaines données sont assez lentes à récupérer (10 s ou même plus), nous avons donc implémenté la prélecture de shopping-cart
telle sorte que les données soient plus susceptibles d'être présentes avant d'appeler les règles. moteur, et garder une expérience utilisateur acceptable.
Quelques idées
- Laissez le moteur de règles récupérer les données dont il a besoin. Cela y ajouterait encore plus de complexité, violant le principe de la responsabilité unique ( encore plus… );
- Implémentez un proxy μs avant le moteur de règles pour récupérer les données;
- Implémentez un «récupérateur de données» μs que le moteur de règles appelle pour récupérer toutes les données dont il a besoin en même temps (interrogation composite).
shopping-cart
, mais nous pourrions l'adapter assez facilement aux besoins des autres microservices (ils sont toujours liés aux utilisateurs, aux produits et aux commandes). Comme nous le voyons, ils auront besoin des mêmes données d'entrée, d'autant plus que l'entreprise est en mesure de choisir les prédicats à appliquer. Toutes les données sont fournies par d'autres microservices à l'exception du contenu du panier lui-même. La récupération des données n'est pas complexe en soi, mais elle devient complexe lorsque vous devez appeler ~ 10 autres microservices et maintenir la structure attendue par le moteur de règles.