一文读懂SpringCloud全家桶

一、云原生应用

SpringCloud是对Springboot使用的分布式解决方案，适合分布式、中大型的项目架构开发，现在也逐渐成为Java服务端的主流框架。使用Spring Cloud开发的应用程序非常适合在Docker和PaaS（比如Pivotal Cloud Foundry）上部署，所以又叫做云原生应用（Cloud Native Application）。云原生可以简单地理解为面向云环境的软件架构。

springcloud 微服务架构，

1、优点

• 服务拆分粒度更细，有利于资源重复利用，有利于提高开发效率
• 可以更精准的制定优化服务方案，提高系统的可维护性
• 微服务架构采用去中心化思想，服务之间采用Restful等轻量级通讯，比ESB更轻量
• 适于互联网时代，产品迭代周期更短

2、缺点

• 微服务过多，治理成本高，不利于维护系统
• 分布式系统开发的成本高（容错，分布式事务等）对团队挑战大

二、全家桶

SpringCloud提供的全生态的分布式组件支持，

1. 服务注册发现：Eureka（其他选择： Consul，Zookeeper，Nacos，Etcd）
2. 负载均衡：Robbin（声明式调用：Fegin）
3. 断路器：Hystrix
4. 网关：Zuul2，Spring Cloud Gateway
5. 配置中心：Spring Cloud Config
6. 监控：Spring Boot Admin，Spring Boot Actuator
7. 链路跟踪：Spring Cloud Sleuth

三、组件介绍

1、Eureka

（1）体系划分

Eureka是SpringCloud官方推荐的服务注册发现组件。Eureka的角色和Dubbo中Zookeeper的角色类似，体系划分如下，

• 业务上可以分为：服务注册中心、服务提供者、服务消费者。
• 代码逻辑上分为：Eureka Server 和 Eureka Client。

（2）结构原理

看图说话，

• 两台Eureka服务注册中心构成的服务注册中心的主从复制集群；
• 然后服务提供者向注册中心进行注册、续约、下线服务等；
• 服务消费者向Eureka注册中心拉去服务列表并维护在本地；
• 然后服务消费者根据从Eureka服务注册中心获取的服务列表选取一个服务提供者进行消费服务。

（3）Eureka 集群（三节点，两两注册）

从图中可以看出 Eureka Server 集群相互之间通过 Replicate 来同步数据，相互之间不区分主节点和从节点，所有的节点都是平等的。在这种架构中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。

如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点。当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会进行节点间复制，将请求复制到其它 Eureka Server 当前所知的所有节点中。

Eureka Server 集群之间的状态是采用异步方式同步的，所以不保证节点间的状态一定是一致的，不过基本能保证最终状态是一致的（Eureka保证AP，Zookeeper强调CP）。

2、Robbin

（1）客户端的软负载

Robbin是springcloud的LB调用组件，提供客户端的软件负载均衡。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随即连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

Robbin 提供的客户端软负载，是SpringCloud微服务的典型特征之一。

（2）负载均衡策略

• 轮询（RoundRobin)，以轮询的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。
• 随机（Random)，随机选择状态为UP的Server。
• 加权响应时间（WeightedResponseTime)，根据相应时间分配一个weight，相应时间越长，weight越小，被选中的可能性越低。
• 区域感知轮询（ZoneAvoidanceRule)，复合判断server所在区域的性能和server的可用性选择server。

（3）核心组件

Ribbon的核心组件(均为接口类型)有以下几个，

• ServerList，用于获取地址列表。它既可以是静态的(提供一组固定的地址)，也可以是动态的(从注册中心中定期查询地址列表)。
• ServerListFilter，仅当使用动态ServerList时使用，用于在原始的服务列表中使用一定策略过虑掉一部分地址。
• IRule，选择一个最终的服务地址作为LB结果。选择策略有轮询、根据响应时间加权、断路器(当Hystrix可用时)等。

Ribbon在工作时首选会通过ServerList来获取所有可用的服务列表，然后通过ServerListFilter过虑掉一部分地址，最后在剩下的地址中通过IRule选择出一台服务器作为最终结果。

3、Fegin

Fegin是一个声明式Http端调用，集成了Robbin的负载均衡功能，同时声明式调用更加方便（只需要简单的注解即可）。简单的可以理解为：Spring Cloud Feign 的出现使得Eureka和Ribbon的使用更加简单。

（1）Fegin接口示例

a、启动类 @EnableFeignClients 注解

@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients // 启用fegin声明式调用
public class FeginComsumerApplication {

    public static void main(String[] args) {
        SpringApplication.run(FeginComsumerApplication.class, args);
    }

}

b、声明一个调用的Feign接口，

@Service
@FeignClient(name = "name-service")
public interface NameService {

    @RequestMapping(value = "/getName", method = RequestMethod.GET)
    public String getName();

}

c、服务端提供接口实现

@RequestMapping(value = "/getName", method = RequestMethod.GET)
public String getName(){
    return "hello world";
}

d、fegin声明是调用

@Autowired
private NameServiceClient feginNameServiceClient;

@RequestMapping(value = "/getName", method= RequestMethod.GET)
public String getName(){
    return feginNameServiceClient.getName();
}

（2）Fegin 的类加载流程

• 通过主类上的EnableFeignClients 注解开启FeignClient；
• 根据Feign 的规则实现接口，并加上FeignClient注解，供调用的地方注入调用；
• 程序启动后，会扫描所有FeignClient 注解的类，并将这些信息注入到IOC 容器中；
• 当b中接口被调用时，通过jdk代理，以及反射（Spring处理注解的方式），来生成具体的RequestTemplate
• RequestTemplate 生成Reqest
• Request 交给httpclient处理，这里的httpclient 可以是OkHttp，也可以是HttpUrlConnection 或者HttpClient
• 最后Client被封装到LoadBalanceClient类，这个类结合Ribbon 实现负载均衡。

（3）Fegin的原理

4、Hystrix

Hystrix 是springcloud生态的断路器（隔离、限流、降级），主要是用来预防服务雪崩的现象，剔除掉分布式系统中某些挂掉或请求过慢的服务节点。Hystrix 是一个帮助解决分布式系统中超时处理和容错的类库, 拥有保护系统的能力。

（1）隔离、限流、降级

Hystrix断路器有两种隔离策略：信号量隔离（默认）和线程池隔离。

• 信号量模式从始至终都只有请求线程自身，是同步调用模式，不支持超时调用，不支持直接熔断，由于没有线程的切换，开销非常小。
• 线程池模式可以支持异步调用，支持超时调用，支持直接熔断，存在线程切换，开销大。

信号量隔离：常用于获取共享资源的场景中，比如计算机连接了两个打印机，那么初始的信号量就是2，被某个进程或线程获取后减1，信号量为0后，需要获取的线程或进程进入资源等待状态。Hystrix的处理有些不同，其不等待，直接返回失败。

线程池隔离：采用的就是jdk的线程池，其默认选用不使用阻塞队列的线程池，例如线程池大小为10，如果某时刻10个线程均被使用，那么新的请求将不会进入等待队列，而是直接返回失败，起到限流的作用。

此外，其还引入了一个断路器机制，当断路器处于打开状态时，直接返回失败或进入降级流程。断路器打开和关闭的触发流程为：当总的请求数达到可阈值HystrixCommandProperties.circuitBreakerRequestVolumeThreshold()，或总的请求失败百分比达到了阈值HystrixCommandProperties.circuitBreakerErrorThresholdPercentage()，这时将断路器的状态由关闭设置为打开。当断路器打开时，所有的请求均被短路，在经过指定休眠时间窗口后，让下一个请求通过（断路器被认为是半开状态）。如果请求失败，断路器进入打开状态，并进入新的休眠窗口；否则进入关闭状态。

（2）Hystrix 的整体处理流程

流程如上图所示，Hystrix框架通过命令模式来实现方法粒度上的服务保障，主要涉及HystrixCommand和HystrixObservableCommand类，前者提供同步的execute和异步的queue方法，后者提供立即执行observe和延迟执行toObservable的回调方法。此外，实际项目中通常不会使用Hystrix集成的本地缓存。

5、Spring Cloud Gateway

Spring Cloud Gateway 是springcloud全新推出的第二代微服务网关，用来替代Zuul。gateway实现了服务转发、熔断、限流、权限校验等功能，有测评显示，性能比Zuul要好不少。

（1）相关概念

• Route（路由）：这是网关的基本构建块。它由一个 ID，一个目标 URI，一组断言和一组过滤器定义。如果断言为真，则路由匹配。
• Predicate（断言）：这是一个 Java 8 的 Predicate。输入类型是一个 ServerWebExchange。我们可以使用它来匹配来自 HTTP 请求的任何内容，例如 headers 或参数。
• Filter（过滤器）：这是org.springframework.cloud.gateway.filter.GatewayFilter的实例，我们可以使用它修改请求和响应。

（2）请求流程

spring cloud gateway处理request请求的流程如下图，

我们先看gateway的构成：一个netty server，一个netty client，Route（包含Predicate和Filter）。在gateway中最重要的应该是Route（Netty Server和Client已经封装好了），它由RouteLocatorBuilder构建，内部包含Predicate和Filter。

流程：即在最前端，启动一个netty server（默认端口为8080）接受请求，然后通过Routes（每个Route由Predicate(等同于HandlerMapping)和Filter(等同于HandlerAdapter)）处理后通过Netty Client发给响应的微服务。

（3）yml配置

server.port: 8082

spring:
  application:
    name: gateway
  cloud:
    gateway:
      routes:
        - id: path_route
          uri: http://localhost:8000
          order: 0
          predicates:
            - Path=/foo/**
          filters:
            - StripPrefix=1

上面给出了一个根据请求路径来匹配目标uri的例子，如果请求的路径为/foo/bar，则目标uri为 http://localhost:8000/bar。如果上面例子中没有加一个StripPrefix=1过滤器，则目标uri 为http://localhost:8000/foo/bar，StripPrefix过滤器是去掉一个路径。

6、Spring Boot Admin

Spring Boot Admin 是springcloud提供的监控组件，用于管理和监控SpringBoot各个微服务。Admin通过注册中心（如Eureka）来监控各个节点的状态。可以结合 Spring Boot Actuator 使用，常用的监控数据有，

• 显示健康状况
• 显示详细信息，例如
  • JVM和内存指标
  • micrometer.io指标
  • 数据源指标
  • 缓存指标
• 查看jvm系统和环境属性

监控 server端需要 @EnableAdminServer 注解，client端只需要配置好yaml文件就好了，admin会通过注册中心获取各个服务节点的状态。

management:
  endpoints:
    web:
      exposure:
        include: '*'
  endpoint:
    health:
      show-details: ALWAYS

7、Spring Cloud Config

Spring Cloud Config 是springcloud的分布式配置中心组件。

分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件Spring Cloud Config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。

SpringCloudConfig分为服务端（Config Server）和客户端（Config Client），服务端负责将git（svn）中存储的配置文件发布成REST接口，客户端可以从服务端REST接口获取配置。但客户端并不能主动感知到配置的变化，从而主动去获取新的配置， 它需要每个客户端通过POST方法触发各自的/refresh，SpringCloudBus就通过一个轻量级消息代理连接分布式系统的节点。

Config Server用于配置属性的存储，存储的位置可以为Git仓库、SVN仓库、本地文件等，Config Client用于服务属性的读取。

spring cloud config是将配置保存在git/svn上，依赖git每次push后，触发webhook回调，最终触发spring cloud bus(消息总线），然后由消息总线通知相关的应用。