SpringCloud微服务常见问题

1 微服务

返回面试宝典

问题1 SpringCloud常见组件有哪些？

SpringCloud包含的组件很多，有很多功能是重复的，其中最常见的组件包括：

• 注册中心组件：Eureka、Nacos等；
• 负载均衡组件：Ribbon；
• 远程调用组件：OpenFeign；
• 网关组件：Zuul、Gateway；
• 服务保护组件：Hystrix、Sentinel；
• 服务配置管理组件：SpringCloudConfig、Nacos；

问题2 Nacos的服务注册表结构是怎样的？

Nacos采用了数据分级存储模型，最外层是namespace，用来隔离环境。然后是Group，用来对服务分组。接下来就是服务（Service）了，一个服务包含多个实例，但是可能处于不同机房，因此Service下有多个集群（Cluster），集群下是不同的服务实例。
对应到Java代码中，Nacos采用了一个多层的Map来表示。结构为Map>，其中最外层Map的key就是namespaceId，值是一个Map。内层Map的key是group拼接serviceName，值是Service对象。Service对象内部又是一个Map，key是集群名称，值是Cluster对象。而Cluster对象内部维护了Instance的集合。

问题3 Nacos如何支撑阿里内部数十万服务注册压力？

Nacos内部接收到注册的请求时，不会立即写数据，而是将服务注册的任务放到一个阻塞队列就立即响应客户端。然后利用线程池读取阻塞队列的任务，异步来完成实例更新，从而提高并发写能力。

问题4 Nacos如何避免并发写冲突问题？

Nacos在更新实例列表时，会采用CopyOnWrite技术，首先将旧的实例列表拷贝一份，然后更新拷贝的实例列表，再用更新后的实例列表来覆盖旧的实例列表。这样在更新的过程中，就不会对读实例列表的请求产生影响，也不会出现脏读问题了。

问题5 Nacos与Eureka的区别有哪些？

• 接口方式：Nacos与Eureka都对外暴露了Rest风格的API接口，用来实现服务注册、发现等功能
• 实例类型：Nacos的实例有永久和临时实例之分；而Eureka只支持临时实例
• 健康检测：Nacos对临时实例采用心跳模式检测，对永久实例采用主动请求来检测；Eureka只支持心跳模式
• 服务发现：Nacos支持定时拉取和订阅推送两种模式；Eureka只支持定时拉取模式

问题6 Sentinel的限流与Gateway的限流有什么差别？

限流算法常见的有三种实现：滑动时间窗口、令牌桶算法、漏桶算法。

Gateway则采用了基于Redis实现的令牌桶算法。

而Sentinel内部却比较复杂：

• 默认限流模式是基于滑动时间窗口算法
• 排队等待的限流模式则基于漏桶算法
• 而热点参数限流则是基于令牌桶算法

问题7 Sentinel的线程隔离与Hystix的线程隔离有什么差别?

Hystix默认是基于线程池实现的线程隔离，每一个被隔离的业务都要创建一个独立的线程池，线程过多会带来额外的CPU开销，性能一般，但是隔离性更强。

Sentinel是基于信号量（计数器）实现的线程隔离，不用创建线程池，性能较好，但是隔离性一般。

问题8 Hystrix是怎么实现熔断的？

1.8.1 重点概念

限流： 对并发访问的流量进行限制。主要行为有：限制并发数量、服务降级、分级请求（部分用户可以请求）、延时处理（削峰填谷），主要方式有：计数器（简单的流量技术+1）、漏斗模式（使用队列，队列长度限制）、令牌桶（先从令牌桶获取令牌才能访问）等。
降级： 在流量高峰的时候，为了保全重要的服务，停掉一些不重要的服务，从而释放出更多资源。比如退款系统在流量高峰期，保障退款功能可用，停掉退款查询功能。
熔断： 下游系统故障或者阻塞的时候，自动降级服务，快速返回错误。
熔断是降级的一种方式，降级又是限流的一种方式。

1.8.2 execute()、queue()、observe()、toObservable()方法解释

HystrixCommand实现了4个方法、HystrixObservableCommand实现了后面两个方法。
execute (): 同步执行，从依赖的服务返回一个单一的结果对象，或是在发生错误的时候抛出异常。
queue (): 异步执行，直接返回一个Future对象，其中包含了服务执行结束时要返回的单一结果对象。
observe () :返回Observable对象，它代表了操作的多个结果，它是一个Hot Observable。
toObservable(): 同样会返回Observable对象，也代表了操作的多个结果，但它返回的是 一个Cold Observable。

1.8.3 Hystrix处理流程

1. 创建HystrixCommand或HystrixObservableCommand对象
2. 执行execute()、queue()、observe()、toObservable()命令
3. 如果请求缓存功能被起用，并且命中缓存，缓存的结果会立即以Observable对象的形式返回
4. 检查断路器是不是打开的状态，如果是打开的状态，直接执行getFallback()
5. 如果和命令相关的线程池/请求队列/信号量 已经被占满，hystrix不会执行这个命令，直接执行getFallback()
6. 执行HystrixCommand.run()或HystrixObservableCommand.construct()，如果这两个方法执行失败或者超时，则执行getFallback()
7. Hystrix会将“成功”、“失败”、“拒绝”、“超时” 等信息报告给断路器，而断路器会维护一组计数器来统计这些数据。断路器会使用这些统计数据来决定是否要将断路器打开，来对某个依赖服务的请求进行“熔断/短路”，直到恢复期结束。若在恢复期结束后，根据统计数据判断如果还是未达到健康指标，就再次 “熔断/短路”。
8. 当Hystrix命令执行成功之后，它会将处理结果直接返回或是以Observable 的形式返回。