2024最新：精选33道微服务面试题详解与实用指南，助力提升技术能力与面试竞争力

1. 什么是微服务？

微服务（Microservices）是一种软件架构风格，它将大型应用程序拆分为一组小型、自治且松耦合的服务。每个微服务负责特定的业务功能，并通过轻量级通信机制（例如HTTP）进行互相协作。微服务可以独立开发、部署和扩展，从而提升应用程序的灵活性、可扩展性和可维护性。

微服务架构通常经历以下演进路径：单体式 -> 服务化 -> 微服务。

• 单体服务（Monolithic Service）是传统的软件架构方式，将整个应用作为一个紧耦合的单元开发和部署。单体服务由多个模块构成，这些模块共享同一个数据库和代码库。随着应用程序规模的扩展，单体服务往往变得庞大且复杂，带来维护和扩展的困难。

• 随着单体服务的规模增大，维护的困难愈发显著，逐渐演变为面向服务的架构（SOA）。SOA强调将应用拆分为独立服务，通过标准化接口进行通信，关注服务的重用性和组合性，但未明确服务的大小。

• 微服务则是在SOA的基础上进一步发展，注重将应用拆分为小型、自治且松耦合的服务，每个服务专注于特定的业务功能。这种架构模式使得应用程序更加灵活、可扩展和可维护。

架构演进简图

微服务与单体服务的主要区别在于规模和部署方式。微服务将应用拆分为更小的自治服务单元，每个服务具有独立的数据库和代码库，能够独立开发、测试、部署和扩展，从而提升系统的灵活性、可维护性、可扩展性和容错性。

2. 微服务带来了哪些挑战？

尽管微服务架构有诸多优点，但在决定是否采用微服务架构或拆分现有单体服务时，需要考虑服务拆分后可能面临的一些挑战和问题：

微服务带来的挑战具体包括：

1. 系统复杂性增加：服务拆分后，整体系统复杂性上升，需要处理服务之间的通信、部署、监控和维护等方面的难题。
2. 服务间通信开销：微服务通过网络进行通信，数据交互需要额外的网络和序列化开销，可能造成性能瓶颈与系统延迟。
3. 数据一致性与事务管理：每个微服务都有独立的数据存储，数据一致性和跨服务的事务管理变得复杂，需额外处理分布式事务和数据同步问题。
4. 部署与运维复杂性：微服务架构涉及多个独立部署的服务，对部署、监控和容错机制的要求更高，需要合适的部署管道与自动化工具。
5. 团队沟通与协作成本：每个微服务由专门团队负责，可能增加团队之间的沟通和协作成本，需要高效沟通渠道和协作机制确保服务协调一致。
6. 服务治理与版本管理：随着微服务数量的增加，服务治理和版本管理将变得更为复杂，包括服务注册发现、负载均衡、监控和故障处理等。
7. 分布式系统的复杂性：微服务架构构建和管理分布式系统，面临固有的挑战，如网络延迟、分布式一致性和容错性。

总而言之，采用微服务架构需权衡以上问题和挑战，具体选择相应的技术方案，在许多情况下，单体架构即可满足需求，不必为了微服务而微服务。

3. 现在有哪些流行的微服务解决方案？

当前，最主流的微服务开源解决方案主要有以下三种：

1. Dubbo：

Dubbo工作原理图-来源官网

• Dubbo 是由阿里巴巴开发并于2011年开源的高性能、轻量级Java微服务框架。它提供服务注册与发现、负载均衡、容错和分布式调用等功能，曾一度停止维护，但最近几年又重新开始迭代，推出了Dubbo3。
• Dubbo采用基于RPC（远程过程调用）的通信模型，具备高性能与可扩展性，支持多种传输协议（如TCP、HTTP、Redis）和序列化方式（如JSON、Hessian、Protobuf），可按需配置。
• Dubbo更被视为高性能的RPC框架，部分服务治理功能依赖第三方组件实现，如ZooKeeper、Apollo等。

2. Spring Cloud Netflix：

• Spring Cloud Netflix 是 Spring Cloud 的一个子项目，结合了多个开源Netflix组件。然而，自2018年起，Netflix停止对其OSS项目（包括Eureka、Hystrix等）的维护更新，Spring Cloud Netflix也逐渐进入维护模式。
• 该项目涵盖流行的Netflix组件，如Eureka（服务注册与发现）、Ribbon（客户端负载均衡）、Hystrix（断路器）、Zuul（API网关）等，均经过大规模实践验证，具备高度可扩展性。

3. Spring Cloud Alibaba：

• Spring Cloud Alibaba 是 Spring Cloud 的另一个子项目，与阿里巴巴的分布式应用开发框架相关联，提供与Alibaba生态系统集成的解决方案。
• 项目包含Nacos（服务注册与发现、配置管理）、Sentinel（流量控制、熔断降级）、RocketMQ（消息队列）等组件，且与Alibaba Cloud紧密集成，为构建基于Spring Cloud的微服务架构提供丰富选项。
• 需要注意的是，Spring Cloud Alibaba项目的发起人已经转去腾讯并发起了Spring Cloud Tencent项目，社区发展存在隐忧。

这三种方案有什么区别吗？

三种方案的主要区别如下：

在面试中，微服务一般主要讨论Spring Cloud Netflix，其次是Spring Cloud Alibaba，而Dubbo通常作为RPC框架来询问。

4. 说下微服务有哪些组件？

微服务带来了诸多挑战，比如服务调用的复杂性、分布式事务处理、服务的动态管理等。为了更好地应对这些问题，各种微服务治理组件应运而生，成为微服务架构的基石和支撑。

微服务的各个组件和常见实现：

1. 注册中心：用于服务的注册与发现，管理微服务的地址信息。常见实现包括：

   • Spring Cloud Netflix：Eureka、Consul
   • Spring Cloud Alibaba：Nacos

2. 配置中心：用于集中管理微服务的配置信息，可动态修改配置而不需要重启服务。常见实现包括：

   • Spring Cloud Netflix：Spring Cloud Config
   • Spring Cloud Alibaba：Nacos Config

3. 远程调用：用于在不同微服务之间进行通信与协作。常见实现包括：

   • RESTful API：如RestTemplate、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

5. 注册中心是用来干什么的？

注册中心用于管理和维护分布式系统中各个服务的地址和元数据信息，主要实现服务发现和服务注册功能。

注册中心的作用总结：

1. 服务注册：各服务在启动时向注册中心注册自己的网络地址、服务实例信息及其他相关元数据，便于其他服务获取当前可用的服务列表。
2. 服务发现：客户端可向注册中心查询特定服务的注册信息，获取可用的服务实例列表，进而选择合适的服务进行调用，实现服务间的解耦。
3. 负载均衡：注册中心对同一服务的多个实例进行负载均衡，将请求分发到不同实例，提高系统性能和可用性。
4. 故障恢复：注册中心监测服务的状态，当服务实例故障或下线时，及时更新注册信息，确保服务正常工作。
5. 服务治理：通过注册中心可进行服务的配置管理、动态扩缩容、服务路由、灰度发布等操作，实现对服务的动态管理和控制。

6. Spring Cloud可以选择哪些注册中心？

Spring Cloud支持与多种注册中心的集成，常见的注册中心包括：

1. Eureka：Netflix开源的服务发现框架，具备高可用、弹性、可扩展等特点，与Spring Cloud集成良好。
2. Consul：HashiCorp开发的分布式服务发现和配置管理系统，提供服务注册、发现、健康检查、键值存储等功能，支持多数据中心部署。
3. ZooKeeper：Apache基金会开源的分布式协调服务，适用于服务注册中心，具有高可用、一致性和可靠性等特点。
4. Nacos：阿里巴巴开源的动态服务发现、配置管理和服务管理平台，提供服务注册与发现、配置管理、动态DNS服务等功能。
5. etcd：CoreOS开源的分布式键值存储系统，可作为服务注册中心，具备高可用、强一致性和分布式复制特性。

7. 说下Eureka、ZooKeeper、Nacos的区别？

可以看到，Eureka和ZooKeeper的最大区别在于一个支持AP，一个支持CP，而Nacos则兼具两者的特性。

8. Eureka实现原理了解吗？

Eureka原理示意图

Eureka的实现原理主要包括：

1. 服务注册与发现：服务实例启动时，向Eureka Server发送注册请求，将自身信息注册到注册中心。Eureka Server将这些信息保存在内存中，并提供REST接口供其他服务查询，服务消费者通过查询服务实例列表获取可用的服务提供者实例，实现服务发现。
2. 服务健康检查：Eureka通过心跳机制监测服务实例的健康状态。服务实例定期向Eureka Server发送心跳，表明其存活状态。在一段时间内未收到某服务实例的心跳，Eureka Server将其标记为不可用并从服务列表中移除。
3. 服务负载均衡：Eureka客户端在调用其他服务时，从本地缓存中获取服务注册信息，若缓存无此信息则向Eureka Server发送查询请求，获得可用的服务实例列表，客户端可使用负载均衡算法选择一个进行调用。

9. Eureka Server怎么保证高可用？

Eureka Server通过以下三个方面保障高可用性：

Eureka Server

1. 多实例部署：通过在不同节点部署多个Eureka Server实例，确保某个实例故障时，其他实例仍能提供服务，并保持注册信息一致。
2. 服务注册信息的复制：服务实例注册时，所有Eureka Server实例都会复制其他实例的注册信息，以确保数据的一致性。若某Eureka Server实例出现故障，其他实例能接管其工作，保证系统正常运行。
3. 自我保护机制：Eureka支持自我保护机制。当Eureka Server节点在一定时间内未接收到心跳，它将进入自我保护模式，此时不再剔除注册表中的服务实例，以维护现有注册信息，防止因网络抖动等误剔除，提高系统稳定性。

10. 为什么微服务需要配置中心？

在微服务架构中，每个服务通常需要一些配置信息，例如数据库连接地址、服务端口、日志级别等。由于服务实例数量庞大，逐一管理这些配置信息的运维成本极高，因此集中化的配置中心显得尤为重要。

11. Spring Cloud可以选择哪些配置中心？

与注册中心类似，Spring Cloud也支持多种配置中心的集成。常见的选型包括：

1. Spring Cloud Config：官方推荐的配置中心，支持将配置文件存储在Git、SVN等版本控制系统中，并提供RESTful API进行访问和管理。
2. ZooKeeper：开源的分布式协调服务，也可用作配置中心，具备高可用性、一致性及通知机制特性。
3. Consul：开源的分布式服务发现和配置管理工具，也可用作配置中心，支持多种配置文件格式，具备健康检查、故障转移和动态变更等功能。
4. Etcd：分布式键值存储系统，可用作配置中心，使用Raft算法确保一致性。
5. Apollo：携程开源的配置中心，支持多种语言和框架，提供细粒度的配置权限管理和通知功能。
6. Nacos：阿里巴巴开源的服务发现、配置管理和服务管理平台，支持动态配置管理、服务健康监测等功能。

12. Nacos配置中心的原理了解吗？

配置中心的核心是配置管理的CRUD操作。

具体实现流程如下：

1. 配置信息存储：Nacos默认使用内嵌数据库Derby来存储配置信息，也可以使用MySQL等关系型数据库。
2. 注册配置信息：服务启动时，Nacos Client向Nacos Server注册配置信息，将其写入存储并生成版本号。
3. 获取配置信息：服务运行时，Nacos Client通过API从Nacos Server获取配置信息，Server根据键查找对应数据并返回给Client。
4. 监听配置变化：Nacos Client可注册监听器，实现对配置信息的监听，发生变化时，Nacos Server会通知注册的监听器，触发相应的回调方法。

13. Nacos配置中心长轮询机制是什么？

Nacos在Pull机制的基础上，采用长轮询来动态刷新配置。

在长轮询模式下，客户端定期向服务器发起请求检查配置是否发生变更。如无变更，服务器会“hold”住请求，不返回结果，直至发生配置变化或超时时间到达。

具体过程如下：

1. 客户端发起Pull请求，服务器检查是否有变更。如无变更，设置定时任务并将当前连接加入等待队列。
2. 若配置发生变更，服务器立即返回结果给客户端。
3. 若在等待期间未发生变更，超时后服务器返回结果。
4. 若通过Nacos Dashboard或API修改配置，将触发事件机制，服务器遍历等待队列，寻找需变更配置项的客户端连接并返回变更数据。

通过长轮询，Nacos客户端能够实时感知配置变化，并及时获取最新配置信息。这一方式还降低了服务器压力，避免了大量长连接占用内存资源。

14. 能说下HTTP和RPC的区别吗？

严格来说，HTTP和RPC并不在同一个层面。

• HTTP（超文本传输协议）：应用层协议，主要用于网络通信；
• RPC（远程过程调用）：用于分布式系统间通信的协议，着重于服务之间的远程调用。

一些RPC框架（如gRPC）底层传输协议通常也是HTTP2，Dubbo3也兼容gRPC，使用HTTP2作为传输层协议。

在微服务体系中，基于HTTP的远程调用通常使用Feign框架，而基于RPC的远程调用则使用Dubbo框架。

15. Feign和Dubbo的区别是什么？

这两个框架适合进行直接比较：

需要注意的是，Feign与Dubbo并不互斥，Dubbo可使用HTTP协议作为通信方式，Feign也可集成RPC协议进行远程调用。选择哪种方式依赖于具体业务需求及技术栈选择。

16. 说一下Feign？

Feign是一个声明式Web服务客户端，简化基于HTTP远程服务的开发。

Feign是在RestTemplate 和 Ribbon的基础上进一步封装的，通过RestTemplate实现HTTP调用，使用Ribbon实现负载均衡。

Feign的主要特点与功能包括：

1. 声明式API：开发者可使用简单注解定义远程服务访问，指定URL、HTTP方法、请求参数、请求头等信息，使远程调用直观易懂。

   @FeignClient(name = "example", url = "https://api.example.com")
   public interface ExampleService {
       @GetMapping("/endpoint")
       String getEndpointData();
   }
   

2. 集成负载均衡：Feign集成Ribbon负载均衡器，实现客户端负载均衡，根据服务名和可用实例进行动态路由，分发请求到不同服务实例，提高系统可用性和可伸缩性。

3. 容错机制：Feign支持集成Hystrix容错框架，为远程服务调用提供容错和断路器功能。在远程服务不可用或响应时间过长时，Feign快速失败并返回预设响应结果，避免系统级联故障。

17. 为什么Feign第一次调用耗时很长？

主要原因在于Ribbon的懒加载机制，首次调用时Feign触发Ribbon的加载过程，包括从服务注册中心获取服务列表、建立连接池等，这些步骤增加了首次调用的耗时。

解决方案是在应用启动时预热Feign客户端，自动触发一次无关紧要的调用，以提前加载Ribbon及相关组件。这样相当于完成了首次调用的预热。

18. Feign怎么实现认证传递？

常见做法是使用拦截器传递认证信息。可以通过实现RequestInterceptor接口，定义拦截器，在拦截器中将认证信息添加到请求头中，如下所示：

@Configuration
public class FeignClientConfig {
    @Bean
    public RequestInterceptor requestInterceptor() {
        return new RequestInterceptor() {
            @Override
            public void apply(RequestTemplate template) {
                // 添加认证信息到请求头
                template.header("Authorization", "Bearer " + getToken());
            }
        };
    }
    private String getToken() {
        // 获取认证信息的逻辑
        return "your_token";
    }
}

19. Feign怎么做负载均衡？使用Ribbon吗？

在Feign中，负载均衡通过集成Ribbon实现。Ribbon是Netflix开源的客户端负载均衡器，能够与Feign无缝集成，为Feign提供负载均衡能力。

Ribbon通过向服务注册中心获取可用服务列表并通过负载均衡算法选择合适的服务实例进行请求转发，达成客户端负载均衡。

20. 说说有哪些负载均衡算法？

常见负载均衡算法如下：

1. 轮询算法（Round Robin）：请求依次分配给每个后端服务器，适用于后端服务器处理能力相同的场景。
2. 加权轮询算法（Weighted Round Robin）：为每台后端服务器分配权重，权重越高被选中概率越大，适合处理能力不平衡的情况。
3. 随机算法（Random）：请求随机分配给后端服务器，适用于服务器性能相近且无需考虑处理能力的场景。
4. 加权随机算法（Weighted Random）：结合随机算法与权重概念，性能较高的服务器处理更多请求。
5. 最少连接算法（Least Connection）：根据后端服务器当前连接数，选择连接数最少的服务器处理请求。
6. 哈希算法（Hash）：通过请求特定属性（如客户端IP地址）计算哈希值选出服务器。

常见的负载均衡器（如Ribbon、Gateway等）基本都支持这些负载均衡算法。

21. 什么是服务雪崩？

在微服务架构中，若一个或多个服务故障，并且依赖于这些服务的其他服务持续发起请求或进行重试，这会导致请求压力在下游服务上不断累积，最终可能引发级联故障，造成整个系统崩溃，这种现象称为服务雪崩。

防止服务雪崩的措施：

1. 服务高可用部署：确保各服务具备高可用性，通过冗余部署、故障转移来减少单点故障影响。
2. 限流和熔断：对服务请求进行限流和熔断，防止过多请求涌入导致后端不可用。
3. 缓存和降级：合理使用缓存减轻后端负载，并在必要时进行服务降级，确保核心功能可用。

22. 什么是服务熔断？什么是服务降级？

什么是服务熔断？

服务熔断是微服务架构中的容错机制，旨在保护系统免受服务故障或异常影响。当某个服务出现故障时，熔断机制快速隔离该服务，确保系统稳定。

熔断机制通过监控服务调用情况，当错误率或响应时间超过阈值时，触发熔断，后续请求返回默认值或错误信息，避免资源浪费与系统崩溃。

熔断支持自动恢复，重新尝试对故障服务请求，确保服务恢复后继续使用。

什么是服务降级？

服务降级是微服务架构中的容错机制，保证在系统资源紧张或服务故障时核心功能可用。

当系统异常时，服务降级主动屏蔽非核心或可选功能，仅提供基本功能，确保系统稳定运行。可根据业务需求制定策略，替换耗时操作、返回默认响应、甚至静态错误页面等。

有哪些熔断降级方案实现？

常见熔断降级实现方案如下：

23. 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() {
           // 实际的服务调用逻辑
           return "service response";
       }
       
       public String fallbackMethod() {
           // 降级方法逻辑，当服务调用失败时执行
           return "fallback response";
       }
   }
   

3. 请求缓存（Request Caching）：Hystrix可缓存相同请求的响应结果，后续相同请求直接从缓存获取，减少网络请求。

4. 请求合并（Request Collapsing）：Hystrix将多个并发请求合并为一个批量请求，减少网络开销和资源占用。

5. 实时监控和度量（Real-time Monitoring and Metrics）：Hystrix提供实时监控功能，统计服务执行情况，包括错误率、响应时间、并发量等指标，及时发现和解决服务故障或性能问题。

6. 线程池隔离（Thread Pool Isolation）：Hystrix为每个依赖服务请求分配独立的线程池，避免某个服务故障耗尽整个系统线程资源，提高稳定性和可用性。

24. Sentinel怎么实现限流的？

Sentinel通过动态管理限流规则，依据定义的规则对请求进行限流控制，具体步骤如下：

1. 定义资源：在Sentinel中，资源可以是URL或方法等，标识需限流的请求。

   @SentinelResource(blockHandler = "blockHandlerForGetUser")
   public User getUserById(String id) {
       throw new RuntimeException("getUserById command failed");
   }
   
   // blockHandler函数，原方法调用被限流/降级/系统保护时调用
   public User blockHandlerForGetUser(String id, BlockException ex) {
       return new User("admin");
   }
   

2. 配置限流规则：在Sentinel配置文件中定义资源的限流规则，包括资源名称、限流阈值、限流模式（令牌桶或漏桶）等。

   private static void initFlowQpsRule() {
       List<FlowRule> rules = new ArrayList<>();
       FlowRule rule1 = new FlowRule();
       rule1.setResource("resource");
       rule1.setCount(20); // 设置最大QPS为20
       rule1.setGrade(RuleConstant.FLOW_GRADE_QPS);
       rule1.setLimitApp("default");
       rules.add(rule1);
       FlowRuleManager.loadRules(rules);
   }
   

3. 监控流量：Sentinel监控每个资源的流量情况，包括请求QPS、线程数、响应时间等。

4. 限流控制：当请求到达时，Sentinel根据资源的限流规则判断是否进行限流控制，达到阈值将限制、拒绝或其他降级处理。

Sentinel采用的限流算法？

Sentinel采用滑动窗口限流算法，基于时间窗口控制请求通过速率。其将时间划分为多个窗口并统计请求数量，动态调整窗口大小和滑动步长，实现更精准的请求控制。

Sentinel怎么实现集群限流？

Sentinel通过Token Server与Token Client机制实现集群限流。开启集群限流后，Client向Token Server发送请求，Token Server根据配置的规则决定是否限流。

25. 什么是API网关？

API网关（API Gateway）是一种中间层服务器，集中管理、保护与路由对后端服务的访问。它充当客户端与后端服务之间的入口，提供统一接口管理与控制API的访问。

API网关的主要功能包括：

1. 路由转发：根据请求的URL路径或其他标识，将请求路由到相应后端服务。通过配置路由规则灵活分发请求。
2. 负载均衡：在后端服务间实现负载均衡，平均分发请求，提高系统吞吐量与可扩展性。
3. 安全认证与授权：集中处理身份验证与授权，确保经过验证的客户端才能访问后端服务，集成身份提供者（如OAuth、OpenID Connect）。
4. 缓存：缓存后端服务响应，减少请求次数，提高系统性能与响应速度。
5. 监控与日志：收集请求指标与日志，提供实时监控与分析，帮助故障排查与性能优化。
6. 数据转换与协议转换：在客户端与后端服务间进行数据格式转换，使请求满足后端需求。
7. API版本管理：管理不同版本API，支持同时存在多个API版本，借助路由规则将请求路由到相应版本。

使用API网关可简化前后端交互，提供统一接口与安全保障，同时便利服务治理与监控，是微服务架构的重要组成部分。

26. Spring Cloud可以选择哪些API网关？

在Spring Cloud开发中，可以采用以下API网关选型：

1. Netflix Zuul（已停止更新）：Spring Cloud早期版本中默认API网关，基于Servlet技术栈，支持路由、过滤、负载均衡等功能。2020年12月，Netflix宣布停止对Zuul 1的维护，转而支持新API网关项目。
2. Spring Cloud Gateway：Spring Cloud官方推荐的API网关，基于非阻塞WebFlux框架，充分利用响应式编程优势，支持路由、过滤、断路器、限流等特性，能与Spring Cloud其他组件集成。
3. Kong：独立云原生API网关与服务管理平台，基于Nginx，提供强大的路由、认证、授权、监控等能力，支持多种插件与扩展，满足不同API管理需求。
4. APISIX：基于Nginx与Lua开发，具备强大路由、流量控制、插件扩展等功能，支持灵活配置，进行动态路由、负载均衡与限流。

27. Spring Cloud Gateway核心概念？

Spring Cloud Gateway的关键组件：

1. Route（路由）：Spring Cloud Gateway的基本构建块，定义请求匹配规则与转发目标，通过配置路由将请求映射至后端服务实例或URL上。
2. Predicate（断言）：用于匹配请求条件，若请求满足条件，则应用配置的过滤器，提供多种内置断言（如Path、Method、Header），并支持自定义断言。
3. Filter（过滤器）：用于处理与转换请求，可修改请求、响应并执行其他自定义逻辑。提供多个内置过滤器（如请求转发、请求重试、请求限流），也支持自定义。

Spring Cloud Gateway的具体工作流程如下：

其他重要概念：

• Gateway Handler（网关处理器）：Gateway的核心组件，负责将请求转发至匹配的路由上，依据路由配置与断言进行路由匹配，应用配置的过滤器链。
• Gateway Filter Chain（网关过滤器链）：由一系列过滤器组成，按配置顺序依次执行。每个过滤器可在请求前、后或发生错误时进行处理，修改请求、响应及执行其他自定义逻辑。

28. 为什么要用微服务链路追踪？

在微服务架构中，可能存在十几个服务的调用，若某一环出现问题，排查难度极大，因此需要链路追踪来辅助排查问题。

通过链路追踪，可视化请求在微服务间的调用情况，协助排查问题，同时帮助性能优化，展示可视化依赖关系、服务监控与告警。

29. Spring Cloud可以选择哪些微服务链路追踪方案？

Spring Cloud提供多种微服务链路追踪方案，常用的包括：

1. Zipkin：开源的分布式实时追踪系统，由Twitter开发，Spring Cloud Sleuth提供与Zipkin集成，追踪信息发送至Zipkin服务器进行可视化展示与查询。

2. Jaeger：Uber开源的分布式追踪系统，也被纳入CNCF（云原生计算基金会）维护，通过Spring Cloud Sleuth与Jaeger客户端库，追踪信息可发送至Jaeger进行可视化展示与查询。
3. SkyWalking：Apache SkyWalking是开源的应用性能监控与分析系统，支持Java、.NET与Node.js，可与Spring Cloud Sleuth集成，追踪数据发送至SkyWalking服务器进行可视化展示与分析。

4. Pinpoint：Naver开源的分布式应用性能监控系统，支持Java与.NET，提供与Spring Cloud Sleuth集成的功能，追踪数据发送至Pinpoint服务器并通过UI进行分析与监控。

这些方案均可与Spring Cloud Sleuth集成，后者在微服务调用时生成追踪信息的能力。

30. Seata支持哪些模式的分布式事务？

Seata支持以下几种模式的分布式事务：

1. AT（Atomikos）模式：Seata默认支持的模式，最常用，通过在业务代码中嵌入事务上下文实现分布式事务的管理，拦截并解析SQL语句，通过对数据库连接的拦截与代理实现事务管理。

2. TCC（Try-Confirm-Cancel）模式：基于补偿机制的分布式事务模式，业务逻辑需要实现Try、Confirm和Cancel三个阶段，Seata通过调用业务代码中的Try、Confirm和Cancel方法，在每个阶段记录操作日志，实现分布式事务一致性。

3. SAGA模式：基于事件驱动的分布式事务模式，每个服务通过发布与订阅事件，实现分布式事务一致性，Seata提供与SAGA模式兼容的Saga框架。

4. XA模式：基于两阶段提交协议的分布式事务模式，Seata与数据库XA事务协议交互，实现分布式事务管理，需数据库支持XA事务并在应用程序中配置XA数据源。

31. 了解Seata的实现原理吗？

Seata的实现原理主要包括三个核心组件：事务协调器（Transaction Coordinator）、事务管理器（Transaction Manager）和资源管理器（Resource Manager）。

• 事务协调器：负责协调和管理分布式事务的整个过程，接收事务的开始和结束请求，管理全局事务ID和分支事务ID记录。
• 事务管理器：负责全局事务的管理，协调各个分支事务的提交或回滚，确保分布式事务的一致性与隔离性。
• 资源管理器：负责管理和控制各个参与者的事务操作，并根据事务管理器的指令执行相应事务操作。

Seata的实现原理基于两阶段提交协议，具体机制如下：

1. 一阶段：事务提交过程中，首先进行预提交阶段，事务协调器向各资源管理器发送预提交请求，资源管理器执行事务操作并返回结果，此阶段记录业务数据与回滚日志在同一本地事务中提交，释放锁与连接资源。
2. 二阶段：预提交成功后，进入提交阶段，主要包括提交异步化和回滚反向补偿两个步骤：
   • 提交异步化：事务协调器发出提交请求，各资源管理器执行最终提交操作，此阶段的操作需迅速，以保证事务提交效率。
   • 回滚反向补偿：若预提交阶段有任何资源管理器返回失败，事务协调器发出回滚请求，资源管理器根据回滚日志执行撤销操作，恢复数据至事务开始前状态。

32. 全局事务ID和分支事务ID如何传递？

在分布式事务中，全局事务ID和分支事务ID可通过上下文传递，常见方式包括参数传递、线程上下文传递和消息中间件传递，具体可根据业务场景与技术选型选择。

33. Seata的事务回滚如何实现？

Seata的事务回滚通过回滚日志实现。参与者在执行本地事务时生成回滚日志，记录对数据的修改操作。当需回滚事务时，事务协调器向参与者发送回滚请求，参与者依据回滚日志中的信息执行撤销操作。

回滚日志管理与存储为Seata的核心机制，可选择将日志存储于不同介质，通过回滚日志持久化与恢复确保事务一致性与恢复性。

服务监控

====

32. 你们的服务怎么做监控和告警？

我们使用Prometheus和Grafana实现微服务集群监控与告警：

1. Prometheus：开源监控系统，灵活的数据模型和强大查询语言，能收集存储时间序列数据，通过HTTP协议定期拉取微服务指标数据，并提供可扩展存储与查询功能。
2. Grafana：开源可视化仪表板工具，结合Prometheus使用，创建实时与历史数据仪表板，提供丰富图表与可视化选项，帮助用户理解与分析微服务性能和状态。

33. 你们的服务怎么做日志收集？

我们采用ELK方案：

• Elasticsearch：分布式搜索与分析引擎，用于存储与索引大量日志数据，提供快速搜索与聚合功能，高效处理大规模日志数据。
• Logstash：用于收集、过滤与转发日志数据的工具，可从多种来源收集日志，并对数据进行处理和转换，发送至Elasticsearch进行存储与索引。
• Kibana：日志数据可视化与分析工具，提供丰富图表、仪表盘及搜索功能，帮助用户实时监控与分析日志数据，发现潜在问题与趋势。

ELK的工作流程如下：

1. 每个微服务配置日志输出：将微服务日志输出至标准输出或日志文件。
2. 使用Logstash收集日志：配置Logstash收集器，监听微服务日志输出，并对数据进行过滤与处理。
3. 日志数据发送至Elasticsearch：配置Logstash输出插件，将处理后的日志数据发送至Elasticsearch进行存储与索引。
4. 使用Kibana进行可视化与分析：通过Kibana连接Elasticsearch，创建仪表盘、图表与查询，实时监控与分析微服务日志数据。

除了广泛使用的ELK，还有如Fluentd、Graylog、Loki、Filebeat等其它方案，云厂商也提供付费方案，如阿里云的SLS。

参考文献：

https://cn.dubbo.apache.org/
https://cloud.spring.io/spring-cloud-netflix/reference/html/
https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu
https://grafana.com/
https://www.bmabk.com/index.php/post/142012.html
https://sentinelguard.io/zh-cn/
https://www.elastic.co/elastic-stack
https://seata.io/