RPC 实战与核心原理
何小锋
京东云混合云首席架构师
40244 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 29 讲
RPC 实战与核心原理
15
15
1.0x
00:00/00:00
登录|注册

16 | 业务分组:如何隔离流量?

区分主次分组
允许调用方配置多个分组
分组标准
改造服务发现逻辑
早期管理模式不适用于业务发展
道路建设与完善的类比
解决开发人员和测试人员并行工作可能导致的问题
利用分组完成一个接口多种实现的功能
通过分组实现调用方流量隔离
如何实现高可用?
怎么实现分组?
为什么需要分组?
限流
熔断
课后思考
总结
隔离流量
RPC中的保护手段
业务分组:如何隔离流量?

该思维导图由 AI 生成,仅供参考

你好,我是何小锋。上一讲我们介绍了 RPC 中常用的保护手段“熔断限流”,熔断是调用方为了避免在调用过程中,服务提供方出现问题的时候,自身资源被耗尽的一种保护行为;而限流则是服务提供方为防止自己被突发流量打垮的一种保护行为。虽然这两种手段作用的对象不同,但出发点都是为了实现自我保护,所以一旦发生这种行为,业务都是有损的。
那说起突发流量,限流固然是一种手段,但其实面对复杂的业务以及高并发场景时,我们还有别的手段,可以最大限度地保障业务无损,那就是隔离流量。这也是我今天重点要和你分享的内容,接下来我们就一起看看分组在 RPC 中的应用。

为什么需要分组?

在我们的日常开发中,我们不都提倡让用户使用起来越简单越好吗?如果在接口上再加一个分组维度去管理,不就让事情变复杂了吗?
实则不然,举个例子。在没有汽车的年代,我们的道路很简单,就一条,行人、洋车都在上边走。那随着汽车的普及以及猛增,我们的道路越来越宽,慢慢地有了高速、辅路、人行道等等。很显然,交通网的建设与完善不仅提高了我们的出行效率,而且还更好地保障了我们行人的安全。
同样的道理,我们用在 RPC 治理上也是一样的。假设你是一个服务提供方应用的负责人,在早期业务量不大的情况下,应用之间的调用关系并不会复杂,请求量也不会很大,我们的应用有足够的能力扛住日常的所有流量。我们并不需要花太多的时间去治理调用请求过来的流量,我们通常会选择最简单的方法,就是把服务实例统一管理,把所有的请求都用一个共享的“大池子”来处理。这就类似于“简单道路时期”,服务调用方跟服务提供方之间的调用拓扑如下图所示:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

在RPC中,隔离流量是至关重要的,本文介绍了业务分组的概念及实现方法。作者通过道路交通的类比引出了分组的概念,指出了随着业务发展,粗暴的管理模式已不再适用,需要通过分组实现流量隔离。文章提出了按照应用重要级别划分的规则,并介绍了服务发现的改造逻辑。此外,还探讨了如何实现高可用,提出了允许调用方配置多个分组,并区分主次分组的方法,以保障调用方应用的高可用性。通过分组的方式隔离调用方的流量,可以避免因为一个调用方出现流量激增而影响其它调用方的可用率。文章内容深入浅出,为读者提供了在RPC中实现流量隔离的方法和思路。 在实际工作中,开发人员和测试人员并行工作可能会导致接口分组名冲突,影响工作效率。为了解决这一问题,可以考虑在接口分组命名时增加标识符以区分开发和测试环境,或者在部署应用时动态生成接口分组名,避免冲突。这样可以有效避免不同环境下的接口干扰,提高工作效率。 这篇文章对于需要了解RPC中流量隔离方法和思路的读者来说是一份有价值的参考资料。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《RPC 实战与核心原理》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(28)

  • 最新
  • 精选
  • Darren
    我们目前使用的不同的注册中心,就是注册中心是部署了3份,prod、qa、test等,其实test和dev用的是同一个注册中心,因为我们的注册中心内部也有环境的区分,服务在往注册中心注册时,需要说明自己的环境。 所以我们目前服务间的调用是: prod走生产网关prod.gateway.com(网关同步注册中心信息) 环境参数默认prod qa走生产网关qa.gateway.com(网关同步注册中心信息) 环境参数默认qa test和dev走 test.gateway.com(网关同步注册中心信息),test需要环境的参数,test就是tets,dev就是dev

    作者回复: 是的,环境硬隔离最省心

    2020-03-25
    25
  • 刘楠
    环境不同,注册中心不同

    作者回复: 是个好办法。

    2020-03-25
    5
  • 百威
    直连

    作者回复: 直连的话,服务发现就失去意义了

    2020-03-27
    3
    2
  • 盘胧
    不是很明白了。开发这边开发环境容器化,我们云主机克隆过来或者直接拉镜像都行,最后修改好配置。就相当于和开发隔离开来了。开发这边每天的更新打包好,我们也拿过来打包升级就行了。

    作者回复: 关键在于配置是否存在开发测试冲突

    2020-03-25
    2
  • 陈国林
    开发推荐使用开发机测试,测试则使用Pre环境,互不干扰

    作者回复: 如果能隔离环境肯定更好,很多企业是不隔离测试和开发环境的

    2020-03-26
    1
  • hello
    故障隔离还能这么玩,今天又见识到了一种新思路(”借道“),感谢老师!

    作者回复: 加油

    2020-03-25
    1
  • 小哇
    请问老师,您讲的是同个服务集群的分组还是说不同服务的分组,如果是同个服务分组,既然同个服务里有核心和非核心接口,那是不是继续拆分服务才对呢?如果是不同服务,分组只是为了标识不同的应用而已吧?

    作者回复: 同一个接口分不同组,分组的目的就是为了隔离不同调用方

    2020-03-25
    1
  • Reason
    服务本身增加环境属性,注册信息中增加环境信息,服务发现时默认发现同环境的服务,类似于再增加个分组级别?

    作者回复: 是的,可以利用自动部署来自动加

    2020-03-25
    1
  • Dovelol
    老师好,如果没有用rpc而是走http调用的微服务怎么做分组呢,现在有在网关可以做分组的吗?

    作者回复: 可以通过不同vip来隔离

    2020-03-25
    2
    1
  • dancer
    请问老师如果在限流阈值配置中加入应用分组的设置,和本文方案是不是也有相同的效果?

    作者回复: 可以把限流融入到分组

    2020-05-10
收起评论
显示
设置
留言
28
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部