10 | 路由策略：怎么让请求按照设定的规则发到不同的节点上？

我们是做支付系统，需要对接多个银行服务。我们内部将外部服务接口都抽象化一组接口，每次接入只要相应实现即可。每个银行服务，我们会定义一个唯一ID。服务暴露的时候，利用 dubbo group 配置，将group设置为该id，个性化导出。 在银行服务前面有一个路由系统，这个系统会根据上游系统指定id，通过 dubbo 提供 api 调用，调用相应 group 的银行服务。 嘿嘿，这应该也是一种利用服务版本路由策略。

路由本质是节点分组、隔离流量，因此不论打标签还是分流等特性都天然适合在路由策略里做。 这里分享一个小经验案例：虽然在调用方(上游)做路由策略选择可用的提供方(下游)集群，是天然符合RPC调用机制的，但是在团队协作上却是反人性的。想一想，当你作为下游服务方，你希望链路中扩展某种路由特性(原生不支持)，这时候你需要和你的上游协商并且需要对方优先你或与你同时上线，一般来说对方都是不情愿的，因为对对方而言不仅没有收益还要面临配合你升级带来的风险。因此遇到这种情况时(你作为下游业务方)，最好能有全局视角的人来推动不同团队服务的路由策略同时升级，或者能初期设计考虑周全，后期扩展时业务不需要更新部署(例如Dubbo的条件路由、脚本路由等都是可以从第三方写注册中心更新路由策略而无需业务变更)。 扩展新的路由策略不难，新的路由策略上线比较难😂

越到后面越像k8s的服务治理了，基于etcd的服务发现，pod的状态管理与探活，service的负载功能。原来好多东西都是相通的

我们的应用场景：在多个feature同时开发的时候 可以用路由策略在test环境对某一个服务发布多个版本 在配置中心配置路由规则把来自某一个调用方的请求路由到某一个特定版本的服务上去

老师，IP级限制是好理解的，而路由应该是在rpc中相对底层的模块，而在做处理路由策略的时候，还需要应用层的数据，这样的处理感觉不是特别的合理。

思考题还真想不出来别的了😅期待评论区大佬出现

我认为有一种变更是不能做灰度的，比如修改计费逻辑，不可能说不同的用户不同的计费规则，肯定是一视同仁的。所以必须全部节点同时发布

路由策略怎么和后面的负载均衡连接起来的呢？有形象一点的结构图吗？每个服务集群前面是不是只有一台或一组实现负载均衡的设备？负载均衡设备是怎么区别对待同一个集群里面的新应用和旧应用的呢？

这篇文章给我做灰度有了新的思路，多谢老师！

这篇理论太强了，感觉实现起来会很难。有参考的开源框架实现吗？