Last article we introduced the API Gateway's basic building methods and requests are filtered, the role of small partners Zuul should already have a basic understanding, but for routing configuration we just did a brief introduction, we come to this article take a look at some of the other details of the routing configuration.
First let us recall that the last article we two lines of code to configure routing rules:
- zuul.routes.api-a.path=/api-a/**
- zuul.routes.api-a.serviceId=feign-consumer
We say that when I visit address matches / api-a / ** rules, will be automatically positioned to feign-consumer services go up, but two lines of code a little trouble, we can use the following line of code instead of, as follows:
- zuul.routes.feign-consumer=/api-a/**
Followed behind zuul.routes is the service name, followed by the service name is the path behind the rules, this configuration is clearly easier.
If the mapping rules we write nothing, the system also provides us with a set of default configuration rules, the default configuration rules are as follows:
- zuul.routes.feign-consumer.path=/feign-consumer/**
- zuul.routes.feign-consumer.serviceId=feign-consumer
By default, all the registered service will be created on Eureka Zuul mapping relationship for routing, but for my example here, I want to provide services is to feign-consumer, hello-service as a service provider only for consumer services to provide services, does not provide services, if the default routing rules, the Zuul will automatically create a mapping rule for hello-service, this time we can use the following way to make Zuul skip the hello-service service, not to create routing rules:
- zuul.ignored-services=hello-service
Some junior partner may be in doubt, we define routing rules / api-a / ** when and why the final surface is two *, a possible? Sure, but the significance can not be the same, the route matching rules Zuul uses the Ant style definition, a total of three different wildcard:
| Wildcards | meaning | For example | Explanation |
|---|---|---|---|
| ? | Matches any single character | /feign-consumer/? | 匹配/feign-consumer/a,/feign-consumer/b,/feign-consumer/c等 |
| * | Matches any number of characters | /feign-consumer/* | Match / feign-consumer / aaa, feign-consumer / bbb, / feign-consumer / ccc, etc., can not be matched / feign-consumer / a / b / c |
| ** | Matches any number of characters | /feign-consumer/* | Match / feign-consumer / aaa, / feign-consumer / ccc the like, can also match / feign-consumer / a / b / c |
Sometimes we will encounter such a problem, for example, I have two services, called feign-consumer, also called feign-consumer-hello, this time my routing configuration rules may be written like this:
- zuul.routes.feign-consumer.path=/feign-consumer/**
- zuul.routes.feign-consumer.serviceId=feign-consumer
-
- zuul.routes.feign-consumer-hello.path=/feign-consumer/hello/**
- zuul.routes.feign-consumer-hello.serviceId=feign-consumer-hello
At this point my path access feign-consumer-hello's match will also be two rules, the path to match the way Zuul in a linear way match, which in turn matches the stored order routing matching rules, so we just need to make sure feign-consumer-hello matching rules is to define the matching rules feign-consumer can be defined later, but in the properties file, we can not guarantee the order, then we need to use YAML configuration, this time we can delete application.properties under the resources folder, then create a new application.yml, reads as follows:
- spring:
- application:
- name: api-gateway
- server:
- port: 2006
- zuul:
- routes:
- feign-consumer-hello:
- path: /feign-consumer/hello/**
- serviceId: feign-consumer-hello
- feign-consumer:
- path: /feign-consumer/**
- serviceId: feign-consumer
- eureka:
- client:
- service-url:
- defaultZone: http://localhost:1111/eureka/
This time we will be sure to load the matching rules feign-consumer-hello, and after loading the matching rules feign-consumer.
We said above a zuul.ignored-services = hello-service attributes can ignore a service, not to set up a service mapping rules, we can further refine this configuration, for example, I do not want to / hello interface route, that we can configure (I use the back yaml configuration) as follows:
- zuul:
- ignored-patterns: /**/hello/**
At this visit / hello interfaces will report a 404 error, and we can also see the following log spooling:
In addition, we can also increase a unified prefix routing rules, set up as follows:
- zuul:
- prefix: /myapi
At this point we access path becomes http: // localhost: 2006 / myapi / feign-consumer / hello1.
Under normal circumstances only as a unified API Gateway portal system, but sometimes we may need to do a bit of business logic operations on the API Gateway, for example, I now create a new Controller follows the api-gateway project:
- @RestController
- public class HelloController {
- @RequestMapping("/local")
- public String hello() {
- return "hello api gateway";
- }
- }
-
I want users to be able to automatically jump up to deal with this method when accessing / local, so this time we need to use local jump Zuul, the configuration is as follows:
- zuul:
- prefix: /myapi
- ignored-patterns: /**/hello/**
- routes:
- local:
- path: /local/**
- url: forward:/local
At this visit http: // localhost: 2006 / myapi / local results are as follows:
When we use the Nginx, involves a configuration header information request to prevent the page redirects to jump to the upstream server up, the issues are the same in the Zuul, provides an interface / hello4 suppose I feign-consumer in when accessing / hello4 interface, page redirects to / hello, by default, the redirection address is the address of a specific service instances, rather than jump address API gateway, this approach exposes the real service address , so you need to configure the Zuul, the configuration is very simple, as follows:
- zuul:
- add-host-header: true
It represents Host API gateway making the request header information setting request before forwarding route.
By default, the head of sensitive information can not be passed through the API Gateway, we can so that it can pass through the following configuration:
- zuul:
- routes:
- feign-consumer:
- sensitiveHeaders:
In the Zuul, Ribbon and Hystrix configuration is consistent with previous configuration, I will not go into details, if we want to close Hystrix retry mechanism, can be as follows:
Close Global retry mechanism:
- zuul:
- retryable: false
Close Retry mechanism for certain services:
- zuul:
- routes:
- feign-consumer:
- retryable: false
About routing configuration details Zuul we stop here, there is a problem welcome discussion. That's all for this article, I want to be helpful to learn, I hope you will support programming tips.
