目录
SpringCloud的常用组件有哪些:
Nacos的服务注册表结构是怎样的？
Nacos如何支撑数十万服务注册压力？
Nacos如何避免并发读写冲突问题？
Nacos与Eureka的区别有哪些？
Sentinel与Hystix的线程隔离有什么差别
Sentinel的限流与Gateway的限流有什么差别
SpringCloud的常用组件有哪些:
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，常见的springCloud的常用组件如：
服务调用组件：Feign
Feign通过处理注解，将请求模板化，当实际调用的时候，传入参数，根据参数再应用到请求上，进而转化成真正的 Request 请求。通过Feign以及JAVA的动态代理机制，使得Java 开发人员，可以不用通过HTTP框架去封装HTTP请求报文的方式，完成远程服务的HTTP调用。
服务注册组件：eurka，Nacos
服务提供者：提供服务，在启动时，根据服务发布文件中的配置的信息，向注册中心注册自身服务，并向注册中心定期发送心跳汇报
服务消费者：调用服务，在启动时，根据服务引用文件中配置的信息，将注册中心订阅服务，把注册中心返回的服务节点列表缓存在本地内存中，并于服务提供者建立连接
- 当服务提供者节点发生变更时，注册中心会同步变更。服务消费者感知后会刷新本地缓存的服务节点列表
- 服务消费者从本地缓存的服务节点列表中，基于负载均衡算法选择服务提供者的一个节点发起调用
负载均衡组件：nginx，Ribbon
俄罗斯人开发的一个高性能的 HTTP和反向代理服务器。由于Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多，其中包括新浪、网易、腾讯、搜狐等企业的一些门户网站等，在3w以上的高并发环境下，ngnix处理能力相当于apache的10倍。
服务保护组件：sentinel
Sentinel 是面向分布式服务架构的高可用流量防护组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。
网关组件：gateway，Zuul
服务配置管理组件：Nacos，SpringCloudConfig
Nacos的服务注册表结构是怎样的？
Nacos的服务注册表结构与分级存储模型是分不开的，首先，在nacos的分级存储模型中，在Namespace中以Map结构存储着以name_id为key与其结构下的Map类型的键值Group，在Group中的结构中又存储着同样的servcic，在之后，service同样存储同类型的Cluster，在Cluster的键值对中存储着Set类型的实例。
Nacos如何支撑数十万服务注册压力？
Nacos内部接收到注册的请求时，不会立即写数据，而是将服务注册的任务放入一个阻塞队列就立即响应给客户端。然后利用线程池读取阻塞队列中的任务，异步来完成实例更新，从而提高并发写能力。
Nacos如何避免并发读写冲突问题？
Nacos在更新实例列表时，会采用CopyOnWrite技术，首先将旧的实例列表拷贝一份，然后更新拷贝的实例列表，再用更新后的实例列表来覆盖旧的实例列表。
这样在更新的过程中，就不会对读实例列表的请求产生影响，也不会出现脏读问题了。
Nacos与Eureka的区别有哪些？
Nacos与Eureka有相同点，也有不同之处，可以从以下几点来描述：
- 接口方式：Nacos与Eureka都对外暴露了Rest风格的API接口，用来实现服务注册、发现等功能
- 实例类型：Nacos的实例有永久和临时实例之分；而Eureka只支持临时实例
- 健康检测：Nacos对临时实例采用心跳模式检测，对永久实例采用主动请求来检测；Eureka只支持心跳模式
- 服务发现：Nacos支持定时拉取和订阅推送两种模式；Eureka只支持定时拉取模式
-
Sentinel与Hystix的线程隔离有什么差别
-
线程隔离有两种方式实现：
• 线程池隔离（ Hystix 默认采用） • 信号量隔离（ Sentinel 默认采用）
| 优点 | 缺点 | |
| 信号量隔离 | 轻量级，无额外开销 | 不支持主动超时、异步调用 |
| 线程池隔离 | 支持主动超时、异步调用 | 线程的额外开销大 |
Hystix默认是基于线程池实现的线程隔离，每一个被隔离的业务都要创建一个独立的线程池，线程过多会带来额外的CPU开销，性能一般，但是隔离性更强。
Sentinel是基于信号量（计数器）实现的线程隔离，不用创建线程池，性能较好，但是隔离性一般。
Sentinel的限流与Gateway的限流有什么差别
限流算法常见的有三种实现：滑动时间窗口、令牌桶算法、漏桶算法。Gateway则采用了基于Redis实现的令牌桶算法。
而Sentinel内部却比较复杂：
默认限流模式是基于滑动时间窗口算法 排队等待的限流模式则基于漏桶算法 而热点参数限流则是基于令牌桶算法补充说明：
固定窗口计数器算法概念如下：
将时间划分为多个窗口，窗口时间跨度称为 Interval ，本例中为 1000ms ；每个窗口维护一个计数器，每有一次请求就将计数器加一，如果计数器超过了限流阈值，则超出阈值的请求都被丢弃。滑动窗口计数器算法会将一个窗口划分为n个更小的区间，例如
窗口时间跨度 Interval 为 1 秒；区间数量 n = 2 ，则每个小区间时间跨度为 500ms 限流阈值依然为 3 ，时间窗口（ 1 秒）内请求超过阈值时，超出的请求被限流 窗口会根据当前请求所在时间（ currentTime ）移动，窗口范围是从（ currentTime -Interval ）之后的第一个时区开始，到 currentTime 所在时区结束。令牌桶算法说明：
l 以固定的速率生成令牌，存入令牌桶中，如果令牌桶满了以后，多余令牌丢弃 l 请求进入后，必须先尝试从桶中获取令牌，获取到令牌后才可以被处理 l 如果令牌桶中没有令牌，则请求等待或丢弃漏桶算法说明：
将每个请求视作"水滴"放入"漏桶"进行存储；
漏桶 " 以固定速率向外 " 漏 " 出请求来执行，如果 " 漏桶 " 空了则停止 " 漏水”； 如果 " 漏桶 " 满了则多余的 " 水滴 " 会被直接丢弃。 可以理解成请求在桶内排队等待对比图如下：
