微服务架构—SpringCloud2023_openfeign和springcloud的版本

Spring Cloud Alibaba源码：https://github.com/alibaba/spring-cloud-alibaba
Spring Cloud Alibaba官网：https://spring.io/projects/spring-cloud-alibaba#overview
Spring Cloud Alibaba中文社区地址: https://github.com/alibaba/spring-cloud-alibaba/blob/2.2.x/README-zh.md

一、Spring Cloud第一代与第二代的区别

第一代很多都停止更新维护了，直接学习第二代 Spring Cloud Alibaba

SpringCloud第一代：

SpringCloud Config 分布式配置中心
SpringCloud Netflix 核心组件
Eureka:服务治理
Hystrix:服务保护框架
Ribbon:客户端负载均衡器
Feign：基于ribbon和hystrix的声明式服务调用组件
Zuul: 网关组件,提供智能路由、访问过滤等功能。

SpringCloud第二代（自己研发）和优秀的组件组合：

Spring Cloud Gateway 网关
Spring Cloud Loadbalancer 客户端负载均衡器
Spring Cloud r4j(Resilience4J) 服务保护

Spring Cloud Alibaba Nacos 服务注册
Spring Cloud Alibaba Nacos 分布式配置中心
Spring Cloud Alibaba Sentinel服务保护
SpringCloud Alibaba Seata分布式事务解决框架
Alibaba Cloud OSS 阿里云存储
Alibaba Cloud SchedulerX 分布式任务调度平台
Alibaba Cloud SMS 分布式短信系统

二、什么是Spring Cloud Alibaba

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

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

此外，阿里云同时还提供了 Spring Cloud Alibaba 企业版 微服务解决方案，包括无侵入服务治理(全链路灰度，无损上下线，离群实例摘除等)，企业级 Nacos 注册配置中心和企业级云原生网关等众多产品。

三、微服务架构演变过程

1、传统架构
传统的架构，也就是为单点应用，也就是大家在早期所学习的JavaEE知识SSH或者SSM架构模式，
会采用分层架构模式：数据库访问层、业务逻辑层、控制层，从前端到后台所有的代码都是一个开发者去完成。
该架构模式没有对我们业务逻辑代码实现拆分，所有的代码都写入到同一个工程中里面，适合于小公司开发团队或者个人开发。
这种架构模式最大的缺点，如果该系统一个模块出现不可用、会导致整个系统无法使用。

2、分布式架构
分布式架构模式是基于传统的架构模式演变过来，将传统的单点项目根据业务模块实现拆分、会拆分为会员系统、订单系统、支付系统、秒杀系统等。 从而降低我们项目的耦合度，这种架构模式开始慢慢的适合于互联网公司开发团队。

3、SOA面向服务架构
SOA架构模式也称作为：面向服务架构模式、俗称面向与接口开发，将共同存在的业务逻辑抽取成一个共同的服务，提供给其他的服务接口实现调用、服务与服务之间通讯采用rpc远程调用技术。

SOA架构模式特点：
1）SOA架构通讯中，采用XML方式实现通讯、在高并发下通讯过程中协议存在非常大冗余性，所以在最后微服务架构模式中使用JSON格式替代了XML。

2）SOA架构模式实现方案为WebService或者是ESB企业服务总线 底层通讯协议SOAP协议（Http+XML）实现传输。

4、微服务架构
微服务架构产生的原因
微服务架构基于SOA架构演变过来的
在传统的WebService架构中有如下问题:
1）依赖中心化服务发现机制
2）使用Soap通讯协议，通常使用XML格式来序列化通讯数据，xml格式非常喜欢重，比较占宽带传输。
3）服务化管理和治理设施不完善

微服务架构基本概念
微服务架构模式是从SOA架构模式演变过来， 比SOA架构模式粒度更加精细，让专业的人去做专业的事情（专注）， 目的是提高效率，每个服务与服务之间互不影响，微服务架构中每个服务必须独立部署、互不影响，微服务架构模式体现轻巧、轻量级、适合于互联网公司开发模式。

微服务架构倡导应用程序设计程多个独立、可配置、可运行和可微服务的子服务。
服务与服务通讯协议采用Http协议，使用restful风格API形式来进行通讯，数据交换格式轻量级json格式通讯，整个传输过程中， 采用二进制，所以http协议可以跨语言平台，并且可以和其他不同的语言进行相互的通讯，所以很多开放平台都采用http协议接口。

微服务架构与SOA架构的不同
1.微服务架构基于 SOA架构 演变过来，继承 SOA架构的优点，在微服务架构中去除 SOA 架构中的 ESB 企业服务总线，采用 http+json（restful）进行传输。
2.微服务架构比 SOA 架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。
3.SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。
4.项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。

微服务架构会产生那些问题

分布式事务解决方案(rabbitmq/rocketmq/lcn(已经淘汰)/ Seata)
分布式任务调度平台(XXL-Job、阿里Scheduler)
分布式日志采集系统ELJ+Kafka
分布式服务注册中心 eureka、Zookeeper、consule、nacos等。
分布式服务追踪与调用链Zipkin等。

为什么我们要使用SpringCloud
SpringCloud并不是rpc远程调用框架，而是一套全家桶的微服务解决框架，理念就是解决我们在微服务架构中遇到的任何问题。

服务治理基本的概念
在RPC远程调用过程中，服务与服务之间依赖关系非常大，服务Url地址管理非常复杂，所以这时候需要对我们服务的url实现治理，通过服务治理可以实现服务注册与发现、负载均衡、容错等。

服务注册中心的概念
每次调用该服务如果地址直接写死的话，一旦接口发生变化的情况下，这时候需要重新发布版本才可以该接口调用地址，所以需要一个注册中心统一管理我们的服务注册与发现。

注册中心： 我们的服务注册到我们注册中心，key为服务名称、value为该服务调用地址，该类型为集合类型。Eureka、consul、zookeeper、nacos等。

服务注册： 我们生产者项目启动的时候，会将当前服务自己的信息地址注册到注册中心。

服务发现: 消费者从我们的注册中心上获取生产者调用的地址（集合），在使用负载均衡的策略获取集群中某个地址实现本地rpc远程调用。

四、Nacos

Nacos可以实现分布式服务注册与发现/分布式配置中心框架。
Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service的首字母简称，一个更易于构建云原生应用的 动态服务发现、配置管理和服务管理平台。

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现 动态服务发现、服务配置、服务元数据及流量管理。

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

Nacos官网的介绍: https://nacos.io/zh-cn/docs/what-is-nacos.html

五、Ribbon 客户端负载均衡器

六、OpenFeign

OpenFeign是一个Web声明式的Http客户端调用工具，提供接口和注解形式调用。

七、SpringCloud Gateway

什么是微服务网关
微服务网关是整个微服务API请求的入口，可以实现日志拦截、权限控制、解决跨域问题、
限流、熔断、负载均衡、黑名单与白名单拦截、授权等。

过滤器与网关的区别
过滤器用于拦截单个服务
网关拦截整个的微服务

Zuul与Gateway有那些区别

Zuul网关属于netfix公司开源的产品属于第一代微服务网关
Gateway属于SpringCloud自研发的第二代微服务网关
相比来说SpringCloudGateway性能比Zuul性能要好：
注意：Zuul基于Servlet实现的，阻塞式的Api， 不支持长连接。
SpringCloudGateway基于Spring5构建，能够实现响应式非阻塞式的Api，支持长连接，能够更好的整合Spring体系的产品。

八、SpringCloud Sentinel

Sentinel中文文档介绍：https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D

服务保护的基本概念
服务限流/熔断
服务限流目的是为了更好的保护我们的服务，在高并发的情况下，如果客户端请求的数量达到一定极限（后台可以配置阈值），请求的数量超出了设置的阈值，开启自我的保护，直接调用我们的服务降级的方法，不会执行业务逻辑操作，直接走本地falback的方法，返回一个友好的提示。

服务降级
在高并发的情况下， 防止用户一直等待，采用限流/熔断方法，使用服务降级的方式返回一个友好的提示给客户端，
不会执行业务逻辑请求，直接走本地的falback的方法。
提示语：当前排队人数过多，稍后重试~

服务的雪崩效应
默认的情况下，Tomcat或者是Jetty服务器只有一个线程池去处理客户端的请求，
这样的话就是在高并发的情况下，如果客户端所有的请求都堆积到同一个服务接口上，
那么就会产生tomcat服务器所有的线程都在处理该接口，可能会导致其他的接口无法访问。

假设我们的tomcat线程最大的线程数量是为20，这时候客户端如果同时发送100个请求会导致有80个请求暂时无法访问，就会转圈。

服务的隔离的机制
服务的隔离机制分为信号量和线程池隔离模式
服务的线程池隔离机制： 每个服务接口都有自己独立的线程池，互不影响，缺点就是占用cpu资源非常大。
服务的信号量隔离机制： 最多只有一定的阈值线程数处理我们的请求，超过该阈值会拒绝请求。

Sentinel 与hytrix区别

Sentinel 以流量为切入点，从流量控制，熔断降级，系统负载保护等多个维度保护服务的稳定性。

Sentinel 具有以下特征：
1）.丰富的应用场景： 前哨兵承接了阿里巴巴近10年的双十一大促流的核心场景，例如秒杀（即突然流量控制在系统容量可以承受的范 围），消息削峰填谷，传递流量控制，实时熔断下游不可用应用等。
2）.完备的实时监控： Sentinel同时提供实时的监控功能。您可以在控制台中看到接收应用的单台机器秒级数据，甚至500台以下规模 的整合的汇总运行情况。
3）.广泛的开源生态： Sentinel提供开箱即用的与其他开源框架/库的集成模块，例如与Spring Cloud，Dubbo，gRPC的整合。
您只需要另外的依赖并进行简单的配置即可快速地接入Sentinel。
4）.完善的SPI扩展点： Sentinel提供简单易用，完善的SPI扩展接口。您可以通过实现扩展接口来快速地定制逻辑。
例如定制规则管理，适应动态数据源等。

注解形式配置管理Api限流
@SentinelResource value参数：流量规则资源名称、
blockHandler 限流/熔断出现异常执行的方法
Fallback 服务的降级执行的方法

控制台形式管理限流接口
Sentinel dashboard 控制台选择创建流量规则，设置资源名称（服务接口地址）、设置QPS 为1 表示每s最多能够访问1次接口。

Sentinel如何保证规则的持久化
默认的情况下Sentinel的规则是存放在内存中，如果Sentinel客户端重启后，Sentinel数据规则可能会丢失。
解决方案：
Sentinel持久化机制支持四种持久化的机制。
1.本地文件
2.携程阿波罗
3.Nacos
4.Zookeeper

sentinel实现熔断降级
熔断降级：https://github.com/alibaba/Sentinel/wiki/%E7%86%94%E6%96%AD%E9%99%8D%E7%BA%A7

除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。
由于调用关系的复杂性，如果调用链路中的某个资源不稳定，最终会导致请求发生堆积。
Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，
让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，
对该资源的调用都自动熔断（默认行为是抛出 DegradeException）。

降级的策略
1）.平均响应时间 (DEGRADE_GRADE_RT)：当 1s 内持续进入 5 个请求，对应时刻的平均响应时间（秒级）均超过阈值（count，以 ms 为单位），那么在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地熔断（抛出 DegradeException）。注意 Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。

2）.异常比例 (DEGRADE_GRADE_EXCEPTION_RATIO)：当资源的每秒请求量 >= 5，并且每秒异常总数占通过量的比值超过阈值（DegradeRule 中的 count）之后，资源进入降级状态，即在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地返回。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。

3）.异常数 (DEGRADE_GRADE_EXCEPTION_COUNT)：当资源近 1 分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟 级别的，若 timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态。

Sentinel实现热点词限流
热点参数限流:https://github.com/alibaba/Sentinel/wiki/%E7%83%AD%E7%82%B9%E5%8F%82%E6%95%B0%E9%99%90%E6%B5%81
可以根据访问频繁的参数实现限流。

九、SpringCloud 解决分布式事务

事务的定义
对我们的业务逻辑可以实现提交或者回滚，保证数据的一致性的情况。
所以要么提交，要么回滚。

原子性a 要么提交 要么回滚
一致性c
隔离性i 多个事务在一起执行的时候，互不影响；
持久性d 事务一旦提交或者回滚后，不会在对该结果有任何影响

Base与CAP理论
这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性C：在分布式系统中，同一时刻所有的节点的数据都是相同的；
可用性A: 集群中部分节点出现了故障，集群的整体也能够给响应；
**分区容错性P：**分区容错性是指系统能够容忍节点之间的网络通信的故障，意味着发生了分区的情况，必须就当前操作在C和A之间做出选择；

BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写

目前主流分布式解决框架
1.单体项目多数据源 可以jta+ Atomikos
2.基于rabbitmq的形式解决 最终一致性的思想
3.基于rocketmq解决分布式事务 采用事务消息
4.LCN采用lcn模式 假关闭连接 （目前已经被淘汰）
5.Alibaba的Seata 未来可能是主流 背景非常强大

十、 LCN解决分布式事务

LCN官网基本介绍 http://www.txlcn.org/zh-cn/

LCN并不生产事务，LCN只是本地事务的协调工。

LCN基本实现原理
1.发起方与参与方都与我们的LCN管理器一直保持长连接；
2.发起方在调用接口之前，先向LCN管理器申请一个全局的事务分组id；
3.发起方调用接口的时候在请求头中传递事务分组id；
4.参与方获取到请求头中有事务分组的id的，则当前业务逻辑执行完实现假关闭，不会提交或者回滚当前的事务。
5.发起方调用完接口后，如果出现异常的情况下，在通知给事务协调者回滚事务，这时候事务协调则告诉给参与方回滚当前的事务。

用法
参与方与发起方都要加上该注解
@LcnTransaction
@Transactional

源码核心入口
重新feign客户端拦截器 RequestInterceptor
Aop的重学的入口TransactionAspect
实现该接口可以在请求之前处理参数SpringTracingApplier
http://127.0.0.1:8090/insertOrder?age=1

1.Lcn如何判断自己是发起方还是参与方？
根据当前的线程threadlocal中获取事务分组id，如果能够成功获取到则是为参与方，没有能够获取到就 是为发起方。
2.A调用B，B调用C 到底会生产几次事务id？

A调用 B 调用C 调用D 只有全局的分组的id 都是有一个局部的事务id

3.参与方如何从请求头中获取事务id?如何加入事务组中？

4.LCN如何实现数据源代理实现假关闭？
学习LCN源码分析的话 入口 @LcnTransaction 必须有AOP才能够对我们注解生效。
TransactionAspectAop的入口类。

十一、Seata解决分布式事务

Seata源码：https://github.com/seata/seata
Seata文档：https://seata.io/zh-cn/index.html

Seata的实现原理
Seata有3个基本组成部分：
**事务协调器（TC）：**维护全局事务和分支事务的状态，驱动全局提交或回滚。
**事务管理器TM：定义全局事务的范围：**开始全局事务，提交或回滚全局事务。
**资源管理器（RM）：**管理分支事务正在处理的资源，与TC进行对话以注册分支事务并报告分支事务的状态，并驱动分支事务的提交或回滚。

分布式事务产生的背景
1、如果是在传统项目中，使用同一个数据源，在数据用同用一个事务管理器的情况下，不存在分别事务事务问题，因为有事务的传播行为帮助我们实现。每个数据源都自己独立的事务事务管理，每个数据源中的事务管理都互不影响。
2、如果是在单体项目中， 存在多个不同的数据源，每个事务源都有自己独立的事务管理器，每个事务管理器互不影响，也会存在分布式事务的问题。Jta+atominc 将每个独立的事务管理器统一交给我们的atominc全局事务管理。
3、在分布式系统中采用rpc远程通讯也会存在分布式事务问题

分布式rpc通讯中为什么会存在分布式事务？
消费者(调用方)调用完接口成功之后后，调用方突然抛出异常

调用者(订单服务) 生产者(派单服务)

1.生产者调用接口如果失败的情况下，一定要抛出异常或者是手动的回滚，不然会产生脏读数据。

Rpc通讯中产生的分布式事务的问题原因

1.调用方（订单服务）调用完rpc接口之后，突然程序抛出异常，调用方的事务回滚了，但是被调用方接口没有回滚。
订单服务回滚了，派单成功，在每个jvm中都有自己的本地事务，每个事务都互不影响。
2.被调用方（派单服务）的接口失败的话，调用方可以根据返回的结果，手动回滚调用方本地事务

解决分布式事务的最大核心是什么？

1、最终一致性 在分布式系统中， 因为rpc通讯是需要时间的，短暂的数据一致这是允许的，但是最终数据一定要保持一致性；
2、全局协调者

有很多的机构的老师反应，有学员报名钱已经付款了，但是在后台中查询该订单还是没有支付状态。

Base理论和CAP理论

CAP总结：三者无法兼顾，在分布式系统当中可以容忍网络之间出现的通讯故障；
要么是CP或者AP
CP：当你网络出现故障之后，只能保证数据一致性，但是不能保证可用性； zk
AP：当你网络出现故障之后，不能保证数据一致性，但是能够保证可用性 eureka