简单认识SpringCloud

时间  2021-08-15 标签 网络 网关 java 分布式 spring

SpringCloud

前言

SpringCloud，将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集群状态等等功能。其主要涉及的组件包括：

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

一、SpringCloud是什么？

SpringCloud 是一系列框架的有序集合，它利用SpringBoot 的开发便利性简化了分布式系统的开发，比如服务发现.服务网关.服务路由.链路追踪等。其设计目的是为了简化Spring 应用的搭建和开发过程。该框架遵循“约定大于配置”原则，采用特定的方式进行配置，从而使开发者无需定义大量的XML 配置。通过这种方式，SpringBoot 致力于在蓬勃发展的快速应用开发领域成为领导者。SpringCloud 并不重复造轮子，而是将市面上开发得比较好的模块集成进去，进行封装，从而减少了各模块的开发成本。换句话说：Spring cloud 提供了构建分布式系统所需的“全家桶”。核心组件如下：

  1. Eureka：各个服务启动时，Eureka Client 都会将服务注册到EurekaServer，并且Eureka Client 还可以反过来从Eureka Server 拉取注册表，从而知道其他服务在哪里

  2. Ribbon：服务间发起请求的时候，基于Ribbon 做负载均衡，从一个服务的多台机器中选择一台

  3. Feign：基于Feign 的动态代理机制，根据注解和选择的机器，拼接请求URL 地址，发起请求

  4. Hystrix：发起请求是通过Hystrix 的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题

  5. Zuul：如果前端.移动端要调用后端系统，统一从Zuul 网关进入，由Zuul网关转发请求给对应的服务

二、核心组件讲解

1.Eureka(服务中心)

在这里插入图片描述

  • 作用: 负责管理、记录服务提供者的信息。
  • 简介：SpringCloud Eureka 是SpringCloud Netflix 项目下的服务治理模块。
  • 由两个组件组成：Eureka 服务端和Eureka 客户端。
  • Eureka 服务端用作服务注册中心。支持集群部署。
  • Eureka 客户端是一个java 客户端，用来处理服务注册与发现。
  • 在应用启动时，Eureka 客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

Eureka-Server：就是服务注册中心（可以是一个集群），对外暴露自己的地址。
提供者：启动后向Eureka注册自己信息（地址，服务名称等），并且定期进行服务续约
消费者：服务调用方，会定期去Eureka拉取服务列表，然后使用负载均衡算法选出一个服务进行调用。
心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态
详细描述

2.Ribbon(负载均衡工具)

在这里插入图片描述

  • 作用：Ribbon，主要提供客户侧的软件负载均衡算法。
  • 简介：SpringCloud Ribbon 是一个基于HTTP 和TCP 的客户端负载均衡工具，它基于Netflix Ribbon 实现。通过S 的封装，可以让我们轻松地将面向服务的REST 模版请求自动转换成客户端负载均衡的服务调用。

3.Hystrix(熔断器)

Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。
作用：断路器，保护系统，控制故障范围。
简介：为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet 容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

1)雪崩问题

微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路：
在这里插入图片描述

如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。

如果此时，某个服务出现异常：
在这里插入图片描述
例如微服务I发生异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：
在这里插入图片描述

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。

这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。 此时如果有很多个车型都需要这个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。

Hystix解决雪崩问题的手段主要是服务降级，包括：

  • 线程隔离
  • 服务熔断

2) 线程隔离，服务降级

线程隔离示意图：

1533829598310

解读：

Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队.加速失败判定时间。

用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理，什么是服务降级？

服务降级：优先保证核心服务，而非核心服务不可用或弱可用。

用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回友好的提示信息） 。

服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它服务没有响应。

触发Hystix服务降级的情况：

  • 线程池已满
  • 请求超时

3) 服务熔断：

Hystix的熔断状态机模型：

在这里插入图片描述
状态机有3个状态：
Closed：关闭状态（断路器关闭），所有请求都正常访问。
Open：打开状态（断路器打开），所有请求都会被降级。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全关闭。默认失败比例的阈值是50%，请求次数最少不低于20次。
Half Open：半开状态，open状态不是永久的，打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放1次请求通过，若这个请求是健康的，则会关闭断路器，否则继续保持打开，再次进行5秒休眠计时。

4. Zuul(服务网关)

在这里插入图片描述

  • 网关的核心功能是：过滤（鉴权）和路由
  • 作用：api 网关，路由，负载均衡等多种作用
  • 简介：类似nginx，反向代理的功能，不过netflix 自己增加了一些配合其他组件的特性。
    在这里插入图片描述

在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API 网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。

5. Config(配置中心)

  • 作用：配置管理
  • 简介：SpringCloud Config 提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。
  • 这个还是静态的，得配合SpringCloud Bus 实现动态的配置更新。

6. Feign

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

7.SpringCloudBus(消息总线)

在这里插入图片描述

三、SpringCloud 和Dubbo 的区别

SpringCloud：Spring 公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案（微服务生态）。

Dubbo：阿里巴巴开源的RPC 框架，Dubbo 是SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。

Spring Cloud 的功能很明显比Dubbo 更加强大，涵盖面更广，而且作为Spring 的旗舰项目，它也能够与Spring Framework、Spring Boot、
Spring Data、Spring Batch 等其他Spring 项目完美融合，这些对于微服务而言是至关重要的。

四、使用SpringCloud 的优缺点？

优点

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

缺点

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

总的来说优点大过于缺点，目前看来SpringCloud 是一套非常完善的分布式框架，目前很多企业开始用微服务、Spring Cloud 的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习Spring Cloud 是一个不错的选择。

五、服务注册和发现是什么意思？SpringCloud 如何实现？

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在Eureka 服务器上注册并通过调用Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。

六、 负载平衡的意义什么？

在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。

七、什么是Hystrix？它如何实现容错？

Hystrix 是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。
通常对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协作。

八、什么是Hystrix 断路器？我们需要它吗？

由于某些原因，employee-consumer 公开服务会引发异常。在这种情况下使用Hystrix 我们定义了一个回退方法。如果在公开服务中发生异常，则回退方法返回一些默认值。
如果firstPage method() 中的异常继续发生，则Hystrix 电路将中断，并且员工使用者将一起跳过firtsPage 方法，并直接调用回退方法。断路器的目的是给第一页方法或第一页方法可能调用的其他方法留出时间，并导致异常恢复。可能发生的情况是，在负载较小的情况下，导致异常的问题有更好的恢复机
会。

九、什么是SpringCloud Bus？我们需要它吗？

考虑以下情况：我们有多个应用程序使用SpringCloud Config 读取属性，而Spring cloud Config 从GIT 读取这些属性。
下面的例子中多个员工生产者模块从Employee Config Module 获取Eureka 注册的财产。
如果假设GIT 中的Eureka 注册属性更改为指向另一台Eureka 服务器，会发生什么情况。在这种情况下，我们将不得不重新启动服务以获取更新的属性。
还有另一种使用执行器端点/刷新的方式。但是我们将不得不为每个模块单独调用这个url。例如，如果Employee Producer1 部署在端口8080 上，则调用http：// localhost：8080 / refresh。同样对于Employee Producer2 http：// localhost：8081 / refresh 等等。这又很麻烦。这就是SpringCloud Bus 发挥作用的地方。
SpringCloud Bus 提供了跨多个实例刷新配置的功能。因此，在上面的示例中，如果我们刷新Employee Producer1，则会自动刷新所有其他必需的模块。如果我们有多个微服务启动并运行，这特别有用。这是通过将所有微服务连接到单个消息代理来实现的。无论何时刷新实例，此事件都会订阅到侦听此代理的所有微服务，并且它们也会刷新。可以通过使用端点/总线/刷新来实现对任何单个实例的刷新。

十、Eureka 和Zookeeper 注册中心的区别

先看下CAP 原则：C-数据一致性；A-服务可用性；P-服务对网络分区
故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个：

  1. Eureka 满足AP，Zookeeper 满足CP
  2. Zookeeper 满足一致性、容错性。数据要在各个服务间同步完成后才返回用户结果，而且如果服务出现网络波动，会立即从服务列表中剔除，服务不可使用
  3. Eureka 满足AP，可用性，容错性。当因网络故障时，Eureka 的自我保护机制不会立即剔除服务，虽然用户获取到的服务不一定时可用的，但是至少能够获取到服务列表。用户访问服务列表时还可以利用重试机制，找到正确的服务。更符合分布式服务的高可用需求
  4. Eureka 集群各节点平等，Zookeeper 中有主从之分
  5. 如果Zookeeper 集群中部分宕机，可能会导致整个集群因为选主而阻塞，服务不可用
  6. eureka 集群宕机部分，不会对其它机器产生影响
  7. Eureka 的服务发现需要主动去拉取，Zookeeper 服务发现是监听机制
  8. eureka 中获取服务列表后会缓存起来，每隔30 秒重新拉取服务列表
  9. zookeeper 则是监听节点信息变化，当服务节点信息变化时，客户端立即就得到通知
联系我们 沪ICP备13005482号-10