What is spring cloud and what knowledge points need to be mastered

Posted by alevsky on Sun, 26 Dec 2021 21:14:36 +0100

If you understand the above, you can understand the most basic configuration of Zuul. See below.

server: 
	port: 9000 
eureka: 
	client: 
		service-url: 
			# Just register Eureka here 
			defaultZone: http://localhost:9997/eureka

Then add the @ EnableZuulProxy annotation to the startup class. Yes, it's that simple.

2) Uniform prefix

This is very simple, that is, we can add a unified prefix in front of it. For example, what we just called is
localhost:9000/consumer1/studentInfo/update. At this time, we add the following in the yaml configuration file.

zuul: 
	prefix: /zuul

In this way, we need to access it through localhost:9000/zuul/consumer1/studentInfo/update.

3) Routing policy configuration

You will find that the previous access method (using the service name directly) requires exposing the microservice name to users, which will have security problems. Therefore, you can customize the path to replace the microservice name, that is, customize the routing policy.

zuul: 
	routes: 
		consumer1: /FrancisQ1/** 
		consumer2: /FrancisQ2/**

At this time, you can use localhost:9000/zuul/FrancisQ1/studentInfo/update ` to access.

4) Service name mask

Don't think you are good at this time. You can try. After you configure the routing policy, you can still access the microservice name. At this time, you need to mask the service name.

zuul: 
	ignore-services: "*"

5) Path shielding

Zuul can also specify the masked path URI, that is, as long as the user request contains the specified URI path, the request will not be able to access the specified service. In this way, the user's permissions can be restricted.

zuul: 
	ignore-patterns: **/auto/**

In this way, we can filter out the requests about auto.

**Represents an arbitrary path that matches multiple levels
*Represents an arbitrary path that matches one level

6) Sensitive request header masking

By default, sensitive request header information such as cookies and set cookies will be zuul masked. We can remove these default masks. Of course, we can also add request headers to be masked.

2.Zuul's filtering function

If the routing function is Zuul's basic operation, then the filter is Zuul's weapon. After all, all requests go through the gateway (Zuul), so we can carry out various filtering, so that we can realize flow restriction, gray publishing, permission control and so on.

1) Simple implementation of a request time log printing

To implement the Filter defined by ourselves, we only need to inherit ZuulFilter and add the Filter class to the Spring container with @ Component annotation.

Before I show you the code, I'll explain some considerations about filters.

Filter types: Pre, Routing, Post. The Pre filter is used to filter before the request, the Routing filter is the Routing policy mentioned above, and the Post filter is used to filter before the Response. You can observe the above figure combined with understanding, and I will give corresponding comments below.

// Add Spring container 
@Component 
public class PreRequestFilter extends ZuulFilter { 
	// Returns the filter type. Here is the prefilter 
	@Override 
	public String filterType() { 
		return FilterConstants.PRE_TYPE; 
	}
	// Specify that the smaller the filtering order, the earlier to execute. Here, the first to execute 
	// Of course, it's not really the first one. Other filters in Zuul will be executed first 
	// That's dead, like SERVLET_DETECTION_FILTER_ORDER = -3 
	@Override
	public int filterOrder() { 
		return 0; 
	}
	// When should I filter 
	// Here we can make some judgments so that we can filter out some non-conforming requests and so on 
	@Override 
	public boolean shouldFilter() { 
		return true; 
	}
	// What happens if the filter is allowed to pass 
	@Override 
	public Object run() throws ZuulException { 
		// Here I set the global RequestContext and record the request start time 
		RequestContext ctx = RequestContext.getCurrentContext(); 
		ctx.set("startTime", System.currentTimeMillis()); 
		return null; 
	} 
}

// lombok log 
@Slf4j 
// Add Spring container 
@Component 
public class AccessLogFilter extends ZuulFilter { 
	// Specify the filter type for this filter 
	// This is the post filter 
	@Override 
	public String filterType() { 
		return FilterConstants.POST_TYPE; 
	}
	// SEND_RESPONSE_FILTER_ORDER is the last filter 
	// We this filter before it 
	@Override 
	public int filterOrder() { 
		return FilterConstants.SEND_RESPONSE_FILTER_ORDER - 1; 
	}
	@Override 
	public boolean shouldFilter() { 
		return true; 
	}
	// Policy to execute when filtering 
	@Override 
	public Object run() throws ZuulException { 
		RequestContext context = RequestContext.getCurrentContext(); 
		HttpServletRequest request = context.getRequest(); 
		// Get the original start time from RequestContext and calculate the whole time interval through it 
		Long startTime = (Long) context.get("startTime"); 
		// Here I can get the HttpServletRequest to get the URI and print it out 
		String uri = request.getRequestURI(); 
		long duration = System.currentTimeMillis() - startTime; 
		log.info("uri: " + uri + ", duration: " + duration / 100 + "ms"); 
		return null; 
	} 
}

The above simply implements the request time log printing function. Do you feel the power of Zuul filtering function?

No, OK, let's come again.

2) Token bucket current limiting

Of course, it's not just the token bucket current limiting method. Zuul can do any current limiting work. Here I just give a simple example.

Let me first explain what is token bucket current limiting.

First, we will have a bucket. If it is not full, tokens will be put into it at a fixed rate. When a request comes, we must first obtain tokens from the bucket. If it is not obtained, the request will be rejected. If it is obtained, it will be released.

Let's implement token bucket current limiting through Zuul's pre filter.

package com.lgq.zuul.filter; 

import com.google.common.util.concurrent.RateLimiter; 
import com.netflix.zuul.ZuulFilter; 
import com.netflix.zuul.context.RequestContext; 
import com.netflix.zuul.exception.ZuulException; 
import lombok.extern.slf4j.Slf4j; 
import org.springframework.cloud.netflix.zuul.filters.support.FilterConstants; 
import org.springframework.stereotype.Component; 

@Component 
@Slf4j 
public class RouteFilter extends ZuulFilter { 
	// Define a token bucket to generate 2 tokens per second, that is, it can process up to 2 requests per second 
	private static final RateLimiter RATE_LIMITER = RateLimiter.create(2); 
	@Override 
	public String filterType() { 
		return FilterConstants.PRE_TYPE; 
	}
	@Override 
	public int filterOrder() { 
		return -5; 
	}

	@Override 
	public Object run() throws ZuulException { 
		log.info("Release"); 
		return null; 
	}
	
	@Override 
	public boolean shouldFilter() { 
		RequestContext context = RequestContext.getCurrentContext(); 
		if(!RATE_LIMITER.tryAcquire()) { 
			log.warn("Traffic overload"); 
			// Specifies that the current request did not pass the filter 
			context.setSendZuulResponse(false); 
			// The response code 429 is returned to the client, and the number of requests is too large 
			context.setResponseStatusCode(429); 
			return false; 
		}
		return true; 
	} 
}

So we can limit the number of requests to two a second. Do you think it's cool?

3. Other about Zuul

Zuul's filter certainly has more than the two functions I implemented above. It can also realize permission verification, including gray publishing mentioned above.

Of course, Zuul as a gateway must also have a single point of problem. If we want to ensure the high availability of Zuul, we need to configure Zuul's cluster. At this time, we can use some additional load balancers, such as Nginx.

##Spring Cloud configuration management - Config

4. Why use for configuration management?

When our microservice system starts to grow slowly, many consumers, providers, Eureka Server and Zuul systems will have their own configurations. At this time, we may need to change the configuration of some applications when the project is running. If we do not carry out unified configuration management, We can only go to the next application to find the configuration file, then modify the configuration file and restart the application.

First of all, for distributed systems, we should not modify the configuration file for each application. Moreover, for restarting applications, the service cannot be accessed, so we directly abandon the availability, which we prefer not to see.

So is there a method that can not only manage the configuration file uniformly, but also dynamically modify the configuration file when the project is running?

last

Here comes the interview question document, with a lot of content, 485 pages!

Because there are too many contents in the notes, we can't show them all. Only some contents are intercepted below. Friends who want to get the full version of notes, Click here for free after you like