Spring Cloud Ribbon

The D ' E ' let Spring Cloud Ribbon is an HTTP and TCP-based client load Balancing tool implemented based on the Netflix Ribbon. The Springcloud package allows us to easily convert service-oriented rest template requests automatically into client-side load-balanced service calls. Although the Spring CLoud ribbon is just a tool-class framework, it does not need to be deployed independently like the service registration Chinese heart, configuration center, API Gateway, but it almost exists in every Springcloud built microservices and infrastructure, because for calls between services, The request and forwarding of API gateway are actually implemented through the ribbon, including the feign we introduced later.

Client Load Balancing

Load balancing is a very important part of the system architecture and is something that has to be implemented. Because load balancing is one of the important means to the high availability of the system, the ease of network pressure and the capacity expansion of processing. The load balancer we usually call is server-side load balancing, which is divided into hardware load balancing and software load balancing. Hardware load balancing is primarily through the installation of devices dedicated to load balancing between server nodes, such as F5, and software load Balancing is done by installing some software with load balancing functions or modules on the server to complete the request distribution process. As long as the server load balancer can be built in a similar way:

Hardware load balancing devices or software load-balanced software modules maintain a service-side inventory that is available for a drop-down, and the heartbeat detects the failed service-side nodes to ensure that the list is a service-side node that can be accessed normally. When a client sends a request-path load-balancing device, the device takes an algorithm, such as a linear poll, to take the address of the day server from the list of available services maintained by the load of traffic, and then forwards it according to a load of weight.

The biggest difference between client load balancing and server-side load balancing is where the list of services mentioned above is stored. In client load balancing, all client nodes maintain the server-side inventory that they want to access, and the manifests from the service-side are from the service registry.

With the encapsulation of the spring Cloud Ribbon, we use client-side load-balancing calls in the MicroServices architecture to be very simple, requiring only the following two steps:

1. The service provider only needs to launch multiple service instances and register to a registry or multiple associated service registries.

2. Service consumers implement service-oriented interface calls directly by invoking Resttemplate that are modified by @loadbalanced annotations.

In this way, we can implement the high-availability and consumer load-balancing bars for service providers.

Resttemplate Detailed

Resttemplate, the object uses the Ribbon's automation configuration, while the configuration @loadbalanced also enables client load balancing to be turned on.

GET request

　　In Resttemplate, a GET request can be implemented by the following two methods.

POST request

　　In Resttemplate, the following three methods can be used to invoke the implementation of a POST request.

Put request

Delete request

Load Balancing Policy

　　

Each Ribbon client contains: Iloadbalancer, Restclient, Serverlistfilter, Serverlist,irule.

1. Iloadbalancer: Is the load-balanced entry class.
2. ServerList: Store all available nodes for remote service
3. Serverlistfilter: Used to filter illegal remote nodes (e.g., unavailable, etc.)
4. IRule: Load algorithm (policy) for selecting an appropriate node from the available nodes.
5. Restclient: Remote Call

　　　　

<dependency>       <groupId>org.springframework.cloud</groupId>       <artifactId> Spring-cloud-starter-ribbon</artifactid>   </dependency>

Load Balancing strategy for Ribbon

1, Roundrobinrule (polling mode) public class Roundrobinrule extends Abstractloadbalancerrule roundrobin mode Polling Select server Poll Index, select the server that corresponds to the index location The policy is also the default policy for the Ribbon

2, Randomrule (Random strategy) Public class Randomrule extends Abstractloadbalancerrule randomly select a server randomly on index, Select the server that corresponds to the index location.

3, Bestavailablerule (concurrent volume) Public class Bestavailablerule extends Clientconfigenabledroundrobinrule Select one of the smallest concurrent requests server-by-server , if the server is tripped, then ignore, select the server with the smallest activerequestscount

4, Availabilityfilteringrule (server status) Public class Availabilityfilteringrule extends Predicatebasedrule  Filter out back-end servers that are flagged as circuit tripped because they have failed to connect, and filter out those highly concurrent backend servers (active connections exceeds the configured threshold) The logic of using a availabilitypredicate to contain the filtering server is to check the status of each server that is logged in the status

5, Weightedresponsetimerule (according to response time) public class Weightedresponsetimerule extends Roundrobinrule according to the response time assigned a weight, The longer the corresponding time, the smaller the weight, the less likely it is to be selected. A background thread periodically reads the evaluation response time from the status and computes a weight for each server. The calculation of weight is also relatively simple responsetime minus each server's own average responsetime is the weight of the server. Use Roubine policy to select server when the Statas is not formed when it is first run.

6, Retryrule (according to policy + retry) public class Retryrule extends Abstractloadbalancerrule on the selected load Balancing policy machine retry mechanism. During a configuration time period when the server selection is unsuccessful, try to select an available server using the Subrule method

7, Zoneavoidancerule (Zone status + Service status) public class Zoneavoidancerule extends Predicatebasedrule compound to determine the performance of the server area and the availability of the server Select Server uses Zoneavoidancepredicate and availabilitypredicate to determine whether to select a server , the previous decision determines whether a zone's performance is available, rejects the unavailable zone (all servers), and availabilitypredicate is used to filter out servers with too many connections.

Automation configuration

Because each interface defined in the Ribbon has a number of different policy implementations, and there is a dependency between these interfaces, it makes it difficult for developers to use the Ribbon for the first time, not knowing how to choose specific implementation strategies and how to organize their relationships. The automation configuration in the Spring Cloud ribbon solves such pain points, and since the introduction of Springcloudribbon, it is possible to automate the implementation of these interfaces.

With the implementation of the automation configuration, we can easily implement client load balancing and, for some individual needs, we can easily replace these default implementations above.

You can override these default configuration implementations by simply creating the corresponding application instance in the Springboot application.

Retry mechanism

Spring Cloud Ribbon