为什么选择路由策略？
每次上线应用的时候都不止一台服务器会运行实例，那上线就涉及到变更，只要变更就可能导致原本正常运行的程序出现异常，尤其是发生重大变动的时候，导致应用不稳定的因素就变得很多。
灰度发布应用实例，可以先发布少量实例观察是否有异常，后续再根据观察的情况，选择发布更多实例还是回滚已经上线的实例。
这种方式还是会有问题存在，线上一旦出现问题，影响范围还是比较大。服务提供方的服务会同时提供给很多调用方来调用，尤其是像一些基础服务的调用方会更复杂，比如商品、价格等等，一旦刚上线的实例有问题了，那将会导致所有的调用方业务都会受损。
为了减少上线变更导致的风险，路由在RPC中的应用。
IP路由
风险无法100%规避。尽量减小上线出问题导致业务受损的范围。先让一小部分调用方请求过来进行逻辑验证，待没问题后再接入其他调用方，从而实现流量隔离的效果。
×注册中心只把刚上线的服务IP地址推送到选择指定的调用方，而其他调用方不能通过服务发现拿到这个IP地址。
把这种复杂的计算逻辑放到注册中心里面，当集群节点变多之后，就会导致注册中心压力很大，大部分情况下一般都是采用开源软件来搭建注册中心，要满足这种需求还需要进行二次开发。从实际的角度出发，通过影响服务发现来实现请求隔离并不划算。
√调用方IP过滤
要求新上线的节点只允许某个IP可以调用，注册中心把这条规则下发到服务调用方。在调用方收到规则后，在选择具体要发请求的节点前，会先通过筛选规则过滤节点集合，最后会过滤出一个节点，这个节点就是新上线的节点。
参数路由
背景：在升级改造应用的时候，为了保证调用方能平滑地切调用新应用逻辑，在升级过程中常用的方式是让新老应用并行运行一段时间，然后通过切流量百分比，慢慢增大新应用承接的流量，直到新应用承担了100%且运行一段时间后才能去下线老应用。
服务提供方节点打上标签，用来区分新老应用节点。在服务调用方发生请求时，拿到请求参数，根据注册中心下发的规则来判断请求是过滤掉新应用还是老应用节点。规则对所有的调用方都是一样的，保证对应同一个请求要么是新应用的节点，要么是老应用的节点。
核心思想：参数中心下发规则，由调用方按照设定的规则筛选调用节点，将请求发送到目标节点上，从而实现流量隔离的效果。
