Spring Cloud Alibaba介绍

官方文档：https://sca.aliyun.com/docs/2023/overview/what-is-sca/

Spring Cloud Alibaba 是阿里开源的基于 Spring Cloud 的分布式微服务解决方案，它将阿里的中间件产品与 Spring Cloud 框架无缝集成，为开发者提供简单、便捷的一站式微服务开发解决方案。

依托 Spring Cloud Alibaba，只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里分布式应用解决方案，通过阿里中间件来迅速搭建分布式应用系统。

Spring Cloud 微服务体系

Spring Cloud 是分布式微服务架构的一站式解决方案，它提供了一套简单易用的编程模型，使我们能在 Spring Boot 的基础上轻松地实现微服务系统的构建。 Spring Cloud 提供以微服务为核心的分布式系统构建标准。

Spring Cloud本身并不是一个开箱即用的框架，它是一套微服务规范，共有两代实现。1.Spring Cloud Netflix 是Spring Cloud的第一代实现，主要由 Eureka、Ribbon、Feign、Hystrix 等组件组成。2.Spring Cloud Alibaba 是Spring Cloud的第二代实现，主要由 Nacos、Sentinel、Seata 等组件组成。

Spring Cloud Alibaba 定位

注册配置中心–Nacos

服务治理架构

服务治理（Service Governance）是指在微服务架构中管理和控制服务的生命周期、状态、质量和安全性的一系列技术和策略。

注册中心原理

服务治理中的三个角色分别是什么?1.服务提供者:暴露服务接口，供其它服务调用；2.服务消费者:调用其它服务提供的接口；3.注册中心:记录并监控微服务各实例状态，推送服务变更信息。

消费者如何知道提供者的地址?·服务提供者会在启动时注册自己信息到注册中心，消费者可以从注册中心订阅和拉取服务信息。

消费者如何得知服务状态变更?·服务提供者通过心跳机制向注册中心报告自己的健康状态，当心跳异常时注册中心会将异常服务剔除，并通知订阅了该服务的消费者。

当提供者有多个实例时，消费者该选择哪一个?·消费者可以通过负载均衡算法，从多个实例中选择一个。

Nacos介绍

官方文档：https://nacos.io/docs/latest/what-is-nacos/

Nacos 是阿里巴巴推出的一款用于服务发现、配置管理和服务治理的开源平台。它在微服务架构中起着重要作用，尤其是用于服务的注册和发现、动态配置管理，以及支持 DNS 和 RPC 的服务健康检查等功能。

Nacos 的关键特性

1.服务注册和发现

服务发现和注册：1.Nacos支持基于DNS和HTTP的服务发现。服务提供者启动时，会将自己的服务信息注册到 Nacos，消费者则通过 Nacos 查找可用服务。2.通过实时心跳机制和健康检查，确保服务的可用性。

2.动态配置服务

动态配置管理1.Nacos 提供集中化的配置管理，支持动态更新。应用在运行时可以从 Nacos 中获取并实时更新配置，无需重启应用。2.支持多环境（如开发、测试、生产）的配置管理。

3.实时健康监控

Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。

若服务不可用，Nacos 会自动将其从可用列表中移除，确保系统稳定。

4.动态DNS服务

动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。

5.易于集成：

Nacos 很容易与 Spring Cloud、Dubbo 等微服务框架集成，提供更加便捷的开发体验。

Nacos入门示例

服务注册与发现

1.环境准备

1.1下载Nacos
https://github.com/alibaba/nacos/releases

1.2启动 Nacos
解压并在终端中运行以下命令启动 Nacos：

sh startup.sh -m standalone

1.3创建 Spring Boot 项目
可以使用 Spring Initializr 来生成项目。

选择 Spring Boot 版本 2.6.0 或以上，添加以下依赖：
Spring Web
Nacos Discovery

2.服务注册与发现依赖

在 pom.xml 中，添加 Nacos Discovery 依赖：

<dependencies><!-- Spring Boot Web 依赖 --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><!-- Nacos Discovery 依赖 --><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId><version>2021.1</version></dependency>
</dependencies>

3.配置application.yml 文件

在 application.yml 文件中配置 Nacos：

spring:application:name: example-service  # 服务名称cloud:nacos:discovery:server-addr: 127.0.0.1:8848  # Nacos 服务器地址

4.创建一个简单的控制器

@RestController
public class HelloController {@GetMapping("/hello")public String hello() {return "Hello from example-service!";}
}

5.启动服务

启动类

@SpringBootApplication
@EnableDiscoveryClient  // 启用 Nacos 服务发现
public class NacosExampleApplication {public static void main(String[] args) {SpringApplication.run(NacosExampleApplication.class, args);}
}

启动 Spring Boot 项目，服务将自动注册到 Nacos。

6.通过 Nacos 控制台查看服务

访问 Nacos 控制台 http://localhost:8848/nacos，点击 “服务列表”，可以看到注册的 example-service。

服务消费

创建服务消费者
可以创建一个新的 Spring Boot 项目作为服务消费者，添加相同的 Nacos Discovery 依赖和配置，并使用 RestTemplate 或 Feign 来调用服务。

1.配置 Feign 客户端

1.1添加依赖

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

1.2创建Feign客户端接口

@FeignClient("example-service")
public interface ExampleServiceClient {@GetMapping("/hello")String hello();
}

2.使用 Feign 客户端：

@RestController
public class ConsumerController {@Autowiredprivate ExampleServiceClient exampleServiceClient;@GetMapping("/consume")public String consume() {return exampleServiceClient.hello();}
}

3.启动服务消费者

启动服务消费者后，它会通过 Nacos 发现并调用 example-service。访问 http://localhost:8080/consume，可以看到服务的返回结果。

分布式事务–Seata

分布式事务中的问题

对于分布式系统而言，需要保证分布式系统中的数据一致性，保证数据在子系统中始终保持一致，避免业务出现问题。分布式系统中对数据的操作要么一起成功，要么一起失败，必须是一个整体性的事务。

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

简单的说，在分布式系统中一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务节点上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

举个例子：在电商网站中，用户对商品进行下单，需要在订单表中创建一条订单数据，同时需要在库存表中修改当前商品的剩余库存数量，两步操作一个添加，一个修改，一定要保证这两步操作一定同时操作成功或失败，否则业务就会出现问题。

任何事务机制在实现时，都应该考虑事务的 ACID 特性，包括：本地事务、分布式事务。对于分布式事务而言，即使不能都很好的满足，也要考虑支持到什么程度。

典型的分布式事务场景：跨库事务、分库分表、微服务化。

Seata介绍

官方文档：https://seata.apache.org/zh-cn/docs/overview/what-is-seata

Seata 是一款开源的分布式事务解决方案，旨在解决微服务架构下跨多个服务之间数据一致性的问题。它通过分布式事务协调多个服务的数据操作，确保跨多个服务的事务操作要么全部成功，要么全部失败。

Seata 的核心在于其简化的两阶段提交协议，避免了传统分布式事务中常见的性能瓶颈和复杂性。

Seata工作原理详解

Seata的核心思想是将分布式事务拆分成多个 局部事务，并通过一套全局事务协调器（TC，Transaction Coordinator）来统一管理和控制。Seata 的工作原理可以分为以下几个关键组件和工作流程。

Seata的三大核心组件

Seata 的三大核心组件1.Transaction Coordinator (TC)：全局事务协调器，负责协调和管理全局事务的状态，确保所有分支事务按照要求提交或回滚。2.Transaction Manager (TM)：事务管理器，负责开启、提交或回滚全局事务，控制整个事务的生命周期。3.Resource Manager (RM)：资源管理器，负责管理每个分支事务中的资源（如数据库连接、锁等），并汇报分支事务的状态给TC。

工作流程

Seata的工作流程通常包含以下几个步骤，以下以Seata的AT模式（Automatic Transaction）为例：

AT模式流程1.全局事务开始：事务管理器（TM）通过 @GlobalTransactional 注解开启全局事务，TM会向事务协调器（TC）注册该事务并生成唯一的全局事务 ID（XID）。这个XID用来标识整个分布式事务。2.分支事务注册：每个服务的资源管理器（RM）会参与到全局事务中。当业务逻辑执行到每个微服务时，Seata的RM会拦截数据库操作，并将该操作作为一个分支事务向TC注册，分支事务与全局事务绑定在一起。分支事务在本地数据库执行时，只会在本地事务中提交，但不对外暴露，等待全局事务的控制。3.事务提交阶段：当全局事务执行完成时，TM会发出提交请求给TC，TC负责通知各个RM提交分支事务，RM将对应的本地事务进行最终提交，数据操作生效。4.事务回滚阶段：如果全局事务中任意一个分支事务失败，TC会通知所有RM回滚分支事务。在AT模式下，Seata自动生成UNDO日志，保存每个分支事务的操作前状态。当回滚发生时，Seata会根据UNDO日志恢复数据到事务操作前的状态，从而确保数据的一致性。

事务模型

Seata 支持四种事务模式，每种模式适应不同的业务场景和需求：

四种事务模式1.AT模式（Automatic Transaction）：Seata的核心模式，自动管理分布式事务。通过生成UNDO日志来实现事务的自动回滚和提交。适合场景：业务系统对延迟敏感且读写操作频繁的场景。2.TCC模式（Try-Confirm-Cancel）：提供灵活性较高的分布式事务解决方案，开发者需手动实现事务的Try、Confirm和Cancel阶段。Try阶段预留资源，Confirm阶段执行资源的真正操作，Cancel阶段释放资源。适合场景：需要高性能或需要自定义业务逻辑的事务场景。3.SAGA模式：将长事务拆解为一系列可补偿的子事务，通过反向补偿（回滚业务动作）来实现全局事务的回滚。适合长时间运行的事务，如金融系统中的扣款和退款业务。4.XA模式：基于两阶段提交协议，XA模式实现强一致性事务，通常用于对数据一致性要求极高的场景。适合场景：需要数据库级别的分布式事务控制。

两阶段提交

两阶段提交（Two-Phase Commit Protocol）
Seata 的AT模式实现了一种简化版的两阶段提交协议，分为准备阶段和提交阶段：

Seata的AT模式实现了一种简化版的两阶段提交协议，分为"准备阶段"和"提交阶段"：1.准备阶段（Prepare Phase）：在全局事务中，各个分支事务执行本地事务，并生成UNDO日志。此时本地事务已经执行，但并未对外提交（对其他事务不可见），等待全局事务的提交或回滚指令。2.提交阶段（Commit Phase）：当全局事务需要提交时，TC会通知各个分支事务提交操作，删除对应的UNDO日志，数据正式生效。如果需要回滚，TC会通知各个分支事务进行回滚操作，RM通过UNDO日志将数据恢复到事务开始前的状态。

UNDO/REDO 日志

在AT模式下，Seata 依赖 UNDO日志 进行事务的回滚。每个分支事务在执行本地事务操作时，Seata 会自动生成一份UNDO日志，记录该操作前的状态。当TC要求回滚时，RM 会通过UNDO日志恢复到操作前的数据状态，从而保证数据的一致性。

UNDO 日志记录了数据库表的元数据和修改前的数据快照，存储在数据库中，通过这份日志，Seata 能够轻松还原分支事务的操作。

Seata 的优势

Seata的优势1.简化的分布式事务管理：Seata的AT模式通过自动生成和管理UNDO日志，减少了分布式事务的复杂度。2.高性能：在AT模式下，事务提交是本地提交，Seata通过异步方式管理全局事务，大大提升了性能。3.支持多种事务模式：除了AT模式，Seata还支持TCC、SAGA、XA等多种模式，适应不同业务需求。4.强大的扩展性和容错性：Seata采用微内核架构，支持水平扩展，并通过数据库的UNDO/REDO日志保证数据一致性，提供较强的容错能力。

限流降级–Sentinel

服务调用链路上的问题

雪崩效应

在微服务系统中，一个对外的业务功能可能会涉及很长的服务调用链路。当其中某个服务出现异常，如果没有服务调用保护机制，可能会造成该服务调用链路上大量相关服务直接或间接调用的服务器仍然持续不断发起请求，最终导致相关的所有服务资源耗尽产生异常，发生雪崩效应。限流和降级分别作为在流量控制和服务保护方面的两个重要手段，可以有效地应对此类问题。

服务保护方案

1.限流

限流是一种针对服务提供者的策略，用于控制对特定服务接口或服务实例的访问量。其目的在于保护服务提供者免受过大请求流量的影响，确保服务稳定性。限流措施可以在服务提供者或服务消费者两端实现，通过设定流量阈值并采取排队、拒绝请求或返回错误信息等方式来控制流量，从而保护服务。

2.降级

降级是针对服务消费者的应对策略，在服务出现异常或限流时，通过对服务调用进行降级处理，确保消费者端能够在异常情况下正常工作。降级的目的在于转变为弱依赖状态，使系统能够在服务不可用时提供基本的功能或数据。这种策略可以在服务消费者端实施，通过返回默认值、提供备用数据或简化功能等方式来保证系统的可用性。

总体而言，限流和降级作为微服务架构中的重要机制，尽管在实现上可能有多种方式，但它们都着眼于保护服务提供者和消费者，在面对异常情况时确保系统稳定运行。限流关注于保护服务提供者，控制请求流量；而降级则关注于服务消费者，确保在服务不可用或异常情况下提供基本的功能。

Sentinel 介绍

官方文档：https://sentinelguard.io/zh-cn/docs/introduction.html

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。

Sentinel基本概念

Sentinel基本概念1.资源资源是Sentinel的关键概念。它可以是Java应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。在接下来的文档中，我们都会用资源来描述代码块。只要通过Sentinel API定义的代码，就是资源，能够被Sentinel保护起来。大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。2.规则围绕资源的实时状态设定的规则，可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。

Sentinel 功能和设计理念

1.流量控制

流量控制在网络传输中是一个常用的概念，它用于调整网络包的发送数据。然而，从系统稳定性角度考虑，在处理请求的速度上，也有非常多的讲究。任意时间到来的请求往往是随机不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。Sentinel 作为一个调配器，可以根据需要把随机的请求调整成合适的形状，如下图所示：

请求限流：限制访问微服务的请求的并发量，避免服务因流量激增出现故障。

2.熔断降级

什么是熔断降级

熔断机制是为了防止某些资源的异常或超负荷状态影响整个系统。Sentinel 的熔断功能类似于 Netflix 的 Hystrix，在检测到某个服务出现异常或延迟过高时，会短暂地将该服务熔断，拒绝新的请求进入，从而防止系统崩溃。

多种熔断策略

Sentinel提供了多种熔断策略：1.基于响应时间的熔断：如果某个资源的平均响应时间超过设定的阈值，则会触发熔断。2.基于异常比例的熔断：如果某个资源在一定时间窗口内的异常请求比例超过设定的阈值，也会触发熔断。3.基于异常数的熔断：如果某个资源在一段时间内发生的异常请求数超过设定的值，Sentinel 会进行熔断。