SpringCloud框架
一、SpringCloudH版：
1、注册中心-服务注册与发现
CAP理论：
C:Consistency(强一致性)
A:Availability(可用性)
P:Partition tolerance(分区容错)
Eureka -> 维护中
Eureka实现了对分布式微服务的服务注册和服务治理，管理所有注册微服务间的
依赖关系，实现服务注册、服务发现、服务调用、负载均衡、容错的功能。
1 创建Eureka分布式注册中心步骤：
创建项目，修改POM引入相关依赖，创建YAMl文件并配置相关信息，在主启动类上加入@EnableEurekaServer注解，启动主启动类。
2 创建Eureka集群：
创建集群可以实现负载均衡和故障容错。
Eureka服务器之间需要互相注册，所有微服务需要分别注册进入所有Eureka中。
3 Eureka服务发现功能Discovery：
微服务可以通过在主启动类加入@EnableDiscoveryClient实现服务发现功能，获得注册在Eureka上所有微服务得相关信息。
4 Eureka自我保护：
Eureka是AP类型的注册中心，它出厂默认开启自我保护机制。
某时刻某一个微服务不可用了，Eureka不会立刻清理，依旧会对该微服务的信息进行保存。
*
Zookeeper
zookeeper是一个分布式协调工具，可以实现注册中心功能，对注册进入的微服务
有强一致的要求，注册进入的服务节点是临时节点，是CP类微服务注册中心。
直接在官方网站下载压缩包，在本地运行相关命令就可以开启Zookeeper服务器。
*
Consul
Consul是CP类微服务注册中心。
安装Consul要在官方网站下载，下载完成后只有一个consul.exe文件，硬盘路径下双击运行，查看版本信息，可以使用命令consul agent -dev以开发模式启动，通过地址http://localhost:8500访问Consul的首页。
服务发现：提供HTTP和DNS两种发现方式
健康监测：支持多种协议，HTTP、TCP、Docker、Shell脚本定制化
KV存储:key , Value的存储方式
多数据中心:Consul支持多数据中心
可视化Web界面:自带可视化Web界面
*
2、服务调用-负载均衡和服务调用
Ribbon -> 维护中
Ribbon提供客户端本地的负载均衡算法和服务调度。
负载均衡+RestTemplate调用
在服务中心获得注册信息服务列表缓存进本地JVM，从而在本地实现RPC远程服务调用技术。
IRule:根据特定算法从服务列表中选取一个要访问的服务
轮询算法实现原理：
自旋锁+求余
自旋锁实现线程安全的自增，从零开始，每次调用相应的微服务时自增一，与服务中心中注册的微服务服务器数量求余，确定请求发往的服务器，完成负载均衡。
*
OpenFeign
Feign是一个声明式的web服务客户端，让编写web服务客户端变得非常容易，只
需创建一个接口并在接口上添加注解即可。
OpenFeign集成了Ribbon，封装了RestTemplate，使用时很方便，只需要接口和注解。（微服务调用接口+@FeignClient）
OpenFeign可以通过增加注解和修改配置类实现超时控制和日志增强的功能。
*
3、服务降级-断路器
Hystrix -> 停更
Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统
里，多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一
个依赖出现问题的情况下，不会导致整体服务的失败，避免级联故障，以提高分布
式系统的弹性。
Hystrix使用需要直接在服务器的项目中引入依赖，修改配置文件设置降级相
关参数，并使用相关注解。
服务降级：服务器忙，请稍候再试，不让客户端等待并立刻返回一个友好提示，fallback。程序运行异常、超时、服务熔断触发服务降级、线程池/信号量打满会导致服务降级。
服务熔断：类比保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示。
服务的降级->进而熔断->恢复调用链路
服务熔断原理：
当请求数量到达服务降级的阈值时，熔断打开。一段时间之后（默认是5秒），这
个时候断路器是半开状态，会让其中一个请求进行转发。如果请求响应成功，断路
器关闭，若失败，继续开启熔断。
熔断打开：请求不再进行调用当前服务，内部设置时钟一般为MTTR(平均故障处理
时间)，当打开时长达到所设时钟则进入熔断状态。
熔断半开：部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前
服务恢复正常，关闭熔断。
熔断关闭：熔断关闭，不再对服务进行熔断，服务恢复。
接近实时的监控：秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行。
需要创建专门的服务监控hystrixDashboard服务器。项目中引入依赖，修改配置，使用新新注解@EnableHystrixDashboard。
*
resilience4j
与Hystrix类似。
3、服务网关
GateWay
Spring Cloud Gateway 基于异步非阻塞模型开发，优于Zuul基于Servlet
阻塞式处理模型。Zuul对于每一个进来的请求都需要绑定一个线程，这对高并发的
环境很不适用。
Gateway是SpringCloud系统中的网关，所有微服务流量的入口，目标是提供
统一的路由方式且基于Filter链的方式提供了网关基本的功能，如安全、监控指标和
限流。
为了提升性能，使用的Webflux中的reactor-netty响应式编程组件，底层使
用了Netty通讯框架。
能干啥：反向代理、鉴权、流量控制、熔断、日志监控
需要创建专门的网关服务器。项目中引入依赖，修改配置。
默认情况下Gateway会根据注册中心的服务列表，以注册中心上微服务名为路径创建动态路由进行转发，从而实现动态路由的功能。
spring cloud gateway在微服务中自动为我们创建的负载均衡uri。
三大核心概念：
Route(路由)：路由是构建网关的基本模块，它由ID，目标URI，一系列的断言和过滤器组成，如果断言为true则匹配该路由。通过配置可以实现微服务名进行动态路由的功能。
Predicate（断言）：参考的是java8的java.util.function.Predicate开发人员可以匹配HTTP请求中的所有内容（例如请求头或请求参数），如果请求与断言相匹配则进行路由。
Filter(过滤)：指的是Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行修改。
4、服务配置-分布式配置中心+服务总线-消息总线
Config -> 维护中
集中管理配置文件，不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release，运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息，当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置，将配置信息以REST接口的形式暴露，post、curl访问刷新均可。
与Github整合配置，由于SpringCloud Config默认使用Git来存储配置文件。（也有其它方式，比如支持svn和本地文件，但最推荐的还是Git，而且使用的是http/https访问的形式）
需要创建专门的Config服务器，项目中引入依赖，修改配置，绑定GitHub账号。
每次GitHub上的配置文件被修改后，Config会自动从GitHub上下载最新的配置文件，但其它微服务需要手动发送post请求才能更新。
Bus -> 维护中
为了实现自动更新后自动刷新所有微服务配置文件的功能，需要引入Bus服务总线和
消息中间件。
Bus是用来将分布式系统的节点和轻量级消息系统链接起来的框架，它整合了
JAVA的事件处理机制和消息中间件的功能。
Bus支持两种消息代理：RabbitMQ和Kafka
利用消息总线触发一个服务端ConfigServer的/bus/refresh端点,而刷新所有客户端的配置，使用时需要配置进微服务的服务器中。
*
*
*
二、SpringCould alibaba
Nacos:服务注册和配置中心
Nacos，一个更易于构建云原生应用的动态服务发现，配置管理和服务管理中心。
Nacos是注册中心和配置中心的组合。
Nacos = Eureka+Config+Bus
官方文档
从官网下载Nacos，解压安装包，直接运行bin目录下的startup.cmd，命令运行成功后直接访问http://localhost:8848/nacos，默认账号密码都是nacos。
Nacos作为配置中心时，配置修改后，所有的微服务配置也会一并自动更新。
Nacos默认自带的是嵌入式数据库derby，服务器重启后会丢失信息，可以将服务器切换为mysql，实现配置信息的持久化。
*
Sentinuel:实现熔断与限流
Sentinuel与上面的Hystrix类似，可以解决服务雪崩、服务降级、服务熔断、服务
限流等问题，但比Hystrix更好的是它有一个可视化可操作可配置的Web界面。
从官网下载到本地sentinel-dashboard-1.7.0.jar，用java -jar 运行命令，就可以创建出服务器，访问sentinel管理界面http://localhost:8080，默认登录账号密码均为sentinel。
流控模式：
直接（默认） 直接->快速失败
关联 当关联的资源达到阈值时，就限流自己
链路 多个请求调用了同一个微服务
流控效果：
快速失败（默认的流控处理） 直接失败，抛出异常。
预热 公式：阈值除以coldFactor（默认值为3），经过预热时长后才会达到阈值。
排队等待 匀速排队，阈值必须设置为QPS。
降级规则：
Sentinel的断路器是没有半开状态的。
降级策略实战：
RT（平均响应时间）
异常比例
异常数
热点key限流：对某些访问某些资源的请求进行限流。
系统规则：配置全局的服务降级。
@SentinelResource：
1 按资源名称限流+后续处理
2 按照Url地址限流+后续处理
3 客户自定义限流处理逻辑
4 更多注解属性说明：（Sentinel主要有三个核心API）SphU定义资源、Tracer定义统计、ContextUtil定义了上下文
sentinel整合ribbon+openFeign+fallback
fallback为异常方法兜底
blockHandler为符合降级熔断的请求进行兜底
服务降级框架比较
规则持久化：
将规则配置数据保存到Nacos服务器中。
*
Seate:处理分布式事务
一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用，就会产生分布式
事务问题。
Seata是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单
易用的分布式事务服务。
到官网地址下载软件压缩包。
将seata-server-0.9.0.zip解压到指定目录并修改conf目录下的file.conf配置文件。
在mysql5.7数据库新建库seata，在seata库里，使用建表db_store.sql脚本（在\seata-server-0.9.0\seata\conf目录）里面建表。
修改seata-server-0.9.0\seata\conf目录下的registry.conf配置文件。
分布式事务处理过程的-ID+三组件模型
Transaction ID XID：全局唯一的事务ID
3组件概念：
1 Transaction Coordinator(TC)
事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚;
2 Transaction Manager（TM）
控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议;
3 Resource Manager(RM)
控制分支事务，负责分支注册，状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚；
要想分布式事务生效，需要在TM上加上@GlobalTransactional注解。
Seata之原理：
第一阶段，Seata会拦截”业务SQL“
1 解析SQL语义，找到”业务SQL“要更新的业务数据，在业务数据被更新前，将其保存为”before image"。
2 执行“业务SQL”更新业务数据。
3 保存业务数据更新后的快照”after image",最后生成行锁。
第二阶段：回滚或提交
如果需要回滚，Seata就会回滚第一阶段执行的“业务SQL"，还原业务数据。
回滚方式便是用”before image"还原业务数据；但在还原前要首先校验脏写，对比“数据库当前业务数据”和“after image”，如果两份一致，则没有脏写；否则说明有脏写，需要转人工处理。
