First, what can gateways do for us?
It can do routing and forwarding for us, black and white listing, filtering requests, etc
The essence of a gateway is actually a series of filters. Remember when we first learned about filters, the doFilter of servlets, did the DNA of friends move? Haha
What we’re going to talk about today is using the essence of gateways, filters, to do grayscale publishing
Before saying, let’s talk about what is gray release, often hear this term, just don’t know what it is
Today, we have to make it clear to him
Grayscale release, also known as Canary release, refers to A way of releasing A version that can smooth the transition. A/B testing can be done on it, that is, some users continue to use product feature A and some users start using product feature B. If users have no objections to B, then gradually expand the scope. Migrate all users to B.
What’s the benefit?
It can ensure the stability of the overall system, and problems can be found and adjusted at the initial gray level to ensure its impact.
In addition to gray release what kind of release?
Blue-green releases, scrolling releases, etc
Here’s a quick look at how blue-green publishing works:
Three additional servers need to be started (to host the new service)
Rolling release:
You replace one of these services with a new service, and the replaced service sits idle to load another new service, one by one
Gray scale publishing:
Start the same service sets the version of the configuration file, for example: start 3 same services, one version is V2, the remaining two are V1(the version can be dynamically changed using the Eureka registry API)
Eureka: instance: metadata-map: # custom attribute version V1, V2 version: V2
All ready, back to Zuul gateway, Zuul gateway filter, there are several types, pre, route, POST, error
The execution sequence is pre – > route – > POST
To customize a gateway filter, inherit from ZuulFilter and implement its methods
Use the @Component annotation, which is managed by the Spring container
There are four methods: fileType, filterOrder, shouldFilter, and run
- The fileType method specifies what type of filter is pre, route, POST, error
- The filterOrder method, which determines the order of execution, the smaller the number, the more first to execute
- The shouldFilter method, which determines whether the filter is executed, is true, and false is not
- The run method, the execution logic of the filter
Custom gateway filters, such as this grayscale publication, use pre type filters as much as possible
When initiating a request, the request header carries the userId(based on the userId to distinguish whether to access a new service).
Override public Object run() throws ZuulException {// obtain the RequestContext RequestContext currentContext = RequestContext.getCurrentContext(); / / get it it request = currentContext. GetRequest (); Integer userId = integer.parseint (request.getheader ("userId")); If (userId >= 5000) {if (userId >= 5000) {if (userId >= 5000) {if (userId >= 5000); Let him access/experience new service RibbonFilterContextHolder getCurrentContext (). The add (" version ", "v2"); } else {// otherwise, Continue to let the user experience of the old service / / because V1 we launched two load balance can continue to use RibbonFilterContextHolder. GetCurrentContext (). The add (" version ", "V1"); } return null; }
So this is the RibbonFilter dependency, and it’s ready for you
<dependency> <groupId>io.jmnarloch</groupId> <artifactId>ribbon-discovery-filter-spring-cloud-starter</artifactId> The < version > 2.1.0 < / version > < / dependency >
It is also important to note that when the gateway filters the request, it may cause you to lose the header data. Yes, it does
It is not overstated, it is to ensure security, some more special key, it will give you erasure, such as Authorization, Cookie, etc
Zuul: sensitive-header: zuul: sensitive-header: zuul: sensitive-header:
Hey hey, you like to pay attention to my wechat public number oh, I heard that now attention, after are exalted old powder