您的位置: 首页  >  文章  >  SpringCloud框架使用总结

SpringCloud框架使用总结

分类: 文章 • 2022-10-04 13:52:10

关于Spring Cloud框架入门
入口：Spring Cloud入门
关于Spring Cloud框架中Eureka集群使用
入口：Eureka集群
关于Spring Cloud框架中Ribbon负载均衡及Feign消费者调用服务使用
入口：Ribbon以及Feign使用
关于Spring Cloud框架中熔断器Hystrix及服务监控Dashboard使用
入口：Hystrix熔断器使用示例
入口：Hystrix集群使用
关于Spring Cloud框架中Zuul网关使用
入口：Zuul网关使用
关于Spring Cloud框架中服务配置中心使用
入口：spring cloud config 使用

Spring Cloud简介

针对当前流行的微服务架构，比较有名的就是阿里的dubbo和spring cloud。dubbo只专注于服务之间的治理，如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中增加了使用 Dubbo 的难度。spring cloud是spring家族的产品，几乎考虑了服务治理的方方面面，提供一整套解决方案，通过构建其框架下的各个组件可快速实现微服务设计中的相关功能，Spring cloud针对各个功能都有对应的组件框架可供选择使用。

Spring Cloud 作为Java 语言的微服务框架，它依赖于Spring Boot，有快速开发、持续交付和容易部署等特点。Spring Cloud 的组件非常多，涉及微服务的方方面面，井在开源社区Spring 和Netflix 、Pivotal 两大公司的推动下越来越完善。

微服务的功能主要体现在以下儿个方面：

  1. 服务的注册和发现（Eureka）。

  2. 服务的负载均衡(Ribbon)。

  3. 服务的容错（Hystrix）。

  4. 服务网关（zuul）。

  5. 服务配置的统一管理（config）。

  6. 服务监控（Dashboard与Turbine）

  7. 链路追踪。

  8. 实时日志。
    SpringCloud框架使用总结
    微服务具有以下的特点：

  9. 按照业务来划分服务，单个服务代码量小，业务单一，易于维护。

  10. 每个微服务都有自己独立的基础组件，例如数据库、缓存等，且运行在独立的进程中。

  11. 微服务之间的通信是通过HTTP 协议或者消息组件，且具有容错能力。

  12. 微服务有一套服务治理的解决方案，服务之间不相合，可以随时加入和剔除服务。

  13. 单个微服务能够集群化部署，并且有负载均衡的能力。

  14. 整个微服务系统应该有一个完整的安全机制，包括用户验证、权限验证、资源保护等。

  15. 整个微服务系统有链路追踪的能力。

  16. 有一套完整的实时日志系统。

SpringCloud框架使用总结
通过这张图，我们来了解一下各组件配置使用运行流程：

  1. 请求统一通过API网关（Zuul）来访问内部服务.

  2. 网关接收到请求后，从注册中心（Eureka）获取可用服务

  3. 由Ribbon进行均衡负载后，分发到后端具体实例

  4. 微服务之间通过Feign进行通信处理业务

  5. Hystrix负责处理服务超时熔断

  6. Turbine监控服务间的调用和熔断相关指标

关于Spring Cloud框架入门
入口：Spring Cloud入门

服务注册和发现Ereka

什么是Eureka：
Eureka和Consul 、Zookeeper 类似， Eureka 是一个用于服务注册和发现的组件，最开始主要应用于亚马逊公司旗下的云计算服务平台AWS o Eureka 分为Eureka Server 和Eureka Client, EurekaServer 为Eureka 服务注册中心， Eureka Client 为Eureka 客户端。

Ereka优势：
Eureka 和其他组件，比如负载均衡组件Ribbon 、熔断器组件Hystrix 、熔断器监控组件Hystrix Dashboard 组件、熔断器聚合监控Turbine 组件，以及网关Zuul 组件相互配合， 能够很容易实现服务注册、负载均衡、熔断和智能路由等功能。这些组件都是由Netflix 公司开源的，一起被称为Netflix OSS 组件。Netflix OSS 组件由Spring Cloud 整合为Spring Cloud Netflix 组件，

Eureka 的基本架构如下图所示，其中主要包括以下3 种角色。

  • Register Service ：服务注册中心，它是一个Eureka Server ，提供服务注册和发现的功能。
  • Provider Service ：服务提供者，它是一个Eureka Client ，提供服务。
  • Consumer Service ：服务消费者，它是一个Eureka Cient ，消费服务。

服务消费的基本过程如下：首先前要一个服务注册中心Eureka Server ，服务提供者EurekaClient 向服务注册中心Eureka Server 注册，将自己的信息（比如服务名和服务的IP 地址等）通过阻ST A 凹的形式提交给服务注册中心Eureka Server 。同样，服务消费者Eureka Client 也向服务注册中心 Eureka Server 注册，同时服务消费者获取一份服务注册列表的信息， 该列表
包含了所有向服务注册中心Eureka Server 注册的服务信息。获取服务注册列表信息之后，服务消费者就知道服务提供者的IP 地址，可以通过Http 远程调度来消费服务提供者的服务。
SpringCloud框架使用总结
Eureka特点：
1. 高可用性：
Eureka对CAP理论中可保证AP，而牺牲一致性，针对service发现这种非强一致的场景，虽然会有部分情况下没发现新服务导致请求出错，但不会因为数据的不同步问题导致全集群不可用
2. 自我保护模式：
Eureka针对网络分区问题，提供一种“自我保护”模式策略，即当Eureka服务节点在短时间里丢失了大量的心跳连接（注：可能发生了网络故障），此时Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对于”死亡“的仍然保留，以防还有客户端向其发
起请求。当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。
3. 基于HTTP：
Eureka是针对REST 服务，提供的注册发现中心，基于Http的通信机制的中间层服务，有对云环境天生的部署支持，可很方便的接入公有云等Paas平台。

关于Spring Cloud框架中Eureka集群使用
入口：Eureka集群

Ribbon负载均衡及Feign消费者调用服务

Ribbon是Spring Cloud Netflix的子项目，提供在客户端的负载均衡算法，将Netflix的中间层服务连接在一起。
负载均衡：
Ribbon内置可插拔、可定制的负载均衡组件并提供如下负载均衡策略：

  • 简单轮询负载均衡

  • 加权响应时间负载均衡

  • 随机负载均衡

  • 区域感知轮询负载均衡（针对AWS）

在Spring Cloud中，当Ribbon与Eureka配合使用时，Ribbon可自动从Eureka Server获取服务提供者地址列表，并基于负载均衡算法，请求其中一个服务提供者实例。展示了Ribbon与Eureka配合使用时的架构。
SpringCloud框架使用总结
Ribbon的两种运行方式：

  • 配置Ribbon Server List:

    通过在客户端中配置的ribbon Server List服务端列表去轮询访问以达到均衡负载的作用

  • Ribbon与Eureka联合使用：
    Ribbon集成Eureka后，ribbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表，各客户端通过Eureka注册中心自动发现已注册的服务列表以实现负载均衡
    SpringCloud框架使用总结
    Feign是一个声明式的Web Service客户端，它使得编写Web Serivce客户端变得更加简单。我们只需要使用Feign来创建一个接口并用注解来配置它既可完成。它具备可插拔的注解支持，包括Feign注解和JAX-RS注解。Feign也支持可插拔的编码器和解码器。Spring Cloud为Feign增加了对Spring MVC注解的支持，还整合了Ribbon和Eureka来提供均衡负载的HTTP客户端实现。

这段话看起来比较懵逼，这里说下实际使用，前面Ribbon调用服务提供者，我们通过restTemplate调用，缺点是，多个地方调用，同一个请求要写多次，不方便统一维护，这时候Feign来了，就直接把请求统一搞一个service作为FeignClient，然后其他调用Controller需要用到的，直接注入service，直接调用service方法即可；同时Feign整合了Ribbon和Eureka，所以要配置负载均衡的话，直接配置Ribbon即可，无其他特殊地方；当然Fiegn也整合了服务容错保护，断路器Hystrix，后面再说。

关于Spring Cloud框架中Ribbon负载均衡及Feign消费者调用服务使用
入口：Ribbon以及Feign使用

熔断器Hystrix及服务监控Dashboard

Hystrix设计原则

Hystrix 的设计原则如下。

  • 防止单个服务的故障耗尽整个服务的Servlet 容器（例如Tomcat ）的线程资源。
  • 快速失败机制，如果某个服务出现了故障，则调用该服务的请求快速失败，而不是线程等待。
  • 提供回退（ fallback ）方案，在请求发生故障时，提供设定好的回退方案。
  • 使用熔断机制，防止故障扩散到其他服务。
  • 提供熔断器的监控组件Hystrix Dashboard，可以实时监控熔断器的状态。

Hystrix 的工作机制

当服务的某个API 接口的失败次数在一定时间内小于设定的阀值时，熔断器处于关闭状态，该API 接口正常提供服务。当该API 接口处理请求的失败次数大于设定的阀值时， Hystrix 判定该API 接口出现了故障，打开熔断器，这时请求该API 接口会执行快速失败的逻辑（即fallback 回退的逻辑），不执行业务逻辑，请求的线程不会处于阻塞状态。处于打开状态的熔断器， 一段时间后会处于半打开状态，并将一定数量的请求执行正常逻辑。剩余的请求会执行快速失败，若执行正常逻辑的请求失败了，则熔断器继续打开： 若成功了，则将熔断器关闭。这样熔断器就具有了自我修复的能力。

Hystrix Dashboard 是监控Hystrix 的熔断器状态

在微服务架构中，为了保证服务实例的可用性，防止服务实例出现故障导致线程阻塞，而出现了熔断器模型。烙断器的状况反映了一个程序的可用性和健壮性，它是一个重要指标。Hystrix Dashboard 是监控Hystrix 的熔断器状况的一个组件，提供了数据监控和很友好的图形化展示界面。本节在上一节的基础上，以案例的形式讲述如何使用Hystrix Dashboard 监控熔断器的状态。
SpringCloud框架使用总结
Hystrix作用：
1. 熔断器：

Hystrix通过配置请求响应的错误率阈值，定义一个熔断开关，当达到阈值时，可以自动运行或手动调用,停止当前依赖一段时间(10秒)，熔断器默认错误率阈值为50%,超过将自动运行

2. 超时控制：

可配置依赖调用超时时间,超时时间一般设为比99.5%平均时间略高即可.当调用超时时，直接返回或执行fallback逻辑

3. 资源隔离：

采用线程/信号的方式,通过隔离限制依赖的并发量和阻塞扩散, 为每个依赖提供一个独立的小的线程池（或信号），如果线程池已满调用将被立即拒绝，默认不采用排队.加速失败判定时间

4. Fallback降级：

依赖调用结果分为:成功，失败（抛出异常），超时，线程拒绝，短路。 请求失败(异常，拒绝，超时，短路)时执行fallback(降级)逻辑
SpringCloud框架使用总结
SpringCloud框架使用总结
关于Spring Cloud框架中熔断器Hystrix及服务监控Dashboard使用
入口：Hystrix熔断器使用示例
入口：Hystrix集群使用

Zuul路由网关

智能路由网关组件Zuul：Zuul 作为微服务系统的网关组件，用于构建边界服务（ EdgeService ），致力于动态路由、过滤、监控、弹性伸缩和安全。

Zuul的作用

Zuul 作为路由网关组件，在微服务架构中有着非常重要的作用，主要体现在以下6 个方面。

  • 智能路由:Zuul 、Ribbon 以及Eureka 相结合，可以实现智能路由和负载均衡的功能， Zuul
    能够将请求流量按某种策略分发到集群状态的多个服务实例,以动态方式根据需要将请求路由至不同后端集群处理。
  • 网关将所有服务的API 接口统一聚合，并统一对外暴露。外界系统调用API 接口时，都是由网关对外暴露的API接口，外界系统不需要知道微服务系统中各服务相互调用的复杂性。微服务系统也保护了其内部微服务单元的API 接口，防止其被外界直接调用，导致服务的敏感信息对外暴露。
  • 安全与验证：网关服务可以做用户身份认证和权限认证，防止非法请求操作API 接口，对服务器起到保护作用。
  • 网关可以实现监控功能，实时日志输出，对请求进行记录。
  • 网关可以用来实现流量监控， 在高流量的情况下，对服务进行降级。
  • API 接口从内部服务分离出来， 方便做测试。
    SpringCloud框架使用总结

Zuul的工作原理

Zuul 是通过Servlet 来实现的， Zuul 通过自定义的ZuulServlet （类似于Spring MVC 的DispatchServlet〕来对请求进行控制。Zuul 的核心是一系列过滤器，可以在Http 请求的发起和响应返回期间执行一系列的过滤器。Zuul 包括以下4 种过滤器。

  • PRE 过滤器： 它是在请求路由到具体的服务之前执行的，这种类型的过滤器可以做安全验证，例如身份验证、参数验证等。
  • ROUTING 过滤器： 它用于将请求路由到具体的微服务实例。在默认情况下，它使用Http Client 进行网络请求。
  • POST 过滤器：它是在请求己被路由到微服务后执行的。一般情况下，用作收集统计信息、指标，以及将响应传输到客户端。
  • ERROR 过滤器：它是在其他过滤器发生错误时执行的。Zuul采取了动态读取、编译和运行这些过滤器。过滤器之间不能直接相互通信，而是通过RequestContext 对象来共享数据，每个请求都会创建一个RequestContext 对象。Zuul 过滤器具有以下关键特性。
  • Type （类型） ： Zuul 过滤器的类型，这个类型决定了过滤器在请求的哪个阶段起作用，例如Pre 、Post 阶段等。
  • Execution Order （执行顺序） ：规定了过滤器的执行顺序， Order 的值越小，越先执行。
  • Criteria （标准） ： Filter 执行所需的条件。
  • Action （行动）： 如果符合执行条件，则执行Action （即逻辑代码）。

Zuul 请求的生命周期如图所示，该图来自Zuul 的官方文档。当一个客户端Request 请求进入Zuul 网关服务时，网关先进入“pre filter飞进行一系列的验证、操作或者判断。然后交给“routing filter ”进行路由转发，转发到具体的服务实例进行逻辑处理、返回数据。当具体的服务处理完后，最后由“post filter 进行处理， 该类型的处理器处理完之后，将Response 信息返回给客户端。
SpringCloud框架使用总结
SpringCloud框架使用总结
关于Spring Cloud框架中Zuul网关使用
入口：Zuul网关使用

服务配置中心

SpringCloud Config简介

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

通俗点，就是统一管理配置，包括方便切换环境配置，以及修改配置无需动代码，省心省力；

如果用上SpringCloud Bus，能实现无需重启，自动感知配置变化以及应用新配置；

Spring Cloud Bus 是用轻量的消息代理将分布式的节点连接起来，可以用于广播配置文件的更改或者服务的监控管理。个关键的思想就是，消息总线可以为微服务做监控，也可以实现应用程序之间相I T-L 通信。S pring Cloud Bus 可选的消息代理组建包括RabbitMQ 、AMQP 和Kafka 等。本节讲述的是用RabbitMQ 作为Spring Cloud 的消息组件去刷新更改微服务的配置文件。
SpringCloud框架使用总结
关于Spring Cloud框架中服务配置中心使用
入口：spring cloud config 使用

个人总结

微服务vs传统开发
使用微服务有一段时间了，这种开发模式和传统的开发模式对比，有很大的不同。

  1. 分工不同，以前我们可能是一个一个模块，现在可能是一人一个系统。
  2. 架构不同，服务的拆分是一个技术含量很高的问题，拆分是否合理对以后发展影响巨大。
  3. 部署方式不同，如果还像以前一样部署估计累死了，自动化运维不可不上。
  4. 容灾不同，好的微服务可以隔离故障避免服务整体宕掉，坏的微服务设计仍然可以因为一个子服务出现问题导致连锁反应。

相关推荐