微服务版块

服务治理  :  Nacos

配置管理 ：Nacos   （热更新）

远程调用 ：OpenFeign

网关 ：Gateway   (请求转发，身份验证)

服务保护 ： Sentinel

分布式事务 ：seata

Nacos

      Nacos提供了服务注册与发现、配置管理以及服务健康监测等核心功能

客户端注册服务

1. 添加Nacos客户端依赖

   在项目的pom.xml文件中（对于Maven项目）或build.gradle文件中（对于Gradle项目），添加Nacos客户端的依赖。例如，对于Spring Cloud项目，通常会添加spring-cloud-starter-alibaba-nacos-discovery依赖。

2. 配置Nacos服务器地址

            在项目的配置文件（如application.yml或application.properties）中，配置Nacos服务器的地址以及其他必要的配置信息。    

3. 启动服务

   启动应用时，Spring Boot的自动配置功能会自动将服务注册到Nacos服务器。服务注册时，客户端会向Nacos发送REST请求，提供服务的元数据（如服务名、IP地址、端口号等）。

4. 维护心跳

   注册成功后，客户端会维护一个定时心跳，定期向Nacos服务器发送请求，表明服务仍然处于可用状态。Nacos服务器会根据心跳信息来维护服务的健康状态。

客户端发现服务

        同上与客服端注册服务一样的前两步操作  添加依赖，配置服务地址

        调用服务并调用

        1.构造器注入DiscoveryClient

                

           2.基于OpenFeign发现调用

                见OpenFeign板块

OpenFeign

OpenFeign是Spring Cloud中的一个二级子项目，它是一种声明式、模板化的HTTP客户端，主要用于微服务架构中服务之间的调用。

一、概述

• 定义：OpenFeign是一种声明式服务调用框架，它使得编写Web服务客户端变得更加简单。通过创建一个接口并使用注解来配置它，可以定义服务调用的详细信息，而不需要手动编写大量的HTTP请求和响应代码。
• 作用：OpenFeign允许开发者像调用本地方法一样调用远程HTTP服务，从而简化了微服务架构中的服务调用过程。

二、特点

1. 声明式服务调用：开发者只需通过简单的接口和注解，即可实现远程服务的调用，无需关心底层的HTTP请求和响应处理。
2. 集成Spring Cloud：作为Spring Cloud的一部分，OpenFeign与Spring Cloud的其他组件（如Eureka、Ribbon等）紧密集成，提供了丰富的服务治理功能。
3. 轻量级：相比其他RPC框架，OpenFeign更加轻量级，易于在微服务架构中部署和使用。
4. 易用性：通过简单的配置和注解，即可快速实现远程服务的调用，降低了开发者的学习成本和开发成本。

三、使用方式

1. 添加依赖：在项目的pom.xml文件中添加OpenFeign的起步依赖spring-cloud-starter-openfeign。
2. 开启Feign客户端：在Spring Boot的主启动类上添加@EnableFeignClients注解，以开启Feign客户端的功能。
3. 编写Feign客户端接口：创建一个接口，并使用@FeignClient注解进行标注。在该接口中，可以定义远程服务调用的方法，并使用Spring MVC的注解（如@GetMapping、@PostMapping等）来指定请求的方式和路径。
4. 使用Feign客户端：在需要调用远程服务的地方，直接注入上一步编写的Feign客户端接口，并调用其方法即可实现远程服务的调用。

四、优化与配置

• 日志级别：OpenFeign支持多种日志级别，包括NONE、BASIC、HEADERS和FULL等，开发者可以根据需要配置不同的日志级别以查看调用过程中的详细信息。
• GZIP压缩：为了优化网络传输性能，OpenFeign支持对请求和响应进行GZIP压缩。通过配置GZIP压缩，可以显著减少网络传输的数据量，加快数据传输速度。
• 超时时间：开发者可以配置OpenFeign的请求超时时间，以避免因网络延迟或服务故障导致的请求长时间挂起问题。

Gateway

 一、功能

1. 路由转发：网关作为网络之间的桥梁，能够接收来自一个网络的请求，并将其转发到另一个网络的目的地。
2. 负载均衡：在微服务架构中，网关可以根据一定的策略（如轮询、随机、最少连接数等）将请求分发到不同的微服务实例，以实现负载均衡。
3. 权限控制：网关可以对进入系统的请求进行身份验证和权限校验，确保只有合法的用户才能访问相应的资源。
4. 请求限流：为了防止系统因过载而崩溃，网关可以对请求进行限流，限制单位时间内进入系统的请求数量。
5. 协议转换：网关可以在不同的通信协议、数据格式或语言之间进行转换，以适应不同系统之间的通信

二、使用

        1.引入依赖（配合nacos使用）

        2.配置路由

 略

服务保护

   1.雪崩问题

       概念： 微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。

        产生原因：· 微服务相互调用，服务提供者出现故障或阻塞。

                          · 服务调用者没有做好异常处理，导致自身故障

                          · 调用链中的所有服务组联失败，导致整个集群故障

        解决方案 ：服务保护 ： 请求限流(限流器)   线程隔离（服务可用的线程数、避免资源耗尽，                             可以进行其他服务的调用）  服务熔断（断路器、拦截改接口的请求）熔断期间                               所有的请求快速失败，全部走fallback逻辑

                服务保护技术：Sentinel（'哨兵'，阿里）    Hystrix（'豪猪'，国外）

Sentinel

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

        使用：1.安装其控制台方便配置操作

                   2.引入其依赖    跟控制台连接（yml配置sentinel相关配置）

一：请求限流

        簇点链路 -->流控-->配置-->新添

QPS 每秒访问次数  

二：线程隔离

簇点链路 -->流控-->配置-->新添

并发线程数：给改服务提供的线程数

Fallback    ：处理无法访问，给用户返回备用资源或提示信息

             将FeignClient作为Sentinel的簇点资源

             

              FeignClient的Fallback有两种配置方式：

                        方式一：FallbackClass，无法对远程调用的异常做处理

                        方法二：FallbcakFactory，可以对远程调用的异常做处理，（优先）

三：服务熔断

                服务熔断是防止整个系统出现雪崩的设备，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。由短路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断改服务：拦截访问该服务的一切请求；当服务恢复时，断路器会放行访问改服务的请求。

最大RT ：响应时长    比例阈值 ：请求失败数/总请求数    熔断时长：断开多长时间  最小统计数：统计时间长内的总请求量     统计时长：在这个时长内得到比例 进行熔断操作

分布式事务 

        在分布式系统中，如果一个业务需要多个服务合作完成，而且每一个服务都有事务，多个事务必须同时成功或失败，这样的事务就是分布式事务。其中每一个服务的事务就是一个分支服务，整个业务称为全局事务。

        解决技术：Seata

Seata主要由三个重要组件组成：

TC：Transaction Coordinator 事务协调器，管理全局的分支事务的状态，用于全局性事务的提交 和回滚。

TM：Transaction Manager 事务管理器，用于开启、提交或者回滚全局事务。

RM：Resource Manager 资源管理器，用于分支事务上的资源管理，向TC注册分支事务，上报分 支事务的状态，接受TC的命令来提交或者回滚分支事务。

1.部署TC服务

2.微服务集成Seata

Seata（Simple Extensible Autonomous Transaction Architecture）是一个简单可扩展自治事务框架，提供全方位的分布式事务解决方案。Seata的四种模式分别是AT、TCC、Saga和XA，每种模式都有其特定的应用场景和优缺点。

1. AT模式

特点与原理：

• AT模式是Seata的默认模式，基于全局锁隔离，无代码侵入。
• 在一阶段，Seata会拦截业务SQL，解析SQL语义，找到要更新的业务数据，在更新前保存成“前镜像”（before image），然后执行SQL更新业务数据，并保存成“后镜像”（after image），同时生成行锁，以保证一阶段操作的原子性。
• 二阶段如果是提交，则删除一阶段保存的快照数据和行锁；如果是回滚，则用“前镜像”还原业务数据。

优缺点：

• 优点：无代码侵入，一阶段事务直接提交，失败则根据undolog日志回滚，性能较好。
• 缺点：隔离性引入全局锁，并发几率低时可能影响性能；在极端情况下可能存在脏写问题。

2. TCC模式

特点与原理：

• TCC模式分为Try、Confirm、Cancel三个阶段。
• Try阶段做业务检查和资源预留。
• Confirm阶段确认提交资源。
• Cancel阶段在业务执行错误需要回滚的状态下执行分支事务的业务取消，释放预留资源。

优缺点：

• 优点：性能最好，不需要依赖关系型数据库。
• 缺点：代码侵入度高，try、confirm、cancel需要人工手写，且需要考虑空悬挂、空回滚、幂等性判断等问题，使用成本较高。

3. Saga模式

特点与原理：

• Saga模式是基于状态机实现的二阶段协议，用于长事务场景。
• 针对每个分支事务的正向业务逻辑，都要求提供一个反向的逻辑实现，以便在出现异常时可以调用反向逻辑进行回滚。

优缺点：

• 优点：适用于长事务和与第三方系统交互的场景，一阶段提交本地数据库事务，无锁，高性能。
• 缺点：不是强一致的，存在中间状态的数据；正向和反向逻辑需要程序员实现，使用成本较高。

4. XA模式

特点与原理：

• XA模式是基于数据库的XA协议来实现两阶段提交（2PC）的分布式事务。
• 分布式事务完全由数据库去保障，当前主流的关系型数据库都支持XA协议。

优缺点：

• 优点：强一致性，无代码侵入。
• 缺点：性能较差，存在严重的资源独占和阻塞问题，在可用性要求较高的互联网系统中几乎不会使用。

总结

Seata的四种模式各有优缺点，适用于不同的业务场景。在选择时，需要根据业务的具体需求、性能要求、一致性要求等因素综合考虑。例如，对于不希望对业务进行改造的场景，可以选择AT模式；对于核心系统等对性能有很高要求的场景，可以选择TCC模式；对于业务流程长且需要保证事务最终一致性的业务系统，可以选择Saga模式；而对于需要强一致性的场景，尽管XA模式性能较差，但仍是一个可行的选择。