Requête JOIN de microservice
Je sais que cette question a été soulevée par de nombreuses personnes ici et sur Internet, mais je n'ai pas réussi à trouver une explication très claire sur la façon d'effectuer des requêtes couvrant plusieurs microservices.
Imaginez que j'ai 2 services, n est gestion des relations avec les utilisateurs, et n est responsable de articles de blog. Si je veux juste obtenir le 20 derniersmessages, je dois interroger la base de données des relations pour TOUS mes amis/suit. Cela pourrait être un mille entrées. Ensuite, je transmettez-les au service de blog et cela renvoie 20 articles de blog. Ensuite, je fais défiler un peu et (imaginez que je ne cache pas) cette opération est répétée. C'est un exagéré à mon avis.
La plupart des réponses à ces questions indiquent que la séparation des domaines n'est pas bonne et que si ces deux services sont toujours utilisés ensemble, ils appartiennent à un seul service. C'est également inacceptable pour moi parce que la plupart d'entre nous écrivent simplement nos programmes à la manière d'un microservice , mais toutes les fonctionnalités sont en quelque sorte cohérentes . Donc au final, si j'avais de nombreuses jointures, je construirais toujours des monolithes? Ou devrais-je accepter l'inefficacité si je vais sur le chemin du microservice?
"la plupart d'entre nous écrivent simplement nos programmes de manière microservice". Soyez prudent avec cette affirmation, car ce qu'est la "voie du microservice" n'est certainement pas une voie unique et je dirais que plusieurs fois c'est mal fait. La raison en est que de nombreux développeurs créent des microservices basés sur des entités: utilisateur, blog, commentaire, catégorie, paiement, etc. Ce type de conception crée un réseau de relations où tous les services ont des dépendances sur tous les autres services et les exigences de création de requêtes avec des jointures sur les données de plusieurs services apparaissent.
Je dirais donc que la première chose que vous devriez faire est d'accepter que vos limites de service sont probablement fausses. Un service doit être en mesure d'atteindre ses objectifs commerciaux sans nécessiter de données provenant d'autres services. J'ai le sentiment fort que c'est votre situation. Cela signifie que vous devriez pouvoir effectuer une requête dans un seul service et renvoyer une liste d'ID de résultat. Utilisez ensuite ces identifiants pour interroger un autre ou plusieurs services afin de créer les informations complètes qui doivent être retournées à l'utilisateur (par exemple, le nom d'utilisateur, la réputation de l'utilisateur et le texte de l'article de blog vivront probablement dans 3 services différents) .
Maintenant, si vous êtes sûr à 100% que vos limites de service sont correctes et que vous trouvez toujours des situations dans lesquelles vous devez effectuer des requêtes sur plusieurs services, vous avez deux options:
- Créer un moteur de recherche: il peut s'agir de lancer plusieurs recherches en parallèle à plusieurs services et de combiner les résultats, ou d'effectuer une recherche dans un service, puis d'appeler d'autres services pour filtrer les résultats du précédent.
- Utilisez un service de recherche: ce service regroupe les données de plusieurs services et les indexe de manière à permettre des recherches efficaces. Cela est utile si vous souhaitez effectuer des requêtes complexes comme la recherche en texte intégral sur tous les blogs et commentaires, les recherches basées sur plusieurs catégories ou balises, les utilisateurs, etc. Ces services trient normalement les résultats en fonction du% de correspondance. Si les recherches sont complexes, il est préférable d'utiliser un service tiers et de ne pas essayer de créer le vôtre.
Concernant votre dernière question "Ou devrais-je accepter l'inefficacité si je vais sur le chemin du microservice?" Je dirais qu'une application de microservices correctement conçue ne devrait pas être plus inefficace qu'un monolithe, compte tenu de "l'efficacité" non seulement de la vitesse d'une seule requête, mais d'une propriété de l'application entière (performances, stabilité, maintenabilité, etc.). Si votre conception de microservices n'est pas meilleure que votre conception de monolithe, optez certainement pour le monolithe.
Si vous avez besoin d'une jointure sur les données de deux microservices, votre conception de microservices n'est tout simplement pas correcte. Les données qui fonctionnent logiquement ensemble dans votre système appartiennent au même microservice.
Une autre alternative consiste à dupliquer les données du microservice utilisateur dans d'autres microservices selon les besoins à l'aide d'événements, par exemple. les relations en postes (mais pas les adresses) et les adresses en facturation (mais pas les relations). Notez que de cette façon, vous pouvez vous retrouver avec une grosse boule de boue (tm) distribuée assez rapidement.
Définissez une base de données de vues, qui est une réplique en lecture seule conçue pour prendre en charge cette requête. L'application maintient la réplique à jour en s'abonnant aux événements de domaine publiés par le service propriétaire des données.