10 | 路由策略：怎么让请求按照设计的规则发到不同的节点上？
我们在真实的环境中，服务提供方是以集群的方式对外提供服务，这对于服务调用方来说，就是一个借口会有多个服务提供方同时提供服务，所以RCP在每次发起请求的时候，都需要从多个服务提供方节点里面选择一个用于发送请求。
当服务在线上运行时，我们如果有变更，会涉及到如何升级，升级过程中可能会影响服务接口，这样会导致系统变的不稳定，甚至系统崩溃，为了减少这种风向，我们一般会选择灰度发布的方式来升级我们的服务实例，例如我们可以发布少量实例来观察是否有异常，然后根据观察的结果，来决定是发布更多实例还是回滚到旧版本。
虽然我们的服务在上线前会有测试的过程，但是因为线上环境太复杂了，测试只能是降低出现风险的概率，想要彻底验证所有场景是不可能的。
我们可以考虑在上线完成后，先让一小部分调用方请求过来进行逻辑验证，待没有问题后再接入其他调用方，从而实现流量隔离的效果。
因为注册中心会维护所有服务提供方的信息，所以我们可以在注册中心中来做流量隔离吗？一般不采用这种方式，注册中心在RPC中的定位是用来存储数据并保证数据一致性，如果把复杂的请求隔离的计算逻辑放到注册中心里面，那么当集群节点变多时，会导致注册中心压力过大，而且大部分时候，我们采用开源软件来打架注册中心，要加入其他计算逻辑的话，还需要进行二次开发，所以从实际的角度出发，在注册中心中实现请求隔离是不划算的。
调用法发起RPC调用的整个流程中，在RPC发起真实请求的时候，有一个步骤就是从服务提供方节点集合里面选择一个合适的节点（也就是负载均衡），那么我们可以考虑在这个节点之前，加入一个“筛选逻辑”，把符合我们要求的节点筛选出来。
这个“筛选过程”，我们称之为“路由策略”。
我们可以设计不同的分路由策略：
- IP路由，根据服务调用方的IP地址，来决定哪些服务提供方的实例可以处理相关请求。
- 参数路由，根据服务调用方发送请求中的参数值，来决定哪些服务提供方的实例可以处理相关请求。
参数路由是比IP路由更灵活、粒度更细的路由规则，它为服务提供方应用提供了另外一个服务治理的手段。
灰度发布功能是RPC路由功能的一个典型应用场景，通过RPC的路由策略的组合使用可以让服务提供方更加灵活的管理、调用自己的流量，进一步降低可能导致的风险。
在RPC里面，不论是哪种路由策略，其核心思想是一样的，就是让请求按照我们设定的规则发送到目标节点上，从而实现流量隔离的效果。
