SpringCloud总结二

客户端负载均衡：Spring Cloud 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来构建微服务非常重要。

客户端负载均衡

负载均衡在系统架构中是一个非常重要，并且是不得不去实施的内容。因为负载均衡是对系统的高可用，网罗压力的缓解和处理能力扩容的重要手段之一。我们通常所说的负载均衡都是指服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备，比如F5等，而软件负载均衡则是通过服务器上安装一些具有负载均衡功能或模块的软件来完成请求分发工作，比如Nginx。硬件负载均衡或者软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备的时候，该设备按某种算法从维护的可用服务清单中取出一台服务端的地址，然后进行转发。

而客户端负载均衡和服务端负载均衡最大的不同点在于上面所提到的服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端的清单来自于注册中心，比如Eureka服务端。同服务端负载均衡的架构类似，在客户端负载均衡中也需要心跳去维护服务端清单的健康性，只是这个步骤配合服务注册中心完成。

通过Spring Cloud Ribbon的封装，我们在微服务架构中使用客户端负载均衡调用非常简单

1. 服务提供者只需要启动多个服务实例并注册到一个注册中心或是多个相关联的注册中心
2. 服务消费者直接通过调用被@LoadBalanced注解修饰过的RestTemplate来实现面向服务的接口调用。

服务容错保护：Spring Cloud Hystrix

在微服务架构中，我们将系统拆分成了许多服务单元，各单元的应用间通过服务注册与订阅的方式互相依赖。由于每个单元在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身的问题出现调用故障或延迟，而这些问题会直接导致调研外的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会因等待出现故障的依赖方响应形成任务积压，最终导致自身服务的瘫痪。

在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，这样的架构相对于传统架构更加不稳定。为了解决这样的问题，产生了断路器等一系列服务保护机制。

在分布式架构中，当某个服务单元发生故障（类似于电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。

针对上述问题，Spring Cloud Hystrix实现了断路器，线程隔离等一系列服务保护功能。它也是基于Netflix的开源框架Hystrix实现的，该框架的目的在于提高控制那些访问远程系统，服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备服务降级，服务熔断，线程和信号隔离，请求缓存，请求合并以及服务监控等强大功能。（@Enable-CircuitBreaker注解开启断路器功能，@HystrixCommand注解来指定回调方法）

声明式服务调用：Spring Cloud Feign

它基于Netflix Fegin实现，整合了Spring Cloud Ribbon与Spring Cloud Hystrix，除了提供这两者的强大功能外，它还提供了一种声明式的web服务客户端定义方式。
@EnableFeignClients注解开启
@FeignClient注解指定服务名来绑定服务。

API网关服务：Spring Cloud Zuul

通过使用Spring Cloud Eureka实现高可用的服务注册中心以及实现微服务的注册和发现；通过Spring Cloud Ribbon或Fegin实现服务间负载均衡的接口调用；同时，为了使分布式系统更为健壮，对于依赖的服务调用使用Spring Cloud Hystrix来进行包装，实现线程隔离并加入熔断机制，以避免在微服务架构中因个别服务出现异常而引起级联故障蔓延。

API网关是一个更加智能的应用服务器，它的定义类似于面向对象设计模式中的Facade模式，它的存在就像是整个微服务架构系统的门面一样，所有的外部客户端访问都需要经过它来进行调度和过滤。它处理要实现请求路由，负载均衡，检验过滤等功能之外，还需要更多能力，比如与服务治理框架整合，请求转发时的熔断机制，服务的聚合等一系列高级功能

首先，对于路由规则与服务实例的维护问题。Spring Cloud Zuul通过Spring Cloud Eureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中获得了所有其他微服务的实例信息。这样的设计非常巧妙地将服务治理体系中维护的实例信息利用起来，使得将维护服务实例的工作交给了服务治理框架自动完成，不需要人工介入。而对于路由规则的维护，Zuul默认会将通过以服务名作为ContextPath的方式来创建路由映射，大部分情况下，这样的默认配置已经可以实现我们大部分的路有需求。

其次，对于类似签名校验，登录校验在微服务架构中的冗余问题。理论上来说，这些校验逻辑在本质上与微服务应用自身的业务并没有多大的关系，所以它们完全可以独立成为一个单独的服务存在，只是它们被剥离和独立出来之后，并不是给各个微服务调用，而是在API网关服务上进行统一调用来对微服务接口做前置过滤，以实现对微服务接口的拦截和校验。Spring Cloud Zuul提供了一套过滤机制，它可以很好的支持这样的任务。开发者可以通过使用Zuul来创建各种校验过滤器，然后指定哪些规则的请求需要执行校验逻辑，只有通过校验的才会被路由到具体的微服务接口，不然就返回错误提示。通过这样的改造，各个业务层的微服务应用就不需要非业务性质的校验逻辑了，这使得我们的微服务应用可以更专注于业务逻辑的开发，同时微服务的自动化测试也变得更容易实现。

微服务架构虽然可以将我们的开发单元拆分的更为细致，有效降低了开发难度，但是它所引出来的各种问题如果处理不当会成为实施过程中的不稳定因素，甚至掩盖掉原本实施微服务带来的优势。所以，在微服务架构的实施方案中，API网关服务的使用几乎成为了必然选择。

分布式配置中心：Spring Cloud Config

Spring Cloud Config是Spring Cloud团队创建的一个全新项目，用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持，它分为服务端和客户端两个部分。其中服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置仓库并为客户端提供获取配置信息，加密/解密信息等访问接口；而客户端则是微服务架构中的各个微服务应用或基础设施，它们通过指定的配置中心来管理应用资源与业务相关的配置内容，并在启动的时候从配置中心获取加载配置信息。Spring Cloud Config实现了对服务端和客户端中环境变量和属性配置的抽象映射，所以它除了适用于Spring构建的应用程序之外，也可以在任何其他语言运行的应用程序中使用。由于Spring Cloud Config实现的配置中心默认采用Git来存储配置信息，并且通过Git客户端工具来方便管理和访问配置内容。

@EnableConfigServer注解，开启Spring Cloud Config的服务端功能。

消息总线：Spring Cloud Bus

在微服务架构的系统中，我们通常会使用轻量级的消息代理来构建一个共用的消息主题让系统中的所有微服务实例都连接上来，由于该主题中产生的消息会被所有实例监听和消费，所以我们称它为消息总线。在总线上的各个实例都可以方便的广播一些需要让其他连接在该主题上的实例都知道的消息，例如配置信息的变更或者其他一些管理

由于消息总线在微服务架构系统中广泛使用，所以它同配置中心一样，几乎是微服务架构中的必备组件。Spring Cloud作为微服务架构综合性的解决方案，对此自然也有自己的实现，这就是本章我们将要具体介绍的Spring Cloud Bus。通过使用Spring Cloud Bus非常容易地搭建起消息总线，同时实现类一些消息总线中的常用功能。

消息代理
消息代理（Message Broker）是一种消息验证，传输，路由的架构模式。它在应用程序之间起到了通过调度并最小化应用之间的依赖作用，使得应用程序可以高效地解耦通信过程。消息代理是一个中间件产品，它的核心是一个消息的路由程序，用来实现接受和分发消息，并根据设定好的消息处理流来转发给正确的应用。它包括独立的通信和消息传递协议能够实现组织内部和组织间的网络通信。设计代理的目的就是为了能够从应用程序中传入消息，并执行一些特别的操作。
下面这些是在企业应用中，我们经常需要使用消息代理的场景
- 将消息路由到一个或多个目的地
- 消息转化为其他的表现方式
- 执行消息的聚集，消息的分解，并将结果发送到它们的目的地，然后重新组合响应返回给消息用户
- 调用Web服务来检索数据
- 响应事件或错误
- 使用发布-订阅模式来提供内容或基于主题的消息路由

消息驱动的微服务：Spring Cloud Stream

Spring Cloud Stream是一个用来为微服务应用构建消息驱动能力的框架。它可以基于Spring
Boot来创建独立的，可用于生产的Spring应用程序。它通过使用Spring Intergration来连接消息代理中间件以实现消息事件驱动。Spring Cloud Stream为一些供应商的消息中间件产品提供了个性化的自动化配置实现，并且引入发布-订阅，消费组以及分区这三个核心概念。简单来说，Spring Cloud Stream本质上就是整合了Spring Boot和Spring Integration，实现了一套轻量级的消息驱动的微服务框架。通过使用Spring Cloud Stream，可以有效简化开发人员对消息中间件的使用复杂度，让系统开发人员可以有跟多的精力关注核心业务逻辑的处理。由于Spring Cloud Stream基于Spring Boot实现，所以它秉承了Sping Boot的优点。支持RabbitMQ和Kafka

分布式服务追踪：Spring Cloud Sleuth

通过之前介绍的Spring Cloud组件，实际上我们已经能够通过使用它们搭建起一个基础的微服务架构系统来实现业务需求了。但是，随着业务的发展，系统规模也会变得越来越大，各微服务间的调用关系也变得越来越错综复杂。通过一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最终的请求结果，在复杂的微服务架构系统中，几乎每一个前端请求都会形成一条复杂的分布式服务调用链路，在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败。这时候，对于每个请求，全链路调用的跟踪救护变得越来越重要，通过实现对请求调用的跟踪可以帮助我们快速发现错误根源以及监控分析每条请求链路上的性能瓶颈。