目录
1.springcloud简介、eureka注册中心的使用
1.1 系统架构演变
1.2 spring cloud
1.3 模拟微服务业务场景
1.4 注册中心 spring cloud eureka
2.ribbon、hystrix、feign的使用
2.1 负载均衡 spring cloud ribbon
2.2 熔断器 spring cloud hystrix
2.3 远程调用 spring cloud feign
3.gateway、config、bus的使用
3.1 网关 spring cloud gateway
3.2 配置中心 spring cloud config
3.3 spring cloud bus 消息总线
4.spring cloud中eureka和zookeeper的区别
5.RPC、zookeeper注册中心、dubbo配置
5.1 应用架构的演变过程
5.2 RPC(远程过程调用)
5.3 Apache Dubbo
5.4 服务注册中心zookeeper
5.5 dubbo快速开发
6.spring cloud alibaba入门简介
7.spring cloud alibab nacos服务注册和配置中心
8.spring cloud alibaba sentinel 实现熔断和限流
9.spring cloud alibaba seata 处理分布式事务
10.spring cloud alibaba snowflake 雪花算法
11.spring cloud alibaba 参考资料：
1.springcloud简介、eureka注册中心的使用
1.1 系统架构演变
单一应用架构-垂直应用框架-分布式服务架(RPC)构-面向服务(SAO)架构(代表是流动计算架构和微服务架构，最佳实现分别是dubbo和spring cloud.流动计算架构的优势在于增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率；微服务架构除了具备流动计算架构的优势外，其中的微服务可以独立部署，独立发展)
1.2 spring cloud
从技术架构上降低了构建大型项目的难度，可以非常低的成本搭建高效的分布式平台，不适合小型项目使用
是一系列分布式微服务技术的有序整合，利用springboot的开发便利性简化了分布式系统基础设施的开发
springcloud是一些列框架组合，为避免和框架版本混淆，采用 大版本名+子版本名称的方式命名。大版本使用伦敦地址站名字。子版本有3种情况：
SNAPSHOT:快照版本，随时可修改
M版本：MileStone,M1为第一个里程碑版本，一般同时标注RPE，表示预览版
SR：Service Release ,SR1表示第一个正式版本，同时标注GA(Generally Available),表示稳定版
因为使用springcloud需要在springboot的基础上使用，为了保证springcloud的稳定性，springboot一般使用2.1.X版本较好
1.3 模拟微服务业务场景
实际开发中，每个微服务为一个独立的springboot工程
最简单的服务调用场景中分为服务调用者(Producer)和服务消费者(Consumer)
通过最简单服务消费者调用服务调用者的方法，引发的问题：
服务管理：自动注册与发现，服务监管 spring cloud eureka
服务负载均衡：spring cloud ribbon
熔断器：spring cloud hystrix
远程过程调用
网关
配置中心及消息总线
1.4 注册中心 spring cloud eureka
简介：
eureka解决了第一个问题：服务监管，注册发现、状态监管、动态路由
负责管理和记录服务提供者的信息，服务调用者无需自己寻找服务，eureke自动匹配服务给调用者
eureka和服务之间通过心跳机制进行监控
原理(基本架构)：
服务提供者向服务中心注册服务，并通过心跳机制进行监控
服务消费者向注册中心定期拉取服务列表
服务消费者通过注册中心调用服务提供者的服务
eureke就是服务注册中心
服务提供者是向eureke注册自己的信息，包括地址及提供那些服务等
服务消费者就是向eureka订阅服务，eureka会将对应服务的所有提供者地址列表发送给消费者，并定期更新
心跳：也可成为续约，是提供者通过http方式定期向eureka刷新自己状态
注册中心整合eureka
搭建注册中心：启动类添加@EnableEurekaServer注解，表示当前应用为eureka服务使用；配置文件配置eureka-server地址，同时需要关闭注册自己。
服务提供者：启动类添加@EnableDiscoveryClient，开启客户端发现功能；配置文件配置eureka-server地址
服务消费者：启动类添加@EnableDiscoveryClient，开启客户端发现功能；配置文件配置eureka-server地址
消费者通过eureka访问提供者(DiscoveryClient实例的getInstance(String producerAppName)方法获取eureka中的服务提供者列表；随后获取实例ServiceInstance;最后获取实例的ip和端口请求即可)
eureka详解
eureka架构中3个核心角色：注册中心、服务提供者、服务消费者
服务提供者向注册提供服务并完成服务续约
服务注册过程：
导入eureka-client依赖坐标，配置eureka服务注册中心地址；服务启动检测启动类是否有@DiscovertClient和配置信息；
有则向注册中心发起注册请求，携带服务元数据；eureka注册中心会将服务保存在map中
服务续约过程：服务提供者每隔30秒向注册中心续约一次，如果没续约，90秒之后服务会失效。
服务下线：服务正常关闭或下线，会发送服务下线的rest请求给eurekaserver；注册中心接收到请求后，将该服务置于下线状态
服务剔除：每隔一段事件(默认60秒)将未续约的服务剔除
自我保护：eureka会统计最近15分钟心跳续约的比例，如果低于85%，会触发自我保护机制，不会提出任何实例。可通过enable-self-preservation：false来关闭，默认是打开
2.ribbon、hystrix、feign的使用
2.1 负载均衡 spring cloud ribbon
简介：
用于解决集群服务中，多个服务高效访问的问题
ribbon是netflix发布的负载均衡器，有助于控制http请求，在ribbon控制服务提供者列表后，ribbon可基于负载均衡算法，自动帮助服务消费者请求。
ribbon默认提供的负载均衡算法是轮询、随机其他。也可自定义负载均衡算法。
入门案例
想做负载均衡，服务提供者至少需要2个以上。
实现步骤：启动2个服务提供者向注册中心注册；eureka已经集成ribbon,pom文件中无需引入；RestTemplate配置上添加@LoadBalanced注解开启负载均衡；服务消费者调用服务提供者改为通过服务名称调用；
2.2 熔断器 spring cloud hystrix
简介：
Netflix公司发布的组件，表示一种保护机制
hystrix是Netflix开源的延迟和容错库，用于隔离访问远程服务、第三方库、防止出现级联失败也就是雪崩效应。
雪崩效应：
微服务中，1个请求可能需要调用多个微服务接口才能实现，会形成复杂的调用链路，
如果某服务出现异常，请求阻塞，用户得不到响应，容器中线程不会释放，于是越来越多用户请求堆积，越来越多线程阻塞
单服务器支持线程和并发数有限，如果请求一直阻塞，会导致服务资源耗尽，从而导致其他服务都不可用，从而行程雪崩效应。
hystrix解决雪崩问题的手段，主要是服务降级(兜底)，线程隔离
熔断案例
目的：服务提供者提供服务出现故障，服务消费者快速失败给用户友好提示，体验服务降级。
实现步骤：引入熔断依赖，开启熔断注解(@EnableCircuitBreaker)，编写服务降级处理方法(使用@HystrixCommand(fallbackMethod=”方法名”))，配置熔断策略(配置文件相关配置)
熔断原理分析
如同电力保护器。
熔断器状态机有3个状态：
关闭(所有请求正常访问)
打开(所有请求都会降级，hystrix会对请求情况进行计数，当一定事件内请求失败百分比达到阈值，熔断触发)
半开(打开状态非永久，打开一会后进入休眠(默认5秒)，休眠过后进入半开状态。)
半开状态：熔断求会判断下次请求的请求状况，如果成功，熔断器切回关闭状态；如果失败，熔断器切回打开状态。
熔断器核心解决方案：线程隔离和服务降级(兜底方法)
线程隔离和服务降级之后，用户请求故障之后，线程不会阻塞，更不会无休止等待或系统崩溃，至少可看到执行结果(熔断机制)
熔断时机：访问超时；服务不可用；服务抛出异常(服务有异常但是或者)；其他请求导致服务异常达到阈值，所有服务降级
服务降级的fallbackMethod方法
方法上服务降级的方法：@HystrixCommand(fallbackMethod = “兜底方法”)
类上服务降级的方法：@DefaultProperties(defaultFallBack = “兜底方法”) 方法上使用@HystrixCommand。则类中所有方法兜底方法都会生效。
2.3 远程调用 spring cloud feign
引出：通过RestTemplate进行调用，出现大量重复代码，无非参数区别
简介：feign是一个http请求调用的轻量级框架，封装了http调用流程，更符合面向接口化的编程习惯。类似Dubbo服务调用
案例：
导入依赖；启动类添加@EnableFeignClients；
编写FeignClient接口，使用springmvc注解(类上使用注解@FeignClient(“服务名称”)表示指定feign调用的服务,方法上使用@RequestMapping注解修饰)；
(Feign会mvc注解逆向生成URL并请求)
controller注入feign接口，无需实现类，直接调用。(feign会通过动态代理，生成实现类)
原理：使用feign会根据定义的feignclient接口，逆向解析出服务提供方法接口请求地址，然后进行调用
负载均衡：
负载均衡是远程调用的必备因素，feign本身集成了ribbon,因此无需额外引入依赖。
feign内置ribbon默认设置了连接超时，1秒。
熔断器支持：
feign本身也集成了hystrix
实现步骤：配置文件开启feign熔断器支持；编写fallback处理类，实现FeignClient接口；在@FeignClient注解中，指定fallBack处理类
请求压缩和响应压缩
springcloudfeign支持请求和响应进行GZIP压缩，以提升通信中的传输速度
配置文件中开启请求和响应的压缩功能，也可对请求的数据类型及触发压缩的大小进行设置
配置日志级别
发送和接收请求，feign定义了日志的输出定义了4个登记
NONE：不做记录
BASIC:只记录输出Http 方法名称、请求URL、返回状态码和执行时间
HEADERS:记录输出Http 方法名称、请求URL、返回状态码和执行时间 和 Header 信息
FULL:记录Request 和Response的Header，Body和一些请求元数据
实现步骤：
配置文件开启日志级别配置；编写配置类，定义日志级别bean;接口的@FeignClient指定配置类；
3.gateway、config、bus的使用
3.1 网关 spring cloud gateway
简介：
网关是所有微服务的入口，为微服务提供统一且简单有效的路由API管理方式，并且基于Filter链的方式提供了网关的基本功能，例如安全、监控/指标、限流。用于替代Netflix的zuul，
网关本身也是一个微服务，需要注册到eureka
功能特性：
动态路由、Predicates 和 Filters 作用于特定路由、集成熔断Hystrix、集成spring cloud discoveryclient、限流、路径重写
无论是客户端请求还是内部请求都可经过网关、网关实现鉴权及动态路由等操作、Gateway是服务统一入口
术语说明
路由(Route)：网关的基本模块。由一个ID、1个目标URI、一组断言和一组过滤器定义。如果断言为真，则路由匹配
断言(Predicate):java8的Predicate，输入类型是ServerWebExchange，可用匹配http请求的任何内容，包括header和参数
过滤器(Filter):GateFilter的实例，可用来修改请求和响应
快速入门
目的：搭建网关微服务，实现服务路由分发
实现步骤：引入eureka、gateway的依赖；启动类使用@EnableDiscoveryClient注解；配置端口、服务名、注册中心地址、网关(路由id、路由地址、断言)；重启测试
动态路由：配置文件中网关的URI地址写死不太合适，如果服务提供者是集群的话，需要根据服务名称获取，从而动态路由。格式：lb://服务名称 lb://表示协议，通过此协议，会自动使用负载均衡访问服务
路由前缀：
添加前缀：配置路由的过滤器PrefixPath实现前缀添加，可隐藏接口地址
移除前缀：配置路由的过滤器StripPrefix实现移除前缀
过滤器：
简介：
作为网关的重要功能，即实现请求鉴权。
自带过滤器很多，常见过滤器有：AddRequestHeader(请求添加header)、AddRequestParameters(请求添加参数)、
AddResponseHeader(响应添加header)、StripPrefix(移除前缀)、PrefixPath(添加前缀)。
使用场景：请求鉴权(无权限直接拦截)、异常处理(记录异常日志)、服务调用时长统计
类型：gateway有2种过滤器，分为局部过滤器(仅作用局部路由)和全局过滤器(作用全部路由)
配置全局过滤器规则：default-filters:-过滤器:参数值。例如：default-filters: – AddResponseHeader=i-love,itheima 在响应头中添加 i-love:itheima
执行顺序：pre请求前调用;post请求后调用。可通过过滤器的GatewayFilterChain执行filter方法前后来进行实现
自定义全局过滤器：自定义类实现GlobalFilter和Ordered接口，重写filter和getOrder方法，编写判断逻辑。过滤器必须注入在spring容器中
3.2 配置中心 spring cloud config
config简介：
分布式系统中，微服务数量众多，配置文件分散在不同的微服务项目中，管理不方便。为了方便配置文件集中管理，因此需要分布式配置中心组件。
spring cloud config支持配置文件放在本地，也支持配置文件放在远程仓库(git、码云、github)
spring could config本质上是一个管理所有微服务配置文件的微服务，需要注册到eureka服务中心。
配置中心整合步骤
配置文件集中放在远程仓库；配置中心获取远程仓库配置文件；用户服务获取配置中心文件
git配置管理
git仓库有国外的github和国内的gitee,为了保证远程仓库的稳定性，在gitee创建仓库并新建{application}-{profile}.yml或者{application}-{profile}.properties文件。
application表示应用名称，profile表示区分开发环境(dev,test,pro)。
例如创建 user-dev.yml
搭建配置中心微服务
创建项目；引入config server和eureka的starter;启动类添加@EnableConfigServer；修改配置文件(端口、应用名称、注册中心地址、码云仓库地址等配置)；测试配置文件实时同步
启动eureka客户端和配置中心后，访问http://localhost:端口/user-dev.yml 可显示码云中的文件内容
服务获取配置中心配置
bootstrap.yml和application.yml文件的说明
bootstrap.yml是spring boot的默认配置文件，相当于项启动的引导文件，加载时间相对application.yml更早
application.yml则是springboot的常规配置参数，变化比较频繁，使用spring cloud config可使application.yml的配置可以动态替换
目的：项目配置文件不再由微服务项目提供，而是从配置文件获取
实现步骤：
pom文件添加config server依赖；
删除application.yml,添加bootstrap.yml;
bootstrap.yml中添加配置中心相关配置(配置文件前后缀、仓库分支、是否开启配置中心)、及注册中心地址；
启动测试，可在服务中心检查服务
配置中心存在问题
git仓库配置文件的更新，并不会及时更新至别的服务端口，只有重启用户微服务才可以
spring cloud bus可解决上述问题，实现配置自动更新
3.3 spring cloud bus 消息总线
简介：
bus是用轻量的消息代理将分布式节点连接起来，可用于”广播配置文件的更改”或”服务的监控管理”
bus可为微服务做监控，也可实现程序之间相互通信
bus可选的消息代理(消息队列)rabbitmq和kafka
广播出去的配置文件会进行本地缓存
springcloudbus基于rabbitmq实现，默认使用本地消息队列服务，本地需安装并重启rabbitmq,rabbitmq安装路径及系统用户名不可为中文，所有操作需管理员权限运行
整合案例
目标：消息总线整合进微服务系统，实现配置中心的配置自动更新，无需重启微服务
改造步骤：config server微服务中添加bus和rabbitmq的依赖；配置文件中添加rabbitmq服务地址，触发配置文件更改接口；在需要刷新配置的类添加@RefreshScope注解
修改远程仓库配置文件后，可调用接口http://127.0.0.1:12000/actuator/bus-refresh(此地址固定不变，是config server中application.yml文件的配置项include的内容)来刷新配置
消息总线实现消息分发过程：请求地址访问配置中心的消息总线；消息总线收到请求；消息总线向消息队列发送消息；微服务监听消息队列；微服务收到消息队列后从配置中心获取最新配置
4.spring cloud中eureka和zookeeper的区别
CAP理论说明：是分布式系统的重要概念
Consistency:数据一致性，保证所有数据都要同步
Availability：可用性，保证任何时间请求数据都可正常响应
Partition Tolerance：分区容错性，网络通信故障，集群仍然可用，不会因为某个节点挂了，导致整合系统无法正常运作
zookeeper的CP原则(最终一致性)：
遵循数据一致性和分区容错性，但并非强一致性(例如客户端A执行写操作，执行到一半后返回，此时客户端B读取客户端A写操作还未同步的数据节点，那么读取到的数据就不是A最新的数据)。
想保证数据的强一致性，在读取数据时候先从leader节点同步下数据，再去获取，才可保证
zookeeper缺点：当master节点因为网络瘫痪和其他节点失去联系，剩余节点会重新进行leader节点选举，此选举过程大约需要30S-120S，在此期间zookeeper是不可用的，导致选举期间服务瘫痪
zookeeper要的是一致性，而非可用性
eureka的AP原则(可用性和分区容错性)
eureka优先保证可用性
eureka中节点都是平等的，几个节点瘫痪并不会影响其他服务的注册和查询
某个eureka客户端在向eureka注册时，如果发现失败，则会自动切换至其他节点，只要一台eureka存活，即可保证服务可用，可能无法保证数据最新
eureka可以很好应对网络故障导致的服务瘫痪
服务最重要的是可用性，可接受短时间内数据不一致的情况，相对eureka比zookeeper作为单纯的注册中心可用性更强一些。
5.RPC、zookeeper注册中心、dubbo配置
5.1 应用架构的演变过程
单一应用：所有功能部署在一起，减少部署节点和成本，简化CRUD工作量的ORM(数据访问框架)是关键
垂直应用:访问量增大，单一应用带来的加速度逐渐减小，将单一应用拆成互不相干的几个应用来提升效率。因此加速前端页面开发的web框架(MVC)是关键
分布式：垂直应用越来越多，应用之间交互不可避免，核心业务抽取出来，作为独立服务，成为稳定服务中心。提高业务复用及整合的分布式服务框架(RPC)是关键
流动计算：服务越来越多，容量评估，小服务资源等浪费问题的出现，需增加调度中心基于访问压力实时管理集群容量，提升集群利用率。此时提高机器利用率和资源调度(SOA)是关键
5.2 RPC(远程过程调用)
Remote Procedure Call,分布式架构核心，有同步调用和异步调用2类。
同步调用：客户端调用服务端方法，等返回结果或超时，再进行自己的操作
异步调用：客户端调用服务端方法，不用等待返回，直接进行自己的操作。是进程之间的通信
RPC并非具体技术，而是指整个网络远程调用过程。常见RPC框架：dubbo、RMI、Hessian等
RPC架构组件：客户端、客户端存根、服务端存根、服务端
5.3 Apache Dubbo
简介：高性能的java RPC框架，前身是阿里巴巴开源的java RPC矿界，可与spring框架无缝集成
提供了三大核心能力：面向接口远程方法调用、智能容错和负载均衡、服务自动注册和发现
Dubbo架构：
Provider(服务提供方)、Consumer(服务消费者)、Registry（注册中心）、Monitor(监控中心)、Container(服务运行容器)
5.4 服务注册中心zookeeper
zookeeper是apache hadoop的子项目，是树形的目录服务，支持变更推送，适合作为dubbo服务的注册中心
流程说明：
provider启动时，向/dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地址
consumer启动时，订阅 /dubbo/com.foo.BarService/providers 目录下的提供者 URL 地址。并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址
monitor启动时， 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址
zookeeper客户端命令
安装目录，启动zkCli.cmd文件
ls 节点路径 –查看指定节点下的内容
ls / — 查看根目录下节点
ls2 节点路径 –查看指定节点的详细信息，查看所有子节点和当前节点的状态
get 节点路径 –获取节点路径中的值
delete 节点路径 –删除空节点，被删除节点不能含有子节点
rmr 节点路径 –递归删除节点
stat 节点路径 –查看节点状态
5.5 dubbo快速开发
dubbo最核心功能是实现跨网络的远程调用，服务提供者和服务消费者会使用共同的接口。
一般创建项目是一个父工程，包含接口模块、服务提供者模块、服务消费者模块，共计3个子模块。通过dubbo实现服务消费方远程调用服务提供方的方法。
实现步骤：创建父工程；创建接口子模块；创建服务提供者子模块；创建服务消费者子模块
6.spring cloud alibaba入门简介
简介：阿里巴巴基于自身微服务实现而开源的一套微服务解决方案，是spring cloud生态的子项目，2018.10.31正式入驻spring cloud 官方孵化器
主要功能：服务流量降级；服务注册与发现；分布式配置管理；消息驱动能力；分布式事务；阿里云对象存储；分布式任务调度；阿里云短信服务
组件：
Nacos：更易于构建云原生应用的动态服务发现、配置管理和服务管理平台
Sentinel:流量作为切入点，从流量控制、熔断降低、系统负载保护等多个维度维护系统的稳定性
RockeqMQ:分布式消息系统，基于高可用分布式集群技术，提供低延时、高可靠的信息发布与订阅服务
Dubbo:高性能java RPC框架
Seata:易于使用高性能微服务分布式事务解决方案
Alibaba Cloud ACM:分布式中架构对配置集中管理和推送的应用配置中心产品
Alibaba Cloud OSS:阿里云对象存储服务，海量、安全、低成本、高可靠的云存储服务
Alibaba Cloud SchedulerX:分布式任务调度，秒级、精准、高可靠、高可用
Alibaba Cloud SMS:覆盖全球的短信服务，
7.spring cloud alibab nacos服务注册和配置中心
Nacos定义：Dynamic Naming and Configuration Services。注册中心+配置中心的组合。等价于 eureka+config+bus
Nacos作用：替代eureka做服务注册中心，替代config做服务配置中心
Nacos安装：docker上安装nacos,拉去nacos镜像；运行nacos;访问http://dockerb部署ip:8848/nacos,账号和密码都是nacos
Nacos作为服务注册中心
基于nacos的服务提供者：创建moudle;引入依赖；修改配置文件；启动类添加@EnableDiscoveryClient；自定义controller；启动后访问 http://docker部署ip:8848/nacos 可查看注册服务；可创建多个module，实现提供者集群
基于nacos的服务消费者：创建module；引入依赖；修改配置文件；启动类添加@EnableDiscoveryClient；创建配置类引入RestTemplate;自定义controller;访问 服务提供者接口 即可看到负载均衡效果
整合feign:引入starter-openfeign依赖；启动类添加@EnableFeignClients注解；新建service接口，使用@FeignClient(value = “服务提供者项目名”)；controller无需注入RestTemplate，可直接使用
Nacos和其他注册中心(eureka)对比：
一致性协议：可在CP(一致性+分区容错性)+AP之间进行切换，,默认AP(可用性+分区容错性)
支持跨注册中心，支持dubbo集成，支持k8s集成
Nacos作为服务配置中心
基础配置：创建子moudle;引入依赖；配置文件配置(和spring cloud config一样，项目初始化时需要先从配置文件进行拉取，拉取之后才能保证项目正常启动)；spring cloud eureka启动类；
创建controller;nacos中添加配置信息；需要动态刷新配置的类添加@RefreshScope注解
分类配置:解决多项目多环境管理问题
Namespace、group、dataId 三者之间的关系：类似pachage名和类名。namespace用于区分部署环境，group和dataId逻辑上区分两个目标对象。
Namespace包含group,group包含service（微服务），每个微服务中包含多个cluster(集群)，每个集群可包含多个微服务实例
默认情况下Namespace=public,group=DEFAULT_GROUP;默认cluster=DEFAULT
Namespace主要用于区域开发、测试、生产环境。创建3个Namespace即可实现，不同的Namespace之间是隔离的
group可以把不同的微服务划分到同一个分组中
service就是微服务，一个service可以包含多个cluster(集群)，cluster是对指定微服务的一个虚拟划分
instance即微服务的实例
3种类加载配置方案：dataId方案、group方案、namespace方案
dagaId方案示例：创建 application-test.yml和application-dev.yml两个groupId。通过 spring.profile.active即可进行多环境下配置文件的读取
group方案示例：创建2个dataId相同的配置，但是group不同；bootstrap.yml中指定group，重启项目请求配置文件内容即可看到效果
namespace方案示例：新建2个不同名的namespace；在namespace中创建group和dataId；bootstrap.yml文件中通过namespace即可指定对应namespace的配置；重启即可看到效果
Nacos集群和持久化配置(重要)
nacos默认使用嵌入式数据库实现数据的存储，所以如果启动多个默认配置下的nacos节点，数据一致性存在问题
解决此问题，nacos采用集中式存储的方式来支持集群化部署，目前只支持Mysql的存储
nacos支持3种部署方式：单机模式(用于测试和单机试用)、集群模式(用于生产环境、确保高可用)、多集群模式(用于多数据中心场景)
单机模式：
linux/unix/mac操作系统中运行 startup.sh脚本；windows系统中运行startup.bat脚本名；
单机模式支持mysql(执行nacos-mysql.sql初始化Mysql，修改nacos中conf下的application.properties文件，增加Mysql配置，后续nacos的数据即可写入到mysql)
nacos持久配置解释：就是将nacos保存到自带的数据库中改为保存到mysql中
集群配置：通过nginx进行映射3个nacos的地址，使用1台数据库进行存储
8.spring cloud alibaba sentinel 实现熔断和限流
简介：sentinel是单独一个组件，可独立出来，界面化的细粒度统一配置，由2部分构成，分别是核心库(java客户端)和控制台(EnableHystrixDashboardboard)
特征：丰富的应用场景；完备实时监控；广泛开源生态；完善的SPI扩展点
初始化演示工程：新建模块；引入依赖；配置文件；启动类添加eureka注解；自定义controller;请求后刷新sentinel界面进行查看
流控规则：
资源名称:唯一默认请求路径
针对来源：sentinel可针对调用者进行限流
阈值类型/单机阈值：QPS(每秒钟请求数量)达到阈值，进行限流；线程数：调用API的线程数达到阈值进行限流
流控模式：直接(api达到限流条件直接限流)、关联(关联资源达到阈值，限流自己)、链路(记录指定链路上的流量，达到阈值进行限流)
流控效果：只有QPS会有，线程数没有
快速失败(直接失败，抛出异常)、
Warm up(根据codeFactoe冷加载因子，默认为3，阈值除以codeFactoe，经过预热时长，才达到设置的QPS阈值)、
排队等待(匀速排队，请求匀速通过，阈值类型必须设置QPS，否则无效)
降级规则：
衡量资源是否稳定的方式：平均响应时间(DEGRADE_GRADE_RT)、异常比例、异常数
RT(平均响应时间)：1S内持续进入N个请求，对应时刻平均响应时间(秒级)超过阈值(以ms为单位)，后续对此方法调用都会自动熔断。Sentinel默认统计RT上线是4900ms,超出阈值都会算作4900
异常比例：资源的每秒请求量大于等于N(可配置)，并且每秒异常数占通过总数的比值超过阈值之后，资源进入降级，后续的方法调用都会自动返回
异常数：资源近1分钟的异常数超过阈值会自动熔断
热点key限流：针对访问频次最高的数据进行限制，利用LRU算法策略统计最常访问的热点参数，热点参数限流支持集群模式
针对方法限流指定自定义的兜底降级方法：从@HystrixCommand到@SentinelResource(value=”当前方法名”,blockHandler=”兜底降级方法名”)
系统规则:从应用级别的入口流量进行控制，从单台机器的Load、CPU使用率、平均RT、入口QPS、并发线程数等几个指标监控应用指标，让系统在最大保证系统吞吐量的同时保持系统稳定性
支持以下模式：load自适应、CPU usage、平均RT、并发线程数、入口QPS
@SentinelResource使用模式
根据资源名称进行限流+后续处理 示例：@SentinelResource(value=”当前方法名”,blockHandler=”兜底降级方法名”)
根据URL地址限制+后续处理 示例：@SentinelResource(value=”URL地址”); 没有兜底方法，采用默认
自定义限流处理逻辑 示例：先自定义限流处理类，在限流方法上使用@SentinelResource(value=”方法名”,blockHandlerClass=”自定义类”,blockHandler=”自定义类中静态方法名”)
@SentinelResource注解fallback和blockHandler都指定后，然后同时符合，优先执行blockHandler兜底方法
服务负载均衡+熔断功能
负载均衡：ribbon
feign系列：添加依赖；配置文件添加sentinel对feign的支持；主启动类添加@EnableFeignClients；service中添加@FeignClient(value=””,fallback=”兜底降级类，实现service接口”)
配置规则持久化：
一旦重启sentinel，配置规则将会丢失，因此需要对其进行持久化
实现步骤：添加依赖；修改配置；nacos后台添加配置
9.spring cloud alibaba seata 处理分布式事务
分布式事务问题产生原因：单体服务拆分成多个微服务，每个微服务分别使用不同的数据源，业务操作需要调用3个服务完成，每个服务内部的数据一致性由本地事务来保证，但是全局的数据一致性无法保证。总之：一次业务操作需要跨多个数据源或多个系统，就会出现分布式事务问题
seata简介：开源的分布式事务解决方案，致力于微服务架构下提供高性能和简单易用的分布式事务服务
seata术语：
Transaction Coordinator(TC-事务协调者)：维护全局与分支事务的状态，驱动全局事务提交或回滚
Transaction Manager(TM-事务管理器)：定义全局事务的范围，开启全局事务，提交或回滚全局事务
Resource Manager(RM-资源管理器)：管理分支事务的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚
处理过程
1.TM向TC申请开启一个全局事务，创建成功并生成全局事务的唯一XID
2.XID在微服务的调用链路上下文中传播
3.RM向TC注册分支事务，将其纳入XID对应全局事务的管理
4.TM向TC发起针对XID的全局提交或回滚决议
5.TC调度XID下管辖的全部分支事务完成提交或回滚请求
本地事务使用%Transactional注解，全局事务使用@GlobalTransaction注解
seata-server安装：下载版本；解压到指定目录并修改file.conf配置文件；mysql中建库seata；seata中建表;修改registry.conf配置文件；启动nacos;启动seata;
在某个服务的发起方类上添加注解 @GlobalTransaction
10.spring cloud alibaba snowflake 雪花算法
集群高并发情况下如何保证分布式全局ID唯一生成：雪花算法。
一般解决方案：UUID、数据库自增主键、基于redis生成全局id策略
snowflake(雪花算法)
概述：每秒可产生26万个自增可排序的ID,并按照时间有序生成，生成的Id结果是一个64bit大小的Long类型整数，转成字符串长度为19。分布式系统内不会产生ID碰撞，并且效率较高。
生成64bit数据结构分析：
1bit:1表示负数，0表示正数
41bit:表示时间戳
10bit:记录工作机器id
12bit:序列号，用来记录同毫秒内产生的不同ID
作用：所有生成的id按时间趋势递增；整个分布式系统中不会产生重复ID
实现步骤：引入hutool-all依赖；自定义分布式ID生成类；service中调用即可
优点：ID趋势递增；不依赖第三方数据库，以服务方式部署，稳定性和性能更高；也根据自身业务灵活分配bit位置，相对灵活；
缺点：依赖机器时钟，如果机器时间回拨，则ID会重复。此问题可通过百度的分布式唯一ID生成器UidGenerator或美团的Leaf分布式ID生成系统
11.spring cloud alibaba 参考资料：
https://blog.csdn.net/qq_36903261/category_10087946.html (spring cloud & spring cloud alibaba 系列教程)
https://blog.csdn.net/qq_36903261/article/details/106835279 (spring cloud alibaba nacos 服务注册和配置中心)
https://blog.csdn.net/qq_36903261/article/details/106899215 (spring cloud alibaba sentinel 实现熔断与限流)
https://blog.csdn.net/qq_36903261/article/details/107009285 (spring cloud alibaba seate 处理分布式事务)
https://blog.csdn.net/qq_36903261/article/details/107045717 (spring cloud alibaba snowflake 雪花算法)
springcloud+docker
参考：https://blog.csdn.net/pengjinlong521/article/details/109061839
相关文章
赣公网安备36020002000448号