17 SpringCloud

一 微服务的认知

https://blog.csdn.net/keehom/article/details/108172020

二 SpringCloud的理解

springcloud 是一系列框架的集合。它利用spring boot的开发便利性巧妙地简化了分布式系统基础设施地开发。如服务发现注册，配置中心，消息总线，负载均衡，断路器，数据监控等，都可以用spring boot放入开发风格做到一键启动。spring cloud 并没有重复制造轮子，只是将目前各家公司开发地比较成熟，经得起实际考验地服务框架组合起来，通过spring boot 风格进行再封装屏蔽掉了复杂地配置和实现原理，最终给开发者留出了一套简单易懂，易部署和易维护地分布式系统开发工具包
首先，尽管Spring Cloud带有“Cloud”这个单词，但它并不是云计算解决方案，而是在Spring Boot基础之上构建的，用于快速构建分布式系统的通用模式的工具集。

三 SpringCloud的常用组件以及作用

服务限流降级（Sentinel）：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性
服务注册与发现（Nacos）：更易于构建云原生应用的动态服务发现、配置管理和服务管理平台
分布式配式管理（Nacos）：支持分布式系统中的外部化配置，配置更改时自动刷新
消息驱动能力（RocketMQ）：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务
分布式事务（Seata）：使用 @GlobalTransactional 注解， 高效并且对业务零侵入地解决分布式事务问题。
阿里云对象存储（OSS）：阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。
分布式任务调度（SchedulerX）：提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有 Worker（schedulerx-client）上执行。
阿里云短信服务（SMS）：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。
声明式服务调用（Openfeign）：一种声明式、模板化的HTTP客户端，不是阿里的组件
网关中心（Gateway）：是作为一个 API 架构，用来保护、增强和控制对于 API 服务的访问，不是阿里的组件

四 Nacos：注册中心和配置中心，AP（nacos）—引入CAP与BASE理论

注册中心：

nacos：一个更易于构建原生应用地动态服务发现，配置管理和服务管理平台nacos致力于帮助你发现，配置和管理微服务。nacos提供了一组简单易用地特性集，帮助你快速实现动态服务发现，服务配置，服务元数据及流量
nacos核心地两大作用:1注册中心实现服务地管理；2配置中心，实现微服务的配置同意管理
nacos的第一个核心作用就是作为注册中心使用，可以实现服务大的发现和注册功能。
使用：第一步：实现依赖jar

<!--        1.Nacos注册中心-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
            <version>2021.1</version>
        </dependency>

第二步：配置路径：application.yml

server:
  port: 9090
spring:
  application:
    name: LxHelloConsumer #项目名，服务名
  cloud:
    nacos:
      discovery: #注册中心
        server-addr: 127.0.0.1:8848

第三步：开关类 ，注册与发现服务

@SpringBootApplication //开关类
@EnableDiscoveryClient //注册与发现服务
public class ProviderApplication {
    public static void main(String[] args) {
        SpringApplication.run(ProviderApplication.class,args);
    }
}

配置中心

配置中心，就是将一些可能会改变的配置，单独存储到一个独立的系统中，可以实现不停机更新
实现配置变更，可以立即推送到各个服务器，不需要重新发布系统
Nacos的核心作用：
1.注册中心 实现服务治理
2.配置中心 实现配置动态化
3.实现服务管理
基于Nacos实现配置中心：
配套的各个版本
使用步骤：
1.服务中依赖jar

 <!-- https://mvnrepository.com/artifact/com.alibaba.cloud/spring-cloud-starter-alibaba-nacos-config -->
<dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
            <version>2.2.5.RELEASE</version>
 </dependency>

根项目的依赖：
2.实现配置
必须实现boostarp类型的配置文件
bootstrap.propertie或者bootstrap.yml

spring.cloud.nacos.config.server-addr=127.0.0.1:8848

3.实现代码
使用注解：
@RefreshScope //实时刷新最新的动态配置
@Value(“${配置名称}”) 获取指定配置的内容
4.在nacos控制器实现动态配置
在 Nacos Spring Cloud 中，dataId的完整格式如下：
${prefix}-${spring.profiles.active}.${file-extension}

• prefix 默认为 spring.application.name 的值，也可以通过配置项 spring.cloud.nacos.config.prefix来配置。
• spring.profiles.active 即为当前环境对应的 profile，详情可以参考 Spring Boot文档。注意：当spring.profiles.active为空时，对应的连接符 - 也将不存在，dataId 的拼接格式变成 ${prefix}.${file-extension}
• file-exetension 为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension来配置。目前只支持 properties和yaml 类型。

5.运行测试
访问接口，观察配置的值
在Nacos控制器实现配置的变更，再次观察接口的值
会跟着一起改变
ps一定要注意各个模块的版本号

五 CAP和Base理论

在分布式事务中，往往离不开两个理论，那就是CAP和BASE

1 CAP理论：

C:一致性consistency—所有节点访问的都是同一份最新的数据副本；
A：可用性availabitity—在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求
P：分区容错性：tolerance of partition：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况。
一个分布式系统中由若干节点组成，每个节点之间通过网络进行通信，当有些节点之间因为网络原因不能继续通信，就会形成多个孤立的节点，成为“网络分区”或“脑裂”。
容错式一种分布式的能力，要做到节点之间的网络异常发生后整个分布式系统仍然是可用的、如果数据只存储在一个节点上，那么当“网络分区”现象出现后，与这个节点时区通信能力的所有节点都访问不到数据了。
为了提高分布式系统的容错能力，会把数据复制到分布式系统的所有节点上面，当“网络分区”现象再次出现后，每个节点上面的请求都能够访问数据，保证了可用性，即通过提高分区容错性来保证分布式系统的可用性。
CAP不能同时满足：如果在分布式系统中，假设有两台服务器serverA和serverB，客户端往serverA写数据，但是serverB还没有来及同步数据，客户端发起读请求，势必会造成读取的数据会不一致，这就满足了可用性。但是你要保证一致性，就必须锁住serverB，只有数据同步后，才可以放开serverB的读写，那这种就没有可用性可言了。然后，P(分区容错)呢？假如serverA和serverB两台服务器分别在中国和美国，这两台服务器可能无法通信，在系统设计的时候，必须要考虑到这种情况，一般来说，分区容错无法避免，因此可以认为CAP中的P总是成立的。所以，CAP是不能同时满足，CA存在矛盾，只能存在CP和AP。
造成通信故障的原因有：1、GC的STW阻塞太长；2、服务器CPU利用率达到100%；3、网络不稳定因素。
BASE理论是指基本可用(Basically Available)、软状态(Soft State)和最终一致性(Eventual Consistency)

2 BASE理论

为了追求C(一致性)和A(可用性)，在CAP定理的基础上逐步演化成BASE理论，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来试系统达到最终一致性。
基本可用(Basically Available)：分布式系统出现故障的时候，允许损失一部分可用性，拿响应时间和功能上的损失来换取可用。
软状态(Soft State)：就是说在订单系统中，在下单完成进行支付的过程中，我们可以让页面显示”支付中”，等待支付系统彻底同步完数据，订单系统才显示支付完成。即允许系统存在中间状态，这个中间态不会影响系统整体可用性。
终一致性(Eventual Consistency)：它可以理解为是一种弱一致性。在允许出现中间状态的情况下，经过一段时间之后，所有数据状态才最终达到一致，从而在页面上显示为”支付成功”。

六 Gateway的路由匹配：9种

6.1 问题
如果让客户端直接与各个微服务通信可能出现：

1. 客户端需要调用不同的url地址
2. 增加难度在一定的场景下
3. 存在跨域请求的问题每个微服务都需要进行单独的身份认证

6.2 Gateway

Spring Cloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于Netty、Reactor以及WEbFlux构建，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。 Spring Cloud Gateway 作为 Spring Cloud 生态,系统中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关
基本的功能，例如：安全、监控、埋点和限流等。

6.3 Gateway的特点

优点
性能强劲，是Zuul的1.6倍 功能强大，内置了很多实用的功能，例如转发、监控、限流等 设计优雅，容易扩展
缺点
依赖Netty与WebFlux，不是传统的Servlet编程模型，有一定的学习成本不能在Servlet容器下工作，也不能构
建成WAR包，即不能将其部署在Tomcat、Jetty等Servlet容器里，只能打成jar包执行 不支持Spring Boot 1.x， 需2.0及更高的版本

6.4 Gateway的作用

6.5 Gateway核心

Route（路由）
这是Spring Cloud Gateway的基本构建块，可简单理解成一条转发规则。包含：ID、目标URL、一组断言和一组过滤器，可以根据规则进行匹配
Predicate（断言）
这是一个 Java 8 的 Predicate，即java.util.function.Predicate这个接口，Gateway使用Predicate实现路由的匹配条件
Filter（过滤器）
这是 org.springframework.cloud.gateway.filter.GatewayFilter 的实例，我们可以使用它修改请求和响应

Gateway的路由匹配规则

七 Gateway实现过滤器

Gateway提供了2类过滤器：1.全局过滤器（GlobalFilter） 2.局部过滤器（GatewayFilter）
开发中主要使用全局过滤器
实现步骤：
1.编写类 实现接口GlobalFilter
2.重写方法filter

八 Sentinel的流控的方式：单机、集群总量、集群中单机均摊

7.1 Sentinel是什么

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Spring Cloud Circuit Breaker 是 Spring Cloud 官方的熔断器组件库，提供了一套统一的熔断器抽象API接口，允
许开发者自由选择合适的熔断器实现。这个官方的熔断器组件库，截至目前，官方推荐的熔断器组件有：
Hystrix Resilience4J Sentinel Spring Retry 当前，Spring Cloud Circuit Breaker 处于孵化阶段中，未来将合并到
Spring Cloud 主干版本正式发布。

7.2 Sentinel发展历程

2012 年，Sentinel 诞生于阿里巴巴集团内部，主要功能为入口流量控制；
2013 - 2018 年，Sentinel 在阿里巴巴集团内部迅速发展，成为基础技术模块，覆盖了所有的核心场景。Sentinel 也因此积累了大量的流量控制场景以及生产实践；
2018年7月，阿里巴巴宣布限流降级框架组件 Sentinel 正式开源，在此之前，Sentinel 作为阿里巴巴“大中台、小前台”架构中的基础模块，已经覆盖了阿里的所有核心场景，因此积累了大量的流量归整场景以及生产实践；
2018年9月，Sentinel 发布 v0.2.0版本，释放异步调用支持、热点参数限流等多个重要特性；
2018年10月，Sentinel 发布首个 GA 版本 v1.3.0，该版本包括 Sentinel 控制台功能的完善和一些 bug
修复，以及其它的产品改进；
2018年12月，Sentinel发布v1.4，加入了开发者关注的集群流控功能；
2019年3月，Sentinel 发布1.5.0 ，引入 Reactive 支持；
2019年4月，Sentinel 贡献的 spring-cloud-circuitbreaker- sentinel 模块正式被Spring Cloud社区合并至 Spring Cloud Circuit Breaker，成为 Spring Cloud 官方的主流推荐选择之一。
2019年4月25日，Sentinel 发布 1.6.0 ，提供对 Spring Cloud Gateway、Zuul 等主流 API Gateway 的定制化支持。

7.3 Sentinel 的特点

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

7.4 Sentinel的功能

sentinel熔断器，主要的作用就是2个：1.流量控制 2.熔断降级
流量控制：根据测试的服务可处理请求上限，设置最大请求数
熔断降级：服务一旦不可用（超时、数据库、网络抖动、死锁、服务资源（CPU 内存）等等），可以立即执行降级方法
服务容错的三个核心思想是：

1. 不被外界环境影响
2. 不被上游请求压垮
3. 不被下游响应拖垮

接口降级

@RestController
@RequestMapping("/api/vote/")
public class VoteController {
    @Autowired
    private VoteService service;
    //文件上传
    @PostMapping("uploadimg.do")
    @SentinelResource(value = "uploadimg.do",fallback = "uploadError")//实现服务降级
    public R upload(@RequestParam MultipartFile file){
        return service.upload(file);
    }
    //降级方法-和受保护的方法具有一样的参数和返回值
    //一旦upload出现了错误，就会自动执行降级方法
    public R uploadError(MultipartFile file){
        return R.fail("亲，请检查网络");
    }
}

九 Sentinel实现服务降级：1.RT 2.异常比例 3.异常数

十 Sleuth+Zipkin配置

8.1 Sleuth概述

Spring Cloud Sleuth为Spring Cloud实现了分布式跟踪解决方案.其实是一个工具,它在整个分布式系统中能跟踪一个用户请求的过程(包括数据采集，数据传输，数据存储，数据分析，数据可视化)，捕获这些跟踪数据，就能构建微服务的整个调用链的视图，这是调试和监控微服务的关键工具。服务链路跟踪技术框架

8.2 Sleuth核心

Span：基本工作单元，发送一个远程调度任务 就会产生一个Span，Span是一个64位ID唯一标识的，Trace是用另一个64位ID唯一标识的，Span还有其他数据信息，比如摘要、时间戳事件、Span的ID、以及进度ID。
迹线：一组spans，形成树状结构
注释：用于及时记录事件的存在，一些核心注解用来定义一个请求的开始和结束，这些注解包括以下：
cs：客户端已发送。客户提出了要求。此注释指示跨度的开始。
sr：服务器收到数据：服务器端收到了请求并开始处理它。从此时间戳中减去 cs 时间戳可显示网络延迟。
ss：服务器已发送。在请求处理完成时进行注释（当响应被发送回客户端时）。从此时间戳中减去 sr
时间戳将显示服务器端处理请求所需的时间。
cr：客户端收到数据。表示跨度结束。客户端已成功收到服务器端的响应。从此时间戳中减去 cs 时间
戳将显示客户端从服务器接收响应所需的整个时间。

8.3 Sleuth的功能

8.4 Zipkin

Zipkin是一个分布式跟踪系统。它有助于收集解决服务体系结构中的延迟问题所需的时序数据。功能包括该数据的收集和查找。
Zipkin 是 Twitter 的一个开源项目，它基于 Google Dapper 实现，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。 我们可以使用它来收集各个服务器上请求链路
的跟踪数据，并通过它提供的 REST API 接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序，从而
及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向开发的 API 接口之外，它也提
供了方便的 UI 组件来帮助我们直观的搜索跟踪信息和分析请求链路明细，比如：可以查询某段时间内各用户
请求的处理时间等。 Zipkin 提供了可插拔数据存储方式：In-Memory、MySql、Cassandra 以及 Elasticsearch。
接下来的测试为方便直接采用 In-Memory 方式进行存储，生产推荐 Elasticsearch。

Zipkin的基础架构，它主要由4个核心组件构成：
Collector：收集器组件，它主要用于处理从外部系统发送过来的跟踪信息，将这些信息转换为 Zipkin 内部处理的 Span 格式，以支持后续的存储、分析、展示等功能。
Storage：存储组件，它主要对处理收集器接收到
的跟踪信息，默认会将这些信息存储在内存中，我们也可以修改此存储策略，通过使用其他存储组件将跟踪信息存储到数据库中。
RESTful API：API 组件，它主要用来提供外部访问接口。比如给客户端展示跟踪信息，或是外接系统访问以实现监控等。
Web UI：UI 组件，基于 API 组件实现的上层应用。通过 UI 组件用户可以方便而有直观地查询和分析跟踪信息。
如果日志文件中有跟踪ID，则可以直接跳至该跟踪ID。否则，您可以基于属性进行查询，例如服务，操作名称，标签和持续时间。将为您总结一些有趣的数据，例如在服务中花费的时间百分比以及操作是否失败。提供了有个可视化平台

java jar jar包名字—-运行jar包

十一 Nacos实现原理

十二 OpenFeign使用

十三 OpenFeign负载均衡以及策略

十四 分布式事务-Seata