【合集】Spring Cloud 组件——架构进化史话 & Eureka，Nacos，Apollo，OpenFeign，Ribbon，Sentinel，Gateway ，Seata+事务. . .

前言

Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁，领导选举，分布式会话，集群状态）。

注意：

首先，尽管Spring Cloud带有“Cloud”这个单词，但它并不是云计算解决方案，而是在Spring Boot基础之上构建的，用于快速构建分布式系统的通用模式的工具集。

其次，使用Spring Cloud开发的应用程序非常适合在Docker和PaaS（比如Pivotal Cloud Foundry）上部署，所以又叫做云原生应用（Cloud Native Application）。云原生可以简单地理解为面向云环境的软件架构。

Spring Boot用来开发项目

Spring Cloud用来管理项目，Spring Cloud管理的项目需要基于Spring Boot来开发

Spring Cloud常用的组件列举：

Eureka：服务注册与发现组件，用于实现服务的自动注册与发现。
Ribbon：负载均衡组件，用于实现客户端的负载均衡。
Feign：声明式的HTTP客户端，用于简化服务间的调用。
Hystrix：容错管理组件，用于实现服务的容错和降级。
Zuul：API网关组件，用于实现统一的访问入口和路由。
Config：配置管理组件，用于实现分布式系统的配置管理。
Bus：消息总线组件，用于实现配置的动态刷新。
Sleuth：分布式追踪组件，用于实现分布式系统的请求追踪。
Stream：消息驱动组件，用于实现分布式系统的消息传递。
Security：安全管理组件，用于实现分布式系统的安全管理。
Nacos：动态服务发现、配置管理和服务管理平台。
Consul：服务发现和配置管理工具。
Zipkin：分布式跟踪系统，用于追踪请求的调用链。
Spring Cloud Gateway：新一代的API网关，用于实现统一的访问入口和路由。
Spring Cloud Alibaba：阿里巴巴提供的一套基于Spring Cloud的微服务解决方案，包括Nacos、Sentinel、Dubbo等组件。
Seata：分布式事务解决方案，用于解决分布式系统中的事务一致性问题。

本篇博客是Spring Cloud 常用组件的相关博客文章的合集，涉及Spring Cloud常用的组件，比如Nacos，Gateway，Sentinel，OpenFeign，Ribbon等，结合实际应用场景阐述相关组件的使用。

前言
引出
单体架构到微服务
- 1.单体架构，微服务，分布式
- 2.服务器安装nacos+sentinel
服务注册与发现–Nacos+Eureka
- 0.Eureka（服务注册和发现）
- 1.Nacos的Linux安装配置
- - nacos参数设置初步（JVM调优）
- 2.Nacos作为注册中心和配置中心
- 3.Nacos集群和nginx
- Eureka和Nacos的区别？
- 4.Apollo（阿波罗）配置中心
服务的调用–OpenFeign+Ribbon
- 1.RestTemplate+Ribbon
- 2.OpenFeign
- 3.微服务调用链路分析 Sleuth+Zipkin
流量治理–Sentinel
- 1.雪崩问题和Sentinel初识
- 2.Sentinel的流控和熔断
统一的访问入口和路由–Gateway
- 1.Gateway的入门案例
- 2.Gateway的认证鉴权，与Sentinel整合
事务，分布式事务–Seata
- 0.MySQL数据库的事务
- 1.什么是分布式事务
- 2.Seata组件的模式和应用案例
- 3.再深入，分布式事务理论基础
总结

引出

1.SpringCloud是，在Spring Boot基础之上构建的，用于快速构建分布式系统的通用模式的工具集；
2.单体架构到微服务Microservices架构的变迁；
3.动态服务发现、配置管理和服务管理平台nacos；
4.声明式的HTTP客户端，用于简化服务间的调用openFeign；
5.流量控制、熔断降级规则统一配置和管理的入口sentinel；
6.新一代的API网关，用于实现统一的访问入口和路由gateway；

单体架构到微服务

1.单体架构，微服务，分布式

SpringCloud溯源——从单体架构到微服务Microservices架构 & 分布式和微服务 & 为啥要用微服务

2.服务器安装nacos+sentinel

SpringCloud相关组件——nacos和sentinel的安装和配置 & 运行内存情况 & 服务器被非法登陆尝试的解决

服务注册与发现–Nacos+Eureka

0.Eureka（服务注册和发现）

Eureka（服务注册和发现）——Eureka的简介和原理 & Eureka的使用和分析 & 心跳续约策略，服务的下线和剔除，自我保护 & Eureka集群的搭建

用在前面的微服务学习过程中注册中心和配置中心是两个非常重要的组成部分，但是注册中心、配置中心的管理却非常困难，特别是配置中心在更新完配置之后需要用到Bus进行配置推送，整个操作过程及其麻烦，正是因为这些原因阿里推出了一款叫做nacos的应用，该应用在能够实现注册中心的同时也实现了配置中心，而且操作十分简单，能够将程序员从繁琐的注册中心、配置中心的操作中解救出来。

英文全称Dynamic Naming and Configuration Service，Na为naming/nameServer即注册中心,co为configuration即注册中心，service是指该注册/配置中心都是以服务为核心。

Nacos注册中心分为server与client，server采用Java编写，为client提供注册发现服务与配置服务。而client可以用多语言实现，client与微服务嵌套在一起，nacos提供sdk和openApi，如果没有sdk也可以根据openApi手动写服务注册与发现和配置拉取的逻辑。

1.Nacos的Linux安装配置

Nacos基础（1）——初识Dynamic Naming and Configuration Service & Linux上nacos安装 + 配置 + 运行【附安装包】

华为云云耀云服务器L实例评测｜SpringCloud相关组件——nacos和sentinel的安装和配置 & 运行内存情况 & 服务器被非法登陆尝试的解决

nacos参数设置初步（JVM调优）

nacos应用——占用内存过多问题解决（JVM调优初步）

2.Nacos作为注册中心和配置中心

Nacos基础（2）——nacos的服务器和命名空间 & springBoot整合nacos & 多个nacos配置的情况

3.Nacos集群和nginx

Nacos基础（3）——nacos+nginx & 集群的配置和启动 & 端口开放 & nginx反向代理nacos集群

Eureka和Nacos的区别？

eureka是一个jar包，必须在项目中引用才能发布，eureka没有配置中心
nacos是一个可运行的服务程序。nacos有配置中心
eureka是ap方案，nacos默认是cp方案
CAP方案
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
- 分区容错性（Partition tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务。因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域，不同的区域仍然可以正常访问数据。分区容错性是必须的
- 可用性(Availability)：每一个请求不管成功或者失败都有响应。
- 一致性(Consistency）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。

4.Apollo（阿波罗）配置中心

Apollo（阿波罗）——携程推出的分布式配置管理中心 & 启动Apollo & SpringBoot集成 & @ConfigurationProperties的使用姿势

主要内容：

1.如何启动Apollo；
2.如何SpringBoot集成；
3.@ConfigurationProperties的使用姿势；

服务的调用–OpenFeign+Ribbon

1.RestTemplate+Ribbon

SpringCloud入门（微服务调用 RestTemplate）——微服务调用的方式 & RestTemplate的使用 & 使用nacos的服务名初步（Ribbon负载均衡）

2.OpenFeign

SpringCloud入门（微服务调用 OpenFeign）——从RestTemplate到OpenFeign & OpenFeign的相关配置 & 源码的分析和请求流程拆解

实际使用遇到的问题及解决

bug记录——The bean ‘xxx.FeignClientSpecification‘ could not be registered.
bug记录——设置了feign的fallback，但是没有生效

3.微服务调用链路分析 Sleuth+Zipkin

SpringCloud链路追踪——Spring Cloud Sleuth 和 Zipkin 介绍 & Windows 下使用初步

流量治理–Sentinel

Sentinel 控制台是流量控制、熔断降级规则统一配置和管理的入口，它为用户提供了机器自发现、簇点链路自发现、监控、规则配置等功能。在 Sentinel 控制台上，我们可以配置规则并实时查看流量控制效果。

随着微服务的普及，服务调用的稳定性变得越来越重要。Sentinel以“流量”为切入点，在流量控制、断路、负载保护等多个领域开展工作，保障服务可靠性。

哨兵具有以下特点：

场景丰富： Sentinel 支持阿里巴巴双十一的关键场景10多年，如秒杀（即控制突发流量，使其在系统容量可接受范围内），消息负载转移，不可靠下游应用的断路。
全面的实时监控： Sentinel 提供实时监控能力。您可以秒级精确查看服务器的监控数据，甚至可以看到少于500个节点的集群的整体运行状态。
广泛的开源生态系统： Sentinel 提供了开箱即用的模块，可以轻松地与其他开源框架/库集成，例如 Spring Cloud、Dubbo 和 gRPC。使用Sentinel只需要引入相关的依赖，做一些简单的配置即可。
Sound SPI Extensions： Sentinel 提供了简单易用且完善的 SPI 扩展接口。您可以使用 SPI 扩展快速自定义逻辑，例如，您可以定义自己的规则管理，或适应特定的数据源。

1.雪崩问题和Sentinel初识

Sentinel学习（1）——CAP理论，微服务中的雪崩问题，和Hystix的解决方案 & Sentinel的相关概念 + 下载运行

2.Sentinel的流控和熔断

Sentinel学习（2）——sentinel的使用，引入依赖和配置 & 对消费者进行流控 & 对生产者进行熔断降级

统一的访问入口和路由–Gateway

SpringCloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。

SpringCloud Gateway 作为 Spring Cloud 生态系统中的网关，目标是替代 Zuul，在Spring Cloud 2.0以上版本中，没有对新版本的Zuul 2.0以上最新高性能版本进行集成，仍然还是使用的Zuul 2.0之前的非Reactor模式的老版本。而为了提升网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。

Spring Cloud Gateway 的目标，不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。

SpringCloud Gateway 特征

SpringCloud官方，对SpringCloud Gateway 特征介绍如下：

（1）基于 Spring Framework 5，Project Reactor 和 Spring Boot 2.0

（2）集成 Hystrix 断路器

（3）集成 Spring Cloud DiscoveryClient

（4）Predicates（谓词、断言）和 Filters 作用于特定路由，易于编写的 Predicates 和 Filters

（5）具备一些网关的高级功能：动态路由、限流、路径重写

从以上的特征来说，和Zuul的特征差别不大。SpringCloud Gateway和Zuul主要的区别，还是在底层的通信框架上。

专业术语

a）Filter（过滤器）：

和Zuul的过滤器在概念上类似，可以使用它拦截和修改请求，并且对上游的响应，进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。

b）Route（路由）：

网关配置的基本组成模块，和Zuul的路由配置模块类似。一个Route模块由一个 ID，一个目标 URI，一组断言和一组过滤器定义。如果断言为真，则路由匹配，目标URI会被访问。

c）Predicate（谓词、断言）：

这是一个 Java 8 的 Predicate，可以使用它来匹配来自 HTTP 请求的任何内容，例如 headers 或参数。断言的输入类型是一个 ServerWebExchange。

工作流程

客户端向 Spring Cloud Gateway 发出请求。然后在 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。

类型	作用
pre	这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
post	这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。

Filter在“pre”类型过滤器中可以做参数校验、权限校验、流量监控、⽇志输出、协议转换等，在“post”类型的过滤器中可以做响应内容、响应头的修改、⽇志的输出、流量监控等。

1.Gateway的入门案例

Spring Cloud Gateway学习（1）—— Gateway 的基本概念 & 引入依赖需要注意的事项 +解决方案 & 全局网关的入门使用案例

2.Gateway的认证鉴权，与Sentinel整合

Spring Cloud Gateway学习（2）—— Gateway 中文乱码的解决 & 基于gateway的登陆认证和鉴权案例 & gateway和sentinel整合案例

事务，分布式事务–Seata

0.MySQL数据库的事务

MySQL进阶（事务）——转账事务的问题 COMMIT，ROLLBACK & 百万条数据插入的性能调优=3万次提交变成1次

本篇博客结合生活中常见的转账案例，分析了事务的案例，模拟网络失败情况下事务回滚的情况；分析了百万数据插入数据库时，如何借助提交模式来进行MySQL插入数据库的性能调优。

MySQL进阶（再论事务）——什么是事务 & 事务的隔离级别 & 结合MySQL案例详细分析

主要内容：

1.事务(TRANSACTION)是一个不可分割的逻辑单元，包含了一组数据库操作命令，并且把所有的命令作为一个整体向系统提交，要么都执行、要么都不执行；

2.隔离级别和脏读、不可重复读以及幻象读的对应关系如下：

隔离级别	脏读	不可重复读	幻读
READ UNCOMMITTED	允许	允许	允许
READ COMMITED	不允许	允许	允许
REPEATABLE READ 【默认的隔离级别】	不允许	不允许	允许
SERIALIZABLE	不允许	不允许	不允许

3.在MySQL数据库中，默认的事务隔离级别是REPEATABLE READ 可重复读；

1.什么是分布式事务

分布式事务——CAP理论 & 解决分布式事务的思路 & Seata组件初识和部署

2.Seata组件的模式和应用案例

分布式事务（Seata）——Seata分布式事务XA模式、AT模式、TCC模式的介绍和对比 & 结合案例分析AT模式和XA模式【源码】

主要内容：

1、XA规范使用两阶段提交(2PC,Two-Phase Commit)来保证所有资源同时提交或回滚任何特定的事务。

第一阶段为准备(prepare)阶段。即所有的参与者准备执行事务并锁住需要的资源。参与者ready时，向transaction manager报告已准备就绪。
第二阶段为提交阶段(commit)。当transaction manager确认所有参与者都ready)后，向所有参与者发送commit命令。

2、AT模式与XA模式

（1）Seata AT模式是两阶段提交协议的演变：

一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段：
- 提交异步化，非常快速地完成。
- 回滚通过一阶段的回滚日志进行反向补偿。

（2）AT模式与XA模式的区别

XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
XA模式依赖数据库机制实现回滚：AT模式利用数据快照实现数据回滚。
XA是强一致性；AT是最终一致性。

3、Tny-Confirm-Cancel，TCC模式

TCC是分布式事务中二阶段提交协议的实现，它的全称为Tny-Confirm-Cancel,即资源预留(Try)、确认操作(Confirm)、取消操作(Cancel),具体含义如下：

Try(prepare)阶段：对业务资源的检查并预留。
Confirm(commit)阶段：对y业务处理进行提交，该步骤会对Ty预留的资源进行释放，只要Try成功，Confirm-一定要能成功.
Cancel(rollback)阶段：对业务处理进行取消，即回滚操作。

3.再深入，分布式事务理论基础

分布式事务（再深入）——分布式事务理论基础 & Java分布式事务解决方案

主要内容如下：

1.介绍分布式事务产生的场景，阐述了CAP理论；
2. 分布式理论的CP -> 强一致性，刚性事务，遵循ACID，对数据要求强一致性；
3.分布式理论的AP+BASE -> 弱一致性，柔性事务，最终一致性；
4.基于 XA 协议实现的分布式事务：TM事务管理器（Transaction Manager）+ RM本地资源管理器（Resource Manager）;
5.2PC二阶段提交协议：准备阶段（Preparephase）、提交阶段（commit phase）；
6.3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议；

【合集】Spring Cloud 组件——架构进化史话 & Eureka，Nacos，Apollo，OpenFeign，Ribbon，Sentinel，Gateway ，Seata+事务. . .

前言

目录

引出