SpringCloud学习后相关组件的总结

一、EureKa，Zookeeper，Consul

服务注册与发现 ，前一个需要加@EnableEureKa注解，后两个需要在主启动类要多写一个@EnableDiscoveryClient注解

把服务端注册到注册中心：
服务端配pom，用啥注册中心；写yam，服务端自己的名字，注册点的ip等等
把消费端注册到注册中心：
消费端配pom，用啥注册中心；写yam，消费端自己的名字，注册点的ip等等，服务端消费端应该是同一个注册中心和地址
（消费端调用服务端，直接使用服务端注册的名字，直接访问服务端或者通过消费端访问服务端都可以了）

二、Ribbon

负载均衡（引入EureKa，OpenFeign都自带Ribbon并默认轮询负载均衡），
服务调用（Ribbon+RestTemplate，RestTemplate是对http请求的封装 ）
Ribbon 的负载均衡是本地负载均衡，是在服务消费者身上，在本地自己进行选择调用（我自己选择去哪个）
他会在优先在注册中心里选负载较少的服务端，然后根据指定的策略从服务注册的列表中选一个地址。
（Nginx是服务器负载均衡，所有请求由Nginx进行转发，由服务端实现）（你来告诉我去哪个）

三、OpenFeign

服务调用（替代掉Ribbon+RestTemplate的服务调用）（用在消费端）
主启动类要多写一个@EnableFeignClients注解
创建一个微服务接口，并在接口上添加注解@FeignClient（类似dao），便能实现微服务接口间的调用

四、Hystrix

服务降级，熔断，限流，监控…
主启动类要多写一个@Enablexxx注解
服务降级（服务，消费均可使用，一般在消费）
熔断（失败触发降级，从而用方法，无论）
监控（需要新建另一个模块）

五、Gatewy

服务网关：反向代理，负载均衡（自带Ribbon）
好处：
1、一开始的地址是写死的，如果商品服务挂了我们又得后台手动去改新的商品服务地址，用网关，他可以动态感知注册的服务哪些还活着，自动转发到可用的地址
2、统一鉴权、限流、日志输出等，而不用在具体的服务端去写这些代码

三大核心概念：
路由（由唯一id，url，断言，过滤器共同组成，看yaml配置就懂了），断言（路径匹配，可自行添加要求，符合断言条件就给到指定url路由），过滤器（可以根据逻辑对业务进行处理）
反向代理：
有点像Nginx，通过9527端口这个网关，访问到8001下面的接口
（微服务内部调用不走网关，服务网关只是用于外部访问。访问9527端口并进行断言匹配，判断符合断言后，访问给这个断言所配置的已注册的微服务名称，由这个微服务提供服务）

总结：请求-》网关-》断言（判断是否符合某个url路由规则，不写默认全部符合）-》符合则按照路由规则把请求路由到指定地方（但需要经过一系列的过滤器进行过滤）
难点：1、如何定义好url路由规则；2、怎么写好断言让他判定成功与失败；3、使用哪些Filter

六、Config

配置中心
服务端：可以让服务端连接GitHub，全部使用同一个GitHub上的配置，从而实现统一的配置
客户端：可以让客户端选择一个服务端，使用服务端的配置。从而实现了客户端也使用的GitHub上的配置（但是不能实时更新，需要重启）

七、Bus

消息总线，用于加强Config，实现全局或定点的动态刷新配置（但还是需要发post请求）
全局广播：
1、利用消息总线触发一个客户端/bus/refresh，从而刷新所有客户端配置（不合适：1、破坏了微服务的职责单一性；2、破坏了节点对等性）
2、利用消息总线触发一个服务端ConfigServer的/bus/refresh，从而刷新所有客户端配置（更合适）
定点通知：
只通知其中一部分进行更新，通过添加微服务名称+端口号实现精确通知

八、Stream

消息驱动
1、通过绑定器Binder做中间层，屏蔽底层消息中间件的差异，降低切换成本，统一消息的编程模型
2、默认是分组的，一个消息会被全部的组都获得并消费一次
3、微服务应用应放置在同一个组中，就能保证消息只会被其中一个应用消费一次。不同的组是可以消费的，同一个组内会发生竞争关系，只有其中一个可以消费。

九、Nacos

服务注册和配置中心（=EureKa+Config+Bus并提供Web界面）（自带Ribbon负载均衡）
好处：
注册中心：
1、可用对多个服务统一管理；
2、动态感知服务上线下线；
3、不在需要手动的维护所有的服务访问ip地址列表；
4、单个服务实现负载均衡需要自己搭建，例如使用nginx负载均衡策略，或者基于容器化多实例部署单个服务，在实例之间做负载均衡。。。。。。。。。。很多好处

配置中心：
以往修改了配置文件需要重启服务，而使用配置中心只需要修改配置中心就可用动态刷新
各个服务的配置文件繁琐，进行统一的管理

内容：
支持AP，CP切换（AP是高可用，所有请求都会有相应；CP是一致性，同一时间数据是一致的）
服务注册：
EureKa需要自己建一个微服务，让大家注册进去，而Nacos不需要新建微服务，只需要启动下载的Nacos，其他微服务只要改下yaml就可以注册进Nacos
配置中心：
配置微服务Yaml（选用某一个配置文件）和操作Nacos主界面（crud配置文件）进行配置，自动支持动态刷新
Nacos主界面由命名空间，DataID，分组组成，类似于三层目录的文件夹，简单又方便的切换配置
持久化：
将自带的嵌入式数据库切换为MySQL
集群：
配多个Nacos（可以让一台机子开3个Nacos配3个不同的端口实现），并连接同一个MySQL保证数据一致性，实现Nacos集群

十、Sentinel

熔断、限流和监控等（=Hystrix并提供Web界面）
不需要像Hystrix新建微服务，配置微服务Yaml（添加Sentinel地址等 ）然后启动Sentinel即可
在热点key上那节视频中，讲了使用@SentinelResource注解代替原来HystrixCommand的那个注解实现自定义降级的兜底方法
@SentinelResource处理的是Sentinel控制台配置的违规情况，由blockHandler方法配置兜底处理
Java代码的运行错误是RuntimeException，由
流控：
1、QPS直接失败：可以设置QPS，当一定时间内的请求数量大于设定值是=时直接报错
2、线程数直接失败：可以设置线程数，当请求量多余设置的线程数能操作的请求时报错
3、关联：当A关联B，可以设置关联对象，B满足失败条件时，请求A会失败
4、预热：默认3，可以设置时间和最高值，会慢慢预热到最高值。当一定时间后达到最高值仍不能满足QPS或者线程数就报错
5、排队等待：一次处理不了的多余的请求会排队等待，可以设定时间值，当到达时间值还未处理完就报错
降级：（没有Hystrix的半开半闭状态了）
1、RT：1秒内持续进入5个请求且平均相应时间>阀值-----》触发降级（断路器打开）-----》直到时间窗口（熔断时间）结束-----》关闭降级
2、异常比例：1秒内持续进入5个请求且异常比例>阀值-----》触发降级（断路器打开）-----》直到时间窗口（熔断时间）结束-----》关闭降级
3、异常数：1分钟内异常数>阀值-----》触发降级（断路器打开）-----》直到时间窗口（熔断时间）结束-----》关闭降级
热点Key限流：
@SentinelResource配置方法名，Sentinel中选择那个方法名。
1、可以设置是第几个参数，只要1秒内这个参数的QPS超过设定的次数，马上进行降级处理，最好是自定义一个降级的兜底方法。
（参数P1的QPS大于5时，进行降级）
2、可以在参数例外项那配置特殊的参数，设置参数的类型，值和他的阀值，给这个参数做单独的设置
（参数是String类型的P1的值是5时，QPS大于200时，才进行降级。不等于5时就和平常的上面1的设置一样）
系统规则：
上面是对【某个方法或类】做限制，系统规则则是在最外层，对单台机器上的所有入口流量做限制
包含：Load自适应（装载率保护），CPU阀值保护，平均RT阀值保护，并发线程数阀值保护，QPS阀值保护
@SentinelResource注解详解1：
p127~p129。
@SentinelResource注解详解2：
p132~p134：
fallback兜底管运行异常，负责业务异常的出现（代码写错、出错。相当于服务降级）；
blockHndler兜底管配置违规，负责sentinel控制台配置违规的出现（代码没错，触发了配置的规则。相当于服务熔断）；
可以都配，如果两个同时触发了，按blockHandler处理
【普通服务降级是出现异常会切换到兜底方案并且不会自动恢复过来。但是服务熔断导致的服务降级过一段时间会自动恢复。】
熔断：
【普通服务降级是出现异常会切换到兜底方案并且不会自动恢复过来。但是服务熔断导致的服务降级过一段时间会自动恢复。】
持久化：
（就是把我们做的配置做持久化）
因为保存的都是临时的，每次服务关闭后Sentinel控制台之前的配置就都消失了，这样每次更新都得全部在Sentinel这里再配一次太麻烦，
所以我们需要持久化，无论是用MySQL还是Nacos自带数据库等等都可以。

十一、Seata

分布式事务==