Preface
Now more and more companies are embracing Spring Cloud. Spring Boot is the next generation of web frameworks and Spring Cloud is the leader in the latest and most popular microservices. What reason do you have to refuse? Many students in Java have also begun to actively learn Spring Cloud. In fact, there is another problem here: Although everyone has learned Eureka, Ribbon, Hystrix, Zuul, Feign, etc., it is still difficult to apply it to actual projects.
The difficulty of microservices lies in the splitting of services. Framework is just a tool, and many people will use it. Service splitting and the relationship between services are things that need to be considered during splitting.
Today a classmate sent me an email to ask me about the following two questions:
Here are some answers based on my own experience, for reference only:
Regarding the API in the first question is the Controller under each microservice?
What we call API is actually an interface, and most of them are developed using Spring MVC, which is an annotated method in the Controller. Annotations are the ones we often use:
Regarding the first question, does it require a unified project to encapsulate the controller of other microservices?
There is actually no fixed pattern. Most of this is directly forwarded to your business services through the API gateway
Take the business category of blog websites like Yuantiandi as an example:
There is a business function. When I view specific blog posts, the information I need to return is as follows:
At this time, our interface to view the article actually involves three parts of data, the information of the article itself, the comment information, and the information of the author.
There are 3 services, user services, blog services, and comment services
So the question is, it involves the interaction between multiple services before. In fact, the same question as the classmate above asked me. Do I need to have a unified project and assemble other services? Can they be called each other?
I recommend two ways to implement this:
1. The API gateway forwards directly to the blog service
Our API is an interface for obtaining blog post information. The main body must be the blog service. There is an interface for blog post information in the blog service. In the interface, we call the user information interface provided by the user service, and we also call the blog post comment information in the comment service. Let’s see the pseudo code:
@GetMapping("/blog/detail/{id}")public BlogInfo blogInfo(@PathVariable("id") Long id) { // Get blog information Blog blog = blogService.getById(id); // Get user information UserInfo userInfo = userFeignClient.getUserInfo(blog.getUserId()); // Get comment information CommentInfo commentInfo = commentFeignClient.getCommentInfo(id); return Assemble all information and return. }2. Add an aggregation service layer
The collection service layer is the classmate above, is it necessary to have a unified project to do assembly services? This means that our blog service still provides basic blog information, and a separate business aggregation service is added to assemble this information and return it to the caller uniformly. The pseudo-code is as follows:
@GetMapping("/blog/detail/{id}")public BlogInfo blogInfo(@PathVariable("id") Long id) { // Get blog information Blog blog = blogFeignClient.getById(id); // Get user information UserInfo userInfo = userFeignClient.getUserInfo(blog.getUserId()); // Get comment information CommentInfo commentInfo = commentFeignClient.getCommentInfo(id); return Assemble all information and return. }Data are called remotely, of course you can call it in parallel here. Another way is to perform aggregation operation in the API gateway. This solution is also feasible. I suggest not to do it in the gateway. The API gateway is as simple as possible and only forward. Adding the aggregation service layer is a good choice.
If your service governance is built with dubbo, the aggregation service layer is also a better method. Dubbo service aggregation provides the http interface to external calls.
3. The caller obtains various data by himself
Another way is to call the blog interface, comment interface, and user interface themselves. In this way, the interface only needs to pay attention to its own data and hand over the assembly problem to the user. This is generally used less. It is best to return the data to the caller at one time, and call it repeatedly, especially on the mobile terminal, which requires too many requests and wastes traffic.
Summarize
As for how to assemble the data, you have to decide it yourself. You can place the assembly in the corresponding business services, or add an aggregation service to assemble it separately, or let the client assemble it by itself.
Services can definitely be called each other. If they cannot be called each other, then what's the point of breaking them apart? Use Feign to call the service interface, and you just treat it as a call between Services.
Okay, the above is the entire content of this article. I hope that the content of this article has certain reference value for everyone's study or work. If you have any questions, you can leave a message to communicate. Thank you for your support to Wulin.com.