微服务面试题：远程调用

🧑 博主简介：CSDN博客专家，历代文学网（PC端可以访问：https://literature.sinhy.com/#/?__c=1000，移动端可微信小程序搜索“历代文学”）总架构师，15年工作经验，精通Java编程，高并发设计，Springboot和微服务，熟悉Linux，ESXI虚拟化以及云原生Docker和K8s，热衷于探索科技的边界，并将理论知识转化为实际应用。保持对新技术的好奇心，乐于分享所学，希望通过我的实践经历和见解，启发他人的创新思维。在这里，我希望能与志同道合的朋友交流探讨，共同进步，一起在技术的世界里不断学习成长。
技术合作请加本人wx（注明来自csdn）：foreast_sea

在这里插入图片描述

微服务面试题：远程调用

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

HTTP 和 RPC 不算是一个层面上的东西：

在这里插入图片描述

HTTP 是应用层协议，用于传输超文本数据，基于请求-响应模型，常用于 Web 开发、API 调用等场景。

RPC 是远程过程调用协议，用于实现分布式系统中不同节点之间的通信，基于方法调用模型，常用于构建面向服务的微服务架构。

在微服务架构中，Feign 和 Dubbo 都是用于实现远程调用的框架，Feign 基于 HTTP 协议，Dubbo 基于 RPC 协议。

如果硬要说区别的话，如下：

-	HTTP	RPC
定义	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 调用等。	更加高效，适用于需要高性能和低延迟的分布式系统。

1.1 RPC了解吗？

RPC（Remote Procedure Call）是一种远程过程调用协议，用于实现分布式系统中不同节点之间的通信。它基于方法调用模型，允许客户端调用远程服务的方法，并等待结果返回。

像 gRPC、Dubbo、Thrift 等都是 RPC 框架，它们提供了 IDL（接口定义语言）来定义服务接口，以及序列化协议来进行数据传输。

2. 那 Feign 和 Dubbo 的区别呢？

这两个才是适合拿来比较的东西：

-	Feign	Dubbo
定义	Feign 是一个声明式的 Web 服务客户端，用于简化 HTTP API 的调用。	Dubbo 是一个分布式服务框架，用于构建面向服务的微服务架构。
通信方式	基于 HTTP 协议，使用 RESTful 风格的接口进行定义和调用。	基于 RPC 协议，支持多种序列化协议如 gRPC、Hessian 等。
服务发现	通常结合服务注册中心（如 Eureka、Consul）进行服务发现和负载均衡。	通过 ZooKeeper、Nacos 等进行服务注册和发现，并提供负载均衡功能。
服务治理	不直接提供服务治理功能，需要结合其他组件或框架进行服务治理。	提供服务注册与发现、负载均衡、容错机制、服务降级等服务治理功能。
跨语言性	支持跨语言通信，可以使用 HTTP 作为通信协议实现不同语言之间的通信。	支持跨语言通信，通过 Dubbo 的 IDL 生成不同语言的客户端和服务端代码。
生态系统	集成了 Spring Cloud 生态系统，与 Spring Boot 无缝集成。	拥有完整的生态系统，包括注册中心、配置中心、监控中心等组件。
适用场景	适用于构建 RESTful 风格的微服务架构，特别适合基于 HTTP 的微服务调用。	适用于构建面向服务的微服务架构，提供更全面的服务治理和容错机制。

需要注意的是，Feign 和 Dubbo 并不是互斥的关系。实际上，Dubbo 可以使用 HTTP 协议作为通信方式，而 Feign 也可以集成 RPC 协议进行远程调用。选择使用哪种远程调用方式取决于具体的业务需求和技术栈的选择。

3. 说一下 Fegin?

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

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

Feign封装

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

声明式 API：Feign 允许开发者使用简单的注解来定义和描述对远程服务的访问。通过使用注解，开发者可以轻松地指定 URL、HTTP 方法、请求参数、请求头等信息，使得远程调用变得非常直观和易于理解。

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

集成负载均衡：Feign 集成了 Ribbon 负载均衡器，可以自动实现客户端的负载均衡。它可以根据服务名和可用实例进行动态路由，并分发请求到不同的服务实例上，提高系统的可用性和可伸缩性。
容错机制：Feign 支持集成 Hystrix 容错框架，可以在调用远程服务时提供容错和断路器功能。当远程服务不可用或响应时间过长时，Feign 可以快速失败并返回预设的响应结果，避免对整个系统造成级联故障。

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

主要原因是由于 Ribbon 的懒加载机制，当第一次调用发生时，Feign 会触发 Ribbon 的加载过程，包括从服务注册中心获取服务列表、建立连接池等操作，这个加载过程会增加首次调用的耗时。

ribbon:
   eager-load:
     enabled: true
       clients: service-1

那怎么解决这个问题呢？

可以在应用启动时预热 Feign 客户端，自动触发一次无关紧要的调用，来提前加载 Ribbon 和其他相关组件。这样，就相当于提前进行了第一次调用。

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

比较常见的一个做法是，使用拦截器传递认证信息。可以通过实现RequestInterceptor接口来定义拦截器，在拦截器里，把认证信息添加到请求头中，然后将其注册到 Feign 的配置中。

@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() {
         // 获取认证信息的逻辑，可以从SecurityContext或其他地方获取
         // 返回认证信息的字符串形式
         return "your_token";
     }
 }

6. Fegin 怎么做负载均衡？Ribbon?

在 Feign 中，负载均衡是通过集成 Ribbon 来实现的。

Ribbon 是 Netflix 开源的一个客户端负载均衡器，可以与 Feign 无缝集成，为 Feign 提供负载均衡的能力。

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

在这里插入图片描述

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

常见的负载均衡算法包含以下几种：

在这里插入图片描述

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

常见的负载均衡器，比如 Ribbion、Gateway 等等，基本都支持这些负载均衡算法。