9. Spring Cloud面试题汇总

Java全栈面试题汇总目录-CSDN博客

1. 什么是微服务?

微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分为一组小的服务，每个服务运行在其独立的自己的进程中，服务之间相互协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API），每个服务都围绕着具体的业务进行构建，并且能够被独立的构建在生产环境、类生产环境等。另外，应避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

2. 微服务之间如何独立通讯的?

同步：dobbo通过RPC远程过程调用、Spring Cloud通过REST接口json调用等。

异步：消息队列。

3. Spring Cloud和Dubbo有哪些区别?

最大的区别：

Spring Cloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。

严格来说，这两种方式各有优劣。虽然在一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适。

4. 服务注册和发现是什么意思，Spring Cloud如何实现?

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。Nacos服务注册和发现可以在这种情况下提供帮助。由于所有服务都在Nacos服务器上注册并通过调用Nacos服务器完成查找，因此无需处理服务地点的任何更改和处理。

5. Nacos注册中心原理?

服务提供者、服务消费者、服务发现组件这三者之间的关系大致如下

1. 微服务在启动时，将自己的网络地址等信息注册到服务发现组件(nacos server)中，服务发现组件会存储这些信息
2. 各个微服务与服务发现组件使用一定机制通信（例如在一定的时间内发送心跳包）。服务发现组件若发现与某微服务实例通信正常则保持注册状态(up在线状态)、若长时间无法与某微服务实例通信，就会自动注销（即：删除）该实例
3. 服务消费者可从服务发现组件查询服务提供者的网络地址，并使用该地址调用服务提供者的接口
4. 当微服务网络地址发生变更（例如实例增减或者IP端口发生变化等）时，会重新注册到服务发现组件

6. Feign介绍?

Feign是Netfilx开源的声明式HTTP客户端，Feign是一个http请求调用的轻量级框架，可以以Java接口注解的方式调用Http请求。Spring Cloud引入Feign并且集成了Ribbon实现客户端负载均衡调用。

7. Feign调用原理?

Feign远程调用，核心就是通过一系列的封装和处理，将以JAVA注解的方式定义的远程调用API接口，最终转换成HTTP的请求形式，然后将HTTP的请求的响应结果，解码成JAVA Bean，放回给调用者。

基于重试器发送HTTP请求：Feign内置了一个重试器，当HTTP请求出现IO异常时，Feign会有一个最大尝试次数发送请求。

8. 什么是熔断，什么是服务降级，什么是服务雪崩效应?

服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

雪崩效应是在大型互联网项目中，当某个服务发生宕机时，调用这个服务的其他服务也会发生宕机，大型项目的微服务之间的调用是互通的，这样就会将服务的不可用逐步扩大到各个其他服务中，从而使整个项目的服务宕机崩溃。

9. Nginx与Ribbon的区别?

Nginx是反向代理同时可以实现负载均衡，nginx拦截客户端请求采用负载均衡策略根据upstream配置进行转发，相当于请求通过Nginx服务器进行转发。Ribbon是客户端负载均衡，从注册中心读取目标服务器信息，然后客户端采用轮询策略对服务直接访问，全程在客户端操作。

10. Ribbon底层实现原理?

Ribbon使用discoveryClient从注册中心读取目标服务信息，对同一接口请求进行计数，使用%取余算法获取目标服务集群索引，返回获取到的目标服务信息。

11. 分布式事务产生的背景?

在传统的单体项目中，多个不同的业务逻辑使用的都是同一个数据源，使用的都是同一个事务管理器，所以不会存在事务问题。

在分布式或者微服务架构中，每个服务都有自己的数据源，使用不同事务管理器，如果A服务去调用B服务，B服务执行失败了，A服务的事务和B服务的事务都会回滚，这时候是不存在事务问题的，但是如果A服务B服务执行成功之后出现异常，A服务的事务会回滚，但是B服务的事务不会回滚，此时就存在分布式事务问题。

12. Seata是什么?

Seata是阿里巴巴推出的一款用来解决分布式事务问题的框架，他经过天猫双十一的考验，很有可能成为解决分布式事务问题的主流框架。

13. Seata术语？

Seata分为三个模块，分别是TM、RM和TC(简写)。

TC(transaction Coordinator) 事务协调器，维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM(transaction Manager)事务管理器，定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM(Resource Manager)资源管理器，管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata使用一个XID，代表了一个分布式事务，相当于dubbo中的Request ID。

14. Seata流程？

TM向TC注册全局事务，并生成全局唯一的XID。

RM向TC注册分支事务，并将其纳入该XID对应的全局事务范围。

RM向TC汇报资源的准备状态。

TC汇总所有事务参与者的执行状态，决定分布式事务是全部提交还是全部回滚。

TC通知所有RM提交/回滚事务。

15. Seata分布式事务框架实现原理？

Seata有三个组成部分：

事务协调器TC：协调者

事务管理器TM：发起方

资源管理器RM：参与方

1. 发起方会向协调者申请一个全局事务id，并保存到ThreadLocal中（为什么要保存到ThreadLocal中？弱引用，线程之间不会发生数据冲突）
2. Seata数据源代理发起方和参与方的数据源，将前置镜像和后置镜像写入到undo_log表中，方便后期回滚使用
3. 发起方获取全局事务id，通过改写Feign客户端请求头传入全局事务id
4. 参与方从请求头中获取全局事务id保存到ThreadLocal中，并把该分支注册到SeataServer中
5. 如果没有出现异常，发起方会通知协调者，协调者通知所有分支，通过全局事务id和本地事务id删除undo_log数据，如果出现异常，通过undo_log逆向生成sql语句并执行，然后删除undo_log语句。如果处理业务逻辑代码超时，也会回滚