1, Meet Ribbon

1.1 what is Ribbon

Ribbon is a customer service load balancing tool based on HTTP and TCP, which is implemented based on Netflix Ribbon. It is not deployed independently like the Spring Cloud service registry, configuration center and API gateway, but it exists in almost every Spring Cloud micro service. Including the declarative service call provided by Feign is also based on the ribbon implementation.

1.2 why use Ribbon

Ribbon provides a set of load balancing solutions for microservices. At present, the mainstream load balancing schemes in the industry can be divided into two categories:

Serial number	category
1	Centralized load balancing (server load balancing), that is, an independent load balancing facility (which can be hardware, such as F5, or software, such as nginx) is used between the consumer and the provider, which is responsible for forwarding access requests to the provider through some policy;
2	Intra process load balancing (client load balancing) integrates the load balancing logic into the consumer. The consumer knows which addresses are available from the service registry, and then selects an appropriate provider from these addresses. The Ribbon belongs to the latter. It is just a class library integrated into the consumer process, through which the consumer obtains the address of the provider.

2, Ribbon introduction case

All our next operations are carried out on the project completed by * * Eureka** day01-day02

2.1 adding a service provider

Since we want to do service load balancing, there must be many services. How to load balance a service is still his own. Therefore, we need to add a service provider on the basis of the original project. The configuration is basically the same as that of the service provider, except that the port is different. Next, we will give specific different configurations.

2.1. 1 right click New Module

2.1. 2 select the SpringBoot project

2.1. 3. Modify project name

2.1. 4 add dependency

2.1. 5. Modify yml configuration file

server:
  port: 8002

spring:
  application:
    #The name should be consistent in cluster mode
    name: service-provider

eureka:
  instance:
    #Whether to register with ip address
    prefer-ip-address: true
    #The unique ID of the instance registered with the service center
    instance-id: ${spring.cloud.client.ip-address}:${server.port}
  client:
    #Set service registry address
    service-url:
      defaultZone: http://localhost:7001/eureka/,http://localhost:7002/eureka/

2.1. 6. Modify the controllers of the two service providers respectively

Add a new method: the code is as follows:

Add to port 8001:

@RequestMapping("/provider/item/getById")
    public String getById(@RequestParam("id") Integer id){
    return "8001 getById ...";
}

Add in port 8002:

@RequestMapping("/provider/item/getById")
    public String getById(@RequestParam("id") Integer id){
    return "8002 getById ...";
}

2.1. 7 start registry, service provider

1. Start Eureka server7001
2. Start eureka-server7002
3. Start service-provider8001
4. Start service-provider8002

2.2 modifying service consumers

2.2. 1. Method 1: LoadBalancerClient

(1) Modify the ItemController controller code of the service consumer and add the following code inside

// Ribbon load balancer
// import org.springframework.cloud.client.loadbalancer.LoadBalancerClient;
    @Autowired
    private LoadBalancerClient loadBalancerClient;

    @RequestMapping("/consumer/item/getById")
    public String findByPid(@RequestParam("id") Integer id) {
        //Get an instance object of the SERVICE-PROVIDER service from the registry
        ServiceInstance si = loadBalancerClient.choose("SERVICE-PROVIDER");
        if (si == null) {
            return null;
        }

        String getByIdUrl = si.getUri() + "/provider/item/getById" + "?id=" + id;
        String product = restTemplate.getForObject(getByIdUrl, String.class);
        return product;
        //Here is only a string returned by simulation. Of course, you can also return a commodity object, which depends on you
    }

(2) Start consumer request
http://localhost:9001/consumer/item/getById?id=1
If you refresh repeatedly, you will find that it will be called back and forth in 8001-8002 each time

2.2. 2. Mode 2: @ LoadBalanced

(1) Modify the main startup class code of service consumer. The modified code is as follows:

(2) Add the following method to the ItemController controller code

@RequestMapping("/consumer/item/getById2")
    public String findByPid2(@RequestParam("id") Integer id) {
        String findByPidUrl = "http://SERVICE-PROVIDER/provider/item/getById" + "?id=" + id;
        String product = restTemplate.getForObject(findByPidUrl, String.class);
        System.out.println(product);
        return product;
    }

(3) Restart the consumer for access testing

http://localhost:9001/consumer/item/getById2?id=1
The effect will be the same as mode 1

3, Ribbon load balancing strategy

3.1 polling policy (default)

Implementation principle:

• The polling policy means that one provider is taken down in sequence each time. For example, there are five providers in total. The first provider is taken for the first time, the second provider for the second time, the third provider for the third time, and so on.

3.2 weight polling strategy

Implementation principle:

• A weight is assigned according to the response time of each provider. The longer the response time, the smaller the weight, and the lower the possibility of being selected.
• Principle: start with the polling strategy and start a timer to collect the average response time of each provider every 30 seconds. When the information is sufficient, attach a weight to each provider and randomly select the provider according to the weight. The provider with higher weight will be selected with high probability.

3.3 random strategy

Implementation principle:

• Select one at random from the list of provider s.

3.4 minimum concurrency strategy

Implementation principle:

• Select the provider with the smallest number of concurrency in the request, unless the provider is in use.

3.5 retry strategy

Implementation principle:

• In fact, it is an enhanced version of polling policy. When the polling policy service is unavailable, it will not be processed. When the retry policy service is unavailable, it will retry other nodes in the cluster.

3.6. Availability sensitive strategy

Implementation principle: provider with poor filtering performance

• The first is to filter out the provider s in Eureka that have failed to connect all the time.
• Second: filter out highly concurrent (busy) provider s.

3.7 regional sensitivity strategy

Implementation principle:

• The availability is evaluated by one area. The unavailable areas are discarded, and the available provider s are selected from the remaining areas.
• If one or more instances in the ip area are unreachable or the response is slow, the weight of other ip selected in the ip area will be reduced.