Overview: zuul underlayer is based servlet, the filter is composed of a series of chain.
1, routing configuration
a, mapping singleton serverId
zuul: routes: client-a: path: /client/** serviceId: client-a
Means to / client / ** paths to service endpoints are mapped to client-a, such a configuration can also be simplified into the following format, both fully consistent results:
官网 www.1b23.com zuul: routes: client-a: /client/**
There is a more brutal way is serverId maps do not have to write, as follows:
zuul: routes: client-a:
This configuration, zuul adds a default mapping rule for the client-a, namely: / client / **, a first configuration corresponding to the above.
b, URL mapping singleton
This means that the configuration, the gateway routing service to a specific address, namely: to replace serverId url, as follows:
Zuul: routes: Client-A: path: / Client / ** url: HTTP: // localhost: 7070 # Client-A address
c, multi-instance routing
zuul will use the default eureka integrated load balancing, if you want to use ribbon load balancing, you need to specify serverId, this operation must disable the swap ribbon use eureka, do the following:
Zuul: routes: Ribbon-route: path: / Ribbon / ** serviceId: Ribbon-route Ribbon: Eureka: Enabled: false # Use prohibited Ribbon Eureka Ribbon-route: Ribbon: NIWSServerListClassName: com.netflix.loadbalancer.ConfigurationBasedServerList # define acquisition service list of methods NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #Ribbon LB strategy random load strategy listOfServers: localhost: 7070, localhost: 7071 #client services for Ribbon LB designated service address
d, forword local jump
If the Gateway service, you need to do some processing logic, you can configure url, add forword options:
Zuul: routes: Client-A: path: / Client / ** URL: Forward: / Client # jump to the gateway service @GetMapping ( "/ client") end
e, same loading path
zuul: routes: client-b: path: /client/** serviceId: client-b client-a: path: /client/** serviceId: client-a
From the above profile can be seen, the configuration of the two routing engineering, namely: client-a project, client-b project, but the path of the two paths is the same, in this case, at the time of loading access , which will cover the former.
f, routing wildcard
| rule | Explanation | Examples |
| /** | Matches any number of paths with character | /client/add, /client/update, client/a, client/add/a, client/update/a/b |
| /* | Matches any number of characters | /client/add, /client/update, client/a |
| /? | Matches any single character | /client/a |
2, feature configuration
a, shielding service shield path
zuul: ignored-services: client- b # neglected service, service prevent intrusion ignored-patterns: / ** / div / ** # negligible interface shielded interface routes: Client-A: / Client / **
Plus ignored-services and ignored-patterns after, zuul when the pull service list, create mapping rules and they will ignore the service and client-b / ** / div / ** interface.
b, filtered off request header sensitive
We use normal HTTP request after the service, passed in added value header, it is a normal thing, some basic authentication protocol also in the header, such as cookie, or after the user login authentication information by base64 encoding, on the authorization which, in this delivery system is no problem, but if the system interact with the outside, this might appear unusual, after all, have to take preventive measures, then you can specify sensitive information zuul head inside, cut off interaction with its downstream, as follows:
zuul: routes: client-a: path: /client/** sensitiveHeaders: Cookie,Set-Cookie,Authorization serviceId: client-a
c, redirection
In practice, enterprise-level projects, many operations are required after the user logs before they can operate, in order to prevent the user logs in successfully, the redirect, when the corresponding service address exposed to the user, you can set a head, as follows :
Zuul: the Add-Host-header: # redirection header to true problem routes: Client-A: / Client / **
d, retry mechanism
In a production environment, it may be due to various reasons, resulting in occasional failure of the request, may be used in conjunction with ribbon made zuul retry the operation, as follows:
zuul: retryable: true # Open retry ribbon: MaxAutoRetries: 1 # number (first removal) MaxAutoRetriesNextServer same service retried: the same number of services switching # 1
However, this feature should be used with caution, because some of the interfaces need to ensure idempotency.