On the API gateway service zuul in spring cloud

So far, we have introduced a lot of contents in spring cloud. We are familiar with ribbon, hystrix and feign. We also mentioned that microservice is to split a large project into many small independent modules, and then make these independent modules work together through service governance. So let's think about two questions: 1 If there are many independent services in my micro service that need to provide services externally, how should developers or operation and maintenance personnel manage these interfaces? Especially when the project is very large and complex, how to manage it? 2. Permission management is also an old topic. In microservices, an independent system is divided into many independent modules. In order to ensure security, do I need to add the same authentication code to each module to ensure that the system is not illegally accessed? If so, the workload is too large and the maintenance is very inconvenient.

In order to solve the problems mentioned above, we introduced the concept of API gateway. API gateway is a more intelligent application server, which is somewhat similar to the facade of our microservice architecture system. All external access must first pass through the API gateway, and then the API gateway realizes the functions of request routing, load balancing, permission verification and so on. Spring cloud zuul provided in spring cloud implements the function of API gateway. In this article, let's take a look at a basic use of spring cloud zuul.

Build gateway

The gateway is built through the following three steps.

1. Create a spring boot project and add dependencies

First, we create an ordinary spring boot project called API gateway, and then add related dependencies. Here we mainly add two dependencies: spring cloud starter zuul and spring cloud starter Eureka. The spring cloud starter zuul dependency includes ribbon, hystrix, actor, etc., as follows:

2. Add notes

Then add the @ enablezuulproxy annotation on the entry class to enable the API gateway service function of zuul, as follows:

3. Configure routing rules

application. The configuration in the properties file can be divided into two parts. One part is the basic information of zuul application, and the other part is the routing rules, as follows:

We have configured the routing rules here. All requests conforming to / api-a / * * will be forwarded to feign consumer service. As for the address of feign consumer service, Eureka server will analyze it. We only need to write the service name here. Take the above configuration as an example, if I request http://localhost:2006/api -The A / hello1 interface is equivalent to a request http://localhost:2005/hello1 (my feign consumer address here is http://localhost:2005 ）, the api-a configured in the routing rule is the name of the route, which can be defined arbitrarily, but the route names of a set of path and serviceid mapping relationships should be the same.

OK, after doing this, we start our Eureka server, provider and feign consumer in turn, and then visit the following address http://localhost:2006/api -A / hello1. The access results are as follows:

Seeing this effect shows that our API gateway service has been successfully built, and the requests that meet the routing rules we send are automatically forwarded to the corresponding services for processing.

Request filtering

After building the gateway, let's take a look at how to use the gateway to implement a simple permission verification. This involves another core function of spring cloud zuul: request filtering. Request filtering is a bit similar to the filter filter in Java. First intercept all requests, and then make different processing according to the on-site situation. Here, let's take a look at how to use the filter in zuul. Very simple, two steps:

1. Define filters

First, we define a filter inherited from zuulfilter, as follows:

About this class, I say the following:

1. The return value of the filtertype method is the filter type. The filter type determines which life cycle the filter is executed in. Pre means to execute the filter before routing. Other optional values include post, error, route and static. Of course, they can also be customized.

2. The filterorder method indicates the execution order of the filter. When there are many filters, this method will be meaningful.

3. Shouldfilter method is used to judge whether the filter is executed. True means to execute and false means not to execute. In actual development, we can decide whether to filter the address according to the current request address. Here I directly return true.

4. The run method represents the specific logic of filtering. If the login parameter is carried in the request address, it is considered a legal request, otherwise it is an illegal request. If it is an illegal request, set CTX first setSendZuulResponse(false); Indicates that the request will not be routed, and then set the response code and response value. The return value of this run method has no meaning in the current version (Dalston. SR3) and can return any value.

2. Configure filter bean

Then configure related beans in the entry class, as follows:

At this point, if we visit http://localhost:2006/api -A / hello1, the results are as follows:

If the login parameter is added to the request address, the result is as follows:

summary

Here, my friends should have seen the power of spring cloud zuul. As the unified entrance of the system, API gateway shields the internal details of microservices, and can automatically maintain service instances and realize load balanced routing and forwarding. At the same time, the filter it provides provides provides a unified permission verification mechanism for all microservices, The service itself only needs to focus on business logic.

Let's introduce zuul's introductory knowledge here. If you have any questions, please leave a message for discussion. The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.