如何限制多台客户端请求一个服务端的次数_微服务架构七：Ribbon客户端的负载均衡...

本篇讲述Ribbon实现微服务架构中的负载均衡，需要有注册中心，服务消费者、服务提供者等基础概念的理解，以及工程创建、配置、启动等方面的知识，第一次看的铁子可以查看之前发布的文章(通过公众号，共享学习菜单，点击微服务入口进入学习)，有了基础之后，在继续此篇的学习。

言归正传，我们先看一下问题场景：

在生产系统中，如果我们的服务只有一个实例，如果由于异常或其他原因导致该服务停止，则整个系统将处于宕机状态，系统无法正常运行，为了解决整个问题，我们可以在一个服务器上，开启多个端口不通的服务实例或者在多台服务器上部署端口相同或不通的服务实例，来提供服务。那么与之而来的问题就是来自客户端的请求，我们如何分发到各个服务端实例。负载均衡在系统架构中是一个非常重要，并且是不得不去实施的内容。因为负载均衡是对系统的高可用、网络压力的缓解和处理能力扩容的重要手段之一。这时候就需要引入负载均衡的概念了。

负载均衡分为：客户端负责均衡和服务端负载均衡；我们通常所说的负载均衡都指的是服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务器节点之间按照专门用于负载均衡的设备，比如F5等；而软件负载均衡则是通过在服务器上安装一些用于负载均衡功能或模块等软件来完成请求分发工作，比如Nginx等。

服务端负载均衡架构图：

客户端负责均衡：Ribbon是一个客户端负载均衡器，它有几种负载均衡机制,默认是轮询，我们也可以自定义规则,通过合理的分配网络请求来减小服务器的压力。

服务端负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备的时候，该设备按某种算法(比如线性轮询、按权重负载、按流量负载等)从维护的可用服务端清单中取出一台服务端端地址，然后进行转发。而客户端负载均衡和服务端负载均衡最大的不同点在于上面所提到服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端端清单来自于服务注册中心，同服务端负载均衡的架构类似，在客户端负载均衡中也需要心跳去维护服务端清单的健康性

言归正传：

Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Spring Cloud Ribbon虽然只是一个工具类框架，它不像服务注册中心、配置中心、API网关那样需要独立部署，但是它几乎存在于每一个Spring Cloud构建的微服务和基础设施中。因为微服务间的调用，API网关的请求转发等内容，实际上都是通过Ribbon来实现的，包括后续我们将要介绍的Feign，它也是基于Ribbon实现的工具。所以，对Spring Cloud Ribbon的理解和使用，对于我们使用Spring Cloud来构建微服务非常重要。

利用Ribbon实现客户端的负载均衡，总体流程为：搭建注册中心，服务提供者注册到注册中心，服务消费者注册到注册中心，服务消费者从注册中心获取服务并执行。

第一步：搭建注册中心

参考博客：https://blog.csdn.net/u013310119/article/details/111997007

第二步：创建服务提供者

参考博客：https://blog.csdn.net/u013310119/article/details/112020596

第三步：服务消费者

首先新建一个SpringBoot项目，命名spring-cloud-consumer-ribbon，然后按照下面步骤编写代码即可。

1、pom.xml代码

添加eureka-client的依赖，代码如下