Spring Cloud 初步认识-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_52803316/article/details/148471134

一、Spring Cloud 概述

（一）定义

Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的开发便利性，简化了分布式系统基础设施的开发。它将市面上成熟的服务框架组合起来，通过 Spring Boot 风格进行再封装，屏蔽掉复杂的配置和实现原理，为开发者提供了一套简单易懂、易部署和易维护的分布式系统开发工具包。例如，它能实现服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等功能，且都可以用 Spring Boot 的开发风格做到一键启动和部署。

（二）特点

集成性：深度集成了 Netflix 等开源组件，这些组件在微服务领域应用广泛且得到认可，为开发者提供了完整且经过实践检验的微服务解决方案。
易用性：遵循 Spring Boot 的开发风格，开发者能快速理解和上手，同时有丰富的文档和社区支持，便于解决使用过程中遇到的问题。
灵活性：允许开发者根据项目实际需求选择适合的组件进行集成，可满足不同规模和复杂度的微服务应用需求。
扩展性：随着业务发展，微服务应用需要不断扩展，Spring Cloud 提供了良好的扩展性，开发者能轻松对应用进行水平或垂直扩展。
可靠性：通过一系列机制，如熔断器、负载均衡等，确保微服务应用的稳定性和可靠性，即使面对高并发、故障转移等复杂场景，也能保持良好的性能表现。

（三）与其他技术的关系

与微服务的关系：微服务是一种架构理念，提出了微服务的设计原则，为具体的技术落地提供指导思想。Spring Cloud 是关注全局的微服务协调整理治理框架，它将 Spring Boot 开发的一个个单体微服务整合并管理起来，为各个服务之间提供配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、精选决策、分布式会话等集成服务。
与 Spring Boot 的关系：Spring Boot 专注于快速方便地开发单个个体微服务，而 Spring Cloud 是在 Spring Boot 基础上构建的，用于快速构建分布式系统的通用模式的工具集。Spring Boot 可以离开 Spring Cloud 独立开发项目，但 Spring Cloud 离不开 Spring Boot，属于依赖关系。

二、Spring Cloud 核心组件

（一）服务注册与发现组件

Eureka
- 基本架构：由服务提供者（暴露服务的服务提供方）、服务消费者（调用远程服务的服务消费方）和 Eureka Server（服务注册中心和服务发现中心）三个角色组成。
- 工作原理：服务提供者启动时，会将自己的网络地址、端口号等信息注册到 Eureka Server 上；服务消费者通过 Eureka Server 查询所需服务的信息，从而实现服务的动态发现。同时，Eureka 还提供了客户端缓存机制，即使所有的 Eureka Server 都挂掉，客户端依然可以利用缓存中的信息消费其他服务的 API。
- 自我保护机制：如果 Eureka Server 在多个心跳周期内（默认 90 秒）没有接收到某个节点的心跳，Eureka Server 将会进入自我保护机制，此时它不会轻易剔除该服务实例，以防止因网络分区等原因导致的误判。
Nacos
- 功能特性：不仅提供服务注册与发现功能，还具备服务健康监测、动态配置服务、动态 DNS 服务、服务及其元数据管理等功能。
- 分级存储模型：支持服务分级存储，可根据不同的环境、集群等进行划分，方便管理和维护。
- 与 Eureka 的区别：Nacos 功能更全面，支持动态配置，而 Eureka 主要侧重于服务注册与发现。
Consul
- 特点：不仅提供服务注册与发现，还提供了服务健康检查、键值存储等功能，可与 Docker 容器无缝集成。
- 适用场景：适用于需要进行服务健康检查和键值存储的场景。

（二）负载均衡组件

Ribbon
- 原理：是一个基于 HTTP 和 TCP 的客户端负载均衡工具，它基于 Netflix Ribbon 实现。通过 Spring Cloud 的封装，可以让面向服务的 REST 模版请求自动转换成客户端负载均衡的服务调用。
- 负载均衡策略：包括简单轮询、随机、加权响应时间、区域感知轮询、最小连接数等多种策略，开发者还可以自定义负载均衡策略。例如，RoundRobinRule 为轮询策略，RandomRule 为随机策略。
- 使用方式：通常在服务消费者的 RestTemplate 上添加 @LoadBalanced 注解，这样 RestTemplate 就具有了负载均衡的能力。在调用服务时，只需要使用服务名称，Ribbon 会自动从注册中心获取服务实例列表，并根据负载均衡策略选择一个实例进行请求。
Spring Cloud LoadBalancer
- 优势：是 Spring Cloud 官方推出的负载均衡器，替代了 Ribbon，具有更好的性能和扩展性，支持 WebFlux 等。
- 使用场景：在新的 Spring Cloud 项目中，推荐使用 Spring Cloud LoadBalancer 进行负载均衡。

（三）服务调用组件

Feign
- 简介：是一个声明式的 Web 服务客户端，使得编写 Web 服务客户端变得更加简单。它默认会使用 Ribbon 来实现负载均衡。
- 使用方式：通过定义接口和注解的方式来实现服务调用。例如，使用 @FeignClient 注解指定服务名称，在接口中定义服务调用的方法。
- 优点：代码简洁，提高了开发效率，同时支持请求压缩和响应压缩等功能。
OpenFeign
- 与 Feign 的关系：是 Feign 的扩展，在 Feign 的基础上增加了对 Spring MVC 注解的支持，使用起来更加方便。
- 常用注解：如 @GetMapping、@PostMapping 等，用于定义服务调用的请求方式和路径。

（四）服务熔断与降级组件

Hystrix
- 作用：用于防止服务雪崩效应。在微服务架构中，一个服务可能依赖多个其他服务，如果某个服务出现故障或响应延迟，可能会导致调用它的服务也出现问题，最终影响整个系统的稳定性。Hystrix 通过断路器模式，当服务调用失败或超时达到一定阈值时，会切断对该服务的请求，直接返回一个默认的响应或执行一个降级逻辑，避免服务之间的连锁故障。
- 使用方式：可以使用 @HystrixCommand 注解来对服务调用方法进行包装，当方法调用失败时，执行降级方法。例如：

@HystrixCommand(fallbackMethod = "fallbackMethod") public String callService () {  // 调用服务的代码 } public String fallbackMethod () {  return "This is a fallback response" ; }

Resilience4j
- 特点：是 Spring Cloud G 版本推荐的容错方案，是一个轻量级的容错库，专为 Java 8 和函数式编程而设计，借鉴了 Hystrix 的设计，提供了断路器、并发调用隔离、限流、重试、超时等功能。
- 适用场景：适用于对性能要求较高、需要更灵活容错策略的场景。
Sentinel
- 组成：由 Sentinel 控制台和 Sentinel 客户端组成，控制台用于配置和监控规则，客户端用于执行限流、熔断等操作。
- 基本概念：包括资源、规则、簇点链路等。通过定义资源和规则，可以对服务进行限流、降级等操作。
- 应用场景：在 Spring Cloud Alibaba 项目中广泛应用，可有效保障服务的高可用性。

（五）配置中心组件

Spring Cloud Config
- 工作原理：提供服务器端和客户端，服务器端将配置文件存储在集中的位置（如 Git 仓库、SVN 等），客户端从配置中心获取自己所需的配置信息。这样可以方便地对配置进行管理和修改，而不需要在每个服务中修改配置文件，并且可以实现配置的动态更新，无需重启服务即可使配置生效。
- 特点：支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。
Nacos Config
- 优势：支持配置可视化和动态刷新，提供了更加友好的配置管理界面，方便开发者进行配置的管理和维护。
- 使用场景：在 Spring Cloud Alibaba 项目中，推荐使用 Nacos Config 作为配置中心。

（六）服务网关组件

Zuul
- 功能：是 Spring Cloud 全家桶中的微服务 API 网关，提供动态路由、监控、弹性负载和安全功能。所有从设备或网站来的请求都会经过 Zuul 到达后端的应用程序，它就像一个边界性质的应用程序，对请求进行过滤和转发。
- 与其他组件的配合：通常与 Ribbon 结合实现负载均衡，与 Hystrix 结合实现熔断和降级。
Spring Cloud Gateway
- 核心概念：基于 Project Reactor 的智能可编程路由器，具有路由断言工厂、路由过滤器等核心概念。通过定义路由规则和过滤器，可以实现请求的路由和处理。
- 特征：性能更高，支持 WebFlux，提供了更加灵活的配置方式。例如，可以根据请求的路径、头部信息等将请求转发到不同的微服务，并可以在请求转发前后进行过滤处理。

（七）服务链路追踪组件

Sleuth + Zipkin
- 作用：Sleuth 用于生成链路 ID，Zipkin 是可视化工具，它们共同用于跟踪请求在微服务间的调用路径，定位性能瓶颈，统计每个服务的响应时间、错误率。例如，在一个电商系统中，可以跟踪用户从下单到支付的整个请求流程，找出可能存在的性能问题。
- 工作流程：Sleuth 为每个请求生成唯一的 TraceID 和 SpanID，记录调用路径，Zipkin 收集并可视化请求链路，展示每个服务的耗时。
Skywalking
- 优势：功能更强大，支持监控，不仅可以进行链路追踪，还可以对服务的性能、健康状态等进行全面监控。
- 适用场景：适用于对服务监控和性能分析要求较高的场景。

（八）消息总线组件

Spring Cloud Bus - 作用：集成 RabbitMQ 或 Kafka 等消息队列，实现配置变更的广播。当修改 Config Server 后，通过 Bus 通知所有客户端刷新配置。同时，它还支持服务间事件驱动通信，例如订单创建后发布事件，库存服务订阅并扣减库存。 - 使用场景：在需要进行配置动态更新和服务间事件通信的场景中使用。

三、Spring Cloud 工作流程示例

以电商系统为例，包含 api - gateway、order - service、payment - service、inventory - service 等服务，其调用流程如下：

服务注册：order - service、payment - service 等服务启动后，自动向 Eureka Server 或 Nacos 等注册中心注册自己的 IP 和端口信息。
客户端请求：用户请求 http://gateway:8080/api/orders/create，API Gateway 根据路由规则，将请求转发至 order - service。
服务间调用：order - service 通过 OpenFeign 调用 payment - service 进行支付。Ribbon 从注册中心获取 payment - service 的多个实例列表，并选择一个调用。
熔断与降级：若 payment - service 超时或异常，Hystrix 或 Sentinel 等熔断器触发熔断，返回预定义的 fallback 结果。
配置管理：所有服务从 Config Server 或 Nacos Config 获取配置（如数据库连接信息、熔断器阈值）。配置变更时，Spring Cloud Bus 通知各服务刷新配置。
链路追踪：Sleuth 为每个请求生成唯一的 TraceID 和 SpanID，记录调用路径。Zipkin 收集并可视化请求链路，展示每个服务的耗时。