springcloud

Spring Cloud Eureka/nacos/consul： 服务注册与发现。
Spring Cloud Feign/Openfeign： 服务接口调用。
Spring Cloud Ribbon/loadbanlancer： 客户端负载均衡。
Spring Cloud Hystrix/Resilience4J： 断路器。
Spring Cloud Zuul/gateway： 服务网关。
Spring Cloud Config： 分布式统一配置管理。

CAP理论

CP：Consistency and Partition tolerance 一致性与分区容错度
AP：Availability and Partition tolerance 可用性与分区容错度

一致性（C）：确保分布式系统中的所有数据备份在同一时刻具有相同的值，即所有节点访问同一份最新的数据副本。
可用性（A）：在集群中一部分节点发生故障后，集群整体仍然能够响应客户端的读写请求，保持服务的高可用性。
分区容错性（P）：在分布式系统中，由于网络分区等原因，系统可能会无法与部分节点通信，此时系统必须能够继续提供服务，即使是在部分节点不可用的情况下。

CAP三者是相互矛盾的！

一个分布式系统，不能同时将CAP都很好的满足，只能满足其中两者，所以可以使用AP策略、也可以用CP策略

nacos功能与优势

eureka已经停更了，而且对初学者很不友好，它需要作为一个单独的微服务嵌入到系统中，无法做到解耦

nacos是springcloudalibaba提供的注册中心，它不仅能提供服务注册&发现，还能作为配置中心使用，配置中心的数据可以动态刷新，不需要重启服务，也就是说nacos=consul=eureka+config+bus

服务调用和负载均衡

loadBalancer负载均衡

loadBalancer是Ribbon的替换方案

概念：将用户的请求平摊分配到多个服务商，从而达到系统的高可用。

Nginx是服务器的负载均衡，客户端所有的请求都会交给Nginx，然后由Nginx实现转发请求，即负载均衡由服务端实现。

loadbalance本地负载均衡，在调用微服务接口的时候，会在注册中心（如consul）上获取注册信息服务列表之后缓存到JVM本地，从而在本地实现RPC远程服务调用技术。

工作原理：

loadbalance在工作时分为两步：

第一步：先选择ConsulServer从服务端查询并拉取服务列表，默认轮询调用这些相同的服务。

负载均衡算法有轮询和随机方式

openFeign

Feign是一个声明式的Web服务客户端（Web服务客户端就是Http客户端），让编写Web服务客户端变得非常容易，只需创建一个接口并在接口上添加注解即可。

openFeign优点

使用RestTemplate做远程调用时，每个调用其他微服务的服务，都需要手动编写一个URL，而一个微服务肯定不止被一个其他服务调用，所以经常会编写多次这个URL，比较麻烦。而使用openfeign以后，每个被其他服务调用的微服务接口，只需要在这个接口上加上一个@feignclient注解，就可以暴露给其他服务，不需要每次调用都去声明URL。openfeign可以集成sentinel实现服务降级

openFeign高级特性

1. 可以做超时控制，默认60秒，超时提示错误
2. 重试机制
3. 请求/响应压缩：Spring Cloud OpenFeign支持对请求和响应进行GZIP压缩，以减少通信过程中的性能损耗。
4. openfeign日志打印

Hystrix与Resilience4J

Hystrix已经停止更新了，Resilience4J是Hystrix的替代者，Resilience4J的规范是Spring Cloud Circult Breaker，Resilience4J是落地实现

断路器Circult Breaker只是一套规范和接口，落地实现是Resilience4J

断路器三大状态

close关闭状态

open开启状态

half_open半开状态

断路器状态之间的转换

当熔断器关闭时，所有的请求都会通过熔断器

1. 如果失败率超过设定的阈值，熔断器就会从关闭状态转换到打开状态，这时所有的请求都会被拒绝。

2. 当经过一段时间后，熔断器会从打开状态转换到半开状态，这时仅有一定数量的请求会被放入，并重新计算失败率。

3. 如果失败率超过阈值，则变为打开状态，如果失败率低于阈值，则变为关闭状态。

Resilience4J作用：

服务熔断： 当熔断器关闭时，所有的请求都会通过熔断器，如果失败数量达到阈值，就会打开熔断器，拒绝所有请求访问

服务隔离： 用于限制对下游服务的最大并发数量的限制，当系统的某个服务组件出现故障时，能隔离这些故障并且能进行服务降级

限流：就是限制最大访问流量。系统能提供的最大并发是有限的，同时来的请求又太多，就需要限流。

服务降级和服务熔断的区别

区别： 降级每个请求都会发送过去，而熔断不一定，达到失败率，请求就不会再去发送了。请求出错时熔断返回的是fallback数据，而熔断则是一段时间不会去访问服务提供者。
比如：
①降级：A调B，发送10个请求，即使每个请求都超时，也会去请求B。
②熔断：A调B，发送10个请求，失败率设置为50%，如果5个请求失败，此时失败率到了50%，那么后面的5个请求就不会走到B。

服务隔离的实现方式

Resilience4J提供了两种隔离的实现方式，可以限制并发执行的数量，一种是信号量舱壁隔离，一种是固定线程池舱壁隔离

信号量舱壁隔离：定义一个信号量3，如果并发请求超过信号量3，则返回网络繁忙

固定线程池舱壁隔离：使用有界队列和固定线程池，当线程池存在空闲时，可以开启使用空闲线程来处理请求，线程池没有空闲时，接下来的请求进入等待队列

限流算法

1. 漏斗算法

一个固定容量的漏桶，按照设定常量固定速率流出水滴，类似医院打吊针，不管你源头流量多大，我设定匀速流出。 如果流入水滴超出了桶的容量，则流入的水滴将会溢出了(被丢弃)，而漏桶容量是不变的。

缺点：这里有两个变量，一个是桶的大小，支持流量突发增多时可以存多少的水（burst），另一个是水桶漏洞的大小（rate）。因为漏桶的漏出速率是固定的参数，所以，即使网络中不存在资源冲突（没有发生拥塞），漏桶算法也不能使流突发（burst）到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。

2. 令牌桶算法

向桶中匀速的添加令牌，每一个请求都要去去桶中拿到一个令牌才能执行，如果能拿到令牌就执行，拿不到就进入等待队列

3. 固定时间窗口：在固定的时间窗口内，可以允许固定数量的请求进入。超过数量就拒绝或者排队，等下一个时间段进入。存在bug,如果说按固定时间统计请求数量，0-1秒是一个时间窗口，这个窗口内请求数量没有超过阈值，但是0.5-1.5秒也是一个时间窗口，这个窗口的数量超过了阈值，但这个框框跨了两个固定的时间窗，无法统计，也就无法限制这一段时间超出的请求
4. 滑动时间窗口：滑动时间窗限流算法解决了固定时间窗限流算法的问题。其没有划分固定的时间窗起点与终点，而是将每一次请求的到来时间点作为统计时间窗的终点，起点则是终点向前推时间窗长度的时间点。

sentinel

介绍：alibaba的轻量级的流量控制、熔断降级java库。是alibaba版本的熔断器。 是一个流量控制和熔断降级的框架，可以在分布式系统中实现实时的流量控制，防止系统因流量过大导致系统崩溃和服务降级。

流控模式：

1. 直接：默认的流控模式，当接口达到限流条件时，直接开启限流功能
2. 关联：当关联的资源达到阈值时，就限流自己。当与A关联的资源B达到阈值时，限流A自己
3. 链路：来自不同链路的请求对同一个目标访问时，实施针对性的不同限流措施，比如C请求来访问就限流，D请求来访问就不限流

@SentinelResource注解可以在业务代码上配置编写自定义的服务降级处理和自定义限流返回

@SentinelResource(value = “doActionSentinelResource”,
blockHandler = “doActionBlockHandler”, fallback = “doActionFallback”)

热点规则：热点即经常访问的数据，很多时候我们希望统计或者限制某个热点数据中访问频次最高的TopN数据，并对其访问进行限流或者其它操作，限流模式只支持QPS模式，固定写死了。（这才叫热点）@SentinelResource注解的方法参数索引，0代表第一个参数，1代表第二个参数，以此类推，单机阀值以及统计窗口时长表示在此窗口时间超过阀值就限流。

授权规则：在某些场景下，需要根据调用接口的来源判断是否允许执行本次请求。此时就可以使用Sentinel提供的授权规则来实现，Sentinel的授权规则能够根据请求的来源判断是否允许本次请求通过。在Sentinel的授权规则中，提供了 白名单与黑名单 两种授权类型。白放行、黑禁止

gateway

定义：Gateway是在Spring生态系统之上构建的API网关服务，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。gateway本身也是一个微服务，需要注册进微服务注册中心

作用：反向代理，鉴权，流量控制，熔断，日志监控

三大核心：

Route路由：路由是构件网关的基本模块，它由ID,目标URL,一系列的断言和过滤器组成，如果断言为true则匹配该路由

Predicate断言：参考的是java8的java.util.function.predicate，开发人员是可以匹配HTTP请求中的所有内容（例如请求头或请求参数），如果请求与断言相匹配则进行路由。

Filter过滤：指的是spring框架中gatewayfilter的实例，使用过滤器，可以再请求被路由前或者之后对请求进行修改。

gateway工作流程

客户端向 Spring Cloud Gateway 发出请求。然后在 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。

过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前(Pre)或之后(Post)执行业务逻辑。

在“pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等;

在“post”类型的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控等有着非常重要的作用。

服务降级

服务降级，说白了就是一种服务托底方案，如果服务无法完成正常的调用流程，就使用默认的托底方案来返回数据。

服务熔断

在分布式与微服务系统中，如果下游服务因为访问压力过大导致响应很慢或者一直调用失败时，上游服务为了保证系统的整体可用性，会暂时断开与下游服务的调用连接。这种方式就是熔断。

服务限流

服务限流就是限制进入系统的流量，以防止进入系统的流量过大而压垮系统。其主要的作用就是保护服务节点或者集群后面的数据节点，防止瞬时流量过大使服务和数据崩溃（如前端缓存大量实效），造成不可用；还可用于平滑请求，类似秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行。

限流算法有两种，一种就是简单的请求总量计数，一种就是时间窗口限流（一般为1s），如令牌桶算法和漏牌桶算法就是时间窗口的限流算法。

服务隔离

有点类似于系统的垂直拆分，就按照一定的规则将系统划分成多个服务模块，并且每个服务模块之间是互相独立的，不会存在强依赖的关系。如果某个拆分后的服务发生故障后，能够将故障产生的影响限制在某个具体的服务内，不会向其他服务扩散，自然也就不会对整体服务产生致命的影响。

互联网行业常用的服务隔离方式有：线程池隔离和信号量隔离。

服务超时

整个系统采用分布式和微服务架构后，系统被拆分成一个个小服务，就会存在服务与服务之间互相调用的现象，从而形成一个个调用链。

形成调用链关系的两个服务中，主动调用其他服务接口的服务处于调用链的上游，提供接口供其他服务调用的服务处于调用链的下游。服务超时就是在上游服务调用下游服务时，设置一个最大响应时间，如果超过这个最大响应时间下游服务还未返回结果，则断开上游服务与下游服务之间的请求连接，释放资源。

服务雪崩

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。