面试篇：SpringCloud
一、SpringCloud常见的组件有什么？
1、常见微服务功能架构图
2、阿里巴巴SpringCloud常用组件
- 注册中心/配置中心：Nacos
- 负载均衡：Ribbon
- 服务调用：Feign
- 服务保护：Sentinel
- 服务网关：Gateway
二、服务注册和发现是什么意思? Spring Cloud 如何实现服务注册发现?
1、Eureka的作用
如上图，order-service为服务的消费者，user-service为服务的提供者，那么user-service需要将自己的信息如ip地址以及端口号上传的eureka-server注册中心，注册中心保存着user-service的ip和端口信息。
因为order-service也可能被其他服务调用，所以也会上传到注册中心。这样注册中心就保存了两个微服务的IP和端口号。
order-service会定期的从注册中心拉取信息，将其保存到自己服务的本地中，这样就可以通过feign和使用Ribbon利用负载均衡实现对某一实例的远程调用。
user-service会30秒发送一次心跳给注册中心，当user-service中的某一台服务宕机的时候，并且注册中心90秒内未收到心跳，那么就会认为某一台实例宕机了，就会从注册中心中删除宕机的实例。并且user-service会定期从注册中心拉取服务信息，更新自己的本地信息表。
2、服务注册和发现是什么意思? Spring Cloud 如何实现服务注册发现?
- 我们当时项目采用的eureka作为注册中心，这个也是spring cloud体系中的一个核心组件
- 服务注册:服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等
- 服务发现:消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
- 服务监控:服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除
3、nacos与eureka的区别?
首先是nacos的流程：
- 服务分为服务的消费者和服务的提供者，服务的提供者和服务的消费者通过心跳监测机制将当前服务的IP和端口号上传到nacos注册中心，这样nacos就拥有了各服务的IP和端口号。
- 服务消费者会定期从注册中心拉取服务信息，如IP和端口号。注册中心会根据心跳来进行健康监测，并且维护注册中心给的信息。
- 因此在设置ephemeral:false之前，和eureka一模一样。当设置的ephemeral:false就会有所不同。
不同：
- 当设置了ephemeral:false那么注册中心就会主动查询服务的提供者，看有没有实例宕机。
- 如果有实例宕机那么就会将实例宕机的信息主动推送给调用这个服务的服务消费者，服务消费者立马就可以更新自己的本地信息。这样就可以更加的及时。
4、 我看你之前也用过nacos、你能说下nacos与eureka的区别?
Nacos与eureka的共同点 (注册中心)
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别 (注册中心)
- Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式，非临时实例采用主动检测模式
- 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
- Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式Eureka采用AP方式
Nacos还支持了配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因
三、 你们项目负载均衡如何实现的?
1、Ribbon负载均衡流程
首先是order-service调用user-service。那么就会通过url地址发起请求，在这个请求的中间会调用Feign这个组件（内置Ribbon），Feign会从注册中心拉取user-service的IP地址和端口号，然后注册中心会将user-service的IP地址和端口号返回给Feign，这样Feign就知道了user-service的IP地址和端口号。Feign里面内置了Ribbon，因此根据不同的策略进行对user-service的远程调用。Ribbon默认为轮询策略。
2、Ribbon负载均衡策略有哪些？
- RoundRobinRule: 简单轮询服务列表来选择服务器
- WeightedResponseTimeRule: 按照权重来选择服务器，响应时间越长，权重越小
- RandomRule: 随机选择一个可用的服务器
- ZoneAvoidanceRule: 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询
3、如果想自定义负载均衡策略如何实现？
可以自己创建类实现IRule接口，然后再通过配置类或者配置文件配置即可，通过定义IRule实现可以修改负载均衡规则，有两种方式：
全局生效：对于order-service远程调用的所有服务都是用的是RandomRule。被调用方使用- 局部生效：对于调用user-service的服务使用的是RandomRule。调用方使用
四、服务雪崩，熔断降级
1、什么是服务雪崩，怎么解决这个问题?
如果在某一时刻，服务B出现故障（可能就卡在那里了），而这时服务A依然有大量的请求，在调用服务B，那么，由于服务A没办法再短时间内完成处理，新来的请求就会导致线程数不断地增加，这样，CPU的资源很快就会被耗尽。那么就会出现服务雪崩。
2、服务的降级
部分服务不可以
如上图，如果正常调用失败的话，那么就会采用备用的回答来返回结果。
3、Sentinel的熔断
所有服务不可以
如上图，为服务熔断的流程。根据熔断策略，当服务调用失败到一定的次数，就会触发熔断机制，首先打开熔断器，所有请求全部降级处理。当熔断时间结束(Sentinel和Hystrix相同)，会尝试进行放行一次请求查看是否成功，如果失败就继续全部降级处理，直到成功后关闭熔断。
4、Sentinel的熔断策略
慢调用比例
判定为慢调用条件：一次请求的响应时间超过最大RT值，那么就是慢调用。
即：在一个统计时长内，如果请求数目大于最小请求数目，并且被判定为慢调用的请求比例已经超过阈值，将触发熔断
如上图，如果在1000ms内，当请求超过1次请求，并且请求时间超过500ms占每1次请求的100%就会触发5秒熔断
异常比例
如上图，在1秒内当每2次请求中异常比例达到1的时候 ，那么就会触发5秒熔断时间。
异常数
如上图，在1秒内当每2次请求中异常数为1的时候 ，那么就会触发5秒熔断时间。
5、概括
什么是服务雪崩，怎么解决这个问题?
- 服务雪崩:一个服务失败，导致整条链路的服务都失败的情形
- 服务降级:服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑
- 服务熔断:默认关闭，需要手动打开，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求
五、微服务的监控SkyWalking
六、RabbitMQ如何保证消息不丢失
1、RabbitMQ消息丢失的三种情况
- 第一种：生产者弄丢了数据。生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题啥的，都有可能。
- 第二种：RabbitMQ 弄丢了数据。MQ还没有持久化自己挂了
- 第三种：消费端弄丢了数据。刚消费到，还没处理，结果进程挂了，比如重启了。
2、RabbitMQ消息丢失解决方法
3、生产者方案： 使用confirm机制
事务机制和 confirm 机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是 confirm 机制是异步的。
RabbitMQ支持消费者确认机制，即: 消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息，而SpringAMQP则允许配置三种确认模式：
- manual:手动ack，需要在业务代码结束后，调用api发送ack。
- auto: 自动ack;由spring监测listener代码是否出现异常，没有异常则返回ack;抛出异常则返回。
- nacknone: 关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除。
在生产者开启了confirm模式之后，每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq之中，rabbitmq会给你回传一个ack消息，告诉你这个消息发送OK了；如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息失败了，你可以进行重试。而且你可以结合这个机制知道自己在内存里维护每个消息的id，如果超过一定时间还没接收到这个消息的回调，那么你可以进行重发。
对于如何重发消息有以下方法：
- 回调方法即时重发
- 保存到数据库然后定时重发，成功发送后即刻删除表中的数据
4、MQ方案
使用消息持久化来解决RabbitMQ弄丢了数据这个问题。
要想做到消息持久化，必须满足以下三个条件，缺一不可：
- 交换机（Exchange） 设置持久化。
- 队列（Queue） 设置持久化。
- 消息（Message）持久化发送：发送消息设置发送模式deliveryMode=2，代表持久化消息。
5、消费者方案：ACK确认机制
多个消费者同时收取消息，比如消息接收到一半的时候，一个消费者死掉了(逻辑复杂时间太长，超时了或者消费被停机或者网络断开链接)，如何保证消息不丢？
有三种确认方式：
- 自动确认：acknowledge=“none” 默认方式
- 手动确认：acknowledge=“manual”
- 根据异常情况确认：acknowledge=“auto”
其中自动确认是指，当消息一旦被Consumer接收到，则自动确认收到，并将相应 message 从 RabbitMQ 的消息缓存中移除。
但是在实际业务处理中，很可能消息接收到，业务处理出现异常，那么该消息就会丢失。如果设置了手动确认方式，则需要在业务处理成功后，调用channel.basicAck()，手动签收，如果出现异常，则调用channel.basicNack()方法，让其自动重新发送消息。
七、RabbitMQ消息的重复消费问题如何解决的？
造成重复消费的原因：
- 网络抖动
- 消费者挂了
如上图，当consumer将队列中的消息并处理以后准备发送确认ACK的时候，突然宕机了，导致队列没有收到ACK，消费过的消息没有在队列中删除。但是由于有重试机制，导致consumer再次从队列中获取消息，这样就会导致重复消费。
解决方法：
- 每个消息设置一个唯一的ID标识，如支付id，订单id等。
- 当consumer将队列中的消息并处理以后准备发送确认ACK的时候，突然宕机了，导致队列没有收到ACK，消费过的消息没有在队列中删除。但是由于有重试机制，导致consumer再次从队列中获取消息。但是由于有唯一标识，当恢复宕机以后，就重新获取队列消费过的消息，拿到消息以后然后在数据库中进行判断，比如订单id，如果数据库有该订单id就返回ACK，删除队列中的消息，如果没有就进行处理。
- 幂等方案:分布式锁、数据库锁(悲观锁、乐观锁)
八、RabbitMQ中死信交换机?RabbitMQ延迟队列？
延迟队列=死信交换机+TTL
延迟队列:进入队列的消息会被延迟消费的队列
场景:超时订单、限时优惠、定时发布
如上图，应用场景为超时订单，这个时候可以使用延时队列来处理。当下完订单以后，然后将消息发送给延时队列，30分钟以后该消息才可以被支付系统获取去检查是否成功支付。
1、私信交换机
当一个队列中的消息满足下列情况之一时，可以成为死信 (dead letter)：
- 消费者使用basicreject或 basic.nack声明消费失败，并且消息的requeue参数设置为false
- 消息是一个过期消息，超时无人消费
- 要投递的队列消息堆积满了，最早的消息可能成为死信
如果该队列配置了dead-leter-exchange属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机(Dead Letter Exchange，简称DLX)。
如上图，当生产者发布一条消息给交换机并路由到另一个队列的时候，由于消费者拒绝了该消息，就会导致该消息成为死信不能被消费只能进入私信交换机路由到死信队列让其他消费者消费该消息。
2、TTL存活时间
TTL，也就是Time-To-Live。如果一个队列中的消息TTL结束仍未消费，则会变为死信，tl超对分为两种情况:
- 消息所在的队列设置了存活时间。
- 消息本身设置了存活时间。
如上图，生产者发布了一条消息，这个消息的存活时间为5000ms，但是消息队列也设置了存活时间为10000ms，由于RabbitMQ规定二者谁的存活时间短就以谁为准。当TTL到期以后，然后消息回进入死信交换机路由到死信队列，与死信队列绑定的消费者就会消费这条消息。
九、RabbitMQ如果有100万消息堆积在MQ，如何解决(消息堆积怎么解决) ？
如上图，当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。
1、解决消息堆积有三种种思路
- 增加更多消费者，提高消费速度
- 在消费者内开启线程池加快消息处理速度（受CPU的限制）
- 扩大队列容积，提高堆积上限（受磁盘的限制）
对于扩大队列的容积，使用的是惰性队列
2、惰性队列的特征
- 接收到消息后直接存入磁盘而非内存
- 消费者要消费消息时才会从磁盘中读取并加载到内存
- 支持数百万条的消息存储