四、Ribbon负载均衡

上一节中，我们添加了 @LoadBalanced 注解，即可实现负载均衡功能，这是什么原理呢？

1、负载均衡原理

SpringCloud 底层其实是利用了一个名为 Ribbon 的组件，来实现负载均衡功能的。

负载均衡流程：

那么我们发出的请求明明是 http://userservice/user/1 ，怎么变成了 http://localhost:8081 的呢？

2、源码跟踪

为什么我们只输入了 service 名称就可以访问了呢？之前还要获取 ip 和端口。

显然有人帮我们根据 service 名称，获取到了服务实例的 ip 和端口。它就是 LoadBalancerInterceptor，这个类会对 RestTemplate 的请求进行拦截，然后从 Eureka 根据服务 id 获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务 id。

我们进行源码跟踪：

2.1、LoadBalancerIntercepor

可以看到这里的 intercept 方法，拦截了用户的 HttpRequest 请求，然后做了几件事：

request.getURI()：获取请求 URI，本例中就是 http://user-service/user/8
originalUri.getHost()：获取 URI 路径的主机名，其实就是服务 id，即user-service
this.loadBalancer.execute()：处理服务 id，和用户请求。

这里的 this.loadBalancer 是 LoadBalancerClient 类型，我们继续跟入。

2.2、LoadBalancerClient

继续跟入 execute 方法：

代码是这样的：

getLoadBalancer(serviceId)：根据服务 id 获取 ILoadBalancer，而 ILoadBalancer 会拿着服务 id 去 eureka 中获取服务列表并保存起来。
getServer(loadBalancer)：利用内置的负载均衡算法，从服务列表中选择一个。本例中，可以看到获取了 8082 端口的服务

放行后，再次访问并跟踪，发现获取的是 8081：

果然实现了负载均衡。

2.3、负载均衡策略 IRule

在刚才的代码中，可以看到获取服务是通过一个 getServer 方法来做负载均衡：

我们继续跟入：

继续跟踪源码 chooseServer 方法，发现这么一段代码：

我们看看这个 rule 是谁：

这里的 rule 默认值是一个 RoundRobinRule，看类的介绍：

这不就是轮询的意思嘛。

到这里，整个负载均衡的流程我们就清楚了。

2.4、总结

SpringCloudRibbon 的底层采用了一个拦截器，拦截了 RestTemplate 发出的请求，对地址做了修改。用一幅图来总结一下：

基本流程如下：

拦截 RestTemplate 请求 http://userservice/user/1
RibbonLoadBalancerClient 会从请求 url 中获取服务名称，也就是 user-service
DynamicServerListLoadBalancer 根据 user-service 到 eureka 拉取服务列表
eureka 返回列表，localhost:8081、localhost:8082
IRule 利用内置负载均衡规则，从列表中选择一个，例如 localhost:8081
RibbonLoadBalancerClient 修改请求地址，用 localhost:8081 替代 userservice，得到 http://localhost:8081/user/1 ，发起真实请求

3、负载均衡策略

3.1、负载均衡策略

负载均衡的规则都定义在 IRule 接口中，而 IRule 有很多不同的实现类：

不同规则的含义如下：

内置负载均衡规则类	规则描述
RoundRobinRule	简单轮询服务列表来选择服务器。它是 Ribbon 默认的负载均衡规则。
AvailabilityFilteringRule	对以下两种服务器进行忽略：（1）在默认情况下，这台服务器如果 3 次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续 30 秒，如果再次连接失败，短路的持续时间就会几何级地增加。（2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了 AvailabilityFilteringRule 规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的 \.\.ActiveConnectionsLimit 属性进行配置。
WeightedResponseTimeRule	为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。
ZoneAvoidanceRule	以区域可用的服务器为基础进行服务器的选择。使用 Zone 对服务器进行分类，这个 Zone 可以理解为一个机房、一个机架等。而后再对 Zone 内的多个服务做轮询。
BestAvailableRule	忽略那些短路的服务器，并选择并发数较低的服务器。
RandomRule	随机选择一个可用的服务器。
RetryRule	重试机制的选择逻辑

默认的实现就是 ZoneAvoidanceRule，是一种轮询方案

3.2、自定义负载均衡策略

通过定义 IRule 实现可以修改负载均衡规则，有两种方式：

1、代码方式：在 order-service 中的 OrderApplication 类中，定义一个新的 IRule：

作用范围为全体，即 orderservice 访问任何微服务都会按修改后的规则

@Bean
public IRule randomRule(){
    return new RandomRule();
}

2、配置文件方式：在 order-service 的 application.yml 文件中，添加新的配置也可以修改规则：

只针对某个服务而言

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

注意，一般用默认的负载均衡规则，不做修改。

4、饥饿加载

Ribbon 默认是采用懒加载，即第一次访问时才会去创建 LoadBalanceClient，请求时间会很长。

而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，在 order-service 的 application.yml 文件通过下面配置开启饥饿加载：

ribbon:
  eager-load:
    enabled: true # 开启饥饿加载
    clients: userservice # 指定饥饿加载的服务名称

5、总结

Ribbon负载均衡规则
- 规则接口是 IRule
- 默认实现是 ZoneAvoidanceRule，根据 zone 选择服务列表，然后轮询
负载均衡自定义方式
- 代码方式：配置灵活，但修改时需要重新打包发布
- 配置方式：直观，方便，无需重新打包发布，但是无法做全局配置
饥饿加载
- 开启饥饿加载
- 指定饥饿加载的微服务名称

五、Nacos注册中心

国内公司一般都推崇阿里巴巴的技术，比如注册中心，SpringCloudAlibaba 也推出了一个名为 Nacos 的注册中心。

1、认识和安装Nacos

Nacos 是阿里巴巴的产品，现在是 SpringCloud 中的一个组件。相比 Eureka 功能更加丰富，在国内受欢迎程度较高。

1.1、Windows安装

开发阶段采用单机安装即可。

下载安装包

在 Nacos 的 GitHub 页面，提供有下载链接，可以下载编译好的 Nacos 服务端或者源代码：

GitHub主页：https://github.com/alibaba/nacos

GitHub 的 Release 下载页：https://github.com/alibaba/nacos/releases

如图：

解压

将这个包解压到任意非中文目录下，如图：

目录说明：

bin：启动脚本
conf：配置文件

端口配置

Nacos 的默认端口是 8848，如果你电脑上的其它进程占用了 8848 端口，请先尝试关闭该进程。

如果无法关闭占用 8848 端口的进程，也可以进入 nacos 的 conf 目录，修改配置文件中的端口：

修改其中的内容：

启动

启动非常简单，进入 bin 目录，结构如下：

然后执行命令即可：

windows 命令：
```
startup.cmd -m standalone
```

执行后的效果如图：

访问

在浏览器输入地址：http://127.0.0.1:8848/nacos 即可：

默认的账号和密码都是 nacos，进入后：

1.2、Linux安装

Linux 或者 Mac 安装方式与 Windows 类似。

安装JDK

Nacos 依赖于 JDK 运行，所以 Linux 上也需要安装 JDK 才行。

上传 jdk 安装包到某个目录，例如：/usr/local/

然后解压缩：

tar -xvf jdk-8u144-linux-x64.tar.gz

然后重命名为 java

配置环境变量：

export JAVA_HOME=/usr/local/java
export PATH=$PATH:$JAVA_HOME/bin

设置环境变量：

source /etc/profile

上传安装包

如图：

将 tar.gz 上传到 Linux 服务器的某个目录，例如 /usr/local/src 目录下：

解压

命令解压缩安装包：

tar -xvf nacos-server-1.4.1.tar.gz

然后删除安装包：

rm -rf nacos-server-1.4.1.tar.gz

目录中最终样式：

目录内部：

端口配置

与 windows 中类似

启动

在 nacos/bin 目录中，输入命令启动 Nacos：

sh startup.sh -m standalone

1.3、Nacos的依赖

父工程：

<!--Nacos的管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.5.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

客户端：

<!-- nacos客户端依赖包 -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

2、服务注册到nacos

Nacos 是 SpringCloudAlibaba 的组件，而 SpringCloudAlibaba 也遵循 SpringCloud 中定义的服务注册、服务发现规范。因此使用 Nacos 和使用 Eureka 对于微服务来说，并没有太大区别。

主要差异在于：

依赖不同
服务地址不同

2.1、引入依赖

在 cloud-demo 父工程的 pom 文件中的 <dependencyManagement> 中引入 SpringCloudAlibaba 的依赖：

<!--Nacos的管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.6.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

然后在 user-service 和 order-service 中的 pom 文件中引入 nacos-discovery 依赖：

<!-- nacos客户端依赖包 -->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

注意：不要忘了注释掉 eureka 的依赖。

2.2、配置 nacos 地址

在 user-service 和 order-service 的 application.yml 中添加 nacos 地址：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848

注意：不要忘了注释掉 eureka 的地址

2.3、重启

重启微服务后，登录 nacos 管理页面，可以看到微服务信息：

3、服务分级存储模型

一个服务可以有多个实例，例如我们的 user-service，可以有:

127.0.0.1:8081
127.0.0.1:8082
127.0.0.1:8083

假如这些实例分布于全国各地的不同机房，例如：

127.0.0.1:8081，在上海机房
127.0.0.1:8082，在上海机房
127.0.0.1:8083，在杭州机房

Nacos 就将同一机房内的实例划分为一个集群。

也就是说，user-service 是服务，一个服务可以包含多个集群，如杭州、上海，每个集群下可以有多个实例，形成分级模型，如图：

微服务互相访问时，应该尽可能访问同集群实例，因为本地访问速度更快。当本集群内不可用时，才访问其它集群。例如：

杭州机房内的 order-service 应该优先访问同机房的 user-service。

3.1、给user-service配置集群

修改 user-service 的 application.yml 文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 配置集群名称，也就是机房位置，例如：HZ杭州

重启两个 user-service 实例后，我们可以在 nacos 控制台看到下面结果：

我们再次复制一个 user-service 启动配置，添加属性：

-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=SH

配置如图所示：

启动 UserApplication3 后再次查看 nacos 控制台：

总结：

Nacos服务分级存储模型

一级是服务，例如 userservice

二级是集群，例如杭州或上海

三级是实例，例如杭州机房的某台部署了 userservice 的服务器

如何设置实例的集群属性

修改 application.yml 文件，添加 spring.cloud.nacos.discovery.cluster-name 属性即可

3.2、同集群优先的负载均衡

默认的 ZoneAvoidanceRule 并不能实现根据同集群优先来实现负载均衡。

因此 Nacos 中提供了一个 NacosRule 的实现，可以优先从同集群中挑选实例。

给 order-service 配置集群信息

修改 order-service 的 application.yml 文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称

修改负载均衡规则

修改 order-service 的 application.yml 文件，修改负载均衡规则：

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则

总结：NacosRule 负载均衡策略

优先选择同集群服务实例列表

本地集群找不到提供者，才去其它集群寻找，并且会报警告

确定了可用实例列表后，再采用随机负载均衡挑选实例

4、权重配置

实际部署中会出现这样的场景：

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。

但默认情况下 NacosRule 是同集群内随机挑选，不会考虑机器的性能问题。

因此，Nacos 提供了权重配置来控制访问频率，权重越大则访问频率越高。

在 nacos 控制台，找到 user-service 的实例列表，点击编辑，即可修改权重：

在弹出的编辑窗口，修改权重，将权重设置为 0.1，测试可以发现 8081 被访问到的频率大大降低

注意：

Nacos 控制台可以设置实例的权重值，0~1之间

同集群内的多个实例，权重越高被访问的频率越高

如果权重修改为0，则该实例永远不会被访问

5、环境隔离

Nacos 提供了 namespace 来实现环境隔离功能，比如基于开发测试生产环境不同做隔离。

nacos 中可以有多个 namespace
namespace 下可以有 group、service 等
不同 namespace 之间相互隔离，例如不同 namespace 的服务互相不可见

5.1、创建 namespace

默认情况下，所有 service、data、group 都在同一个 namespace，名为 public：

我们可以点击页面新增按钮，添加一个namespace：

然后，填写表单：

就能在页面看到一个新的 namespace：

5.2、给微服务配置 namespace

给微服务配置 namespace 只能通过修改配置来实现。

例如，修改 order-service 的 application.yml 文件：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID

重启 order-service 后，访问控制台，可以看到下面的结果：

此时访问 order-service，因为 namespace 不同，会导致找不到 userservice，控制台会报错：

总结：

每个 namespace 都有唯一 id

服务设置 namespace 时要写 id 而不是名称

不同 namespace 下的服务互相不可见

6、Nacos与Eureka的区别

Nacos 的服务实例分为两种类型：

临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。
非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

配置一个服务实例为永久实例：

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

Nacos 和 Eureka 整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：

Nacos 与 eureka 的共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
Nacos 与 Eureka 的区别
- Nacos 支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
- 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
- Nacos 支持服务列表变更的消息推送模式，服务列表更新更及时
- Nacos 集群默认采用 AP 方式，当集群中存在非临时实例时，采用 CP 模式；Eureka 采用 AP 方式

参考视频：SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务

四、Ribbon负载均衡

1、负载均衡原理

2、源码跟踪

2.1、LoadBalancerIntercepor

2.2、LoadBalancerClient

2.3、负载均衡策略 IRule

2.4、总结

3、负载均衡策略

3.1、负载均衡策略

3.2、自定义负载均衡策略

4、饥饿加载

5、总结

五、Nacos注册中心

1、认识和安装Nacos

1.1、Windows安装

下载安装包

解压

端口配置

启动

访问

1.2、Linux安装

安装JDK

上传安装包

解压

端口配置

启动

1.3、Nacos的依赖

2、服务注册到nacos

2.1、引入依赖

2.2、配置 nacos 地址

2.3、重启

3、服务分级存储模型

3.1、给user-service配置集群

3.2、同集群优先的负载均衡

4、权重配置

5、环境隔离

5.1、创建 namespace

5.2、给微服务配置 namespace

6、Nacos与Eureka的区别

发送评论 编辑评论

发送评论编辑评论