1. 负载均衡介绍

1.1 问题描述

观察上个章节远程调⽤的代码

1. 根据应⽤名称获取了服务实例列表
2. 从列表中选择了⼀个服务实例

思考: 如果⼀个服务对应多个实例呢? 流量是否可以合理的分配到多个实例呢?

现象观察:

我们再启动2个product-service实例
选中要启动的服务, 右键选择 Copy Configuration…

在弹出的框中, 选择 Modify options -> Add VM options

添加 VM options : -Dserver.port=9091

9091 为服务启动的端⼝号, 根据⾃⼰的情况进⾏修改

现在IDEA的Service窗⼝就会多出来⼀个启动配置, 右键启动服务就可以

同样的操作, 再启动1个实例, 共启动3个服务

观察Eureka, 可以看到product-service下有三个实例:

访问结果:

通过⽇志可以观察到, 请求多次访问, 都是同⼀台机器.
这肯定不是我们想要的结果, 我们启动多个实例, 是希望可以分担其他机器的负荷, 那么如何实现呢?

解决⽅案:

通过⽇志可以看到, 请求被均衡的分配在了不同的实例上, 这就是负载均衡

1.2 什么是负载均衡

负载均衡(Load Balance，简称 LB) , 是⾼并发, ⾼可⽤系统必不可少的关键组件

当服务流量增⼤时, 通常会采⽤增加机器的⽅式进⾏扩容, 负载均衡就是⽤来在多个机器或者其他资源中, 按照⼀定的规则合理分配负载.

⼀个团队最开始只有⼀个⼈, 后来随着⼯作量的增加, 公司⼜招聘了⼏个⼈. 负载均衡就是: 如何把⼯作量均衡的分配到这⼏个⼈⾝上, 以提⾼整个团队的效率

1.3 负载均衡的⼀些实现

上⾯的例⼦中, 我们只是简单的对实例进⾏了轮询, 但真实的业务场景会更加复杂. ⽐如根据机器的配置进⾏负载分配, 配置⾼的分配的流量⾼, 配置低的分配流量低等.

服务多机部署时, 开发⼈员都需要考虑负载均衡的实现, 所以也出现了⼀些负载均衡器, 来帮助我们实现负载均衡.

负载均衡分为服务端负载均衡和客⼾端负载均衡

服务端负载均衡

在服务端进⾏负载均衡的算法分配.

⽐较有名的服务端负载均衡器是Nginx. 请求先到达Nginx负载均衡器, 然后通过负载均衡算法, 在多个服务器之间选择⼀个进⾏访问

客⼾端负载均衡

在客⼾端进⾏负载均衡的算法分配

把负载均衡的功能以库的⽅式集成到客⼾端, ⽽不再是由⼀台指定的负载均衡设备集中提供.

⽐如Spring Cloud的Ribbon, 请求发送到客⼾端, 客⼾端从注册中⼼(⽐如Eureka)获取服务列表, 在发送请求前通过负载均衡算法选择⼀个服务器,然后进⾏访问.

Ribbon是Spring Cloud早期的默认实现, 由于不维护了, 所以最新版本的Spring Cloud负载均衡集成的是Spring Cloud LoadBalancer(Spring Cloud官⽅维护)

客⼾端负载均衡和服务端负载均衡最⼤的区别在于服务清单所存储的位置

2. Spring Cloud LoadBalancer