负载均衡的原理、分类、实现架构，以及使用场景。

前言：针对这个话题，我们要知道，为什么 需要负载均衡，负载均衡的原理，负载均衡的原理，负载均衡的分类。

 

 

一、首先说一下为什么需要负载均衡

          当系统面临 大量用户访问的时候，负载过高的时候。通常会使用增加服务器数量来横向扩展，从单机网站到分布式网站，很重要的区别就是业务拆分和分布式部署。将应用拆分后，部署到不同的机器上，实现大规模分布式系统。分布式和业务拆分解决了，从集中到分布的问题，但是每个部署的独立业务还存在单点的问题和访问统一入口问题。为解决单点故障，我们可以采取冗余的方式，将相同的应用部署到多台机器上。解决访问统一入口问题。我们可以在集群前面增加负载均衡设备，实现流量分发。

 

      二、负载均衡的原理

         系统的扩展可分为纵向（垂直）扩展和横向（水平）扩展。纵向扩展，是从单机的角度通过增加硬件处理能力，比如CPU处理能力，内存容量，磁盘等方面，实现服务器处理能力的提升，不能满足大型分布式系统（网站），大流量，高并发，海量数据的问题。所以需要采用横向可扩展的方式。通过添加机器来满足大型网站服务的处理能力。

将同一应用部署到多台机器上，组成处理集群，接收负载均衡设备分发的请求，进行处理，并返回相应数据。将用户访问的请求，根据负载均衡算法，分发到集群中的一台处理服务器。以上就是负载均衡的原理

 

三、负载均衡的作用

 解决并发压力，提高应用处理性能。

提供故障转移，实现高可用。

通过添加或减少服务器数量，提供网站的伸缩性（扩展性）。

安全保护（可在负载均衡设备上做一些过了，黑白名单等处理）。

四、 负载均衡的分类

 ①：二层负载均衡

②：三层负载均衡

③：四层负载均衡

④：七层负载均衡

最常用的是 四层负载均衡（TCP和七层负载均衡（HTTP）四层的负载均衡就是基于IP+端口的负载均衡：在三层负载均衡的基础上，通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡。对应的负载均衡器称为四层交换机（L4 switch）主要分析IP层及TCP/UDP层，实现四层负载均衡。七层的负载均衡就是基于虚拟的URL或主机IP的负载均衡。

五、负载均衡应用场景

 场景一：应用于高访问量的业务

场景二：横向扩张系统

场景三：消除单点故障

场景四：同城容灾

六、相关问题分析处理

 nacos集群启动第一个节点可以，第二个节点就报错了，提示Address already in us，端口改了，cluster.conf也改了。先启动的8850节点，启动后conf里面就多了最下面一行配置，有人知道咋回事吗？是本地

 第二个节点的端口没有被占用，启动起来是这样。

回复：在log下的start.out中看看报什么错，截图看下日志，你看下节点2的application.properties的端口改了没。查下这个端口是不是真的占用了，有没有可能你上一个进程还没杀死，运行下.shutdow.sh试试。或者可以telnet看下那个端口是不是真的有程序用着

补充：

 

另一回复：netstat查看下端口占用，isof也可以。不要用127.0.0.1这个配置。我反正出现了配置为127.0.0.1会导致界面上节点出不来，配置为局域网ip。 补充：

 

 问题状态：已解决。nacos我下的是最新版本，不能部署在同一个ip上，我重新下载了一个1.3.0就好使了

三、我想问大神们一个关于Sping Cloud的问题，为什么spring cloud要调用2次SpringApplication，创建2个容器，加载2次bean，这样设计有什么目的，它会通过BootStrapApplicationListener再次运行一次SpringApplication.run()方法，一直搞不懂为什么要这么搞？而且它还好奇怪，仅仅是把人家的initizer提取出来，放到外层SpringApplication中。

 问题状态：未解决。

四、springcloud gateway + GloabelFilter + Feign 通过gateway调用其他微服务接口能被过滤器拦截，但是在gateway 服务里配置过feignclient的服务 不会被 filter拦截， 这是咋回事 ？gateway里面在用feign。gateway需要调用其他服务，比如做token校验。就是3-4作业啦，用户微服务生成token 并提供接口校验token 给gateway调。

回复：gateway不用Feign的吧，只用了Ribbon。

另一回复：那个啊。我gateway直接去redis获取的token 补充：不用feign吗？gateway也应该调用户微服务操作 读取redis吧， 你是直接在gateway里读了redis吧？

回复：看下这个org.springframework.cloud.netflix.ribbon.RibbonLoadBalancerClient类。还有这个org.springframework.cloud.gateway.filter.LoadBalancerClientFilter 它是通过过滤器，然后里面引入ribbon，进行选择服务器负载均衡，没有用feign。其实我也没仔细看过它源码，rx java的东西看不懂 。

另一回复：个人感觉还是用jwt，直接的gateway校验吧。不然，每次请求过来，gateway还要调用一下user服务。有点浪费

。 补充：恩， 可以抛开这个问题业务问题， 如果我gateway的filter想用feign调其他服务，那就会在gateway里配置这个服务的feignclient，这个时候前端直接通过gateway调这个服务， 它不会被filter拦截。这是啥原理，我百度好多 没找到原因。

提问：你是直接引入feign去调用？ 另一提问：微服务直接feign调用，不走gateway吧？？？

补充： 回复：你这样子就不走gateway的漏油了，还怎么过滤？

补充：用postman调 走的是gateway的网关，不会过滤。

回复：你方法没进去吗？这里能进吗？

补充：其他服务可以，就这个验证token的不会进。方法第一行都没进去，压根不会走到filter。

回复：你确定那个请求地址是走网关请求？

另一回复：验证token这个不是直接用feign在调用嘛，还需要反过来走filter？直接访问user服务不行？让它不走网关呗，不然我感觉是在循环了。

补充：确定， 我都试过把feignclient去掉， 然后用postman调这个接口 能走到网关filter。没在循环， feign调用自然不走filter了， 然后我用postman调这个服务 也不会走到filter了。这就不理解了。

讲师回复：微服务之间的调用是不要走api网关的。通过feign调用的方式下不经过网关，feign拉取的本地ribbon缓存的注册中心的目标微服务信息，跟网关没有关系。

补充：这个理解的，微服务直接是feign调用，自然不走网关。 我说的是在网关服务里配置一个微服务的feignclient，然后用postman也调同一个微服务， 然后不会被全局过滤器拦截。

讲师回复：api网关路由和转发的功能，也可以实现限流。但是这种微服务之间的调用可以通过熔断器或者sentinel进行限流。

提问：现在他的问题是配置了feign之后，正常经过网关去调用user服务也不会走filter了。

讲师回复：不会的，没有没法路由，除非你访问的网关url+微服务目标uri.

五、application.yml中写eureka的配置的时候，没有提示，有办法让提示么？

回复：需要在idea 中配置一下，plugins 装Springboot 了吗？有一个小插件，可以试一下。

补充：好的。有spring boot的插件。其他的配置有提示，eureka的没有。