Préface
Maintenant, de plus en plus d'entreprises adoptent Spring Cloud. Spring Boot est la prochaine génération de frameworks Web et Spring Cloud est le leader des microservices les plus récents et les plus populaires. Quelle raison devez-vous refuser? De nombreux étudiants de Java ont également commencé à apprendre activement Spring Cloud. En fait, il y a un autre problème ici: bien que tout le monde ait appris Eureka, Ribbon, Hystrix, Zuul, Feign, etc., il est toujours difficile de l'appliquer à des projets réels.
La difficulté des microservices réside dans le fractionnement des services. Le cadre n'est qu'un outil et de nombreuses personnes l'utiliseront. Le fractionnement des services et la relation entre les services sont des choses qui doivent être prises en compte lors du fractionnement.
Aujourd'hui, un camarade de classe m'a envoyé un e-mail pour me poser des questions sur les deux questions suivantes:
Voici quelques réponses basées sur ma propre expérience, pour référence uniquement:
En ce qui concerne l'API dans la première question, le contrôleur est-il sous chaque microservice?
Ce que nous appelons l'API est en fait une interface, et la plupart d'entre eux sont développés à l'aide de Spring MVC, qui est une méthode annotée dans le contrôleur. Les annotations sont celles que nous utilisons souvent:
En ce qui concerne la première question, nécessite-t-elle un projet unifié pour résumer le contrôleur des autres microservices?
Il n'y a en fait pas de motif fixe. La plupart de cela est directement transmis à vos services commerciaux via la passerelle API
Prenez la catégorie commerciale de sites Web de blog comme Yuantiandi comme exemple:
Il existe une fonction commerciale. Lorsque je consulte des articles de blog spécifiques, les informations que je dois retourner sont les suivantes:
À l'heure actuelle, notre interface pour afficher l'article implique en fait trois parties de données, les informations de l'article lui-même, les informations de commentaire et les informations de l'auteur.
Il existe 3 services, services utilisateurs, services de blog et services de commentaires
La question est donc de savoir qu'elle implique l'interaction entre plusieurs services auparavant. En fait, la même question que le camarade de classe ci-dessus m'a posé. Dois-je avoir un projet unifié et assembler d'autres services? Peuvent-ils être appelés les uns les autres?
Je recommande deux façons de mettre en œuvre ceci:
1. La passerelle API se transmet directement au service de blog
Notre API est une interface pour obtenir des informations sur les articles de blog. Le corps principal doit être le service de blog. Il existe une interface pour les informations sur les articles de blog dans le service de blog. Dans l'interface, nous appelons l'interface d'informations utilisateur fournie par le service utilisateur, et nous appelons également les informations de commentaire de billet de blog dans le service de commentaires. Voyons le pseudo code:
@GetMapping ("/ blog / Detail / {id}") public bloginfo bloginfo (@pathvariable ("id") long id) {// obtenez le blog Blog Blog = blogService.getById (id); // Obtenez des informations utilisateur userInfo userInfo = userFeignClient.getUserInfo (blog.getUserId ()); // obtenir des informations de commentaire commentInfo commentInfo = commentfeignClient.getCommentInfo (id); Retour assemblez toutes les informations et retournez. }2. Ajouter une couche de service d'agrégation
La couche de service de collecte est le camarade de classe ci-dessus, est-il nécessaire d'avoir un projet unifié pour faire des services d'assemblage? Cela signifie que notre service de blog fournit toujours des informations de blog de base, et un service d'agrégation d'entreprise distinct est ajouté pour assembler ces informations et les rendre uniformément à l'appelant. Le pseudo-code est le suivant:
@GetMapping ("/ blog / Detail / {id}") BlogInfo public BlogInfo (@Pathvariable ("ID") Long ID) {// Get Blog Blog Blog Blog = BlogFeignClient.getById (ID); // Obtenez des informations utilisateur userInfo userInfo = userFeignClient.getUserInfo (blog.getUserId ()); // obtenir des informations de commentaire commentInfo commentInfo = commentfeignClient.getCommentInfo (id); Retour assemblez toutes les informations et retournez. }Les données sont appelées à distance, bien sûr, vous pouvez l'appeler en parallèle ici. Une autre façon consiste à effectuer un opération d'agrégation dans la passerelle API. Cette solution est également possible. Je suggère de ne pas le faire dans la passerelle. La passerelle API est aussi simple que possible et seulement en avant. L'ajout de la couche de service d'agrégation est un bon choix.
Si votre gouvernance de service est construite avec Dubbo, la couche de service d'agrégation est également une meilleure méthode. L'agrégation de service Dubbo fournit l'interface HTTP aux appels externes.
3. L'appelant obtient diverses données par lui-même
Une autre façon consiste à appeler l'interface du blog, l'interface de commentaire et l'interface utilisateur elles-mêmes. De cette façon, l'interface n'a besoin que de faire attention à ses propres données et de remettre le problème d'assemblage à l'utilisateur. Ceci est généralement moins utilisé. Il est préférable de renvoyer les données à l'appelant à la fois et de l'appeler à plusieurs reprises, en particulier sur le terminal mobile, qui nécessite trop de demandes et de déchets de trafic.
Résumer
Quant à la façon d'assembler les données, vous devez le décider vous-même. Vous pouvez placer l'assemblage dans les services commerciaux correspondants, ou ajouter un service d'agrégation pour l'assembler séparément, ou laisser le client l'assembler par lui-même.
Les services peuvent certainement être appelés les uns les autres. S'ils ne peuvent pas s'appeler, alors quel est l'intérêt de les séparer? Utilisez Feign pour appeler l'interface de service, et vous le traitez simplement comme un appel entre les services.
D'accord, ce qui précède est l'intégralité du contenu de cet article. J'espère que le contenu de cet article a une certaine valeur de référence pour l'étude ou le travail de chacun. Si vous avez des questions, vous pouvez laisser un message pour communiquer. Merci pour votre soutien à wulin.com.