RPC架构设计方法论（完结），2024年最新java基础入门第二版第三章答案

• 初始化时，如果建立连接成功，那就是健康状态，否则就是死亡状态；

• 如果健康状态的节点连续出现几次不能响应心跳请求的情况，那就会被标记为亚健康状态；

• 亚健康状态时，如果连续几次都能正常响应心跳请求，那就可以转回健康状态；

• 死亡的节点能够重连成功，那它就可以重新被标记为健康状态。

调用端每次发请求的时候，就可以优先从健康列表里面选择一个节点，如果健康列表为空，为了提高可用性，也可以尝试从亚健康列表里面选择一个。

2.2.2 可用率

1. 调用方每个接口的调用频次不一样，有的接口可能 1 秒内调用上百次，有的接口可能半个小时才会调用一次，所以我们不能把简单的把总失败的次数当作判断条件。

2. 服务的接口响应时间也是不一样的，有的接口可能 1ms，有的接口可能是 10s，所以我们也不能把 TPS 至来当作判断条件。

于是我们可以采用可用率这个参数来做为健康监测的指标，计算方式是某一个时间窗口内接口调用成功次数的百分比。当可用率低于某个比例就认为这个节点存在问题，把它挪到亚健康列表，这样既考虑了不同低频的调用接口，也兼顾了接口响应时间不同的问题。

2.2.3 分布式部署

因为检测程序所在的机器和目标机器之间的网络可能还会出现故障，就会产生误判。

解决方法就是把检测程序部署在多个机器里面，分布在不同的机器上。因为网络同时故障的概率非常低，所以只要任意一个检测程序实例访问目标机器正常，就可以说明该目标机器正常。

2.3 路由策略

---

2.3.1 路由策略的意义

在真实环境中的服务端是以一个集群的方式提供服务，每次上线应用的时候都不止一台服务器会运行实例，那上线就涉及到变更，只要变更就可能导致原本正常运行的程序出现异常，为了减少这种风险，我们一般会选择灰度发布我们的应用实例。

但线上一旦出现问题，影响范围还是挺大的。因为对于服务提供方来说，服务会同时提供给很多调用方来调用，一旦刚上线的实例有问题了，那将会导致所有的调用方业务都会受损。

但路由策略就可以减少上线变更导致的风险。

2.3.2 路由策略的实现

当我们选择要灰度验证功能的时候，注册中心只会把刚上线的服务 IP 地址推送到选择指定的调用方，而其他调用方是不能通过服务发现拿到这个 IP 地址的。

在 RPC 发起真实请求的时候，有一个步骤就是从服务提供方节点集合里面选择一个合适的节点（负载均衡），可以在负载均衡前加上筛选逻辑把符合要求的节点筛选出来。

例如：我们要求新上线的节点只允许某个 IP 可以调用，那我们的注册中心会把这条规则下发到服务调用方。在调用方收到规则后，在选择具体要发请求的节点前，会先通过筛选规则过滤节点集合，最后会过滤出新上线的节点。

上面例子里面的路由策略是我们常见的 IP 路由策略，用于限制可以调用服务提供方的 IP。

2.3.3 参数路由

有些场景下，我们可能还需要更细粒度的路由方式。

例如：在升级改造应用的时候，为了保证调用方能平滑地切调用我们的新应用逻辑，在升级过程中我们常用的方式是让新老应用并行运行一段时间，然后通过切流量百分比的方式，慢慢增大新应用承接的流量，直到新应用承担了 100% 且运行一段时间后才能去下线老应用。

为了保证整个流程的完整性，我们必须保证某个主题对象的所有请求都使用同一种应用来承接。假设我们改造的是商品应用，主题对象是商品 ID，在切流量的过程中，我们必须保证某个商品的所有操作都是用新应用（或者老应用）来完成所有请求的响应。

我们可以给所有的服务提供方节点都打上标签，用来区分新老应用节点。在服务调用方发生请求的时候，可以很容易地拿到商品 ID，我们可以根据注册中心下发的规则来判断当前请求是用新应用还是旧应用。

相比 IP 路由，参数路由支持的灰度粒度更小，他为服务提供方应用提供了另外一个服务治理的手段。

2.4 负载均衡

---

2.4.1 RPC中的负载均衡

RPC 实现的负载均衡所采用的策略与传统的 Web 服务实现负载均衡有所不同。

RPC 的服务调用者会与“注册中心”下发的所有服务节点建立长连接，在每次发起 RPC 调用时&