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放行一个请求
热点参数限流则是基于令牌桶算法
以固定的速率生成令牌,存入令牌桶中,如果令牌桶满了以后,多余令牌丢弃
请求进入后,必须先尝试从桶中获取令牌,获取到令牌后才可以被处理
如果令牌桶中没有令牌,则请求等待或丢弃