RPC 之路由策略

为什么选择路由策略

在真实环境中，我们的服务方是以集群的方式提供服务，这对于服务调用方来说，就是一个接口会有多个服务提供方同时提供服务，所以我们的 RPC 在每次发送请求的时候，都需要从多个服务提供方里面选择一个用于发请求的节点。

既然这些节点都可以用来发送请求，那么我们就可以简单的认为这些节点是同质的，这里的同质就是请求无论发送到集群的哪个节点上，返回的结果都是一样的。

既然服务提供方是以集群的形式对外提供服务，那就需要考虑一些实际问题。每次上线应用的时候都不止一台服务器会运行实例，那上线就涉及到变更，只要变更就可能导致原本正常运行的程序出现异常，尤其是发生重大变动的时候，导致我们的应用不稳定的因素就会变的很多。

为了减少这种风险，一般会选择灰度发布应用实例，比如可以先发布少量实例观察是否有异常，再根据观察的情况，选择发布更多实例还是回滚已经上线的实例。

但是这种方式不好的一点就是，线上一旦出现问题，影响范围还是挺大的。对于服务提供方来说，我们的服务会同时提供给很多调用方来调用，尤其是一些基础服务的调用方会更复杂，比如商品，价格等，一旦刚上线的实例有问题，将会导致所有的调用方业务都会受损。

那么对于 RPC 框架来说，有什么办法可以减少上线变更导致的风险吗，这就需要路由在 RPC 中的应用。

如何实现路由策略

可能最直观的想法就是把所有的场景都重新测试一遍，这也是一种方法，而且测试肯定是上线前的一个重要环节，但是线上环境太复杂，但是测试的角度出发只能降低风险出现的概率，要想彻底验证所有场景基本是不可能的。

那如果没法100%规避风险，就只能尽量减小上线出问题导致业务受损的范围。基于这个思路，可以在上线完成后，先让一小部分调用方请求过来进行逻辑验证，待没问题后再接入其他调用方，从而实现流量隔离的效果，那 RPC 框架里面应该怎么实现呢？

服务调用方是通过服务发现的方式拿到了所有服务提供方的 IP 地址，当要灰度发布的时候，就可以让注册中心在推动的时候区别对待，而不是一股脑的把服务提供方的 IP 地址推动到所有调用方。也就是注册中心只会把刚上线的服务 IP 地址推动到选择指定的调用方，而其他调用方是不能通过服务发现拿到这个 IP 地址的。

通过服务发现的方式来隔离调用方请求，从逻辑上看确实可行，但注册中心在 RPC 里面的定位是用来存储数据并保证数据一致性的。把这种复杂的计算逻辑放到注册中心里面，当集群节点变多之后，就会导致注册中心压力很大，而且大部分情况下我们采用开源软件来搭建注册中心，要满足这种需求还需要进行二次开发，所以通过影响服务发现来实现请求隔离并不划算。

那有没有其他方案呢？

在 RPC 发起真实请求的时候，有一个步骤就是从服务提供方节点集合里面选择一个合适的节点（负载均衡），我们可以在选择节点前加上“筛选逻辑”，把符合我们要求的节点筛选出来。那筛选的规则就是前面说的灰度过程中要验证的规则。

比如要求新上线的节点只允许某个 IP 可以调用，那我们的注册中心会把这条规则下发到服务调用方，调用方收到规则后，在选择具体要发请求的节点前，会先通过筛选规则过滤节点集合，按照这个例子的逻辑，最后会过滤出一个节点，这个节点就是我们刚新上线的节点，那 RPC 调用流程就变成这样：

这个筛选过程在RPC里面有一个名词就是“路由策略”，而上面例子的路由策略就是我们常见的 IP 路由策略，用于限制可以调用服务提供方的 IP，使用了 IP 路由策略后，集群调用图如下：

参数路由

有了 IP 路由之后，上线过程中我们就可以做到只让部分调用方请求调用到新上线的实例，相对于传统的灰度发布功能来说，这样可以把是错成本降到最低。

但在有些场景下，我们可能还需要更细粒度的路由方式。比如升级改造应用的时候，为了保证调用方能平滑地调用我们的新应用逻辑，在升级过程中我们常用的方式是让新老应用并行运行一段时间，通过切流量百分比的方式，慢慢增大新应用承接的流浪，直到新应用承担了100%且运行一段时间后才能去下线老应用。

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

很显然，上面的 IP 路由并不能满足我们的这个需求，因为路由 IP 只是限制调用方来源，并不会根据请求参数请求到我们预设的服务提供方节点上去。

我们可以给所有的服务提供方都打上标签，用来区分新老应用节点，在服务调用方发生请求的时候，我们很容易地拿到请求参数，也就是例子总的商品 ID，可以根据注册中心下发的规则来判断当前商品 ID 的请求是过滤掉新应用还是老应用的节点。因为规则对所有的调用方都是一样的，从而保证对同一个商品 ID 的请求要么是新应用的节点，要么是老应用的节点，如下如：

相比于 IP 路由，参数路由支持的灰度粒度更小，它为服务提供方应用提供了另外一个服务治理的手段。灰度发布功能是 RPC 路由功能的一个典型应用场景，通过 RPC 路由策略的组合使用可以让服务提供方更加灵活地管理、调用自己的流量，进一步降低上线可能导致的风险。

巨人的肩膀：

https://time.geekbang.org/column/intro/100046201?tab=comment