If you have used the microservice project, you must know the gateway service, and the gateway service of microservice must be inseparable from Spring Cloud Zuul. What advantage does Spring Cloud Zuul have as a gateway? The project can be accessed without a gateway, so why use a gateway?
Today, Spring Cloud Zuul
advantage
1 Service-oriented Routing (serverId of set Eruka)
2 Unified permission filtering for microservices
Have load balancing and fusing capability
Above said roughly next, below specific analysis
What is service oriented routing? What is it different from other routing?
Start by creating a springCloudZull
Take a look at his profile
spring.application.name=api-gateway
server.port=5555
# eureka
eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/
# routes to url
zuul.routes.api-a-url.path=/api-a-url/**
zuul.routes.api-a-url.url=http://localhost:8001/
Copy the code
In the configuration file we see # routes to this url is his routing configuration when visiting http://localhost:5555/api-a-url/hello, Will be routed to http://localhost:8001/hello this is the traditional way of routing, we see this configuration for operations staff, is more troublesome. So Zuul worked with Eruka to come up with a service-oriented routing configuration that looked like this
zuul.routes.api-a.path=/api-a-url/**
zuul.routes.api-a.serviceId=hello-service
Copy the code
Eruka serviceId (eruka serviceId, eruka serviceId, eruka serviceId, Eruka serviceId, Eruka serviceId
We start an Eruka and register three services on it, one for our gateway service and two for routing, and this is what happens when we start it
And then visithttp://localhost:5555/api-a-url/helloThe result of the route is returned
Because it is routed by the service ID, it is service-oriented routing.
In fact, each sub-service can do permission filtering without him, but in this case, you need to write a lot of filters and repeat the code, which is not in line with the idea of Don’t repeat yourself. Therefore, zuul is used for unified filtering. Here is his implementation
public class AccessFilter extends ZuulFilter { private static Logger log = LoggerFactory.getLogger(AccessFilter.class); @Override public String filterType() { return "pre"; } @Override public int filterOrder() { return 0; } @Override public boolean shouldFilter() { return true; } @Override public Object run() { RequestContext ctx = RequestContext.getCurrentContext(); HttpServletRequest request = ctx.getRequest(); log.info("send {} request to {}", request.getMethod(), request.getRequestURL().toString()); Object accessToken = request.getParameter("accessToken"); if(accessToken == null) { log.warn("access token is empty"); ctx.setSendZuulResponse(false); ctx.setResponseStatusCode(401); return null; } log.info("access token ok"); return null; }}Copy the code
This is his implementation code, first to implement ZuulFilter interface, interface has several methods
FilterType Specifies the type of filter to use. There are four types of filters, each corresponding to different life cycles. Pre filters before service requests
FilterOrder specifies the order in which the filterOrder filter is executed first
ShouldFilter determines whether the filter should be executed
The fourth method is to execute the content of the filter, which determines whether there is a token in the request, and if so, allows access, if not blocked
When you’re done, you have to put it in a container for it to work
@EnableZuulProxy
@SpringCloudApplication
public class Application {
public static void main(String[] args) {
new SpringApplicationBuilder(Application.class).web(true).run(args);
}
@Bean
public AccessFilter accessFilter() {
return new AccessFilter();
}
Copy the code
Here is the @bean annotation. Before, we said that @bean can only be used in the method, which is a bit weak, in fact, it is not. Through this use, we can find that @bean can still flexibly load some of the content we want
So we have uniform filtering.
Next, load balancing and fuses are implemented through configuration
zuul.routes.api-d.path=/ddd/**
zuul.routes.api-d.serviceId=hello
ribbon.eureka.enabled=true
hello.ribbon.listOfServers=http://localhost:8001/,http://localhost:8002/
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=60000
#ribbon.ConnectTimeout=3000
#ribbon.ReadTimeout=60000
Copy the code
Zuul poM integrates ribbon and Hystrix, so it only needs to be configured. We can configure timeout and fusing time to handle load balancing. Eureka. Enabled =true.