参考资料

概述,总结的很好

一. 微服务概述

添加链接描述

1. CAP理论

• 一致性(Consistency)
  所有节点访问同一份最新的数据副本
• 可用性(Availability)
  非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
• 分区容错性(Partition Tolerance)
  分布式系统出现网络分区的时候，仍然能够对外提供服务。
• 网络分区
  分布式系统中，多个节点之间的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫 网络分区。
  
• 3选2
  分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。 比如 ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构。
• 为什么不支持CA
  若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。
  选择 CP 还是 AP 的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证 CP 。
  另外，需要补充说明的一点是：如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证。

2. BASE理论

• 概述
  即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。
  如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。因此，如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA。
  因此，AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。
• 基本可用BA
  基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性（响应时间上的损失/系统功能上的损失)。但是，这绝不等价于系统不可用。
• 软状态S
  软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• 最终一致性E
  最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

3. SpringBoot 与 SpringCloud对比

• SpringBoot专注于快速方便得开发单个个体微服务。
• SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
• SpringBoot可以离开SpringCloud独立使用开发项目， 但是SpringCloud离不开SpringBoot，属于依赖的关系.
• SpringBoot专注于快速、方便得开发单个微服务个体，SpringCloud关注全局的服务治理框架。

二. 服务注册：Zookeeper,Eureka,Nacos,Consul

1. Nacos两种健康检查方式？

(在nacos中服务提供者是如何向nacos注册中心续约的)
(对于nacos服务来讲它是如何判断服务实例的状态的)

• agent上报模式 （心跳模式，临时实例）
  客户端（注册在nacos上的其它微服务实例）健康检查。
  客户端通过心跳上报方式告知服务端(nacos注册中心)健康状态；默认心跳间隔5秒；
  nacos会在超过15秒未收到心跳后将实例设置为不健康状态；超过30秒将实例删除；
• 服务端主动检测（非临时实例）
  服务端健康检查。
  nacos主动探知客户端健康状态，默认间隔为20秒；健康检查失败后实例会被标记为不健康，不会被立即删除。

2. nacos中负责负载均衡底层是如何实现的

通过Ribbon实现，Ribbon中定义了负载均衡算法，然后基于这些算法从服务实例中获取一个实例为想要服务方提供服务

3. Nacos原理

Nacos的实现原理
1.客户端provider向nacos server的open api发起调用,把自己的服务地址链接,服务名称注册上去
2.nacos server与服务提供者provider建立心跳机制,用来检测服务状态
3.服务消费者consumer查询出提供服务实例列表
4.并且默认10s去nacos server拉取服务实例列表
5.当服务消费者检测到服务异常,基于UDP协议推送更新
6.服务消费者即可调用了

4. 临时实例和持久化(非临时)实例

临时和持久化的区别主要在健康检查失败后的表现，持久化实例健康检查失败后会被标记成不健康，而临时实例会直接从列表中被删除。

三. 服务调用：Feign

1. Feign的底层原理

首先，如果你对某个接口定义了**@FeignClient注解**，Feign就会针对这个接口创建一个动态代理
接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理，这是核心中的核心
Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址
最后针对这个地址，发起请求、解析响应

2. Feign与OpenFeign的区别

• 他们底层都是内置了Ribbon，去调用注册中心的服务。
• Feign是Netflix公司写的，是SpringCloud组件中的一个轻量级RESTful的HTTP服务客户端，是SpringCloud中的第一代负载均衡客户端。
• OpenFeign是SpringCloud自己研发的，在Feign的基础上支持了Spring
  MVC的注解，如@RequesMapping等等。是SpringCloud中的第二代负载均衡客户端。
• Feign本身不支持Spring MVC的注解，使用Feign的注解定义接口，调用这个接口，就可以调用服务注册中心的服务
• OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。

四. 负载均衡:Ribbon

1. Ribbon支持哪几种负载均衡策略

五. 网关:Gateway,Zuul

1. Gateway工作流程

路由判断：客户端的请求到达网关后，先经过 Gateway Handler Mapping 处理，这里面会做断言（Predicate）判断，看下符合哪个路由规则，这个路由映射后端的某个服务。
请求过滤：然后请求到达 Gateway Web Handler，这里面有很多过滤器，组成过滤器链（Filter Chain），这些过滤器可以对请求进行拦截和修改，比如添加请求头、参数校验等等，有点像净化污水。然后将请求转发到实际的后端服务。这些过滤器逻辑上可以称作 Pre-Filters，Pre 可以理解为“在…之前”。
服务处理：后端服务会对请求进行处理。
响应过滤：后端处理完结果后，返回给 Gateway 的过滤器再次做处理，逻辑上可以称作 Post-Filters，Post 可以理解为“在…之后”。
响应返回：响应经过过滤处理后，返回给客户端。

2. Spring Cloud Gateway 的路由和断言是什么关系？

一对多：一个路由规则可以包含多个断言。如上图中路由 Route1 配置了三个断言 Predicate。
同时满足：如果一个路由规则中有多个断言，则需要同时满足才能匹配。如上图中路由 Route2 配置了两个断言，客户端发送的请求必须同时满足这两个断言，才能匹配路由 Route2。
第一个匹配成功：如果一个请求可以匹配多个路由，则映射第一个匹配成功的路由。如上图所示，客户端发送的请求满足 Route3 和 Route4 的断言，但是 Route3 的配置在配置文件中靠前，所以只会匹配 Route3。

3. Spring Cloud Gateway 如何实现动态路由？

Spring Cloud Gateway 作为微服务的入口，需要尽量避免重启，而现在配置更改需要重启服务不能满足实际生产过程中的动态刷新、实时变更的业务需求，所以我们需要在 Spring Cloud Gateway 运行时动态配置网关。
实现动态路由的方式有很多种，其中一种推荐的方式是基于 Nacos 配置中心来做。简单来说，我们将将路由配置放在 Nacos 中存储，然后写个监听器监听 Nacos 上配置的变化，将变化后的配置更新到 GateWay 应用的进程内。
其实这些复杂的步骤并不需要我们手动实现，通过 Nacos Server 和 Spring Cloud Alibaba Nacos Config 即可实现配置的动态变更。

4. Spring Cloud Gateway 支持限流吗？

Spring Cloud Gateway 自带了限流过滤器，对应的接口是 RateLimiter，RateLimiter 接口只有一个实现类 RedisRateLimiter （基于 Redis + Lua 实现的限流），提供的限流功能比较简易且不易使用。
从 Sentinel 1.6.0 版本开始，Sentinel 引入了 Spring Cloud Gateway 的适配模块，可以提供两种资源维度的限流：route 维度和自定义 API 维度。也就是说，Spring Cloud Gateway 可以结合 Sentinel 实现更强大的网关流量控制。

六. 限流/熔断/服务降级:Hystrix,Sentinel

1. 什么是熔断和降级？

• 熔断机制
  服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。
• 服务降级
  服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。
• 相同点
  目标一致 都是从可用性和可靠性出发，为了防止系统崩溃；
  用户体验类似 最终都让用户体验到的是某些功能暂时不可用；
• 不同点
  触发原因不同：服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑

2. 限流

2.1 常见算法

• 固定窗口计数器算法
  
• 滑动窗口计数器算法
  
• 漏桶算法
  
• 令牌桶算法
  

2.2 单机限流

单机限流可以直接使用 Google Guava 自带的限流工具类 RateLimiter 。 RateLimiter 基于令牌桶算法，可以应对突发流量。

2.3 分布式限流

(1) 借助中间件架限流：可以借助 Sentinel 或者使用 Redis 来自己实现对应的限流逻辑。
(2)网关层限流：比较常用的一种方案，直接在网关层把限流给安排上了。不过，通常网关层限流通常也需要借助到中间件/框架。就比如 Spring Cloud Gateway 的分布式限流实现RedisRateLimiter就是基于 Redis+Lua 来实现的，再比如 Spring Cloud Gateway 还可以整合 Sentinel 来做限流。

3. Hystrix和Sentinel简单介绍

• Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
• Sentinel是阿里中间件团队开源的，面向分布式服务架构的轻量级高可用流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。