Spring Cloud Service Protection

MicroServices, while addressing the disadvantages of strong coupling between the various modules of the traditional monolithic application, also lead to new problems, as the microservices are deployed independently of each other, and typically a service often relies on multiple other services, and calls between services are more dependent on unstable networks, Therefore, for the micro-service architecture, the stability of the mutual calls between services is more important, in order to ensure that the system can be more stable operation, we often do some protection of the service, commonly used measures are load balancing, fuse, current limit, downgrade, retry and so on.

One, load balancing

1. Concept

1.1. We should be familiar with the concept of load balancing, which is the distribution of request traffic to different servers, and load balancing is divided into two types:

1.1.1. Service-Side load: Server-side load balancing is transparent to the customer, the user requests to the LB server, the real application server is distributed by the LB server control, the current implementation of the software (Ngnix,ha proxy, etc.) and hardware (F5, etc.).

1.1.2 Client Load: Is a part of the client software that the client learns to distribute the request to the list of available servers according to a certain equalization policy.

This time we focus on client load, client soft load core:

Service discovery, discovers a list of dependent services.

Service selection rules, how to select a valid service in multiple services.

Service monitoring, detection of failed services, efficient elimination of failure services.

1.2. Since we are using the Spring cloud system, the Load Balancer component uses the Ribbon in the spring cloud system, and the Spring Cloud Ribbon is a client load balancing component that provides the client's software load Balancing algorithm

Load Balancing Policy:

1.2.1.RandomRule: Random Policy, select a service instance randomly from the service instance manifest. Get the list of available instances Uplist and all instances list alllist, and use the Rand.nextint (servercount) function to get a random number and return the random number as the index value of the uplist to the specific instance.

1.2.2.RoundRobinRule: Polling policy, select each service instance in a linear polling manner. The Atomicinteger Nextservercycliccounter object is implemented by calling the Incrementandgetmodulo function to increment each time the instance is selected.

1.2.3.RetryRule: Retry policy with instance selection for retry mechanism. The internal definition of the roundrobinrule, and the implementation of the roundrobinrule of repeated attempts to the policy, if the period can be selected to the specific service instance to return, if the selection is not in accordance with the set of attempted end time is the threshold, when the threshold value is returned null.

1.2.4.WeightedResponseTimeRule: Weight strategy, according to the operation of the instance to calculate the weight, and according to the weight to pick instances, in order to achieve better distribution effect. The weighted interval of the average response time (total average response time-the average response time of the instance) is large, and the strength selection is randomly selected according to the weight range, and the selected instance is chosen in which interval.

1.2.5.BestAvailableRule: The best strategy, by traversing all service instances maintained in the load balancer, filters out the failed instances and finds the one with the smallest number of concurrent requests, selecting the most idle instance.

1.2.6.AvailabilityFilteringRule: Available filtering strategy: First filter out the failed or concurrent request is greater than the threshold part of the service instance, and then a linear poll from the filtered list of instances to select one.

1.2.7.ZoneAvoidanceRule: Zone-aware strategy: Filter all instances using the main filter (area load, select optimal region) and return the filtered instance list, then filter the results of the primary filter using the filter conditions in the sub-filter list. Determine the minimum number of filters (default 1) and the minimum filter percentage (default 0), and use Roundrobinrule to select an instance if the condition is met.

2. Real

Load balancing is mainly configured on the consumer side, we use Feignclient to invoke the service

Adding references in 2.1. Pom

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-eureka</artifactId>

</dependency>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-feign</artifactId>

</dependency>

2.2. Start the class by adding the following annotations

@EnableEurekaClient

@EnableFeignClients

2.3. Consumer Client Configuration

@FeignClient (value= "Image-server-service")

Public interface Iimageserverclient {

@RequestMapping (value = "/upload")

Uploadimageresponsemodel Upload (@RequestBody uploadimagerequestmodel request);

}

When using @feignclient annotations, the Ribbon is used to load balance the client by default, so if we want to change the policy, we can add the configuration in config and configure it according to our own requirements, as follows:

@Bean

Public IRule Ribbonrule () {

Abstractloadbalancerrule

Availabilityfilteringrule

Bestavailablerule

Clientconfigenabledroundrobinrule

Predicatebasedrule

Randomrule

Retryrule

Roundrobinrule

Weightedresponsetimerule

Zoneavoidancerule

return new Roundrobinrule ();

}

2.4.0-Node hot-swappable test

The following service launches two instances, and we request that we can request according to the load policy.

Then close one of the instances, the system can call it normally, and then restart the closed instance, and the system will re-allocate the request past

Note: The default configuration, the client with the registry of the heartbeat time is longer, if not modified, will cause a short period of time the load will continue to allocate requests to close the instance below, it is recommended to configure the following configuration according to the situation, to ensure that the service is abnormal situation can be removed from the registry in time

Registration Center Configuration:

# If protected mode is turned on, the default is True

Eureka.server.enable-self-preservation=false

# Eureka Server cleans up the time interval for invalid nodes, default 60000 milliseconds, which is 60 seconds

eureka.server.eviction-interval-timer-in-ms=4000

Consumer-side configuration:

#每间隔1s, send a heartbeat to the server to prove that you are still "alive" by default of 30 seconds

Eureka.instance.lease-renewal-interval-in-seconds=1

#告诉服务端, if I did not give you a heartbeat within 2s, it means I "died" and kicked me out. Default is 90 seconds

eureka.instance.lease-expiration-duration-in-seconds=2

Second, the fuse

1. Concept

In a microservices architecture, there are often multiple service layer calls, and the failure of the underlying service can lead to cascading failures that could result in an entire system being unavailable, a phenomenon known as service avalanche effect. The service avalanche effect is a process in which the service consumer is not available and will not be usable due to the unavailability of the service provider.

The circuit breakers under Spring Cloud are hystrix, so we'll just look at the features of Hystrix:

1.1. Circuit breaker mechanism

Circuit Breaker It's good to understand that when the Hystrix command requests a backend service failure quantity exceeding a certain percentage (default 50%), the circuit breaker switches to the open State (open). At this point, all requests fail directly and are not sent to the backend service. The circuit breaker remains in the open state for some time (default 5 seconds), automatically switches to the semi-open state (Half-open). This will determine the return of the next request, if the request succeeds, the circuit breaker is switched back to the closed circuit (CLOSED), or re-switch to open mode (open). Hystrix Circuit breaker is like a fuse in our home circuit, once the backend service is unavailable, the circuit breaker will directly cut off the request chain, avoid sending a large number of invalid requests affecting the system throughput, and the circuit breaker has the ability to self-detect and recover.

1.2.Fallback

Fallback is equivalent to a downgrade operation. For the query operation, we can implement a fallback method that can use the value returned by the fallback method when the backend service is requested to have an exception. The return value of the fallback method is typically the default value for the setting or from the cache.

2. Real

Because the fuse only works at this end of the service invocation, we just need to change the consumer-side project-related code. Because feign already relies on hystrix, there is no need to make any changes to the MAVEN configuration.

2.1. Turn on the fuse mechanism

Add the following annotations on the startup class:

@EnableHystrix

2.2. Create a Callback class

Methods for creating Helloremotehystrix class inheritance and helloremote implementation callbacks

@Component

public class Helloremotehystrix implements helloremote{

@Override

public string Hello (@RequestParam (value = "name") string name) {

Return "Hello" +name+ ", this messge send failed";

}

}

2.3. Add Fallback property

Add the specified fallback class to the Helloremote class to return the contents of the fallback class when the service is fused.

@FeignClient (name= "Spring-cloud-producer", fallback = Helloremotehystrix.class)

Public interface Helloremote {

@RequestMapping (value = "/hello")

public string Hello (@RequestParam (value = "name") string name)

}

2.4. Testing

Disconnect the service, make the call, and the system will go down the downgrade method

And then restart the service, the system automatically calls normally

Spring Cloud Service Protection