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体系的主要组件,其架构图为Spring Cloud体系架构简介_第1张图片

二、组件简介

1. Eureka注册中心

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

  • 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,使用起来也很简单。

Spring Cloud体系架构简介_第3张图片

注意: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的这个线程不会释放,于是越来越多的用户请求到来,越来越多的线程会阻塞,而服务器支持的线程和并发数有限,请求一直阻塞,会导致服务器资源耗尽,从而导致所有其它服务都不可用,形成雪崩效应。Spring Cloud体系架构简介_第4张图片
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体系架构简介_第5张图片

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

你可能感兴趣的:(java,spring,cloud,架构,eureka,linux,java)