Springcloud + nacos + gateway 负载均衡(ribbon)

Ribbon是客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用

负载均衡,英文名称为Load Balance,其含义就是指将负载(工作任务)进行平衡、分摊到多个 *** 作单元上进行运行,从而协同完成工作任务。 负载均衡构建在原有网络结构之上,它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性

本文主要测试，在Springcloud + nacos + gateway基础上，如何实现负载平衡

前面我们已经整合了Springcloud + nacos + gateway，实现了，当启动3个provider时候，通过gateway,可以对该3个provider进行轮询

1 nocas负载均衡。
   a nocas本身已集成了ribbon，默认使用轮询的方式
   b 在nocas设置weight,实现权重的方式
   c 自定rule(IRule实现类)
   d 顺提，在权重的方式下，可使用先设置权重为0，再关闭单一服务的方式，优雅地下线服务

2 使用ribbon直连ip
   a 使用ribbon提供的自动策略，轮询，随机等
   b 健康检查
   v 自定义rule

关掉其中一个provider，立即通过gateway进行轮询，发现gateway仍然会call已经down掉的provider，导致查询失败。但在大约5秒后，轮询恢复正常，不再call已经prodiver
gateway call provider首先经nacos注册中心，nacos心跳机制默认每5秒钟检查一次provider是否正常，因此就会出现上面现象。

1 在启动类，将配置类 将IRule 的实现类注册到spring容器中即可
2 分别测试轮询和随机，可正常按规则负载

1 增加gatewayriboonip模块
2 pom添加依赖spring-cloud-starter-gateway和spring-cloud-starter-netflix-ribbon
3 修改applicationyml，设置负载均衡
4 启动，测试可正常进行轮询
5 修改applicationyml 如下，可测试到从轮询方式变成了随机的方式
   NFLoadBalancerRuleClassName: comnetflixloadbalancerRandomRule

这个时候down掉一个provider，然后轮询，到这个provider时候，会一直查询失败。我们需要增加一个健康检查处理，在服务down掉的时候，可感知到并将该服务从服务列表去除，在服务上线后，可检查到服务已上线
1 增加健康检查
   provider模块增加rest接口HealthController
   增加config类，产生RestTemplate
   增加健康检查类HealthExamination implements IPing。继承IPing接口，判断服务是否可用。我们在微服务中增加heath接口，在gateway中调用该接口，如果返回正常则认为微服务可用。
    修改applicationyml 增加Ping如下
          NFLoadBalancerPingClassName: comroyspringnacosgatewayribboniploadBalanceHealthExamination
2 重启provider和gateway，进行测试
   a 轮询成功
   b down掉其中一个provider，轮询到该provider时候，查询失败
    这里测试未能成功，使用RoundRobinRule还是一直出现查询失败，未能自动skip掉down掉的provider
   但是自定义LoadBalancerRule的话，是能够成功skip掉down掉的provide的

1 增加MyRule extends AbstractLoadBalancerRule
2 重启后，测试成功按规则查询

我们大多数的客户在他们的服务器上使用Apache作为Web服务器，尤其是部署在一个基于PHP系统的前端并且使用mod-PHP。鉴于扩张性和性能方面的原因，我们通常会建议他们改用Nginx和FPM。\x0d\\x0d\Apache是非常强大的Web服务器，模块化结构，也是Web服务端的鼻祖。除了捆绑一些其他的工具外，Apache已经成为了世上最广泛部署的开源系统，直到最近，世界上大多数网站仍运行着Apache系统。\x0d\\x0d\但是，Apache并不是完美的，并且不再适合大规模系统。为什么？因为他的进程模式虽然简单而灵活，但并不适合大规模尤其是当要处理像PHP这种需要占用大量内存应用程序代码时。\x0d\\x0d\一个典型的网络应用服务器由两部分组成。客户端连接部分负责用户浏览器与>百度词条里的解释是：负载均衡，英文叫Load Balance，意思就是将请求或者数据分摊到多个 *** 作单元上进行执行，共同完成工作任务。
它的目的就通过调度集群，达到最佳化资源使用，最大化吞吐率，最小化响应时间，避免单点过载的问题。

负载均衡可以根据网络协议的层数进行分类，我们这里以ISO模型为准，从下到上分为：
物理层，数据链路层，网络层，传输层，会话层，表示层，应用层。
当客户端发起请求，会经过层层的封装，发给服务器，服务器收到请求后经过层层的解析，获取到对应的内容。

二层负债均衡是基于数据链路层的负债均衡，即让负债均衡服务器和业务服务器绑定同一个虚拟IP（即VIP），客户端直接通过这个VIP进行请求，那么如何区分相同IP下的不同机器呢？没错，通过MAC物理地址，每台机器的MAC物理地址都不一样，当负载均衡服务器接收到请求之后，通过改写>

这是网上摘抄的文章，正好想了解一下负载均衡，看这篇文章写的比较易懂，就。。。。

对于数据流量过大的网络中，往往单一设备无法承担，需要多台设备进行数据分流，而负载均衡器就是用来将数据分流到多台设备的一个转发器。

目前有许多不同的负载均衡技术用以满足不同的应用需求，如软/硬件负载均衡、本地/全局负载均衡、更高网络层负载均衡，以及链路聚合技术。

腾讯、淘宝、新浪等大型门户及商业网站使用的是软负载均衡器Nginx，而农行用的是F5硬负载均衡器，这里就简单介绍下这两种技术：

一软件负载均衡解决方案

在一台服务器的 *** 作系统上，安装一个附加软件来实现负载均衡，如Nginx负载均衡（我们管理系统平台使用的也是这款均衡器）。它的优点是基于特定环境、配置简单、使用灵活、成本低廉，可以满足大部分的负载均衡需求。

1什么是Nginx

Nginx ("engine x") 是一个高性能的>理解负载均衡，必须先搞清楚正向代理和反向代理。

注：

正向代理，代理的是用户。

反向代理，代理的是服务器

什么是负载均衡

当一台服务器的单位时间内的访问量越大时，服务器压力就越大，大到超过自身承受能力时，服务器就会崩溃。为了避免服务器崩溃，让用户有更好的体验，我们通过负载均衡的方式来分担服务器压力。

我们可以建立很多很多服务器，组成一个服务器集群，当用户访问网站时，先访问一个中间服务器，在让这个中间服务器在服务器集群中选择一个压力较小的服务器，然后将该访问请求引入该服务器。如此以来，用户的每次访问，都会保证服务器集群中的每个服务器压力趋于平衡，分担了服务器压力，避免了服务器崩溃的情况。

负载均衡是用反向代理的原理实现的。
1、轮询（默认）

每个请求 按时间顺序逐一分配 到不同的后端服务器，如果后端服务器down掉，能自动剔除。

upstreambackserver {server192168014;server192168015;}

2、weight

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的

情况。

upstreambackserver {server192168014weight=3;server192168015weight=7;}

权重越高，在被访问的概率越大，如上例，分别是30%，70%。

3、上述方式存在一个问题就是说，在负载均衡系统中，假如用户在某台服务器上登录了，那么该用户第二次请求的时候，因为我们是负载均衡系统，每次请求都会重新定位到服务器集群中的某一个，那么已经登录某一个服务器的用户再重新定位到另一个服务器，其登录信息将会丢失，这样显然是不妥的。

我们可以采用ip_hash指令解决这个问题，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

upstreambackserver{ip_hash;server192168014:88;server192168015:80;}

4、fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstreambackserver {serverserver1;serverserver2;fair;}

5、url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

upstream backserver {    server squid1:3128;    server squid2:3128;    hash$request_uri;    hash_method crc32;}123456

每个设备的状态设置为:

down 表示单前的server暂时不参与负载

weight 默认为1weight越大，负载的权重就越大。

max_fails：允许请求失败的次数默认为1当超过最大次数时，返回 proxy_next_upstream模块定义的错误

fail_timeout:max_fails次失败后，暂停的时间。

backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

配置实例：

#user  nobody;worker_processes4;events {# 最大并发数worker_connections1024;}>