SpringCloud系列之负载均衡Ribbon·2-客户端与服务端组件

客户端顾名思义就是放在客户端一侧来做负载均衡的，例如我们就可以从刚刚学过的Eureka的注册中心实时动态的获取到所有的可用服务列表，然后利用负载均衡策略来发起请求

服务端就在客户端与服务之间做一个中间件，客户端发起一个请求到负载均衡器，然后由负载均衡器做分配处理，一般常见的有nginx，不常见的F5

服务治理：Spring Cloud Eureka

Spring Cloud Eureka是Spring Cloud Netflix微服务套件中的一部分，它基于Netflix

Eureka做了二次封装，主要负责完成微服务架构中的服务治理功能。Spring Cloud通过为

Eureka增加了Spring Boot风格的自动化配置，我们只需通过简单引入依赖和注解配置就能

让Spring Boot构建的微服务应用轻松地与Eureka服务治理体系进行整合。

在本章中，我们将指引读者学习下面这些核心内容，并构建起用于服务治理的基础设

施。

·构建服务注册中心

·服务注册与服务发现

。Eureka的基础架构

Eureka的服务治理机制

Eureka的配置

服务治理

服务治理可以说是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务

实例的自动化注册与发现。为什么我们在微服务架构中那么需要服务治理模块呢？微服务

系统没有它会有什么不好的地方吗？

在最初开始构建微服务系统的时候可能服务并不多，我们可以通过做一些静态配置来

完成服务的调用。比如，有两个服务A和B,其中服务A需要调用服务B来完成一个业务

*** 作时，为了实现服务的高可用，不论采用服务端负载均衡还是客户端负载均衡，都需

要手工维护服务的具体实例清单。但是随着业务的发展，系统功能越来越复杂，相应一下的

微服务应用也不断增加，我们的静态配置就会变得越来越难以维护。并且面对不断发展的

业务，我们的集群规模、服务的位置、服务的命名等都有可能发生变化，如果还是通过手

工维护的方式，那么极易发生错误或是命名冲突等间题。同时，对于这类静态内容的维护

为了解决微服务架构中的服务实例维护问题，产生了大量的服务治理框架和产品。这

也必将消耗大量的人力。

些框架和产品的实现都围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化

管理。

服务注册：在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册

中心登记自己提供的服务，将主机与端口号、版本号、通信协议等一些附加信息告

知注册中心，注册中心按服务名分类组织服务清单。比如，我们有两个提供服务A

的进程分别运行于1921680100：8000和1921680101：8000位置上，

另外还有三个提供服务B的进程分别运行于1921680100：9000、

1921680101:9000、1921680102:9000位置上。当这些进程均启动，

并向注册中心注册自己的服务之后，注册中心就会维护类似下面的一个服务清单。

另外，服务注册中心还需要以心跳的方式去监测清单中的服务是否可用，若不可用

需要从服务清单中剔除，达到排除故障服务的效果。

服务名

位置

服务A

1921680100:8000、1921680101:8000

服务B

1921680100:9000、1921680101:9000、1921680102:9000

服务发现：由于在服务治理框架下运作，服务间的调用不再通过指定具体的实例地

址来实现，而是通过向服务名发起请求调用实现。所以，服务调用方在调用服务提

供方接口的时候，并不知道具体的服务实例位置。因此，调用方需要向服务注册中

心咨询服务，并获取所有服务的实例清单，以实现对具体服务实例的访问。比如，

现有服务C希望调用服务A,服务C就需要向注册中心发起咨询服务请求，服务注

册中心就会将服务A的位置清单返回给服务C,如按上例服务A的情况，C便获得

了服务A的两个可用位置1921680100：8000和1921680101：8000。

当服务要发起调用的时候，便从该清单中以某种轮询策略取出一个位置来进行服

务调用，这就是后续我们将会介绍的客户端负载均衡。这里我们只是列举了一种简

单的服务治理逻辑，以方便理解服务治理框架的基本运行思路。实际的框架为了性

能等因素，不会采用每次都向服务注册中心获取服务的方式，并且不同的应用哦场景

在缓存和服务剔除等机制上也会有一些不同的实现策略。

问题的由来：
大规模服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。
(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。
(2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。
(3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。
其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量

关键变化是服务和服务之间的通信

创建两个 spring-boot 工程订单服务（order-service）和库存服务（repo-service）
订单服务

库存服务

RestTemplate是对>