JAVA面试题分享二百八十一：RPC怎么做零呼损？

目录

场景分析

确保 RPC 零呼损的维度

rpc client 维度的零呼损：重试

rpc server 维度的零呼损：优雅启停

优雅启动

优雅停止/优雅下线

优雅停止/优雅下线的简单流程

确保 RPC 零呼损的维度

---

场景分析

微服务架构中，线上跑着几十个，甚至上百的微服务。

服务实例之间，有着错综复杂的RPC调用关系。

这些服务实例，归属到不同的小分队进行开发、设计、维护。

问题是：

在其中部分服务实例重启、升级的过程中， 怎么做到让微服务RPC调用方系统不出问题呢？

确保 RPC 零呼损的维度

如果要确保 RPC 零呼损， 至少可以从以下两个维度进行规避：

• 维度一：rpc client 维度

• 维度一：rpc server 维度

rpc client 维度零呼损的有效措施是：重试

rpc server 维度零呼损的有效措施是：优雅启停

rpc client 维度的零呼损：重试

rpc client 在发生错误的时候，可以进行 服务实例的 重试。

常见的rpc框架如 OpenFeign 框架就有重试几次、重试间隔这样的参数。

当然，如果希望通过重试的机制，让RPC零呼损，那么要保证升级的时候，还有健康的实例可用。

不能所有的微服务实例都同时升级，从而同时不可以使用，这样的话，重试也没有意义。

所以，重试措施最好配套对应的线上滚动升级/滚动发布、或灰度升级/灰度发布等类似的策略。

rpc server 维度的零呼损：优雅启停

优雅启停包括：

• 优雅启动

• 优雅停止/优雅下线

优雅启动

优雅启动，当微服务实例真正完成启动，甚至完成预热之后，真正具备处理 RPC 请求能力的时候，再将实例自己注册到注册中心。

为啥要优雅启动呢？核心原因是：避免了 RPC 请求发进来，没有完成启动流程的微服务实例却无法处理。

优雅启动的流程，还包含 JVM 预热的流程

优雅停止/优雅下线

在服务下线前，先通过“某种方式”把要下线的实例从调用方维护的“健康列表”里面删除就可以了，这样负载均衡就选不到这个节点

这个操作，一般来说，都是依赖注册中心完成的。

当服务提供方关闭前，先通知注册中心进行下线，然后通过注册中心告诉调用方进行节点摘除 。

如上图所示，整个关闭过程中依赖了两次 RPC 调用：

• 一次是服务提供方通知注册中心下线操作

• 一次是注册中心通知服务调用方下线节点操作。

需要注意的是：两次通知都是异步的，只保证最终一致性，并不保证强一致性。

这个中间，有一定的时间周期，所以，如果要做到应用无损升级， 需要在发出通知之后，隔一段时间，再把服务实例正式关闭。

优雅停止/优雅下线的简单流程

1. 下线实例在注册中心进行注销，注销该实例元数据信息；

2. 注册中心节点元数据更新周期为15s，调用方在感知注册中心实例变更后，更新本地缓存服务地址，不再将流量路由到下线实例，期间保障业务无中断；

3. 下线实例等待30s（2个心跳周期）后，进行实际下线操作；

优雅停止的总结：优雅停止是当微服务快要下线的时候，先从注册中心进行去注销，然后把接收到的RPC调用消息，处理完毕后，再彻底关闭。通过优雅停机，可以有效地防止升级期间，发送到老节点的呼损。需要注意发送下线通知，到正式下线之间的时间间隔。

确保 RPC 零呼损的维度

如果要确保 RPC 零呼损， 至少可以从以下两个维度进行规避：

• 维度一：rpc client 维度

• 维度一：rpc server 维度

rpc client 维度  的核心策略是重试

rpc server 维度 的核心策略是 优雅启停

两个维度都不可或缺，都需要实现。