TL; DR: Si vous analysez une architecture de microservices donnée et que vous fusionnez les services A et B pour éviter A ne fonctionne pas, car B est tombé en panne (car il dépend fortement de B , et par spécification de projet A ne peut pas terminer demande si B est défectueux), avec suffisamment d'itérations, n'allez-vous pas simplement vous retrouver avec une architecture monolithique?
C'est une question qui a été soulevée récemment dans notre entreprise et j'ai bien peur qu'ils prennent une décision à courte vue.
Résumé de l'architecture:
- Il s'agit de notre premier système utilisant l'architecture microservice
- Nous avons une quantité N de microservices (en particulier, chaque microservice est un JAR exécuté dans un pod kubernetes dans un cluster)
- Chaque JAR expose un service unique (par exemple auth , users , images ...) via une API HTTP
- 99% de nos services nécessitent une autorisation utilisateur, mais pas d'authentification (cela se fait sur une autre couche, notre service suppose que si une requête l'atteint, l'en-tête de la requête contient un jeton utilisateur valide
- Pour traduire un jeton utilisateur en quelque chose de tangible (par exemple, des informations utilisateur), nous adressons une demande au service users
- Actuellement, chaque service effectue cette opération pour vérifier si l'utilisateur répond à certains critères spécifiques au service.
Maintenant, lors d'une réunion, plusieurs développeurs expérimentés ont fait part de leur inquiétude selon laquelle si les utilisateurs échouent pour une raison quelconque (pas nécessairement quelque chose de logiciel, supposons simplement que les machines allouées pour ces services sont défectueuses) , tout cessera de fonctionner, ce qui en fait (à leur avis) une architecture quasi monolithique avec des étapes supplémentaires. Leur suggestion pour éviter cela est de convertir le service users en une bibliothèque statique et d'ajouter comme dépendance à tous les services qui en ont besoin, de sorte que chaque service contient cette fonctionnalité en soi plutôt que de dépendre d'une API distante.
Mais n'est-ce pas plus un problème de spécification que d'architecture? Ce n'est pas comme si l'API images (techniquement parlant) ne peut pas fonctionner sans utilisateurs , c'est juste que d'après les spécifications actuelles du projet ce n'est pas spécifié c'est censé le faire dans ce cas, donc ça échoue simplement comme si le service lui-même était défectueux .
La raison pour laquelle je pense personnellement qu'il s'agit d'une décision à courte vue est que l'on pourrait soutenir que tout type de communication entre les microservices peut être considéré comme un tel risque. Ce cas est simplement un point d'échec potentiel très évident, et la première itération de l'analyse «ce qui peut casser». Avec suffisamment de réflexion, tout point de terminaison utilisé par de nombreux services peut être traité de la même manière s'il n'y a pas de "plan B" spécifié (par exemple, au cas où une image ne peut pas être extraite du service image utiliser une image d'espace réservé prédéfinie)
3 Réponses :
N'ayant aucune compréhension du cas d'utilisation métier en question, je suis enclin à être d'accord avec vous. Je pense que le problème en question peut être atténué de la manière suivante:
Essayez de réduire la charge sur le service en mettant la réponse en cache dans un système de mise en cache centralisé accessible aux services individuels. Gardez le cache à jour en utilisant la recherche d'événements et la capture des données de modification (de préférence basée sur les journaux)
Le cas échéant, explorez la possibilité d'introduire des vues matérialisées dans la base de données de service individuelle avec une vue matérialisée et une source d'événements et une capture de données de modification (de préférence basée sur les journaux)
Explorez la possibilité d'utiliser une réponse de secours avec disjoncteur. Notez que si un utilisateur gratuit souhaite regarder une vidéo premium lorsque le service utilisateur est en panne, l'entreprise peut souhaiter autoriser l'utilisateur gratuit à regarder la vidéo plutôt que de restreindre un utilisateur premium.
J'ai 2 commentaires sur votre sujet:
Re: spécification. Vous définissez un comportement «alternatif» pour une situation où une chose particulière échoue.
Exemple : le service d'images demande des informations sur l'auteur au service des utilisateurs pour afficher des informations sur la personne qui a téléchargé l'image.
Je crois comprendre que vous avez choisi d'échouer la demande d'images si le service d'images n'est pas en mesure d'obtenir des informations sur l'auteur. Vous auriez pu choisir d'afficher le nom de l'auteur sous la forme "N / A" ou simplement de ne pas afficher les informations utilisateur avec l'image si le service utilisateur n'est pas disponible.
Vous définissez le chemin alternatif. Maintenant, bien sûr, il y a des avantages et des inconvénients pour chaque manière et dépend vraiment d'un scénario.
Re: architecture.
À mon humble avis, je pense que l'un des avantages de l'architecture Microservices est l'isolement des services individuels. Je ne connais pas votre architecture actuelle, mais dans les microservices traditionnels, je m'attendrais à ce que le service utilisateur ait un stockage isolé et n'expose que l'interface HTTP (ou RPC, etc.) pour que d'autres services obtiennent ces informations.
Si vous commencez à l'utiliser comme bibliothèque, vous suivrez le chemin où, dès que vous modifiez votre bibliothèque de "service utilisateur", vous devrez la mettre à niveau pour tous les services, sinon les différences de schéma ou de logique métier jouera avec le temps. Dans le pire des cas, créer une dépendance séquentielle pour la mise à niveau ...
Je pense que vous devez juste comprendre que votre service utilisateur est une partie essentielle de votre architecture et vraiment faire des efforts pour le rendre hautement disponible, c'est-à-dire vous assurer qu'il est déployé au moins sur quelques hôtes différents (ou même des régions si vous soutenir)
C'est assez typique pour une décision architecturale quand il y a un compromis qui peut potentiellement améliorer certains attributs de qualité par les coûts d'un ou plusieurs autres attributs de qualité. Dans votre cas, la décision de convertir le service des utilisateurs en bibliothèque améliorera la fiabilité, mais la question est de savoir quels attributs de qualité peuvent être affectés par cela. Il n'y a pas beaucoup d'informations sur ce service mais spéculons. L'une des bonnes propriétés du style micro-services est sa capacité à maintenir un cycle de vie de développement isolé pour les services. Il s'agit d'un microservice, le composant utilisateurs peut être fourni indépendamment des autres composants, à moins que des changements majeurs ne soient apportés aux marchés publics. Par exemple, les correctifs ou améliorations internes peuvent être fournis avec la nouvelle version du service et devraient devenir disponibles pour d'autres services sans toucher au cycle de vie des versions des autres services. Avec une bibliothèque, la situation devient un peu différente - afin de publier un correctif critique (ou non critique dans la bibliothèque), vous devrez mettre à jour tous les composants dépendant de cette bibliothèque. Même en considérant que ce processus est automatisé, il peut imposer des problèmes opérationnels supplémentaires liés aux questions sur la fréquence à laquelle cela peut se produire, si ce processus garantit un temps d'arrêt nul, comment gérer les scénarios de défaillance lorsque certaines mises à jour de service échouent alors que certains services sont déjà mis à jour. Un autre aspect est l'évolutivité - étant un service, le composant des utilisateurs peut être mis à l'échelle indépendamment en ce qui concerne la charge typique générée par tous ses consommateurs. Avec la bibliothèque, il est supposé qu'elle devrait partager les ressources avec d'autres composants et, pire encore, elle devrait être capable de gérer une charge égale à la charge d'un composant avec lequel la bibliothèque est utilisée sans possibilité de configurer la consommation de ressources indépendamment. La sécurité peut également être un aspect qui nécessite une attention supplémentaire en supposant que le service des utilisateurs devrait utiliser une source de données qui peut stocker des informations sensibles avec la bibliothèque, tous les autres services devraient être autorisés à accéder à cette source de données potentiellement compromettant la sécurité des données. D'un autre côté, la fiabilité peut être obtenue par la redondance des sous-composants de service des utilisateurs, par exemple en ayant plusieurs instances du service et de sa source de données.
Pour revenir à la déclaration initiale, vous avez une sorte de compromis et la décision dépend des attributs de qualité les plus critiques pour l'ensemble du système. S'il est difficile d'obtenir une disponibilité de service élevée pour les utilisateurs en raison de certaines limitations ou des coûts élevés de ce processus et que c'est un scénario relativement rare où cette fonctionnalité peut être mise à jour indépendamment, il vaut la peine d'envisager la migration vers la bibliothèque ou si ce processus est affecté par les attributs de qualité sont cruciaux pour le architecture système, cela peut indiquer qu'il vaut la peine d'accorder plus d'attention aux tactiques d'amélioration de la disponibilité des services des utilisateurs au lieu de compromettre les attributs de qualité obtenus par le style des microservices.
En guise de remarque sur la spécification par rapport à la question de l'architecture. Je présume que vous entendez par spécification des exigences. Une architecture est toujours motivée par des exigences et elles concernent l'architecture donc c'est de toute façon un problème architectural.