Architecture d'une application web basée sur microservice
je suis confus au sujet du point auquel une application web diverge dans les microservices - est-il au niveau de l'url ou des modèles? Comme exemple, supposons que j'ai une application monolithique qui sert 3 pages. Disons que chaque page sert une usecase séparée et je veux soutenir eack d'entre eux 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, gabarits) pour l'une des pages. Et puis en fonction de laquelle chaque page est demandée, j'achemine la demande à cette application particulière. Cela signifie que toute la page de la base de données au HTML est desservie par une application séparée. Fondamentalement, différentes pages dans le même site Web sont complètement servis par différentes applications sur le backend.
- les 3 microservices ne prennent pas en charge L'interface utilisateur, mais seulement les données de leurs usecases (models, controller, no templates) et les exposent sur un repos API. J'ai une appli face au public. Cette application interroge les trois applications différentes(microservices) uniquement pour les données puis génère les pages html à être renvoyé au navigateur. Toutes les pages d'une application web dans ce cas sont servies par une seule application qui utilise en interne trois microservices différents.
4 réponses
vous avez du mal à modéliser vos microservices.
en terme de microservices la seconde approche est la plus appropriée, qui expose sa logique à travers L'API.
toujours lorsque vous modélisez vos microservices, gardez à l'esprit les faits suivants.
Couplage Lâche: lorsque les services sont vaguement couplés, un changement à un service ne devrait pas nécessiter un changement à un autre. Le but de ce truc de micro-service est de pouvoir faire un passer à un service, et le déployer, indépendamment de la nécessité de changer toute autre partie du système. C'est vraiment très important.
Forte Cohésion: nous voulons que les comportements apparentés s'asseyent ensemble, et que les comportements non apparentés s'asseyent ailleurs. Pourquoi? Eh bien, si nous voulons changer de comportement, nous voulons être en mesure de le changer en un seul endroit, et libérer ce changement dès que possible.
comme d'habitude dans L'ingénierie logicielle, la réponse est que cela dépend. Je ne peux imaginer une raison pour l'instant, mais l'option 1 pourrait être utile dans certains scénarios particuliers.
Cependant, compte tenu de la définition formelle des microservices, l'option 2 l'illustre mieux. L'un des principaux avantages d'avoir des microservices, c'est de pouvoir la réutiliser. Les différentes applications ont des exigences et des besoins différents en ce qui concerne la présentation de l'information. Rendre vos microservices à JSON représentation de vos données vous donnera plus de flexibilité sur la façon de formater cette information.
passerelle Api motif de Microservice apigateway est le premier point à partir duquel vous pouvez commencer à distribuer ou transmettre les appels vers différents services
nous sommes en train de mettre en place une architecture similaire à votre deuxième option. Nous avons rencontré les complexités suivantes tout en le faisant: (n'hésitez pas à quiconque de carillon en ce qu'il est encore un travail en cours)
- Il est toujours techniquement une application monolithique dans votre système (l'utilisateur face à l'app). Chaque fois qu'un changement est effectué dans L'api REST, vous devez changer l'application front facing pour gérer ces nouveaux changements. Ne commence même pas sur la façon dont tu introduis une nouvelle microservice derrière. Donc, essentiellement, plus vous mettez de microservices derrière, plus la passerelle API est grande. (https://www.nginx.com/blog/building-microservices-using-an-api-gateway/)
la passerelle API a aussi quelques inconvénients. Il s'agit d'une autre composante très disponible qui doit être développée, déployée et gérée. Il y a également un risque que la passerelle API devienne un goulot d'étranglement de développement. Les développeurs doivent mettre à jour la passerelle API dans l'ordre exposer les paramètres 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 forcés d'attendre en ligne pour mettre à jour la passerelle. Malgré ces inconvénients, cependant, pour la plupart des applications du monde réel, il est logique d'utiliser une passerelle API.
- pour la réutilisabilité j'ai conçu une couche d'abstraction qui définit un comportement unique pour communiquer avec chaque microservice. Un béton mise en œuvre pour chaque microservice. Cela a introduit une autre couche de complexité parce que maintenant nous avons dû maintenir ce que nous avons appelé "connecteurs RPC" avec son microservice correspondant. Personnellement, cela a pris beaucoup de temps d'un développeur car, en plus de maintenir leur microservice respectif, ils ont dû maintenir le connecteur. Si l'un d'eux était périmé, l'application publique échouerait. En outre, les changements dans le connecteur nécessiteraient une reconstruction de l'application publique (nous définissons actuellement les connecteurs comme pot de dépendances).
- alors que ceci est mentionné dans un autre post et un blog, la relation clé étrangère devient un gâchis quand il s'agit de plusieurs microservices manipulant sa propre base de données. (Base de données par modèle de service) Votre application front facing fait maintenant face au problème de devoir les recoudre ensemble. ("J'ai besoin de ces données, mais je dois regarder ces touches 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 affaire à plusieurs lignes ensuite revenus de chacun des identifiants d'être résolu individuellement à partir d'un microservice. Je ne suis pas sûr de savoir comment efficace, c'est bien. Je serais heureux d'entendre vos suggestions.