Detailed explanation of the methods provided by the spring cloud implementation API to the client

preface

Now more and more companies are embracing spring cloud. Spring boot is the next generation web framework, and spring cloud is the leader of the latest and hottest microservices. What reason do you have to refuse. Many students in the Java direction have also begun to actively learn spring cloud. In fact, there is another problem here: Although we have learned Eureka, ribbon, hystrix, zuul, feign and so on, it is still difficult to apply it to practical projects.

The difficulty of microservices lies in the service splitting. The framework is just a tool, which many people will use. Service splitting and the relationship between services are all things that need to be considered when splitting.

Today, a classmate sent me an email asking me the following two questions:

Here are some answers based on my own experience for reference only:

The API in the first question is the controller under each micro service?

The API we are talking about is actually an interface. Most of them are developed in spring MVC, that is, an annotated method in the controller. Annotations are the commonly used ones:

On the first question, do you need a unified project to encapsulate the controllers of other microservices?

In fact, there is no fixed mode. Most of them are directly forwarded to your business services through the API gateway

Take the business class of Blog websites such as ape world for 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 for viewing articles actually involves three parts of data, information of the article itself, comment information and author information

There are three services, user service, blog service and comment service

So here's the question. It involves the interaction before multiple services. In fact, it's the same question that the student above asked me. Is it necessary to unify the project and assemble other services? Can I call each other?

In this case, I recommend two implementation methods:

I The API gateway forwards directly to the blog service

Our API is an interface for obtaining blog information. The main body must be the blog service. There is an interface for blog information in the blog service. In the interface, we call the user information interface provided by the user service and the comment information of the blog in the comment service. See the pseudo code below:

II Add aggregation service layer

The collection service layer, that is, does the student above say that a unified project is needed to assemble services, that is, our blog service still provides basic blog information, and a business aggregation service is added separately to assemble these information and return them to the caller uniformly. The pseudo code is as follows:

The data is called remotely. Of course, you can call it in parallel here. Another way is that the aggregation operation is carried out in the API gateway. This scheme is also feasible. I suggest not to do it in the gateway. The API gateway should be as simple as possible, only forward, and 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 to provide a unified HTTP interface for external calls.

III The caller obtains each data by itself

Another way is for the caller to call the blog interface, comment interface and user interface respectively. In this way, the interface only needs to pay attention to its own data and hand over the assembly problems to the user. Generally, it is less used. It is best to return the data to be used to the caller at one time and call it repeatedly, especially on the mobile end, there are too many requests, Waste traffic.

summary

As for how to assemble data, you still have to decide by yourself. You can put the assembly in the corresponding business service, add a separate aggregation service to assemble, or let the client assemble by itself.

Services can definitely call each other. If they can't call each other, what's the point of dismantling them? Call the service interface with feign, and you can treat it as a call between services.

Well, the above is the whole content of this article. I hope the content of this article has a certain reference value for your study or work. If you have any questions, you can leave a message. Thank you for your support for programming tips.