java - 微服务架构下跨服务查询的聚合有什么好的方案？

Question

微服务架构中，每个服务都有自己的独立数据库。然而现在有个需求，需要生成一张实时的报表，该报表包含两个服务的数据。如服务A，服务B。B中仅包含A的主键id作为关联。而此报表的搜索条件包含A服务实体中的字段也...

迷茫 · Answer

Laxatif

S'il s'agit de données commerciales en ligne (OLTP), la première option est la pratique standard des microservices. Si de telles requêtes connexes doivent être effectuées fréquemment en ligne, cela signifie que le couplage des deux services (et de leurs deux bibliothèques) est très sérieux, alors pourquoi s'embêter à les séparer en premier lieu ?

S'il s'agit d'un rapport d'analyse, il relève de la catégorie OLAP. La solution 2 est en effet une solution souhaitable. Si vous pensez que l'utilisation d'un moteur de recherche est excessive, vous pouvez également essayer d'effectuer diverses opérations d'analyse de rapports sur la base de données esclave. Par exemple, la base de données A en ligne et la base de données B sont synchronisées avec une base de données en lecture seule en temps réel, puis. dans la base de données en lecture seule, JOIN se fait en une seule fois.

天蓬老师 · Answer

L'un des principes de conception des microservices est de séparer les services qui ne sont pas liés à l'entreprise en services distincts. Il y a un chevauchement entre vos activités.

PHP中文网 · Answer

En fait, ce genre de problème est très courant dans les microservices. Par exemple, vous devez interroger la commande via certaines informations sur le produit. La commande et le produit appartiennent respectivement à deux microservices. ce n'est pas seulement vos deux solutions, mais aussi Oui

Placez l'agrégation de données dans l'entrepôt de données, agrégez les données en A et B en temps réel dans une autre bibliothèque (pas nécessairement mysql, cela peut aussi être Hbase), et les données extraites du rapport sont extraites de l'entrepôt de données Allez sur
Lors de la conception de la table, il convient de redondant certains champs Comme vous l'avez dit, certains champs de A peuvent être redondants de manière prévisible sur B

La méthode 1 présente un défaut très fatal. Une fois la pagination impliquée, cette méthode n'est certainement pas réalisable. La solution à adopter dépend de l'ordre de grandeur de vos données, si la quantité de données correspondante n'est pas très importante, vous. peut utiliser la méthode 1. Si la vitesse est lente, vous pouvez ouvrir quelques threads supplémentaires pour récupérer les données correspondantes par lots (il y a trop d'identifiants, extrayez-les par lots et les requêtes par lots sont des solutions efficaces qui peuvent réduire les délais d'attente et le temps) ; si la quantité de données est très importante. Il est recommandé d'utiliser un entrepôt de données. Le principal avantage de l'utilisation d'un entrepôt de données est qu'il n'exercera pas de pression sur la base de données principale, car la génération de tables agrégées peut être obtenue via. Binlog ; car le rapport appartient toujours à la catégorie des données hors ligne, s'il est vraiment nécessaire. Comme la requête de commande, qui est en temps réel et très efficace, elle est également accompagnée de l'état de la table, et il y a tellement de recherches conditions, le moteur de recherche est donc un bon choix
Vous pouvez donc utiliser la méthode 1 et la méthode 3 en fonction de la situation réelle

黄舟 · Answer

Des exigences telles que la génération de rapports ne doivent pas être placées dans les systèmes de bases de données d'entreprise. Vous pouvez créer un ensemble de bibliothèques d'agrégation Otter sur le backend pour synchroniser les données de plusieurs services en temps réel. .Comment jouer