spring cloud6负载均衡

一、负载均衡
负载均衡不仅仅是ribbon,还包括zuul
1，客户端的负载均衡：ribbon
负载均衡作为客户端应用的一部分？
负载均衡部署在客户端
优势：稳定性高
不足：升级成本高
2，服务端的负载均衡：zuul
负载均衡部署在服务端，作为一个单独的应用去管理负载均衡，
优势：成本低，统一维护
不足：一旦故障，影响大

二、RestTemplate
序列化/反序列化：HttpMessageConverter，MIMEType
实现适配：ClientHttpRequestFactory，RestTemplate有多种适配，HttpClient，OkHttp
请求拦截：ClientHttpRequestInterceptor，netflix ribbon的基础，增加了一些拦截起来拦截请求。

public RestTemplate(ClientHttpRequestFactory requestFactory) {
        this();
        setRequestFactory(requestFactory);
    }

通过应用名称(service-id)直接调用。

三、Client Side Load Balancer: Ribbon
用 ribbon实现的负载均衡，实际上还是客户端的负载均衡
ribbon-client去调用service-provider，我们的负载均衡是在ribbon-client端做的，所以其实是客户端的负载均衡。
ribbon的负载均衡一般是用于对于一个service-id的服务列表做负载均衡，通常这些服务列表都是相同的应用。纯粹是集群的扩展。
如果要定向路由还是使用zuul。
所有的应用都注册在eureka，如果有某个服务实例down了，client是可以感知到的，因为大家都在eureka上，client也会定期去拉取服务列表信息。后面的请求就不会转给那个挂掉的服务器。

四、负载均衡相关策略 ，如何实现动态的负载均衡？
实际请求客户端
• LoadBalancerClient
• RibbonLoadBalancerClient
• 负载均衡上下⽂
• LoadBalancerContext
• RibbonLoadBalancerContext
步骤：
1，负载均衡器：ILoadBalancer
DynamicServerListLoadBalancer
负责去找要调用的服务，可能该服务有多个实例，找到这些服务实例的地址
2，负载均衡规则：IRule
如何使用负载均衡器找到的这些服务列表，选择一个服务实例进行调用。
3，PING策略：
虽然有了IRule，但是我们要验证该规则是否可行，需要ping下服务实例是否可用，只有可用的服务才会被发送请求。没有ping通过的服务实例，就不会给它发送请求。
interface：IPingStrategy