Spring Cloud体系架构简介

前言

在项目开发中随着业务越来越多，导致功能之间耦合性高、开发效率低、系统运行缓慢难以维护、不稳定。微服务架构可以解决这些问题，而Spring Cloud是微服务架构最流行的实现方式。现在将一些相关知识点记录下来，方便以后查阅复习，如有错误，还望各位看官不吝赐教。

---

一、Spring Cloud是什么？

	Spring Cloud是Spring旗下的项目之一，官网地址：http://projects.spring.io/spring-cloud

Spring最擅长的就是集成，把世界上最好的框架拿过来，集成到自己的项目中。
Spring Cloud也是一样，它将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集群状态等等功能。其主要涉及的组件包括：
Netflix

• Eureka：注册中心
• Zuul：服务网关
• Ribbon：负载均衡
• Feign：服务调用
• Hystrix：熔断器

以上是springcloud体系的主要组件，其架构图为

二、组件简介

1. Eureka注册中心

我们可以设想一个非常简单的微服务场景：一个服务提供者A（厨师）拥有“提供鱼香肉丝”的功能，它暴露地址给服务调用者B（食客），B就可以通过该地址获取到A提供的鱼香肉丝，如果地址出现变更，两者都需要及时更新。这在服务较少的时候还不觉得有什么，但是在服务多的时候还进行人为的管理地址就会显得非常麻烦。
而Eureka注册中心就好像是餐厅，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。
同时，服务提供方与Eureka之间通过 “心跳” 机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。
这就实现了服务的自动注册、发现、状态监控。
原理图如下：

• Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
• 提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
• 消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
• 心跳(续约)：提供者定期通过HTTP方式向Eureka刷新自己的状态

2.Spring Cloud Gateway网关

 Spring Cloud Gateway是替代Netflix Zuul的一套解决方案。

Spring Cloud Gateway组件的核心是一系列的过滤器，通过这些过滤器可以将客户端发送的请求转发（路由）到对应的微服务。 Spring Cloud Gateway是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，
从而加强安全保护。Spring Cloud Gateway本身也是一个微服务，需要注册到Eureka服务注册中心。其核心功能是：过滤和路由。

补充：网关核心概念之断言（Predicate）：Spring Cloud Gateway中的断言函数输入类型是Spring 5.0框架中的ServerWebExchange。Spring Cloud Gateway的断言函数允许开发者去定义匹配来自于HTTP Request中的任何信息比如请求头和参数

3.Ribbon负载均衡

在刚才的案例中，我们举了一个会做鱼香肉丝的厨师供食客进行服务调用，但是如果有很多个都会做鱼香肉丝的厨师（集群）的话该选择哪一个厨师呢？一般这种情况下我们就需要编写负载均衡算法，在多个实例列表中进行选择。不过Eureka中已经帮我们集成了负载均衡组件：Ribbon，使用起来也很简单。

注意：Ribbon默认的负载均衡策略是简单的轮询，

4. Feign服务调用

使用Ribbon的负载均衡功能可以大大简化远程调用时的代码：

String baseUrl = "http://user-service/user/";
User user = this.restTemplate.getForObject(baseUrl + id, User.class)

但是我们还可以通过Feign以一种更优雅的方式来对这些代码再次进行优化

Feign的中文翻译是伪装，顾名思义，Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等
等操作，一切都交给Feign去做。

补充：Feign本身已经集成了Ribbon依赖和自动配置

5.Hystrix熔断器

Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务，防止出现级联失败。

5.1熔断原理

在服务熔断中，使用的熔断器，也叫断路器，其英文单词为：Circuit Breaker 熔断机制与家里使用的电路熔断原理类似；当如果电路发生短路的时候能立刻熔断电路，避免发生灾难。在分布式系统中应用服务熔断后；服务调用方可以自己进行判断哪些服务反应慢或存在大量超时，可以针对这些服务进行主动熔断，防止整个系统被拖垮。
Hystrix的服务熔断机制，可以实现弹性容错；当服务请求情况好转之后，可以自动重连。通过断路的方式，将后续请求直接拒绝，一段时间（默认5秒）之后允许部分请求通过，如果调用成功则回到断路器关闭状态，否则继续打
开，拒绝请求的服务。

5.2 雪崩问题

微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路，如图，当微服务I 发生异常，请求阻塞，用户请求就不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞，而服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。
Hystrix解决雪崩问题的手段，主要包括：

• 线程隔离
  Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加速失败判定时间。用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理，
• 熔断降级
  服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它服务没有影响。可以优先保证核心服务。

6.Spring Cloud Config分布式配置中心

在分布式系统中，由于服务数量非常多，配置文件分散在不同的微服务项目中，管理不方便。为了方便配置文件集中管理，需要分布式配置中心组件。在Spring Cloud中，提供了Spring Cloud Config，它支持配置文件放在配置服务的本地，也支持放在远程Git仓库（GitHub、码云）。配置中心本质上也是一个微服务，同样需要注册到Eureka服务注册中心。

配置文件的命名方式：
{application}-{profile}.yml 或 {application}-{profile}.properties

• application为应用名称
• profile用于区分开发环境，测试环境、生产环境等

如user-dev.yml，表示用户微服务开发环境下使用的配置文件。

7.Spring Cloud Bus

在上述config配置文件中，如果我们修改了在云端的配置文件，那我们每次都要重启服务才能获取到最新的配置文件，Spring Cloud Bus可以帮助我们解决这个问题。
Spring Cloud Bus是用轻量的消息代理将分布式的节点连接起来，可以用于广播配置文件的更改或者服务的监控管理。也就是消息总线可以为微服务做监控，也可以实现应用程序之间相互通信。 Spring Cloud Bus可选的消息代理有RabbitMQ和Kafka。

三、完整体系架构图

本文仅仅简单介绍了关于Spring Cloud的一些知识点，并未深入展开，多有不足请多见谅。