微服务面试题

ens
64 阅读9分钟

1698242457272.png

Spring Cloud 5大组件有哪些？

通常情况下： Eureka : 注册中心
Ribbon : 负载均衡
Feign : 远程调用
Hystrix : 服务熔断
Zuul/Gateway : 网关

随着SpringCloudAlibba在国内兴起 , 我们项目中使用了一些阿里巴巴的组件
注册中心/配置中心 Nacos
负载均衡 Ribbon
服务调用 Feign
服务保护 sentinel
服务网关 Gateway

微服务技术对比

1698237394804.png

spring cloud 和 spring cloud alibaba的区别

Spring Cloud和Spring Cloud Alibaba都是用于构建微服务架构的框架，但它们有一些区别和不同的特点：

  1. 生态系统:

    • Spring Cloud是Spring团队开发的项目，构建在Spring框架之上，与Spring Boot完美集成。它是一个开源的微服务框架，提供了一系列的库和工具，用于构建微服务应用，如服务发现、服务治理、负载均衡、断路器等。
    • Spring Cloud Alibaba是阿里巴巴公司基于Spring Cloud开发的微服务框架，它在Spring Cloud的基础上增加了一些阿里巴巴生态系统的特性和工具，如Nacos、Sentinel、Dubbo等，用于解决微服务应用中的一些分布式系统问题。

  2. 注册中心:

    • Spring Cloud使用Eureka或Consul等作为服务注册和发现的组件。
    • Spring Cloud Alibaba使用Nacos作为默认的注册中心，Nacos是阿里巴巴开发的服务注册中心和配置中心。

  3. 配置中心:

    • Spring Cloud使用Spring Cloud Config或其他外部配置中心（如Git、Vault等）来集中管理和分发配置。
    • Spring Cloud Alibaba使用Nacos作为配置中心，可以方便地集成配置管理和服务注册。

  4. 限流与熔断:

    • Spring Cloud使用Hystrix来实现断路器和限流等功能。
    • Spring Cloud Alibaba使用Sentinel来实现限流、熔断等功能，Sentinel是阿里巴巴开发的分布式系统的流量控制组件。

  5. RPC通信:

    • Spring Cloud通常使用HTTP/REST作为微服务之间的通信协议。
    • Spring Cloud Alibaba可以集成Dubbo，提供更强大的RPC通信能力。

  6. 社区和支持:

    • Spring Cloud拥有广泛的社区支持，由Spring团队维护，有大量的文档和示例。
    • Spring Cloud Alibaba虽然是开源的，但相对较新，社区规模相对较小，但正在不断发展壮大。

根据项目的需求和现有技术栈，可以选择使用Spring Cloud或Spring Cloud Alibaba。在某些情况下，也可以结合使用它们，以充分利用各自的特性和工具来构建微服务应用。

服务注册和发现是什么意思？Spring Cloud 如何实现服务注册发现？

1698237964754.png

我们当时项目采用的eureka作为注册中心，这个也是spring cloud体系中的一个核心组件

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

nacos与eureka的区别？

1698238102672.png

  • Nacos与eureka的共同点（注册中心）
    1. 都支持服务注册和服务拉取
    2. 都支持服务提供者心跳方式做健康检测
  • Nacos与Eureka的区别（注册中心）
    1. Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
    2. 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
    3. Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
    4. Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
  • Nacos还支持了配置中心，eureka则只有注册中心，也是选择使用nacos的一个重要原因

项目负载均衡如何实现的 ?

微服务的负载均衡主要使用了一个组件Ribbon，比如，我们在使用feign远程调用的过程中，底层的负载均衡就是使用了ribbon

Ribbon负载均衡策略有哪些 ?

  • RoundRobinRule：简单轮询服务列表来选择服务器
  • WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
  • RandomRule：随机选择一个可用的服务器
  • ZoneAvoidanceRule：区域敏感策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认的负载均衡策略，也就是就近选择，如果没有区域的概念，就是轮询策略)

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

1698240600065.png

提供了两种方式：
1，创建类实现IRule接口，可以指定负载均衡策略（全局生效，由spring进行管理，对所有服务的负载均衡都生效）
2，在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略（局部生效，比如只调用user服务则只定义user服务就可以）

什么是服务雪崩，怎么解决这个问题？

服务雪崩：一个服务失败，导致整条链路的服务都失败的情形
解决方案有两种：

  1. 服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑
  2. 服务熔断：默认关闭，需要手动打开，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求

1698241197043.png

1698241231313.png

你们的微服务是怎么监控的？

为什么需要监控？

  • 问题定位
  • 性能分析
  • 服务关系
  • 服务告警

Springboot-admin
prometheus+Grafana
zipkin 链路追踪工具，有代码耦合
skywalking 链路追踪工具

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

1698243096858.png

你们项目中有没有做过限流 ? 怎么做的 ?

  1. 先来介绍业务，什么情况下去做限流，需要说明QPS具体多少
    我们当时有一个活动，到了假期就会抢购优惠券，QPS最高可以达到2000，平时10-50之间，为了应对突发流量，需要做限流

    常规限流，为了防止恶意攻击，保护系统正常运行，我们当时系统能够承受最大的QPS是多少（压测结果）

  2. nginx限流
    控制速率（突发流量），使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量
    控制并发数，限制单个ip的链接数和并发链接的总数

  3. 网关限流
    在spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算法 可以根据ip或路径进行限流，可以设置每秒填充平均速率，和令牌桶总容量

1698242170918.png

1698242205812.png

1698242253687.png

解释一下CAP和BASE

  • CAP 定理(一致性、可用性、分区容错性)
    1. 分布式系统节点通过网络连接，一定会出现分区问题（P）
    2. 当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足
  • BASE理论
    1. 基本可用
    2. 软状态
    3. 最终一致
  • 解决分布式事务的思想和模型：
    1. 最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据（AP）
    2. 强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚,在等待的过程中，系统就处于软可用状态，这时优先保证了cp，达到了数据的强一致性。（CP）

zookeeper 和 eruka 比较

zookeeper是保证cp，不保证a
eruka是保证ap，不保证c
c和a的选择，没有标准的规定，取决于自己的业务

Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”，因为注册服务更重要的是可用性，我们可以接受短期内达不到一致性的状况。

你们采用哪种分布式事务解决方案？

1698291235725.png

image.png

1698289312742.png

1698289476637.png

1698289512741.png

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

  • 幂等: 多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致
  • 如果是新增数据，可以使用数据库的唯一索引
  • 如果是新增或修改数据，没有唯一索引，则：
    • 分布式锁，性能较低，需要注意快速失败和控制锁的粒度
    • 使用token+redis来实现，性能较好
      1. 第一次请求，生成一个唯一token存入redis，返回给前端
      2. 第二次请求，业务处理，携带之前的token，到redis进行验证，如果存在，可以执行业务，删除token；如果不存在，则直接返回，不处理业务

1698292033897.png

1698292079686.png

1698292463438.png

你们项目中使用了什么分布式任务调度

xxl-job解决的问题

  • 解决集群任务的重复执行问题
  • cron表达式定义灵活
  • 定时任务失败了，重试和统计
  • 任务量大，分片执行

xxl-job路由策略有哪些？

1698293706666.png

xxl-job任务执行失败怎么解决？

  • 路由策略选择故障转移，使用健康的实例来执行任务
  • 设置重试次数
  • 查看日志+邮件告警来通知相关负责人解决

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

  • 让多个实例一块去执行（部署集群），路由策略分片广播
  • 在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行

1698293871377.png

avatar
文章
阅读
粉丝