Architecture d'une application Web basée sur un microservice
Je suis confus quant au moment où une application Web divise en microservices - est-ce au niveau de l'URL ou des modèles? Par exemple, supposons que j'ai une application monolithique de 3 pages. Supposons que chaque page serve un cas d'utilisation distinct et que je souhaite les sauvegarder avec leurs propres microservices. Maintenant, quelle est la bonne façon de mettre en œuvre une architecture basée sur microservice:
- Je crée trois applications différentes (microservices), chacune contenant le (route, contrôleur, modèles, modèles) pour l'une des pages. Et puis, en fonction de la page demandée, je dirige la demande vers cette application particulière. Cela signifie que la page entière de la base de données au HTML est desservie par une application distincte. Fondamentalement, différentes applications du même site Web sont complètement desservies par différentes applications sur le backend.
- Les 3 microservices ne gèrent pas le contenu de l'interface utilisateur, mais uniquement les données de leurs cas d'utilisation (modèles, contrôleur, pas de modèles) et l'exposent sur une API REST. J'ai un public face à l'application. Cette application interroge les trois applications différentes (microservices) uniquement pour les données, puis crée les pages HTML à renvoyer au navigateur. Dans ce cas, toutes les pages d’une application Web sont desservies par une seule application qui utilise en interne trois microservices différents.
Vous avez du mal à modeler vos microservices.
En ce qui concerne les microservices, la deuxième approche est la plus appropriée, car elle expose sa logique via l’API.
Toujours lorsque vous modélisez vos microservices, gardez à l’esprit les faits suivants.
Couplage lâche : Lorsque des services sont couplés de manière lâche, un changement de service ne devrait pas nécessiter de changement de service. L’intérêt de ce système de microservices est de pouvoir modifier un service et de le déployer, indépendamment du besoin de modifier une autre partie du système. C'est vraiment très important.
Cohésion forte : Nous souhaitons que les comportements liés coexistent et que les comportements sans relation coexistent ailleurs. Pourquoi? Eh bien, si nous voulons changer de comportement, nous voulons pouvoir le changer en un seul endroit et publier ce changement le plus rapidement possible.
Comme d'habitude en génie logiciel, la réponse est que cela dépend. Je ne peux pas imaginer de raison pour l'instant, mais l'option 1 pourrait être utile dans certains cas de figure.
Cependant, compte tenu de la définition formelle de microservices, l'option 2 l'illustre mieux. L'un des principaux avantages des microservices est de pouvoir les réutiliser. Différentes applications ont des exigences et des besoins différents pour la présentation des informations. Faire en sorte que vos microservices renvoient une représentation JSON de vos données vous donnera plus de souplesse pour formater ces informations.
Modèle de passerelle Api de Microservice apigateway est le premier point à partir duquel vous pouvez commencer à distribuer ou à transférer les appels vers différents services.
Nous mettons actuellement en œuvre une architecture similaire à votre deuxième option. Nous avons rencontré les complexités suivantes en le faisant: (n'hésitez pas à laisser quiconque y répondre car c'est encore un travail en cours)
- Il existe encore techniquement une application monolithique sur votre système (l'application orientée utilisateur). Chaque fois qu'un changement est effectué dans l'API REST, vous devez modifier l'application qui fait face au premier plan pour gérer ces nouveaux changements. Ne me dites même pas comment vous introduisez un nouveau microservice. En résumé, plus vous mettez de microservices, plus la passerelle API est volumineuse. ( https://www.nginx.com/blog/building-microservices-using-an-api-gateway/ )
La passerelle API présente également certains inconvénients. C'est un autre composant hautement disponible qui doit être développé, déployé et géré. Il existe également un risque que l'API Gateway devienne un goulot d'étranglement pour le développement. Les développeurs doivent mettre à jour la passerelle API afin d’exposer les points de terminaison de chaque microservice. Il est important que le processus de mise à jour de la passerelle API soit aussi léger que possible. Sinon, les développeurs seront obligés d'attendre en ligne pour mettre à jour la passerelle. Malgré ces inconvénients, toutefois, pour la plupart des applications du monde réel, il est logique d'utiliser une passerelle API.
- Pour plus de convivialité, j'ai conçu une couche d'abstraction qui définit un comportement unique pour la communication avec chaque microservice. Une implémentation concrète pour chaque microservice. Cela introduisait une autre couche de complexité, car nous devions maintenant gérer ce que nous appelions des "connecteurs RPC" avec le microservice correspondant. Personnellement, cela a pris beaucoup de temps aux développeurs car, en plus de maintenir leur microservice respectif, ils devaient entretenir le connecteur. Si l'un d'entre eux était obsolète, l'application publique échouerait. De plus, les modifications du connecteur nécessiteraient une reconstruction de l'application publique (nous avons actuellement défini les connecteurs comme dépendances de jar).
- Bien que cela soit mentionné dans un autre billet et un blog, la relation de clé étrangère devient un gâchis lorsqu'il est question de plusieurs microservices gérant sa propre base de données. (Base de données par modèle de service) Votre application frontale est maintenant confrontée au problème de devoir les assembler. ("J'ai besoin de ces données mais je dois rechercher ces clés dans chaque microservice pour voir qui a quoi.") Je ne dis pas que c'est la bonne façon de le faire, mais si nous avons plusieurs lignes renvoyées, alors chacun des identifiants doit être résolu individuellement à partir d'un microservice. Je ne sais pas si c'est efficace. Je serais heureux d'entendre des suggestions.