在上一章，我介紹了springcloud的eureka搭建，我們做了服務注冊，最后我們還介紹了一些續約，失效剔除等引數配置，已經不需要再通過手動輸入ip去訪問服務，而是通過中心只需要通過服務名就可以獲取服務，這一章我們將要學習一下Ribbon負載均衡

上一章：（二 什么是Eureka服務注冊中心，如何搭建？）手摸手帶你一起搭建 Spring cloud 微服務 理論+實踐+決議

一、Ribbon是什么？

負載均衡顧名思義，平均每臺服務器的壓力，實際開發程序中，同一種服務可能有多個服務器，即服務集群，這個時候為了保證這個型別的服務每臺服務負載平均分配，
Ribbon是Netfix發布的負載均衡器，他有助于控制HTTP和TCP客戶端的行為，為Ribbon配置服務提供者地址串列后，Ribbon就可以基于某種負載均衡演算法，自動幫助服務消費者去請求，

我們上一章的例程是通過服務名獲取完服務集合，serviceInstances.get(0) 可以看到總是獲取第一個，因為我們當時只有一個user-service，這樣顯然是不對的，

 List<ServiceInstance> serviceInstances= discoveryClient.getInstances("user-service");
 String url = "http://"+serviceInstances.get(0).getHost()+":"+serviceInstances.get(0).getPort()+"/user/"+id;

所以我們需要根據演算法，每次去選取合適的服務器，進行訪問，
Ribbon默認為我們提供了很多負載均衡演算法，我們先了解一下ribbon負載均衡有幾種策略，也就是演算法，

二、ribbon負載均衡有幾種策略

1、隨機策略RandomRule

從名字就能看出，這是個很隨性的策略，隨性到什么程度呢?它會從當前可用的服務節點中，隨機挑選一個節點訪問，媽的真隨便，比我還隨便，

2、輪詢策略RoundRobinRule（默認策略）

這個rule是RandomRule的親兄弟，RandomRule是隨性而為挑選節點，RobinRule卻按部就班從一個節點一步一步地向后選取節點，既不會跳過一個，也不會原地踏步，每一次只向后移動一步，

3、重試策略RetryRule

RetryRule他的BUFF就是給其他負載均衡策略加上重試功能，而在RetryRule里還藏著一個subRule ,這才是隱藏在下面的真正被執行的負載均衡策略，RetryRule正是要為它添加重試功能(如果初始化時沒指定subRule，將默認使用RoundRibinRule )

4、最低并發策略BestAvailableRule

這個Rule繼承自RoundRibonRule ，他會根據服務節點的回應時間計算權重，回應時間越長權重就越低，回應越快則權重越高，權重的高低決定了機器被選中概率的低，也就是說，回應時間越小的機器，被選中的概率越大，

5、可用過濾策略AvailabilityFilteringRule

應該說這個Rule有點智能的味道了，在過濾掉故啤服務以后，它會基于過去30分鐘的統計結果選取當前并發量最小的服務節點，也就是最%閑”"的節點作為目標地址，如果統計結果尚未生成，則采用輪詢的方式選定節點，

6、回應時間加權策略WeightedResponseTimeRule

這個規則底層依賴RoundRobinRule來選取節點，但并非來者不拒，它也是有一些底線的，必須要滿足它的最低要求的節點才會被選中，如果節點滿足了要求，無論其回應時間或者當前并發量是什么，都會被選中，
每次AvailabilityFilteringRule(簡稱AFR）都會請求RobinRule挑選一個節點，然后對這個節點做以下兩步檢查:
是否處于熔斷狀態（這里大家可以把熔斷當做服務不可用)
節點當前的active請求連接數超過閾值，超過了則表示節點目前太忙，不適合接客
如果被選中的server不幸掛掉了檢查，那么AFR會自動重試（次數最多10次），讓RobinRule重新選擇一個服務節點，

7、區域權衡策略ZoneAvoidanceRule

這個過濾器包含了組合過濾條件，分別是Zone級別和可用性級別，
ZoneFilter:在Eureka注冊中一個服務節點有Zone,Region和URL三個身份資訊，其中Zone可以理解為機房大區（未指定則由Eureka給定默認值)，而這里會對這個Zone的健康情況過濾其下面所有服務節點，
可用性過濾∶這里和AvailabilityFilteringRule的驗證非常像，會過濾掉當前并發量較大，或者處于熔斷狀態的服務節點，

二、Ribbon測驗

同樣，我們的例程是用上一章的例程接著往下做
上個章節例程

2.1 copy出一個user服務

首先copy出一個新的user-service
如何復制工程
我給它命名為user-service-other
設定埠為1002

為了方便查看效果，我們修改一下啟動類名，和回應內容

如果你發現啟動eureka時，有報錯很正常，因為上個章節我們做了eureka集群，所以我們取消集群就行，修改一下eureka配置即可

server:
  port: 11111
spring:
  application:
    name: eureka-server
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:11111/eureka
    register-with-eureka: false
    fetch-registry: false
  server:
    eviction-interval-timer-in-ms: 60000
    enable-self-preservation: true

然后運行測驗一下eureka和兩個user-service，看看工程是否復制成功
eureka中心可以看到兩個user-service注冊了

且能夠通過1002埠訪問回傳資訊

2.2 修改消費服務custom-service

首先在啟動類CustomService的RestTemplate配置上加上負載均衡注解@LoadBalanced

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

@SpringBootApplication
@EnableEurekaClient
public class CustomService {
    public static void main(String[] args) {
        SpringApplication.run(CustomService.class, args);
    }
    @Bean
    @LoadBalanced //負載均衡
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

修改UserHandler，訪問的方式改為直接通過服務名的方式獲取服務，原本需要獲取ip處，我們直接換成服務名，

import org.antry.service.UserService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cloud.client.ServiceInstance;
import org.springframework.cloud.client.discovery.DiscoveryClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;

import java.util.List;

/**
 * @ClassName UserHandler
 * @Description TODO
 * @Autor T_Antry
 * @Date 2020/11/11 11:32
 * @Version 1.0
 */
@RestController
@RequestMapping("user")
public class UserHandler {
    @Autowired
    private RestTemplate restTemplate;
    @Autowired
    private UserService userService;
    @Autowired
    private DiscoveryClient discoveryClient;
    @GetMapping("/{id}")
    public String doGet(@PathVariable Long id){
//       String url = "http://127.0.0.1:1001/user/"+id;
//       return "<div><h1>custom-Service回應：</h1><div>"+restTemplate.getForObject(url, String.class);
//       return userService.doGetUser(id);
//         List<ServiceInstance> serviceInstances= discoveryClient.getInstances("user-service");
//         String url = "http://"+serviceInstances.get(0).getHost()+":"+serviceInstances.get(0).getPort()+"/user/"+id;
         String url = "http://user-service/user/"+id;
        return "<div><h1>custom-Service[通過注冊中心拉取服務]回應：</h1><div>"+restTemplate.getForObject(url, String.class);
    }
}

2.3 運行

如果之前的eureka和兩個user-service沒關的話，直接運行custom-service就可以，如果關了，再運行起來，然后運行custom-service
在地址欄輸入http://127.0.0.1:9001/user/123，因為custom的工程埠我們在之前的案例中給它設定成9001埠
一直重繪，我們可以看到，拿到是來自兩個不同服務的回應，這是默認的輪詢策略

2.4 如何修改策略

在消費者服務的組態檔中按下面個規則修改，
這個案例是給user-service配置策略為隨機策略
配置完重新運行工程，會發現，回應不再像上面那樣有規律地變化，而是無規律的回應了，

user-service: #要配置策略的服務名
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule  #要配置的策略名

本章資源
原本我選擇0幣下載，但是會自動要求收幣，所以只好改成關注免費下載，