gRPC常见面试题目

1. gRPC服务端启动流程
答：定义服务接口->实现服务->创建服务器->启动服务器
定义服务接口：实现proto文件，这个文件服务端和接收端共用，通过protoc命令进行编译生成c++代码
实现服务：实现接口方法
创建服务：指定监听地址和注册服务实现

2. gRPC服务类型有哪些？
答： 一元RPC模式、服务端流RPC模式、客户端流RPC模式、双向流RPC模式

简单 RPC（Unary RPC）：这是最基础的服务类型，客户端发送一个请求给服务器，服务器处理后返回一个响应。这是一种请求-响应模式，两者都是一次性的。

服务端流式 RPC （Server streaming RPC）：在这种类型的服务中，客户端发送一个请求给服务器，服务器则返回多个响应消息。客户端接收来自服务器的流式数据，直到服务器完成发送。

客户端流式 RPC （Client streaming RPC）：与服务端流式相反，客户端向服务器发送多个请求消息，服务器聚合这些请求（如果需要的话）并仅返回一个响应

双向流式 RPC（Bi-directional streaming RPC）：这种类型允许客户端和服务器都发送多个请求消息和响应消息，且双方可以独立地进行读写操作。适用于需要全双工通信的场景，例如实时数据交换或聊天应用。

3. keepalive是针对流设计的还是连接设置的？有哪些选项？
答：gRPC的keepalive功能是为了保持连接活跃，防止长时间无数据传输时连接被关闭。它不是为特定的数据流设计的，而是应用于整体的网络连接，无论是哪种类型的RPC调用（单次请求、服务器端流、客户端端流还是双向流）都受其影响。简而言之，keepalive是为了维护连接不断开，而非针对个别数据流。
设置选项：流量包的大小，时间间隔、超时时间、发送速率

4. gRPC多路复用是什么？
答：gRPC中的多路复用（Multiplexing）是指在一个单一的TCP连接上同时处理多个客户端到服务器的请求和响应的能力。这一特性得益于gRPC底层使用的HTTP/2协议。在HTTP/1.1中，每个请求-响应对都需要一个新的TCP连接，或者至少需要在连接之间复用，但这限制了并发性和效率。而HTTP/2通过引入多路复用机制解决了这些问题。

多路复用的工作原理如下：http2.0引入了分帧协议，将请求和回应分割成了一系列的帧，通过流的方式进行传输。一个tcp连接上可以存在多个流，每个流都有唯一标识符和优先级，可以独立传输。多个流也能并发传输，通过帧头部中标识符进行区分和组装从而实现多路复用

总结来说，gRPC中的多路复用是一个关键特性，它提高了通信效率，尤其是在需要频繁交互的微服务架构中，能够显著提升系统性能。

5. gRPC如何自定义reslover？
答：在 gRPC 中，自定义解析器（resolver）允许你控制客户端如何确定服务器地址。自定义解析器可以用于实现更复杂的服务发现机制，比如结合 DNS、API 网关或其他服务发现系统。

gRPC C++ 支持自定义解析器，以下是自定义解析器的基本步骤：
（1）定义 Resolver 工厂：创建一个工厂类，用于生成自定义解析器的实例。
（2）实现 Resolver 接口：实现 grpc::Resolver 接口，包括 OrphanablePtr<Resolver> 的 CreateResolver 方法。
（3）实现 Resolver 回调：实现 grpc::Resolver::Next 方法，该方法用于返回服务地址列表和设置下一次回调。
（4）注册 Resolver 工厂：使用 grpc::ResolverRegistry::RegisterResolverFactory 方法注册你的工厂。
（5）使用自定义解析器：在客户端创建时使用 grpc::ChannelArguments 设置自定义解析器的方案。

6. 客户端连接状态有哪些？
答：Idle（空闲）: 初始状态或在没有任何活动后连接回到的状态，此时连接并未建立或已经断开，等待新的连接请求。
Connecting（连接中）: 客户端正在尝试建立与服务器的连接，这可能涉及DNS解析、TCP握手等过程。
Ready（就绪）: 连接成功建立，可以进行数据的发送和接收。这是进行RPC调用的理想状态。
TransientFailure（暂时失败）: 连接尝试失败或现有连接遇到了错误（如超时、网络中断、服务器不可达等），但预期未来可能恢复。gRPC客户端可能会自动尝试重连。
Shutdown（关闭）: 客户端显式关闭了连接，或者因为某些外部条件（如应用退出）导致连接不再可用。在此状态下，客户端通常不会尝试重新连接。
Draining（排空）: 这个状态在某些实现或上下文中可能出现，表示连接即将关闭，但仍可能处理剩余的请求或响应，之后将进入Shutdown状态。

7. 客户端如何获取服务端的服务函数列表？
答：一般通过grpc proto文件获取。grpc_cli也可以。
grpc_cli 是 gRPC 生态系统中的一个命令行工具，它用于调试和测试 gRPC 服务。这个工具允许用户以一种简单直观的方式与 gRPC 服务进行交互，无需编写任何代码。以下是 grpc_cli 的一些主要功能：

列出服务：使用 grpc_cli ls 命令可以列出服务端公开的所有服务和方法。
获取类型信息：使用 grpc_cli type 命令可以获取服务中定义的消息类型和字段信息。
发起 RPC 调用：使用 grpc_cli call 命令可以向服务端发起 RPC 调用，并传递请求参数，查看返回结果。
与反射服务交互：如果服务端开启了 gRPC 反射服务，grpc_cli 可以与之交互，获取服务信息。

8. gRPC如何自定义balancer？
答：在 gRPC 中，负载均衡器（balancer）负责决定将客户端的请求转发到哪个后端服务器。gRPC 支持自定义负载均衡器，允许开发者根据特定的需求来实现自己的负载均衡策略。

以下是自定义 gRPC 负载均衡器的基本步骤：
（1）定义负载均衡器接口：实现 grpc::LoadBalancer 接口，包括 grpc::OrphanablePtr<LoadBalancer> 的 CreateLoadBalancer 方法。
（2）实现负载均衡逻辑：实现 grpc::LoadBalancer 接口中的 UpdateSubchannels 和 RequestReresolution 方法，以及 grpc::Subchannel 接口的 ConnectivityStateWatcherInterface 回调。
（3）注册负载均衡器工厂：使用 grpc::LoadBalancingPolicyRegistry 将你的负载均衡器工厂注册到 gRPC 框架中。
（4）使用自定义负载均衡器：在客户端创建通道时，通过 grpc::ChannelArguments 指定使用你的自定义负载均衡器。

9. 如何实现限流？
答：限流一般在服务端进行。
客户端实现令牌桶：
自定义拦截器：创建一个自定义的 gRPC 客户端拦截器，在发送请求之前检查令牌桶状态。
令牌桶管理：在拦截器中实现令牌桶逻辑，包括令牌的生成和消耗。
请求控制：如果令牌桶中有足够的令牌，允许请求通过；否则，根据策略延迟请求或返回错误。

服务器端实现令牌桶：
中间件：在服务器端使用中间件来实现令牌桶逻辑。
请求拦截：在中间件中检查每个请求的令牌桶状态，决定是否处理请求。
响应控制：根据令牌桶的状态，返回成功响应或错误响应（如 RESOURCE_EXHAUSTED）。

这是一条吃饭博客，由挨踢零声赞助。学C/C++就找挨踢零声，加入挨踢零声，面试不挨踢！