面试总结之微服务篇

一、概览

1、微服务常用组件

• 微服务给系统开发带来了诸多问题和挑战，如服务间通信和调用的复杂性、数据一致性和事务管理、服务治理和版本管理等，为解决应对这些问题和挑战，各种微服务组件应运而生
• 微服务的常见组件和实现：
  
  

1）注册中心：用于服务的注册和发现，管理微服务的地址信息，常见实现有：

• SpringCloud Netflix：Eureka、Consul
• SpringCloud Alibaba：Nacos
  2）配置中心：用于集中管理微服务的配置信息，可动态修改配置而不需要重启服务，常见的实现有：
• SpringCloud Netflix：SpringCloud Config
• SpringCloud Alibaba：Nacos Config
  3）远程调用：用于在不同的微服务之间进行通信和协作，常见的实现有：
• RESTful API：RestTemplate、OpenFeign、Feign
• RPC（远程过程调用）：Dubbo、gRPC
  4）API网关：作为微服务架构的入口，统一暴露服务，并提高路由、负载均衡、安全认证等功能，常见的实现有：
• Spring Cloud Netflix：Zuul、Gateway
• Spring Cloud Alibaba：Gateway、Apisix等
  5）分布式事务：保证跨多个微服务的一致性和原子性操作，常见的实现有 Spring Cloud Alibaba的Seata
  6）熔断器：用于防止微服务之间的故障扩散，提高系统的容错能力，常见的实现有：
• Spring Cloud Netflix：Hystrix
• Spring Cloud Alibaba：Sentinel、Resilience4j
  7）限流和降级：用于防止微服务过载，对请求进行限制和降级处理，常见的实现有：
• Spring Cloud Netflix：Hystrix
• Spring Cloud Alibaba：Sentinel
  8）分布式追踪和监控：用于跟踪和监控微服务的请求流程和性能指标，常见的实现有：
• Spring Cloud Netflix：Spring Cloud Sleuth + Zipkin
• Spring Cloud Alibaba：SkyWalking、Sentinel Dashboard

二、注册中心

1、注册中心的作用

• 注册中心是用来管理和维护分布式系统中各个服务的地址和元数据的组件，主要用于实现服务的发现和注册功能
  
  注册中心的作用：
• 服务注册：各个服务在启动时向注册中心注册自己的网络地址、服务实例信息和其他相关的元数据，如此，其他服务就可以通过注册中心获取到当前可用的服务列表
• 服务发现：客户端通过向注册中心查询特定服务的注册信息，获得可用的服务实例列表，如此客户端即可根据需要选择合适的服务进行调用，实现了服务间的解耦
• 负载均衡：注册中心可以对同一服务的多个实例进行负载均衡，将请求分发到不同的实例上，提高整体的系统性能和可用性
• 故障恢复：注册中心能够监测和检测服务的状态，当服务实例发生故障或下线时，可以及时地更新注册信息，从而保证服务能够正常工作
• 服务治理：通过注册中心可以进行服务的配置管理、动态扩容/ 缩容，服务路由、灰度发布等操作，实现对服务的动态管理和控制

2、注册中心的实现方案

SpringCloud可以和多种注册中心进行集成，常见的注册中心有Eureka、Consul、Zookeeper、Nacos

• Eureka：Netflix开源的服务发现组件，具有高可用、弹性、可扩展等特点，与Spring Cloud集成良好
• Consul：分布式服务发现和配置管理系统，提供了服务的注册和发现、健康检查、键值存储等功能，并支持多数据源中心部署
• Nacos：阿里开源的动态服务发现、配置管理和服务管理组件，提供了服务注册和发现、配置管理、动态DNS服务等功能
• Zookeeper：Apache开源的分布式协调服务，可用作服务注册中心，具有高可用、一致性、可靠性等特点

3、Eureka、Zookeeper和Nacos的区别

三者最大的区别在于Eureka支持AP，Zookeeper支持CP，而Nacos既支持AP，也支持CP

4、Eureka实现原理

Eureka的实现原理，大致可以从服务的注册与发现、服务的健康检查、服务负载均衡三个三面来看：

• 1）服务注册与发现：当一个服务实例启动时，会向Eureka Server发送注册请求，将其信息登记到注册中心，Eureka Server会将这些信息保存到内存中，并提供REST接口以供其他服务查询，服务消费者可以通过查询服务实例列表来获取可用的服务提供者实例，从而实现服务的发现
• 2）服务健康检查：Eureka通过心跳机制来检测服务实例的健康状态，服务实例会定期向Eureka Server发送心跳，即续约，以表明自己的存货状态，如果Eureka Server在一定时间内没有收到某个服务实例的心跳，则会将其标记为不可用，并从服务列表中移除，下线实例
• 3）服务负载均衡：Eureka客户端在调用其他服务时，会从本地缓存中获取服务的注册信息，如果缓存中没有对应的信息，则会向Eureka Server发送查询请求，Eureka Server会返回一个可用的服务实例列表给客户端，客户端可以使用负载均衡算法选择其中的服务实例进行调用

其他的注册中心，如Nacos、Consul等，在服务注册和发现上，实现原理都大同小异

小结：

• 1）服务治理中的三个角色
• 服务提供者：暴露服务接口，以供其他服务调用
• 服务消费者：调用其他服务提供的接口
• 注册中心：记录并监控微服务各实例的状态，推送服务的变更信息
  注：提供者和消费者不是固定的，往往一个服务既是提供者，也是消费者
• 2）消费者如何得知服务提供者的地址？
  服务提供者会在服务启动时将自身信息记录到注册中心，消费者可以从注册中心订阅和拉取服务消息
• 3）消费者如何得知服务状态变更？
  服务提供者通过心跳机制向注册中心报告自身的健康状态（每隔段时间就向注册中心发送心跳），当心跳异常时，注册中心会将异常服务剔除掉，并通知订阅了该异常服务的消费者
• 4）当提供者有多个实例时，消费者该选择哪个
  消费者可以通过负载均衡算法，从多个实例中选择一个

5、Eureka如何保证高可用

• Eureka Server保证高可用，主要通过如下三个方面来实现：
  1）多实例部署：将多个Eureka Server实例部署在不同的节点上，实现其高可用性，当其中某个实例发生故障时，其他实例仍然可以提供服务，并保存注册信息的一致性
  2）服务注册信息的复制：当一个服务实例向Eureka Server注册时，每个Eureka Server实例都会复制其他实例的注册信息，以保证数据的一致性，当某个Eureka Server实例发生故障时，其他实例可以接管其工作，保证整个系统的正常运行
  3）自我保护机制：当Eureka Server节点在一定时间内没有接收到心跳时，会进入自我保护模式，即Eureka不再剔除注册列表中的服务实例，以保护现有服务实例的注册信息，如此，可以防止由于网路抖动或其他原因导致的误删除

三、配置中心

1、微服务为什么需要配置中心

微服务架构中的每个服务通常都需要一些配置信息，如数据库连接地址、服务端口、日志级别等，这些配置可能因为不同环境、不同部署实例或动态运行时需要进行调整和管理
微服务的实例一般较多，如果每个都逐个去配置，就会造成较大的运维成本，因此，就需要集中化地管理这些配置

2、Nacos配置中心的原理

• 配置中心需要完成配置信息的增删改查
  

• Nacos作为配置中心，其具体的实现大概可以分为如下几个部分：
  1）配置信息存储：Nacos默认使用内嵌数据库 Derby来存储配置信息（也可以采用MySQL等关系型数据库）
  2）注册配置信息：服务启动时，Nacos Client会向Nacos Server注册自己的配置信息（即将配置信息写入存储，并生成版本号）
  3）获取配置信息：服务运行期间，Nacos Client通过API从Nacos Server获取配置信息，Server根据键查找对应的配置信息，并返回给client
  4）监听配置变化：Nacos Client可以通过注册监听器的方式，实现对配置信息的监听，当配置信息发生变化时，Nacos Server会通知已注册的监听器，并触发相应的回调方法

3、Nacos配置中心长轮询机制

• 一般来说，客户端和服务端的交互分为两种：推（Push）和 拉（Pull），Nacos在Pull的基础上，采用了长轮询来进行配置的动态刷新
• 在长轮询模式下，客户端定时向服务端发起请求，检查配置信息是否发生变更，如果没有变更，服务端会hold住该请求，即暂时不返回结果，直到配置发生变化或达到一定的超时时间 ==> 通过长轮询的方式，Nacos客户端能够实时感知配置的变化，并及时获取最新的配置信息，同时，此种方式也降低了服务端的压力，避免了大量的长连接占用内存资源
  
  具体的实现过程如下：
  1）客户端发起Pull请求，服务端检查配置是否有变更，如果没有变更，则设置定时任务，在一段时间后执行，并将当前的客户端连接加入到等待队列中
  2）在等待期间，如果配置发生变化，服务端会立即返回结果给客户端，完成一次"推送"操作
  3）如果在等待期间没有配置变更，等到时间达到预设的超时时间后，服务端会自动返回结果给客户端
  4）如果在等待期间，通过Nacos Dashboard或API对配置进行了修改，会触发事件机制，服务端会遍历等待队列，找到发生变更的配置项对应的客户端连接，并将变更的数据通过连接返回，完成一次"推送"操作

四、远程调用

1、HTTP和RPC的区别

• HTTP（Hypertext Transfer Protocol）：一种应用层协议，强调的是网络通信
• RPC（Remote Producer Call）：一种用于分布式系统之间通信的协议，强调的是服务之间的远程调用

在微服务体系中，基于HTTP风格的远程调用通常使用Feign来实现，基于RPC的远程调用通常使用Dubbo来实现，其他区别如下：

HTTP	RPC
用于传输超文本的协议	用于实现分布式系统中不同节点之间通信的协议
基于请求-响应模式，客户端发送请求，服务端返回响应	基于方法调用模型，客户端调用远程方法并等待结果
基于TCP协议，可使用其他传输层协议如TLS/SSL进行安全加密	可使用多种传输协议，如TCP、UDP等
基于文本，常见的数据格式有JSON、XML等	可使用二进制、JSON、Protocol、Buffers等数据格式
使用RESTful风格的接口进行定义，常见的方法有GET、POST、PUT、DELETE等	使用IDL（接口定义语言）进行接口定义，如Protocol Buffers、Thrift等
支持跨语言通信，可使用HTTP作为通信协议实现不同语言之间的通信	支持跨语言通信，可使用IDL生成不同语言的客户端和服务端代码
较灵活，适用于不同类型的应用场景，如Web开发、API调用等	较高效，适用于需要高性能和低延迟的分布式系统

2、负载均衡算法

常见的负载均衡算法：

• 轮询算法（Round Robin）：按照顺序将请求依次分配给每个后端服务器，循环往复，当请求到达时，负载均衡器按照事先定义的顺序选择下一个服务器，轮询算法适用于后端服务器具有相同的处理能力和性能的场景
• 加权轮询算法（Weighted Round Robin）：在轮询算法的基础上增加了权重的概念，每个后端服务器都被赋予一个权重值，权重值越高，被选中的概率就越大，如此就可以根据服务器的处理能力和性能调整请求的分配比例，使性能较高的服务器能够处理更多的请求
• 随机算法（Random）：将请求随机分配给后端服务器，每个后端服务器具有相等的、被选中的概率，该算法简单且快速，但不能考虑服务器实际的负载情况，适用于后端服务器性能相近但无需考虑请求处理能力的场景
• 加权随机算法（Weighted Random）：在随机算法的基础上引入权重，每个后端服务器被赋予一个权重值，权重值越高，被选中的概率就越大，如此就可以根据服务器的处理能力和性能来调整请求的分配比例
• 最少连接算法（Least Connection）：根据后端服务器当前的连接数来决定请求的分配，负载均衡器会选择当前连接数最少的服务器进行请求分配，以保证后端服务器的负载均衡，此种算法适用于后端服务器的处理能力不同或请求的处理时间不同的场景
• 哈希算法（Hash）：根据请求的某个特定属性（如客户端IP地址、请求URL等）计算哈希值，然后根据哈希值选择相应的后端服务器
  常见的负载均衡器，比如Ribbon、Gateway等，基本都支持如上的负载均衡算法

五、服务容灾

1、服务雪崩

• 在微服务中，如果一个或多个服务出现故障，依赖的服务还不断地发起请求或重试，则这些请求的压力会不断在下游堆积，导致下游服务的负载急剧增加，如此可能会导致故障的进一步加剧，可能会导致级联式的失败，甚至整个系统的崩溃，此即为服务雪崩
• 为了防止服务雪崩，可以采取如下措施：
  1）服务高可用部署：确保各个服务都具备高可用性，通过冗余部署、故障转移等方式来减少单点故障的影响
  2）限流和熔断：对服务之间的请求进行限流和熔断，以防止过多的请求涌入导致后端服务不可用
  3）缓存和降级：合理使用缓存来减轻后端服务的负载压力，并在必要时进行服务降级，保证核心功能的可用性

2、服务熔断和降级

1）什么是服务熔断

• 服务熔断是微服务架构中的容错机制，用于保护系统免受服务故障或异常的影响
• 当某个服务出现故障或异常时，服务熔断可以快速隔离该服务，确保系统稳定可用 ==》通过监控服务的调用情况，当错误率或响应时间超过阈值时，触发熔断机制，后续请求将返回默认值或错误信息，避免资源浪费和系统崩溃
• 服务熔断还支持自动恢复功能，重新尝试对故障服务的请求，确保服务恢复正常后可以继续使用

2）什么是服务降级

• 服务降级也是微服务架构中的容错机制，用于在系统资源紧张或服务故障时保证核心功能的可用性
• 当系统出现异常时，服务降级会主动屏蔽一些非核心或可选的功能，只提供最基本的功能，以确保系统的稳定运行。通过减少对资源的依赖，服务降级可保证系统的可用性和性能，可以根据业务需求和系统状况来制定策略，例如替换耗时操作、返回默认响应、返回静态错误页面等

3）熔断降级的实现方案

常见的服务熔断降级的实现方案有如下几种：

• Spring Cloud的Hystrix，提供线程隔离、服务降级、请求缓存、请求合并等功能，与Spring Cloud其他组件无缝集成，但官方已宣布停⽌维护Hystrix，推荐使⽤Resilience4j代替
• Spring Cloud Alibaba的Sentinel，提供实时监控、流量控制、熔断降级等功能，与Spring Cloud Alibaba生态紧密集成
• Dubbo自带的熔断降级机制，可通过配置实现服务熔断和降级，与Dubbo的RPC框架紧密集成

3、Hystrix如何实现服务容错

Hystrix虽不再更新，但还是非常经典的服务容错开源库，Hystrix提供了多种机制来保护系统：
1）服务熔断（Circuit Breaker）：Hystrix通过设置阈值来监控服务的错误率和响应时间，当错误率或响应时间超过设定的阈值时，熔断器将会打开，后续的请求将不再发送到实际的服务提供方，而是返回预设的默认值或错误信息，从而实现快速隔离故障服务，防止故障扩散，提高系统的稳定性和可用性
2）服务降级（Fallback）：当服务熔断器打开时，Hystrix可以提供一个备用的降级方法或返回默认值，以保证系统可以继续正常运行，开发者可以定义降级逻辑，例如返回缓存数据、执行简化的逻辑或调用其他可靠的服务，以提供有限但可用的功能

import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
 /**
 * 服务降级示例
 **/
 @Service
 public class MyService {
 @HystrixCommand(fallbackMethod = "fallbackMethod")
 public String myServiceMethod() {
   // 实际的服务调⽤逻辑
   // ...
 }
 public String fallbackMethod() {
   // 降级⽅法的逻辑，当服务调⽤失败时会执⾏此⽅法
   // 可以返回默认值或执⾏其他备⽤逻辑
   // ...
    }
 }

3）请求缓存（Request Caching）：Hystrix缓存同一请求的响应结果，当下次请求相同的数据时，直接从缓存中获取，避免重复的网络请求，提高系统的性能和响应速度
4）请求合并（Request Collapsing）：Hystrix将多个并发请求合并为一个批量请求，减少网络开销和资源占用，这在高并发场景下，可以有效地减少请求次数，提高系统性能
5）实时监控和度量（Real-time Monitoring and Metrics）：Hystrix提供了实时监控和度量功能，可以对服务的执行情况进行监控和统计，包括容错率、响应时间、并发量等指标，通过监控数据，可及时地发现和解决服务故障或性能问题
6）线程池隔离（Thread Pool Isolation）：Hystrix将每个依赖服务的请求都放在独立的线程池中执行，避免因某个服务的故障导致整个系统的线程资源耗尽，通过线程池隔离，可提高系统的稳定性和可用性

4、Sentinel如何实现限流

• Sentinel通过动态管理限流规则，根据定义的规则对请求进行限流控制，具体的实现步骤如下：
  1）定义资源：在Sentinel中，资源可以是URL、方法等，用于标识需要进行限流的请求
  2）配置限流规则：在Sentinel的配置文件中定义资源的限流规则，规则可以包括资源名称、限流阈值、限流模式（令牌桶或漏桶）等
  3）监控流量：Sentinel会监控每个资源的流量请求，包括请求的QPS（每秒请求数）、线程数、响应时间等
  4）限流控制：当请求到达时，Sentinel会根据资源的限流规则 判断是否需要进行限流控制，如果请求超过了限流阈值，则可以进行限制、拒绝或进行其他降级处理

4.1、Sentinel采用的限流算法

• Sentinel使用滑动窗口算法来实现限流的（基于时间窗口，将一段时间划分为多个小的时间窗口，并在每个时间窗口内统计请求的数量），通过动态地调整时间窗口的大小和滑动步长，可以较为精确地控制请求的通过速率

4.2、Sentinel如何实现集群限流

未完待续…