web-dev-qa-db-fra.com

Conception de microservices de stockage de fichiers

Aperçu du problème:
Je crée une application de printemps uniquement à des fins d'apprentissage. Je voudrais créer un microservice uniquement pour les fichiers, qui:

  • au début aurait seulement deux points de terminaison de base upload/download un fichier (utilisé par d'autres microservices, pas par un utilisateur directement)
  • créez db uniquement pour ce microservice avec la table file. Au moins au début.
  • stocker des fichiers dans un cloud (par exemple Amazon S3)
  • stocker des méta-informations sur le fichier dans la table file. Par méta, je veux dire:
    • Url à déposer dans le cloud
    • Nom
    • Taille
    • Type (un répertoire ou un fichier)
    • Extension

Exemple flux:

  • un microservice A envoie une image: user_attachment.jpg aux fichiers microservice upload endpoint.
  • le serveur effectue la validation, le contrôle de sécurité, etc.
  • envoie le fichier à un stockage cloud f.e. Amazon S3
  • enregistre les méta-informations sur ce fichier dans une table locale appelée file. F.e. il ajoute: INSERT INTO file (url, name, size, type, extension) VALUES ("http://aws.Amazon.com/testapp/pictures/2018-09/picutre.jpg", "picture", 34233, "FILE", "JPG")
  • renvoyer les méta-informations au microservice A qui a initialisé l'opération de téléchargement.

Le téléchargement vers le cloud se ferait dans un fil de discussion différent, de manière asynchrone et peut-être même avec l'aide d'un courtier de messages.

Questions:

  1. Est-ce une approche propre/conforme aux modèles de conception?
  2. Qu'est-ce qui est bon/mauvais dans cette approche?
  3. Comment pourrais-je faire cela d'une meilleure façon? (je ne veux pas stocker de fichiers (contenu) sur la machine sur laquelle l'application s'exécute [localement])

Divers:
Cet exemple est simple. Je crois que la conception de projets commerciaux/grands projets pourrait avoir des hypothèses/fondements similaires. Supposons donc qu'il existe plusieurs tables dans le microservice file, et que leur structure et leur logique de microservice soient avancées.

À quoi pourrait ressembler le microservice de gestion de fichiers dans une application commerciale selon de bonnes règles de conception?

architecturemicroservicesdata
8
user3529850

Un objectif d'un service dans SOA est d'exécuter une logique qui, sinon, devrait être dupliquée parmi d'autres services. Cette logique est, à son tour, la raison de l'existence du service.

Dans votre cas, vous n'ajoutez aucune valeur via le service. Tout autre service pourrait facilement accéder directement à S3, étant donné que S3 est lui-même un service (ce n'est pas votre service, mais cela n'est pas pertinent ici).

Non seulement il n'y a pas de valeur ajoutée au service intermédiaire, mais son coût est plutôt prohibitif. Vous pouvez imaginer que vous pouvez en rédiger un en quelques heures, ce qui est vrai. Cependant, afin d'avoir quelque chose qui fonctionne de manière fiable et gère tous les cas Edge, vous devez gérer la mise en cache, la redondance, les téléchargements et la récupération interrompus, les fichiers volumineux, les délais d'attente, la force brute et DDOS, les caractères spéciaux dans les paramètres, les autorisations et l'IAM, et des dizaines d'autres jolies choses.

Par conséquent, vous êtes sur le point de passer deux ou trois semaines de développement et éventuellement une semaine de débogage (YMMV; je ne connais pas votre expérience en HTTP, SOA et la technologie que vous souhaitez utiliser) pour créer votre service, mais même si vous êtes très expérimenté, vous ne devriez pas vous attendre à y consacrer moins de deux semaines, ce qui est beaucoup).

Je voulais juste savoir comment cela se faisait dans les grands projets commerciaux.

Les entreprises paient en moyenne 700 $/jour pour un développeur très expérimenté, donc étant donné mon estimation de deux semaines, vous êtes à 7 000 $ pour une tâche. Les projets commerciaux sont une question d'argent; quand il est possible d'économiser un montant aussi petit que 7 000 $, ils le feront.

En plus de ce coût direct, il y a un coût en termes d'hébergement et de maintenance du code. Ce service devra être maintenu pendant des années, ajoutant à la facture beaucoup plus que le prix d'origine. Encore une fois, tout cet argent a été gaspillé sans comprendre clairement ce que pourrait un tel service économiser pour l'entreprise. Il n'économise pas de bande passante, ni d'autres ressources. Cela ne réduit pas le montant que l'on paiera à Amazon, alors ...

Ce n'est pas tout. Le coût de maintenance de tous les projets qui dépendent du service intermédiaire augmentera également. Si un service:

  • Doit être corrigé et le correctif nécessite un changement d'interface,
  • Doit être déplacé vers un autre emplacement, avec une modification de son URL,
  • Est en panne, nécessitant d'avoir un disjoncteur pour s'assurer que le service client ne baisse pas à son tour,
  • Est obsolète, nécessitant de migrer le client vers autre chose,

la maintenance immédiate et imprévue est requise et est généralement coûteuse également. Maintenant, il est beaucoup plus probable que ces quatre choses arrivent au service votre qu'au S3 d'Amazon. Pas parce que vous êtes un mauvais développeur, non. Mais parce que l'échelle d'Amazon est légèrement différente de celle de votre service, ce qui signifie qu'ils ont beaucoup plus de main-d'œuvre à payer pour garantir que les clients peuvent compter sur S3.

Enfin, de nombreux développeurs ont une expérience préalable avec Amazon AWS (et éventuellement S3). Cela signifie que lorsque vous embauchez un nouveau type, il peut facilement comprendre comment un service stocke des fichiers s'il utilise directement S3. Si vous ajoutez un niveau d'indirection, cet avantage est perdu. Et, plus important encore, chaque fois que quelqu'un a un problème avec le stockage, il devra se demander si le problème vient du service client, de votre intermédiaire ou de S3. Cela ajoute au temps de débogage.

Donc:

Est-ce une approche propre/conforme aux modèles de conception?

Non. Ajoutez des services lorsqu'ils ajoutent de la valeur. Ne rendez pas les choses plus complexes qu'elles ne devraient l'être (KISS) et, en particulier, n'ajoutez pas de couches qui n'apportent aucun avantage.

Qu'est-ce qui est bon/mauvais dans cette approche?

Ce qui est bien: le fait que vous fournissiez une interface beaucoup plus simple que S3. Pour les développeurs qui ne connaissent pas AWS, S3 peut être assez complexe.

Ce qui est mauvais: je l'ai déjà dit ci-dessus.

Comment pourrais-je faire cela d'une meilleure façon? (je ne veux pas stocker de fichiers (contenu) sur la machine sur laquelle l'application s'exécute [localement])

En appelant directement S3.

10
Arseni Mourzenko

Explication étonnante d'Arseni.

Un avantage que je vois de ce service intermédiaire est qu'il offre à l'appelant (micro-service ou utilisateur final) la possibilité de choisir le stockage à utiliser pour son utilisation. Je ne sais pas à quel point c'est une suggestion pratique, mais j'enregistre souvent mon document important auprès de plusieurs fournisseurs de stockage cloud, de peur de le perdre sur un seul. Ainsi, ce service intermédiaire pourrait offrir la possibilité de choisir le stockage que l'appelant souhaite utiliser (facultativement) ou de le définir par défaut sur le moins cher qui convient à l'objectif de l'appelant.

1
user1833058