SpringCloud常见组件有哪些
注册中心组件：Eureka、Nacos
负载均衡组件：Ribbon
远程调用组件：OpenFeign
网关组件：Zuul、Gateway
服务保护组件：Hystrix、Sentinel
服务配置管理组件：SpringCloudConfig、Nacos
Nacos的服务注册表结构是怎样的？
Nacos采用了数据的分级存储模型，最外层是Namespace，用来隔离环境。然后是Group，用来对服务分组。接下来就是服务（Service）了，一个服务包含多个实例，但是可能处于不同机房，因此Service下有多个集群（Cluster），Cluster下是不同的实例（Instance）。
namespace命名空间
服务、分组
集群、实例
Nacos如何支撑阿里内部数十万服务注册压力？
Nacos内部接收到注册的请求时，不会立即写数据，而是将服务注册的任务放入一个阻塞队列就立即响应给客户端。然后利用线程池读取阻塞队列中的任务，异步来完成实例更新，从而提高并发写能力。
Nacos如何避免并发读写冲突问题？
Nacos在更新实例列表时，会采用CopyOnWrite技术，首先将旧的实例列表拷贝一份，然后更新拷贝的实例列表，再用更新后的拷贝的实例列表来覆盖旧的实例列表。
这样在更新的过程中，就不会对读实例列表的请求产生影响，也不会出现脏读问题了（读旧的实例列表）。
以服务service为锁对象，同一个服务service中多个instance实例，只能串行来完成注册。多个服务service之间互不影响。
Nacos与Eureka的区别有哪些？
| Nacos | Eureka | |
|---|---|---|
| 接口方式 | Nacos对外暴露了Rest风格的API接口，用来实现服务注册、发现等功能 | Eureka都对外暴露了Rest风格的API接口，用来实现服务注册、发现等功能 |
| 实例类型 | Nacos的实例有永久和临时实例之分 | Eureka只支持临时实例 |
| 健康检测 | Nacos对临时实例采用心跳模式检测，对永久实例采用主动请求来检测 | Eureka只支持心跳模式 |
| 服务发现 | Nacos支持定时拉取和订阅推送（当服务发生变更时，通过订阅推送主动通知各个实例）两种模式 | Eureka只支持定时拉取模式（30s） |
Sentinel的线程隔离与Hystix的线程隔离有什么差别?
| Hystix | Sentinel |
|---|---|
| Hystix默认是基于线程池实现的线程隔离 | Sentinel是基于信号量（计数器）实现的线程隔离 |
| 每一个被隔离的业务都要创建一个独立的线程池 | 不用创建线程池 |
| 支持主动超时，支持异步调用 | 不支持主动超时，不支持异步调用 |
| 线程的额外开销比较大，性能一般，但是隔离性更强 | 轻量级，无额外开销，性能较好，但是隔离性一般 |
Sentinel的限流与Gateway的限流有什么差别？
限流算法常见的有三种实现：滑动时间窗口、令牌桶算法、漏桶算法。
Gateway则采用了基于Redis实现的令牌桶算法。
Sentinel限流算法
| 对比项 | 滑动时间窗口 | 令牌桶 | 漏桶 |
|---|---|---|---|
| 能否保证流量曲线平滑 | 不能，但窗口内区间越小，流量控制越平滑 | 基本能，在请求量持续高于令牌生成速度时，流量平滑。在请求量在令牌生成速率上下波动时，无法保证曲线平滑 | 能，所有请求进入桶内，以恒定速率放行，绝对平滑 |
| 能否应对突增流量 | 不能，突增流量，只要高出限流阈值都会被拒绝 | 能，桶内积累的令牌可以应对突增流量 | 能，请求可以增存在桶内 |
| 流量控制精准度 | 低，窗口区间越小，精度越高 | 高 | 高 |
默认限流模式是基于滑动时间窗口算法
滑动时间窗限流算法解决了固定时间窗限流算法的问题。其没有划分固定的时间窗起点与终点，而是将每一次请求的到来时间点作为统计时间窗的终点，起点则是终点向前推时间窗长度的时间点。这种时间窗称为“滑动时间窗”
排队等待的限流模式则基于漏桶算法
将每个请求视作"水滴"放入"漏桶"进行存储；
"漏桶"以固定速率向外"漏"出请求来执行，如果"漏桶"空了则停止"漏水”；
如果"漏桶"满了则多余的"水滴"会被直接丢弃。
可以理解成请求在桶内排队等待，可以处理突发请求，请求处理曲线平滑
比如单机阈值=10，也就是100ms放行一个请求
热点参数限流则是基于令牌桶算法
以固定的速率生成令牌，存入令牌桶中，如果令牌桶满了以后，多余令牌丢弃
请求进入后，必须先尝试从桶中获取令牌，获取到令牌后才可以被处理
如果令牌桶中没有令牌，则请求等待或丢弃
