JAVA面试微服务篇

SpringCloud

1. SpringCloud的五大组件知道吗？

早期我们一般认为的Spring Cloud五大组件是
Eureka : 注册中心
Ribbon : 负载均衡
Feign : 远程调用
Hystrix : 服务熔断
Zuul/Gateway : 网关
随着SpringCloudAlibaba在国内兴起 , 我们项目中使用了一些阿里巴巴的组件：
注册中心/配置中心 Nacos
负载均衡 Ribbon
服务调用 Feign
服务保护 sentinel
服务网关 Gateway

2. 服务注册(什么是服务注册和发现，并且如何实现？)

我理解的是主要三块大功能，分别是服务注册 、服务发现、服务状态监控。
首先以eureka作为注册中心，这个也是spring cloud体系中的一个核心组件。

• 服务注册服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等。
• 服务发现：消费者向eureka 拉取 服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用。
• 服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中自动剔除。

再以我们熟悉的nacos为例谈谈二者的区别

共同点
Nacos与eureka都支持服务注册和服务拉取，都支持服务提供者心跳方式做
健康检测
Nacos与Eureka的区别（主要是Nacos的非临时实例）
①Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时
实例采用主动检测模式。
②临时实例心跳不正常会被剔除，非临时实例则不会被剔除。
③Nacos支持服务列表变更的消息推送模式，服务列表更新更及时。
④Nacos集群默认采用AP方式（高可用），当集群中存在非临时实例时，采用CP模式（强一致）；Eureka采用AP方式。

还一个Nacos作为配置中心 详情请参考链接 详细介绍Nacos的配置中心

深入研究Nacos底层结构以及执行逻辑回答问题点击链接

3. 负载均衡（3.1你们项目负载均衡如何实现的 ?）

在服务调用过程中的负载均衡一般使用SpringCloud的Ribbon 组件实现 ,Feign的底层已经自动集成了Ribbon , 使用起来非常简单。
当发起远程调用时，ribbon先从注册中心拉取服务地址列表，然后按照一定的路由策略选择一个发起远程调用，一般的调用策略是轮询。

3.2负载均衡的策略有哪些?

• RoundRobinRule：简单轮询服务列表来选择服务器。
  比如有A B两个服务器 二者交替执行 ABABAB····
• WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小。
• RandomRule：随机选择一个可用的服务器。
• ZoneAvoidanceRule：区域敏感策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认)。
  比如：一个服务器在杭州，一个在北京，如果我们在北京使用服务器时，优先使用北京服务器，若北京有多个在使用轮询策略。

3.3 如果想自定义负载均衡策略如何实现 ?

提供了两种方式：
1，创建类实现IRule接口，可以指定负载均衡策略，这个是全局的，对所有
的远程调用都起作用。

@Bean
public IRule randomRule(){
	return new RandomRule();
}

2，在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略，只是对配置的这个服务生效远程调用。

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalance.RandomRule #随机选择

4. 线程隔离

4.1 两种手段（如图）

线程池隔离（Hystix默认采用）

针对某个服务（A,B）开辟对应的线程池（内含10个和5个线程），从服务I过来的用户请求会重新开启A或者B中的一条新线程，当A服务出现故障或者满了，A就会拒绝从服务I过来的请求，但是B还是可以继续访问，起到隔离效果。

信号量隔离（Sentinel默认采用）

其实更加简单，本质是一个计数器，来一个请求就-1，当计数器满了后，拒绝请求，也起到隔离效果。

sentinel的实现方法：在流控按钮中添加即可

对比二者的优缺点：

线程池隔离（低扇出）
优点：支持主动超时（线程池内线程超时会自动剔除），支持异步调用（进来是tomcat线程，远程调用则是独立的线程）
缺点：开启多个线程导致额外开销大，cpu开销大。
信号量隔离（高扇出）
优点：轻量级，无额外的开销。
缺点：不支持以上的主动超时，异步调用。
二者应用场景：当服务I依赖很多服务时（高扇出）适合使用信号量隔离，无需开启许多的独立线程，比如Gateway。

5. 熔断与降级（什么是服务雪崩？如何解决？）

5.1 什么是服务雪崩？

在远程调用的时候，假设如图服务D出现故障，会导致整条链路失败的情况。
一般我们在项目解决的话就是两种方案，第一个是服务降级，第二个是服务熔断，如
果流量太大的话，可以考虑限流。

5.2 服务降级（针对某个handler）

服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃。
一般在实际开发中与feign接口整合，编写降级逻辑。

5.3 熔断降级

熔断降级是解决雪崩的重要手段。其思路就是由断路器统计服务调用的异常比例，满请求比例，如果超出阈值则会熔断该服务。即拦截一切的请求；而当服务恢复时，断路器就会放行该请求。

Hystrix熔断机制

默认关闭，需要手动打开，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求。
打开方式：在引导类上添加注解：@EnableCircuitBreaker

sentinel熔断策略（原理图同上）

• 慢调用
  业务的响应时长RT（response time）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小值，慢调用比例大于设定的阈值，则触发熔断。
  
  解读：RT超过500ms调用是慢调用，统计最近的10000ms内的请求，如果请求量超过10次，并且慢调用比例不低于0.5，则触发熔断，熔断时长为5s。然后进入half-open状态，放行一次请求做测试。
• 异常比例
• 异常数
  异常比例和异常数其实本质一样，这里放一起说。
  统计指定时间内，如果调用次数超过指定请求数，并且出现异常的比例达到了设定的比例阈值（超过指定的异常数），则触发熔断。
  
  解读：统计最近1000ms内，如果请求数量超过10次，并且异常比例不低于0.4（图一）后者为异常数比少于2个，则触发熔断，熔断时长为5s。然后进入half-open状态，放行一次请求做测试。

聪明人已经看出来，没错，服务熔断可视为降级方式的一种！
总之
服务熔断是服务降级的一种特殊情况，是防止服务雪崩而采取的措施。系统发生异常或者延迟或者流量太大，都会触发该服务的服务熔断措施，链路熔断，返回兜底方法。这是对局部的一种保险措施。
服务降级是对系统整体资源的合理分配。区分核心服务和非核心服务。对某个服务的访问延迟时间、异常等情况做出预估并给出兜底方法。这是一种全局性的考量，对系统整体负荷进行管理。

6. 监控

我们项目中采用的skywalking进行监控的
1，skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。
2，我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复。

业务相关

7. 限流（7.1你们项目中有没有做过限流 ? 怎么做的 ?）

我当时做的xx项目，采用就是微服务的架构，因为xx，应该会有突发流量，最大QPS可以达到2000，但是服务支撑不住，我们项目都通过压测最多可以支撑1200QPS。因为我们平时的QPS也就不到100，为了解决这些突发流量，所以采用了限流。

1. 我们当时采用的是spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算法（这里需要结合redis），可以根据ip或路径进行限流，可以设置每秒填充平均速率，和令牌桶总容量。
2. 我们同时采用了Sentinel流控机制中的排队等待，底层使用的是漏桶算法，面对突发流量，相比令牌桶更加的稳定。
   注意：Sentinel内部比较复杂，默认限流模式是基于流动窗口实现，排队等待是基于漏桶，而热点参数则是基于令牌桶。

7.2 这里简单介绍三种限流算法：滑动窗口，令牌桶，漏桶算法

1. 滑动窗口

特点：区间数n越大，区间就越小，越精确。一般情况下阈值不建议设置为服务处理上限，容易垮掉。

2. 令牌桶

特点：以固定的速率生成令牌，假设一秒钟产生3个令牌，第一秒内没有请求，第二秒内来了6个请求，在第二秒内其实qbs达到了6，假设上限qbs为5，服务就会垮掉。因此不应该将桶容量设置为服务处理上限。
代码实现：根据请求之间的时间间隔计算产生多少令牌，然后判断桶中（计数器）是否足够来实现。

3. 漏桶

特点：以请求作为水滴，在桶内排队等待，无论请求波动多大，都会平稳的处理。可以理解为令牌桶的升级版。 sentinel中的排队等待就是使用了漏桶算法。

三种算法对比:

8. CAP和BASE理论

8.1 CAP

主要是在分布式项目下的一个理论。包含了三项，一致性、可用性、分区容错性。

• 一致性(Consistency) 是指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致(强一致性)，不能存在中间状态。
• 可用性(Availability) 是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
• 分区容错性(Partition tolerance) 是指分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发
  生了故障。

8.2 BASE

BASE是CAP理论中AP方案的延伸，核心思想是即使无法做到强一致性（StrongConsistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。它的思想包含三方面：

• Basically Available（基本可用）：基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。
• Soft state（软状态）：即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• Eventually consistent（最终一致性）：强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

9. 分布式事务（9.1 你们采用哪种分布式事务解决方案？）

我们当时是xx项目，主要使用到的seata的AT模式（默认模式）解决的分布式事务
seata的AT模型分为两个阶段：
1、阶段一RM的工作：① 注册分支事务 ② 记录undo-log（数据快照）③
执行业务sql并提交 ④报告事务状态
2、阶段二提交时RM的工作：删除undo-log即可
3、阶段二回滚时RM的工作：根据undo-log恢复数据到更新前
AT模式牺牲了一致性，保证了可用性，不过，它保证的是最终一致性。

10. 分布式服务的接口幂等性如何设计？

幂等性

定义：多次调用方法或者接口不会改变业务的状态，可以保证重复调用的结果和单次调用的结果一致。
一般：查询和删除都是幂等的，只有新增数据或者修改数据时才会出现不是幂等。
解决方法：分布式锁（性能低），使用token+redis（性能好）。

回答：我们当时有一个xx项目的下单操作，采用的token+redis实现的，流程是这样的：
第一次请求，也就是用户打开了商品详情页面，我们会发起一个请求，在后台生成一个唯一token存入redis，key就是用户的id，value就是这个token，同时把这个token返回前端
第二次请求，当用户点击了下单操作会后，会携带之前的token，后台先到redis进行验证，如果存在token，可以执行业务，同时删除token；如果不存在，则直接返回，不处理业务，就保证了同一个token只处理一次业务，就保证了幂等性。

11. 分布式任务调度

11.1 xxl-job路由策略有哪些？

xxl-job提供了很多的路由策略，我们平时用的较多就是：轮询、故障转移、分片广播等等。

11.2 任务执行失败怎么解决？

有这么几个操作
第一：路由策略选择故障转移，优先使用健康的实例来执行任务。
第二：如果还有失败的，我们在创建任务时，可以设置重试次数。
第三：如果还有失败的，就可以查看日志或者配置邮件告警来通知相关负责人解决。

11.3 如果有大数据量的任务同时都需要执行，怎么解决？

让部署多个实例，共同去执行这些批量的任务，其中任务的路由策略是分片广播。
在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行就可以。