La recherche dans les données traverse plusieurs microservices


13

J'ai des données pour un certain domaine réparties entre un microservice et une base de données héritée. J'ai une recherche qui couvre les champs de la base de données héritée et microservice. Auparavant (avant la division du microservice), cela se faisait avec 1 requête SQL. Maintenant, j'ai besoin d'un appel REST et d'une requête vers une base de données héritée pour servir cette fonctionnalité de recherche. Nous parlons ici de quelques millions de lignes. Comment puis-je modéliser cela au mieux? En raison du volume de données, l'appel REST renvoie également des résultats paginés. L'approche naïve pour lancer un appel SQL et combiner et fusionner les résultats avec la réponse REST est trop lente et pas vraiment pratique.

Réponses:


21

Une fonction de recherche peut être modélisée comme un service distinct avec une responsabilité distincte des deux services que vous mentionnez. Donc, l'approche ici pourrait être de créer un nouveau service (`` recherche '') et de lui faire stocker une copie des données des deux services sous une forme facile à indexer et à rechercher, éventuellement également dénormalisée afin de donner rapidement des résultats dans le format souhaité.

Ainsi, par exemple, vous pouvez avoir la base de données SQL héritée en utilisant par exemple mySql, l'autre microservice en utilisant par exemple MongoDB, et le nouveau service de recherche en utilisant elasticsearch avec des données des deux déjà collées ensemble (dénormalisées) pour un accès plus pratique. bien sûr, les détails dépendront du type de recherches que vous devez effectuer.

Les données des deux services seraient mieux transférées de manière asynchrone à l'index de recherche via un bus d'événements tel que Kafka ou Hermes afin d'augmenter le débit et de réduire le couplage entre les services. Un changement dans l'un des deux services enverrait un événement informant le service de recherche de mettre également à jour ses données.

Bien sûr, il y a le coût d'un délai supplémentaire entre les changements dans les services et dans le service de recherche, mais comme les microservices sont généralement utilisés dans les systèmes distribués, certains retards et incohérences temporaires sont de toute façon inévitables. Avoir un service supplémentaire et utiliser un stockage supplémentaire pour une copie de données qui se trouve déjà dans les deux autres services est également un coût typique d'avoir un système hautement distribué et évolutif utilisant des microservices.


J'ai déjà pensé à créer un service distinct. La seule chose qui me gêne - créer une autre base de données juste pour la recherche (la nourrir avec élastique serait une autre option, mais nous avons des goulots d'étranglement d'infrastructure)
senseiwu

7
@zencv Malheureusement, les microservices ont des coûts comme celui-ci. Pouvoir évoluer horizontalement signifie que le couplage doit être faible, ce qui signifie qu'il y aura souvent une duplication des données. Vous obtenez également beaucoup plus de trafic réseau. L'évolutivité signifie souvent une baisse des performances par unité matérielle et le choix d'une architecture plutôt qu'une autre (par exemple, microservices ou monolithes) doit tenir compte de ce compromis.
Michał Kosmulski
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.