Comment gérer les données partagées entre les microservices?
Dans mon travail, nous avons une architecture de microservice typique, mais l'un des problèmes que nous rencontrons est le partage de données entre plusieurs services. Nous avons certaines données utilisées par plusieurs services et nous devons donc partager les données entre les services. Nos bases de données sont séparées par service, pour référence.
Pour donner un exemple, nous avons un service utilisateur, un service de communication et un service de récompense. Le service utilisateur stocke toutes les données utilisateur, y compris la préférence de langue et le niveau de récompense. Le service de communication et le service de récompense ont besoin de ces données. Les données sont stockées dans le service utilisateur car elles sont fondamentalement une propriété du modèle utilisateur. Cela nous oblige à accéder aux données en dehors du microservice dans lequel elles sont stockées. Même si elles étaient stockées dans le service approprié, l'exécution d'un GET vers le modèle utilisateur devrait renvoyer ces données et nous rencontrerions donc le même problème .
À l'heure actuelle, les données sont partagées en effectuant des requêtes GET auprès des services pour ces données. Cependant, cela semble vraiment naïf, et cela a été fait en grande partie comme une réponse de "solution la plus simple".
En plus de cela, nous avons certaines exigences sur certaines des données qui nous obligent à maintenir la cohérence. Nous avons une obligation légale de communiquer aux utilisateurs dans leur langue préférée. De même, les récompenses appliquées à partir du mauvais niveau semblent être un problème (bien que ce ne soit peut-être pas un problème critique).
Comment gérons-nous correctement le partage de ces données?
Un processus de réflexion consiste à partager une connexion en lecture à la base de données. Les lectures évoluent très bien et seul le service utilisateur a besoin de mettre à jour les données. Ce serait plus rapide que d'exécuter un GET entre les services, c'est sûr. Je ne suis pas trop sûr de partager des connexions de base de données, mais peut-être juste pour les lectures, ce n'est vraiment pas si mal.
Une autre consiste à créer un service partagé qui stocke les données et les publie, mais le fait que ces données entraînent un retard de propagation semble problématique. Nous avons l'obligation de synchroniser certaines données, et tout problème de propagation peut être énorme. Il est possible que si nos données ne sont désynchronisées que pendant quelques secondes, ce n'est probablement pas un gros problème. Par exemple, si quelqu'un obtient la mauvaise récompense en raison d'un problème de timing, ce n'est peut-être pas si mal, ou la communication est dans la mauvaise langue si elle est fondamentalement correcte car elle a été envoyée. Je ne sais pas s'il y en a qui sont essentiels et qui doivent absolument être partagés.
Une troisième consiste à utiliser un service de cache partagé. Nous avons redis pour notre mise en cache afin que nous puissions potentiellement y stocker des données et uniquement interroger les services sur les échecs de cache. Cela nous permet d'avoir une recherche beaucoup plus rapide des données que nous interrogons plusieurs fois, mais je ne sais pas si nous avons besoin de tant de données dans notre cache, et si nous n'en stockons pas assez, nous pouvons manquer trop souvent.
Une autre consiste à stocker les données dans le microservice où ces données sont critiques. Le problème avec cela est que le magasin de vérité est implicitement le modèle utilisateur. Donc, si les données sont mises à jour par un appel d'API, cela mettrait à jour le microservice, mais les GET vers les données retourneraient temporairement des données obsolètes.
Je suis sûr que ce n'est pas un nouveau problème, mais nous ne sommes pas sûrs de la meilleure façon d'aborder cela. Je suis assez certain que notre solution actuelle n'est pas idéale et ne sera pas mise à l'échelle, mais je ne sais pas quelle approche est la meilleure.
L'une des solutions que j'ai vues consiste à déplacer les données partagées vers des agrégats événementiels et à les rendre accessibles au public à tout service qui a besoin de ces données. Vous pouvez utiliser Kafka ou Eventstore pour les stocker. Dans le cas de Kafka les sujets événementiels sont utilisés par un autre microservices via l'API de flux par exemple sous forme de tableaux avec la plupart des l'état réel et les nouveaux événements qui changent d'état sont également des messages de flux vers n'importe quel client, ce qui signifie qu'aucune requête directe vers un autre service, aucune duplication de données et mises à jour de données ne deviennent réactives dans un certain sens.
Mais ce modèle n'est pas familier et étranger à de nombreux programmeurs, Kafka est un service lourd et apporte une charge opérationnelle et une charge cognitive aux programmeurs, donc, comme alternative, j'aime l'idée d'une base de données partagée. exige des limitations strictes en tant que principe d'écriture unique. D'autres microservices peuvent interroger toutes les tables mais ne peuvent écrire que sur les tables qui leur appartiennent. Les autorisations de base de données peuvent aider à appliquer les règles d'accès.
Je suis moi-même assez nouveau dans le monde des microservices, alors s'il vous plaît, prenez mes mots avec une tonne de sel. :)