Transfert de fichiers / données volumineux dans une architecture de microservice

Mon entreprise travaille actuellement à l'adoption d'une architecture de microservices mais nous rencontrons des difficultés croissantes (choc!) En cours de route. L'un des principaux points de discorde auquel nous sommes confrontés est de savoir comment communiquer de grandes quantités de données entre nos différents services.

Comme arrière-plan, nous avons un magasin de documents qui sert de référentiel pour tout document que nous pourrions avoir besoin de gérer dans toute l'entreprise. L'interaction avec ledit magasin se fait via un service qui fournit à un client un identifiant unique et un emplacement pour diffuser le document. Il est possible d'accéder ultérieurement à l'emplacement du document via une recherche avec l'ID fourni.

Le problème est le suivant: est-il logique que tous nos microservices acceptent cet ID unique dans le cadre de leur API dans le but d'interagir avec des documents ou non? Pour moi, cela semble intrinsèquement mauvais - les services ne sont plus indépendants et dépendent du service du magasin de documents. Bien que je reconnaisse que cela pourrait simplifier la conception de l'API et peut-être même avoir des gains de performances, le couplage résultant plus que contrebalance les avantages.

Quelqu'un sait-il comment les licornes arc-en-ciel (Netflix, Amazon, Google, etc.) gèrent de gros fichiers / échanges de données entre leurs services?

Quelqu'un sait-il comment les licornes arc-en-ciel (Netflix, Amazon, Google, etc.) gèrent de gros fichiers / échanges de données entre leurs services?

Malheureusement, je ne sais pas comment ils gèrent ces problèmes.

Le problème est le suivant: est-il logique que tous nos microservices acceptent cet ID unique dans le cadre de leur API dans le but d'interagir avec des documents ou non?

Il viole le principe de responsabilité unique, qui devrait être intrinsèquement dans l'architecture de votre microservice. Un microservice - logiquement un, plusieurs instances physiques représentant un seul - devrait traiter d'un seul sujet .

Dans le cas de votre magasin de documents, vous avez un point, où vont toutes les requêtes de documents (bien sûr, vous pouvez diviser cette unité logique en plusieurs magasins de documents pour plusieurs types de documents).

• Si votre "application" a besoin de travailler sur un document, elle demande au microservice respectif et traite ses résultats.

• Si un autre service a besoin d'un document réel ou de parties de celui-ci, il doit demander au service de documentation.

L'un des principaux points de discorde auquel nous sommes confrontés est de savoir comment communiquer de grandes quantités de données entre nos différents services.

Il s'agit d'un problème architectural:

1. Réduisez la nécessité de transférer de grandes quantités de données

   Idéalement, chaque service possède toutes ses données et n'a besoin d'aucun transfert pour répondre simplement aux demandes. Dans le prolongement de cette idée - si vous avez besoin de transférer des données, pensez à la redondance (* d'une manière positive_): Est-il logique d'avoir des données redondantes à de nombreux endroits (là où elles sont nécessaires)? Pensez aux incohérences possibles qui pourraient nuire à vos processus. Il n'y a pas de transfert plus rapide que réellement aucun .

2. Diminuez la taille des données elles-mêmes

   Pensez à la façon dont vous pourriez compresser vos données: à partir d'algorithmes de compression réels jusqu'aux structures de données intelligentes . Moins vous passez de fil, plus vous êtes rapide.

Si l'ID renvoyé par votre magasin de documents est le moyen de référencer des documents dans tout le système, il est logique que tous les services acceptent cet `` ID de document '' sur leur API lorsque le service a besoin de savoir avec quel document il doit travailler.

Cela ne crée pas nécessairement un couplage plus étroit entre les services que nécessaire. Les services qui ont besoin d'accéder à des documents doivent de toute façon accéder au service de stockage de documents et ils ont besoin de cet ID pour indiquer au magasin à quel document accéder.
Les services qui n'accèdent pas directement aux documents peuvent avoir besoin de transmettre l'ID de document, mais pour ces services, il s'agirait simplement d'une chaîne arbitraire qui ne crée pas de dépendance.

Personnellement, je préfère ne pas utiliser un service de stockage de documents et un identifiant de document distincts, mais une URL pour accéder aux documents (avec une authentification d'en-tête appropriée). Avec cette approche, vous n'aurez pas besoin d'autres services pour s'appuyer sur le service de documents, mais il pourrait simplement utiliser l'URL complète pour accéder au document. lorsque le stockage augmente et fournissez l'URL.

Cependant, vous pourriez avoir besoin d'un ou de plusieurs services pour télécharger un document et obtenir son URL.

Quelqu'un sait-il comment les licornes arc-en-ciel (Netflix, Amazon, Google, etc.) gèrent de gros fichiers / échanges de données entre leurs services?

Vérifiez les spécifications de l'API Amazon S3 REST, apparemment, elles renvoient l'objet complet en octets. Semble pas beaucoup d'options si vous concevez un microservice. Lien vers le format de réponse Amazon S3