RPC实战与核心原理
何小锋
京东技术架构部首席架构师
立即订阅
3885 人已学习
课程目录
已更新 16 讲 / 共 28 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 别老想着怎么用好RPC框架,你得多花时间琢磨原理
免费
基础篇 (6讲)
01 | 核心原理:能否画张图解释下RPC的通信流程?
02 | 协议:怎么设计可扩展且向后兼容的协议?
03 | 序列化:对象怎么在网络中传输?
04 | 网络通信:RPC框架在网络通信上更倾向于哪种网络IO模型?
05 | 动态代理:面向接口编程,屏蔽RPC处理流程
06 | RPC实战:剖析gRPC源码,动手实现一个完整的RPC
进阶篇 (9讲)
07 | 架构设计:设计一个灵活的RPC框架
08 | 服务发现:到底是要CP还是AP?
09 | 健康检测:这个节点都挂了,为啥还要疯狂发请求?
10 | 路由策略:怎么让请求按照设定的规则发到不同的节点上?
11 | 负载均衡:节点负载差距这么大,为什么收到的流量还一样?
12 | 异常重试:在约定时间内安全可靠地重试
13 | 优雅关闭:如何避免服务停机带来的业务损失?
14 | 优雅启动:如何避免流量打到没有启动完成的节点?
15 | 熔断限流:业务如何实现自我保护?
RPC实战与核心原理
登录|注册

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

何小锋 2020-03-11
你好,我是何小锋。上一讲我们介绍了健康检测在 RPC 中的作用,简单来讲就是帮助调用方应用来管理所有服务提供方的连接,并动态维护每个连接的状态,方便服务调用方在每次发起请求的时候都可以拿到一个可用的连接。回顾完上一讲的重点,我们就切入今天的主题——RPC 中的路由策略。

为什么选择路由策略?

在前面我们提到过,在真实环境中我们的服务提供方是以一个集群的方式提供服务,这对于服务调用方来说,就是一个接口会有多个服务提供方同时提供服务,所以我们的 RPC 在每次发起请求的时候,都需要从多个服务提供方节点里面选择一个用于发请求的节点。
既然这些节点都可以用来完成这次请求,那么我们就可以简单地认为这些节点是同质的。这里的同质怎么理解呢?就是这次请求无论发送到集合中的哪个节点上,返回的结果都是一样的。
既然服务提供方是以集群的方式对外提供服务,那就要考虑一些实际问题。要知道我们每次上线应用的时候都不止一台服务器会运行实例,那上线就涉及到变更,只要变更就可能导致原本正常运行的程序出现异常,尤其是发生重大变动的时候,导致我们应用不稳定的因素就变得很多。
为了减少这种风险,我们一般会选择灰度发布我们的应用实例,比如我们可以先发布少量实例观察是否有异常,后续再根据观察的情况,选择发布更多实例还是回滚已经上线的实例。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《RPC实战与核心原理》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(12)

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

    作者回复: 用的很好👍

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

    作者回复: 是的,路由策略最好要抽象成配置信息,可以动态下发

    2020-03-12
    2
  • kevin
    通过版本号也可以控制,新服务使用不同的版本号,上线后两个版本都存在,控制部分调用方使用新版本的服务,这种方案可以达到灰度的效果,但是需要调用方配合,没有路由来的方便
    2020-03-22
  • 小哇
    我们也可以使用用户的维度,让测试人员直接线上也定服务来测试功能
    2020-03-13
  • d
    我们可以给所有的服务提供方节点都打上标签,用来区分新老应用节点。在服务调用方发生请求的时候,我们可以很容易地拿到请求参数,也就是我们例子中的商品 ID,我们可以根据注册中心下发的规则来判断当前商品 ID 的请求是过滤掉新应用还是老应用的节点。因为规则对所有的调用方都是一样的,从而保证对应同一个商品 ID 的请求要么是新应用的节点,要么是老应用的节点。



    这段是什么意思,文稿能具体一点吗,看不太明白啊

    作者回复: 就是保证同一个商品ID的所有请求都发送到具体某一个应用,这个应用可以是新应用也可以是老应用,但只能唯一

    2020-03-12
    1
  • 感觉这个路由策略也可以来做限流,现在服务请求量的峰值保障系统可用性。
    2020-03-12
    1
  • 安排
    路由策略怎么和后面的负载均衡连接起来的呢?有形象一点的结构图吗?每个服务集群前面是不是只有一台或一组实现负载均衡的设备?负载均衡设备是怎么区别对待同一个集群里面的新应用和旧应用的呢?

    作者回复: 一般是先通过路由筛选,再进行路由选择

    2020-03-11
  • Jackey
    思考题还真想不出来别的了😅期待评论区大佬出现

    作者回复: 并行开发的时候,隔离出不同联调环境

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

    作者回复: 隔离环境👍

    2020-03-11
  • 姜戈
    在使用 RPC 的过程中,除了用路由策略实现过灰度发布、定点调用等功能,还用它完成:
    熔断,限流,降级

    作者回复: 这个好像不太行吧

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

    作者回复: 好的设计都是要互相借鉴

    2020-03-11
  • hello
    这篇文章给我做灰度有了新的思路,多谢老师!

    作者回复: 欢迎交流👏

    2020-03-11
收起评论
12
返回
顶部