springcloud重要组件（SpringCloud组件之Ribbon深入）

本文目录

• SpringCloud组件之Ribbon深入
• SpringCloud

SpringCloud组件之Ribbon深入

在上一节 SpringCloud组件之Ribbon 中，实现了一个Ribbon的Helloword,使用的是Spring Eureka 和Spring Ribbon结合使用，并且使用Ribbon的默认轮询注册清单的负载均衡策略。

Ribbon参数配置通常有两种方式：全局配置和知道客户端配置

通用格式：ribbon.《key》=《value》
key：表示参数名称
value：表示参数值
例如：全局配置Ribbon创建连接的超时时间

针对指定的服务进行配置 通用格式 《client》.ribbon.《key》=《value》
key：表示参数名称
value：表示参数值
client：表示客户端服务的名称
***隐藏网址***

下面将单独使用Spring Ribbon组件来介绍几种Ribbon负载均衡策略，单独使用Ribbon组件，不结合Eureka组件的不同之处在于，不能根据服务名称自动从Eureka的注册中心获取一个服务的实例清单，必须手动在配置文件中添加服务实例清单。

RandomRule策略：该策略实现了从服务实例清单中 随机选择 一个服务实例，作为请求服务对象。

首先创建一个SpringBoot的服务。
pom.xml

application.yaml

LoadBalanceController类

LoadBalanceMain类

***隐藏网址***

RoundRobinRule：该策略实现了按照 线性轮询 的方式一次轮询服务清单上的每个服务实例。

结合上面的例子，修改两个部分，一个是application.yaml中
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule

一个是LoadBalanceMain 中 修改ribbonRule()的返回值

RetryRule：该策略具备重试机制的实例选择功能，在给定时间内能够得到选择到具体的服务实例就返回，当超过时间还有没选到就返回null，参数maxRetryMillis控制这个超时时间。

WeightedResponseTimeRule：该策略是对RoundRobinRule的扩展，增加了根据实例的响应时间来计算权重，并从权重中选择对应的实例。该策略实现主要有三个核心内容

定时任务

WeightedResponseTimeRule策略在初始化的时候会启动一个定时任务，默认每隔30秒计算一次每个服务实例的权重

权重计算
累计所有实例的响应时间，得到总的totalResponseTime，然后为实例清单中的每个实例逐个计算权重，计算公式为
weightSoFar = weightSoFar + totalResponseTime - 该实例的平均响应时间
weightSoFar 起始为零
例子
有A，B，C，D四个实例，他们的平均响应时间是10,40,80,100，
计算总的响应时间10+40+80+100 =230
计算各个实例的权重
A: 230-10=220
B:220+(230-40)=410
C:410+(230-80)=560
D:560+(230-100)=690;
计算各个实例的权重区间
A:
B:(220,410]
C:(410,560]
D:(560,690)

实例选择
WeightedResponseTimeRule策略会在[0,最大权重值)之间随机选取一个数，然后在看这个数落在哪个实例的权重区间内，接着WeightedResponseTimeRule就会去选择该实例。

ClientConfigEnableRoundRobinRule：该策略一般不直接使用，有些高级的策略会继承该类，完成一些高级的策略，ClientConfigEnableRoundRobinRule策略默认使用
RoundRibinRule的线性轮询机制

BestAvailableRule策略继承ClientConfigEnableRoundRobinRule，通过遍历负载均衡中维护的所有服务实例，会过滤掉故障实例，并找出并发数请求数最小的实例，所以该策略的特性就是选出最空闲的实例

PredicateBasedRule策略继承ClientConfigEnableRoundRobinRule，该策略主要特性是“先过滤，在轮询”，也就是先过滤掉一些实例，得到过滤后的实例清单，然后轮询该实例清单，PredicateBasedRule中“过滤”功能没有实现，需要继承它的类完成，也就是说不同继承PredicateBasedRule的类有不同的“过滤特性”

AvailabilityFilteringRule策略继承PredicateBasedRule策略的“先过滤，在轮询”特性，
AvailabilityFilteringRule策略的过滤特性是
1：是否故障，即断路器是否生效已断开
2：实例的并发请求数大于阈值，默认2的32次方减一，该阈值可以通过
《clientName》.《nameSpace》.ActiveConnectionsLimit来设置，只要满足其中一个那么就会过滤掉

SpringCloud

微服务的优点:

1易于开发和维护,只需要关注每个服务的单独业务即可,不需要关心其他

2启动较快

3局部修改容易部署

4技术栈不受限

5按需伸缩

微服务的缺点:

1运维成本较高

3分布式复杂

4接口调整成本高

SpringCloud 的特点：

1约定优于配置
2开箱即用、快速启动

3适用于各种环境

4轻量级的组件,比如 服务发现组件 Eureka  ribbon  zuul

5组件的支持很丰富，功能很齐全 包含:配置中心,注册中心,智能路由

6选型中立 比如服务发现组件,不限制必须使用某一种,例如 Eureka,Zookeeper,Consul

Eureka作为服务注册中心，Eureka比Zookeeper好在哪里

著名的CAP理论指出，在一个分布式系统中， 一致性 （Consistency）、 可用性 （Availability）、分区容忍性（Partition tolerance 分区相当于对通信的时限要求）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
一致性（C）：在 分布式系统 中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：在集群中一部分节点故障后， 集群 整体是否还能响应 客户端 的读写请求。（对数据更新具备高可用性）

分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。

由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。

传统分布式的模式的缺点

传统式是通过restTemplate硬编码硬性指定ip和端口一旦ip和端口改变name系统直接瘫痪，这个ip和端口改变是不可避免的。

springcloud是通过eureka作为服务的发现也就是注册中心就可以解决这个问题
eureka的集群：

  就是多个服务之间互相依赖你中有我我中有你

失效剔除和自我保护
默认每间隔60s服务就会通过心跳检测，检测超过90s没有响应的服务就会剔除，这时候在eureka的面板上就会有提示。
Ribbin 负载均衡

工作原理：

第一步先选择 Eureka Server, 它优先选择在同一个Zone且负载较少的Server；第二步再根据用户指定的策略

负载均衡的侧率：

1默认轮训，

2，随机

3，根据响应速度

开启默认负载均衡只需要价格注解LoadBalanced

@Bean
@LoadBalanced

public RestTemplate restTemplate() {

    return new RestTemplate(new OkHttp3ClientHttpRequestFactory());

}

修改调用方式，不再手动获取ip和端口，而是直接通过服务名称调用：