SpringCoudAlibaba相关学习记录

​​SpringCloud中文官网​​

本文学习参考B站尚学堂SpringCloud视频及工作中已经应用的SpringCloudAlibaba项目和百度;

微服务架构介绍:
微服务架构提倡将单一应用程序划分成一组小的服务,服务之间相互协调,调用,配合,为用户提供最终价值,每个服务运行在独立进程中,服务与服务之间通常采用基于HTTP协议的RestFulAPI轻量级通信机制相互协作,能够独立进行部署,对具体服务而言可以根据服务上下文,选择合适的语言工具进行构建;

Maven管理:添加DependcyManagment注解,多个子项目引用同一个依赖可以避免在子项目中声明版本号,便于维护修改,只需要修改父类不需要修改子类;在该注解下只负责声明版本不实现引入依赖,子类依靠该声明版本号进行引入依赖;当子类指定版本后会使用子类的依赖版本;

相关组件:

Eureka

服务注册中心：Netflix公司开发，管理服务之间依赖关系，可以实现服务调用与注册，负载均衡，容错等；Eureka采用CS架构设计，可以使用Eureka的客户端连接到EureakServer并维持心跳连接，可以通过EurekaServer来监控系统中微服务运行状态；
当服务器启动时将当前服务的信息：服务地址，通讯地址等以别名的方式注册到注册中心，消费者会以该别名的方式去注册中心获取实际地址，通过本地RPC调用远程RPC；
设计思想：注册中心中管理的服务与服务之间有依赖关系也就是服务治理概念；在任何RPC远程框架中都会有注册中心存放服务地址相关信息；
Eureka包含两个组件:EurekaServer,EurekaClient;
Server提供服务注册；Client可以通过注册中心进行访问；
客户端具备一个内置使用轮询的负载算法，在应用启动后向服务发送心跳（默认30s）如果服务在多个周期（默认90s）没有接收到某个节点的心跳服务会将服务注册表中移除该服务；

搭建Eureka集群：

Actuator健康检查：​​https://blog.csdn.net/alinyua/article/details/80009435​​

Discovery服务发现:对于注册金Eureka的微服务可以通过服务发现获取微服务；

Eureka自我保护机制：心跳机制,在一定时间内(默认90s)没有接收到服务端的通讯会在服务注册表中剔除该服务,当短时间内(90s中)丢失大量服务心跳会开启自我保护机制: 在微服务不可用状态下不会立刻清除该服务,依旧会进行保留;默认开启可以再yml配置中关闭;

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THANTHRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUSTTO BE SAFE
该提示代表Eureka进入自我保护状态;符合CAP定理中AP;宁可放过不能错杀;

该机制可以解决当网络分区故障发生时:延时卡顿情况,微服务之间与Eureka无法进行通信时不会销毁由于网络延时问题导致的无法通信的健康的微服务;

Zookeeper

分布式协调工具,可以实现注册中心功能;
单机版安装完成配置yml可以进行注册,注册到zookeeper的服务节点，如果关闭其提供者服务节点，zookeeper的提供者节点就会消失，是因为zookeeper产生的是临时节点;

Consul

开源分布式服务发现和配置管理系统,使用GO语言开发;它提供了微服务系统中的服务治理,配置中心,控制总线等功能;这些功能可以根据需要单独使用,它可以提供全套的完整的服务解决方案;有可视化界面,可作为键值对存储库使用;
优点:基于faft协议,比较简介,支持健康检查,同时支持Http和Dns协议支持跨数据中心的WAN集群提供图形界面,可以跨平台,支持Linux,Mac,Win;
默认端口8500 访问客户端链接地址:ip:8500
​​Consul中文文档​​

三种注册中心对比:

CAP定理:

C：Consistency (强一致性)同一时间数据一致性；
A：Availability (可用性)所有请求会接受响应；
P：Partition tolerance （分区容错性)
分布式系统不能同时满足三个要求,根据CAP原理分为三种:CA,CP,AP;当前系统多数要求满足分区容错性; 
AP:满足可用性,分区容忍性 ,对一致性要求较低;   Eureka
CA:单点集群,满足一致性,可用性,可扩展性不强; 
CP:满足一致性,分区容忍性,一般性能较低;  Consul/Zookeeper

关于CAP定理中选择场景：
当不需要存储服务级别的信息且服务实例是通过nacos-client注册，能够保持心跳上报就可以选择AP模式；AP模式满足可用性减弱了一致性，AP模式下只支持注册临时实例；
当需要存储服务级别编辑或存储配置信息必须满足CP模式，K8s服务和DNS服务适用于CP模式，CP模式下支持注册持久化实例，此时以Raft协议为集群运行模式，该模式下注册实例之前必须先注册服务，如果服务不存在会返回错误信息；

Ribbon

Ribbon是基于NetfixRibbon实现的客户端负载均衡的工具,开源,主要功能是客户端的软件负载均衡算法和服务调用,该客户端组件提供完善的配置项:连接超时,重试,简单来说就是在配置文件中列出LoadBalancer后面所有的机器,Ribbon会自动基于某种规则:轮询,随机连接等规则去连接这些机器;

LoadBalancer:

负载均衡器:将用户请求平摊到多个服务器上,从而达到系统高可用,Nginx,LVS是常见的负载均衡软件;

Nginx与Ribbon区别:

Nginx是服务器端负载均衡,客户端所有请求交由Nginx然后Nginx实现请求转发;
Ribbon是本地负载均衡,在调用微服务接口时会在注册中心获取注册服务信息列表缓存到本地JVM中,从而在本地实现RPC远程服务调用;

Ribbon工作流程:
第一步选择EurekaServer,优先选择在同一个区域内负载较少的Server;第二部再根据用户指定策略从Server中渠道的服务注册列表选取一个地址;
自带负载机制:

RoundRobinRule 轮询
RandomRule 随机
RetryRule 先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内会进行重试;
WeightedResponseTimeRule 对RoundRobinRule的扩展，响应速度越快的实例选择权重越大，越容易被选择;
BestAvailableRule 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务;
AvailabilityFilteringRule 先过滤掉故障实例，再选择并发较小的实例;
ZoneAvoidanceRule 默认规则,复合判断server所在区域的性能和server的可用性选择服务器;
配置负载策略时自定义配置类不能放在@ComponentScan所扫描的当前包下及子包下;否则该自定义配置类会被所有Ribbon客户端共享达不到特殊化定制需求;

Ribbon轮询负载均衡算法原理:

算法:rest接口第几次请求%服务器集群总数=实际调用服务器位置下标,每次服务器重启后计数变为1;

OpenFigen

介绍:Feign为了替代Ribbon+RestTemplate组成的模板化调用方法;使用注解声明就可以进行远程服务调用;SpringCloud也对Feign进行了封装支持SpringMVC标准和HttpMessageConverters,Feign可以和Ribbon/Eureka组合支持负载均衡;
OpenFeign在Feign基础上做了升级,可以支持SpringMVC注解并通过动态代理产生实现类,实现负载均衡;
它是一个声明式WEB服务客户端,通过注解编写使客户端代码更容易编写;它集成了Ribbon可以实现客户端负载均衡;

OpenFeign可以在配置文件设置超时设置;支持日志打印日志功能增强;

Hystrix

断路器:停更;用来处理分布式服务系统的延迟和容错的开源库,它能够保证在一个依赖出现问题时不会导致整体服务失败避免服务雪崩发生,增加系统弹性;可以像保险丝一样通过断路器的故障监控像调用方返回一个备选响应(回调方法)保证服务调用方的线程不会被长时间不必要的占用进而导致雪崩的发生;

服务雪崩概念:微服务中单个服务实例失败后继续接受请求有流量进入,该服务有调用其他模块或被其他模块调用时造成级联故障,由单点故障造成多点故障(扇出效应)称为服务雪崩;

概念:

服务降级:回调方法,兜底解决方案;
大部分原因:程序运行异常;超时;服务熔断触发降级;线程池/信号量打满;

服务熔断:服务达到最大访问量后直接拒绝访问,然后调用服务降级的方法返回提示;
降级>熔断>恢复调用链路

服务限流:秒杀高并发等操作,流量突然增大时有序进行;

GateWay：

为微服务架构提供一种简单有效的统一的API路由管理方式;gateway是基于WebFlux框架实现的,该光甲底层使用了高性能的Reactor模式通信框架Netty;提供统一路由方式且基于Filter链方式提供了网关基本功能:安全,监控/指标,限流等;基于异步非阻塞模型进行开发的;

技术特性：

基于springFramework5,springBoot2.0,ProjectReactor进行构建;
动态路由,能够匹配请求属性;
可以对路由指定Predicate(断言)和Filter(过滤器)并且易于编写;
集成Hystrix熔断功能;
集成SpringCloud服务发现功能;
请求限流功能;
支持路径重写;

路由：Route

路由是指构建网关的基本模块,它由ID,目标URI,一系列的断言和过滤器组成,如果断言为true则匹配该路由;

断言:Predicate

参考Java8的java.util.function.Predicate,开发人员可以匹配HTTP请求中的所有内容:请求头,请求参数等.如果请求与断言匹配进行路由;

过滤:Filter

指Spring框架中GatewayFilter的实例,使用过滤器,可以再请求被路由前后对请求进行修改;

web请求中通过一些匹配条件定位到服务节点,并在转发过程中进行精细化控制,断言就是匹配条件,过滤器可以理解为所有请求的拦截器,加上目标URI就可以实现具体的路由;

工作流程:

客户端向Gateway发出请求,然后再GatewayHandlerMapping中找到与请求相匹配的路由,将其发送到GatewayWebHandler;Handler在通过指定的过滤器链将请求发送到我们实际的服务执行业务逻辑,然后返回;过滤器中的虚线是由于过滤器可能在发送代理请求之前(pre)或之后(post)执行业务逻辑;
pre类型的过滤器可以进行参数,权限校验,流量监控,日志输出,协议转换等功能.
post类型过滤器可以作出响应内容,响应头修改,日志输出,流量监控等重要作用.

代码配置:
yml文件配置:

nacos:

​​nacos官网​​github

全称 Naming Configuration Service
nacos是一个易于构建云原生应用的动态服务发现，配置管理，和服务管理平台；相当于Eureka+Config+Bus；可以替代Eureka作为服务注册中心，替代Config作为配置中心；

Nacos在项目初始化时会创建两个配置文件 bootstrap.yml / application.yml

bootstrap优先级高于application;

nacos中的NameSpace-Group-DataID

类似Java中的包名与类名，NameSpece用于区分部署环境，
Group与DataID逻辑上用来区分目标对象
（DataID命名规则：${prefix}-${spring-profile.active}.${file-extension}.yaml;当active为空时可以拼接为${prefix}.${file-extension}.yaml）；
nacos中的配置可以通过原生注解实现动态刷新配置，Spring Cloud 原生注解@RefreshScope实现配置自动更新。

Nacos默认命名空间是Public，NameSpace主要用来实现隔离用于区分测试，开发，生产环境，通过创建不同命名空间实现隔离；

Group默认是DEFAULT_GROUP，不同分组可以把不同微服务划分到相同的分组中；

Services就是微服务，一个Services可以包含多个Cluster（集群），Nacos默认Cluster是DEFAULT，Cluster是对指定微服务的虚拟划分；例如为了容灾，将服务分别部署在不同地点，通过给不同机房的服务起不同的集群名称，还可以使一个机房的微服务尽量互相调用提升新跟那个；

最后是Instance就是微服务的实例；

nacos集群搭建：

官网架构图：

官网中三种架构模式：

​

​http://ip1​

​:port/openAPI直连IP模式，机器挂载，需要修改IP才可以使用；

​

​http://VIP​

​:port/openAPI挂载VIP模式，直连VIP，下面挂载server真实IP可读性较差；

​

​http://nacos.com​

​:port/openAPI域名+VIP模式，可读性较好，更换IP方便，官网推荐；

vip:虚拟ip（nginx）

官网推荐模式真是架构图：

请求流程：请求发送到nginx集群(虚拟ip)通过虚拟ip映射到nacos，由nacos到主从或集群配置的MySQL读取配置；当前支持数据库为mysql5.6.5+版本

nacos默认使用一个内嵌式数据库（derby）存储配置信息，当集群化时配置数据一致性不能保证；为了解决这个问题使用MySQL进行存储配置信息；

通过修改nacos conf 文件下 application.properties 文件修改为配置存储到MySQL；

spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://localhost:3306/nacos-config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
db.user=root
db.password=root

Linux环境Nacos+MySQL配置：
安装nacos->执行sql文件创建nacosMySQL数据库及创建表->修改application.properties配置MySQL数据源->修改nacos cluster.conf文件映射集群端口->Nginx（安装及配置)

Sentinel

​​中文官网​​

Sentinel以流量为切入点，从流量控制，熔断降级，系统负载保护等多个维度保护服务的稳定性；
应用场景广：秒杀，削峰填谷，集群流量控制，实时熔断下游不可用应用等；
完备实时监控：具有实时监控功能，可以在控制台接入应用的单台机器秒级数据，甚至500台以下的集群的汇总运行情况；
广泛的开源生态：开箱即用，与其他开源框架的整合，只需要引入相关依赖即可使用：SpringCloud,Dubbo等；
完善的SPI扩展点：可以根据SPI扩展接口定制规则管理，适配动态数据源等；

Sentinel 与 Hystrix 对比:

Hystrix没有监控平台需要自己搭建，没有web界面可以进行更加细粒度化配置流控，速率控制，服务熔断，服务降级；

Sentinel单独组件可以独立出来，直接在界面可以进行细粒度统一配置；

当配置文件中配置sentinel监控地址与端口并启动sentinel之后服务不会直接被它监控需要访问该服务之后才会被监控，它采用懒加载机制；

界面监控规则介绍：

流控规则：

资源名：唯一名称，默认请求路径；

针对来源：Sentinel可以针对调用者进行限流，填写微服务名，默认default不区分来源；

阈值类型、单机阈值：

QPS每秒钟请求数量，当调用该api的QPS达到阈值时进行限流；

线程数：当调用该api的线程数达到阈值进行限流；

是否集群：不需要集群；

流控模式：

直接：api达到限流条件时直接限流；

关联：当关联的资源达到阈值时限流自己；

链路只记录链路上的流量（指定资源从入口资源进来的流量，如果达到阈值就进行限流）api级别的针对来源；

流控效果：

快速失败：直接失败抛出异常；

WarmUp：根据CodeFactor（冷加载因子，默认3）的值从阈值/CodeFactor经过预热时长，才达到设置的QPS阈值；在预热时长内缓慢达到阈值；

排队等待：匀速排队，让请求以匀速通过，该流控效果必须设置为QPS否则无效；

降级规则：

熔断降级介绍：在不同服务间相互调用组成的复杂的调用链路，当链路中某一环不稳定时产生级联效应导致整个链路不可用，所以需要对不稳定的弱依赖服务调用进行熔断降级，暂时切断不稳定调用，避免局部不稳定因素导致的整体的雪崩，熔断降级通常在客户端进行配置；

RT：秒级平均响应时间；

平均响应时间超出阈值且在时间窗口内通过的请求>=5出发降级操作；

窗口期过后关闭熔断器；

RT最大4900，可以通过配置提升RT限值；

异常比例：秒级

QPS>=5且秒级异常比例统计超过阈值，触发降级，时间窗口过后关闭降级；

异常数：分钟级

分钟统计异常数超出阈值触发降级，时间窗口过后关闭降级；

Sentinel熔断降级会在调用链路调用超时/异常比例升高之后对该资源调用进行限制，让请求快速失败避免级联错误；当降级发生时在时间窗口内调用该资源会触发自动熔断，Sentinel1.8版本有类似Hystrix半开状态；半开状态时系统自动请求资源是否异常，无异常会关闭断路器恢复正常；

Sentinel热点规则：

热点概念：经常访问的数据，可以用于统计热点数据中访问频次最高的数据，并对其访问进行限制；

根据不同参数可以统计不同数据并进行限制；

热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流，热点参数限流可以看作是一种特殊的流量控制，仅对包含热点参数的资源调用生效；

@SentinelResource 相当于Hystrix @HystrixCommand

@SentinelResource(value = "testHotKey", blockHandler ="deal_testHotKey") blockHandler为配置兜底方法

当value为testHotKey的方法QPS>1时会触发降级并返回兜底方法；

配置参数索引1且数值为5时不进行限流；

只配置热点限流规则时抛出异常不会走兜底方法；

Sentinel系统规则：

sentinel系统自适应限流从整体维度对应用入口流量进行控制，结合Load，CPU使用率，总体平均RT，入口QPS和并发线程数等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到平衡，让系统尽可能跑在最大吞吐量的同事保证整体稳定性；

它是应用整体维度而不是资源维度，仅对入口流量生效；

主要规则：

Load自适应（仅对linux、Unix-like生效）系统的load1作为启发指标进行自适应系统保护；当系统load1超过设定的启发值，且系统当前的并发线程数超过估算的系统容量时才会触发系统保护，系统容量是由maxQPSminRT估算得出，设置参考值为CPU cores2.5；

CPU usage（1.5+版本）：当系统CPU使用率超过阈值触发系统保护；

平均RT：单机器上所有入口流量的并发线程数达到阈值即触发系统保护；

入口QPS：单机器上所有入口流量的QPS达到阈值触发保护；

Sentinel @SentinelResource 注解配置相关:

@SentinelResource(value = "customerBlockHandler",
blockHandlerClass = CustomerBlockHandler.class,//<-------- 自定义限流处理类
blockHandler = "handlerException2",
fallback = "handlerFallback",
exceptionsToIgnore = {IllegalArgumentException.class})
value:配置资源名 blockHandlerClass:配置自定义限流违规处理类 blockHandler :配置违反流控规则兜底方法 fallback:业务异常兜底方法 exceptionsToIgnore 配置忽略指定异常,配置的异常不会触发兜底方法;

Scentinel持久化:

将sentinel限流降级规则配置到nacos,当刷新服务请求时可以再sentinel控制台看到配置的流控规则;

nacos配置:

[{
    "resource": "/rateLimit/byUrl",资源名称；
    "IimitApp": "default",      来源应用；
    "grade": 1,                 阈值类型，0表示线程数, 1表示QPS；
    "count": 1,                 单机阈值；
    "strategy": 0,              流控模式，0表示直接，1表示关联，2表示链路；
    "controlBehavior": 0,       流控效果，0表示快速失败，1表示Warm Up，2表示排队等待；
    "clusterMode": false        是否集群。
}]

Seata

​​官网文档​​ Seata是开源的分布式事务解决方案,用于解决分布式/微服务架构中多应用对应多数据源不能保证全局数据统一性问题,提供高性能和简单易用的分布式服务;

Seata 一 ID 三 组件模型:

Transaction ID XID 全局唯一的事务ID
三组件概念
TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
处理流程:
1:TM向TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID；
2:XID在微服务调用链路的上下文中传播；
3:RM向TC注册分支事务，将其纳入XID对应全局事务的管辖；
4:TM向TC发起针对XID的全局提交或回滚决议；
5:TC调度XID下管辖的全部分支事务完成提交或回滚请求。

项目地址:​​https://gitee.com/ch_20000/abdcd.git​​ 参考文档地址：
https://blog.csdn.net/u011863024/article/details/114298270
https://blog.csdn.net/u011863024/article/details/114298282
​​https://blog.csdn.net/u011863024/article/details/114298288​​