设计模式之美
王争
前 Google 工程师,《数据结构与算法之美》专栏作者
123426 人已学习
新⼈⾸单¥98
登录后,你可以任选6讲全文学习
课程目录
已完结/共 113 讲
设计模式与范式:行为型 (18讲)
设计模式之美
15
15
1.0x
00:00/00:00
登录|注册

96 | 项目实战三:设计实现一个支持自定义规则的灰度发布组件(分析)

待分析
提供编程接口(DarkFeature)判定是否灰度
灰度规则配置解析
灰度组件非功能性需求
灰度组件功能性需求
代码回滚成本
灰度替换老的RPC服务
替换框架
公共服务平台
课堂讨论
灰度组件
代码层面的灰度
需求分析
需求场景
接口幂等框架
接口限流框架
重点回顾
灰度发布组件
实战项目
文章主题:设计实现一个支持自定义规则的灰度发布组件

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

到现在为止,我已经带你学习了接口限流框架和接口幂等框架两个实战项目。接下来,我再带你实战一个新的项目:灰度发布组件。这也是我们专栏的最后一个实战项目。还是老套路,我们把它分为分析、设计、实现三个部分、对应三节课来讲解。今天,我们对灰度发布组件进行需求分析,搞清楚这个组件应该具有哪些功能性和非功能性需求。
话不多说,让我们正式开始今天的学习吧!

需求场景

还记得我们之前接口限流和幂等框架的项目背景吗?我们开发了一个公共服务平台,提供公共业务功能,给其他产品的后端系统调用,避免重复开发相同的业务代码。
最初,公共服务平台提供的是,基于某个开源 RPC 框架的 RPC 格式的接口。在上线一段时间后,我们发现这个开源 RPC 框架的 Bug 很多,多次因为框架本身的 Bug,导致整个公共服务平台的接口不可用,但又因为团队成员对框架源码不熟悉,并且框架的代码质量本身也不高,排查、修复起来花费了很长时间,影响面非常大。所以,我们评估下来,觉着这个框架的可靠性不够,维护成本、二次开发成本都太高,最终决定替换掉它。
对于引入新的框架,我们的要求是成熟、简单,并且与我们现有的技术栈(Spring)相吻合。这样,即便出了问题,我们也能利用之前积累的知识、经验来快速解决。所以,我们决定直接使用 Spring 框架来提供 RESTful 格式的远程接口。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

灰度发布组件设计与实现 本文介绍了一个支持自定义规则的灰度发布组件的设计与实现。作者首先从需求场景出发,讨论了在替换老的RPC服务为新的RESTful接口时,需要进行灰度发布以逐步验证新接口的可靠性。为解决这一问题,作者提出了使用功能开关来灵活切换新老接口调用方式,并通过配置文件或配置中心来优化灵活性。此外,还介绍了灰度功能的实现方式,包括针对请求携带的时间戳、业务ID等信息,按区间、比例或具体值来进行灰度。最后,作者建议在修改复杂功能或核心功能时,也应通过功能开关来灵活控制上下线,以实现快速回滚或新老代码逻辑的切换。 文章重点讲解了代码层面的灰度发布,通过编程来控制是否执行新的代码逻辑,以及灰度执行新的代码逻辑。灰度发布主要解决代码质量问题,通过逐渐放量灰度执行,来降低重大代码改动带来的风险。相对于系统层面的灰度,代码层面的灰度可以做得更加细粒度、灵活、简单、易维护,但也存在着代码侵入的问题,即灰度代码与业务代码耦合在一起。 总体而言,本文通过实际需求场景,介绍了灰度发布组件的设计与实现,为读者提供了一种解决灰度发布问题的思路和方法。文章还提到了灰度组件的功能性需求,包括灰度规则配置解析和提供编程接口判定是否灰度,以及留待下一节课中讨论的非功能性需求。 在下一节课中,读者将有机会进一步了解灰度组件的非功能性需求。整体而言,本文为读者提供了深入了解灰度发布组件设计与实现的基础知识,为灰度发布问题的解决提供了有益的思路和方法。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《设计模式之美》
新⼈⾸单¥98
立即购买
登录 后留言

全部留言(13)

  • 最新
  • 精选
  • 小晏子
    在易用性方面,框架接入要简单方便,学习成本低,尽量减少与业务代码的耦合,最 比如能以自动注入的方式提供开关配置。 在性能方面,因为每次请求要获取开关配置信息,所以要让灰度框架尽可能低延迟,尽可能减少对请求本身响应时间的影响。 在容错性方面,要保证不会因为灰度框架本身的异常引起整个请求异常,影响业务可用性,当灰度框架有异常的时候,请求要能回滚到原来的请求方式。
    2020-06-12
    1
    34
  • Jxin
    1.灰度代码不该和业务代码耦合在一起。 2.以替换rpc实现为例。为每个rpc接口都创建防腐层,业务代码依赖防腐层的接口来写逻辑。这样rpc实例的选择和使用就解耦开了。 a.在灰度发布的场景,可以在防腐层加这个功能开关,既与业务代码分离,且一处变更全局生效。 b.接口隔离,服务方提供的api一般功能都比较多,出入参也会比较臃肿。有防腐层,调用方就可以按需设计防腐层接口,用适配的方式隔离掉服务提供方接口的复杂性。 c.开发隔离,不用再等到服务提供方提供接口才能开发了。整个开发过程基于自己的防腐层写代码,写完用mock方式自测。项目经理再也不用担心我的进度被阻塞。 3.单个函数内部的代码逻辑做灰度。这个看情况,原业务逻辑很简单没几行代码,就耦合呗,问题不大。如果原逻辑比较复杂。那么就可能得抽局部功能的中间函数咯。使用侧依赖中间函数,中间函数做灰度切换,新老具体功能各自封装成函数。如此一来,与依赖接口编程异曲同工。隔离复杂性,一处改动全局生效。
    2020-06-12
    19
  • 龙猫
    1、高性能,低延迟 2、容错性,组件异常不影响业务代码 3、易用性,配置简单容易理解 4、低耦合,与业务代码隔离
    2020-10-02
    7
  • Heaven
    本质上,这是一个将原本的老接口和新接口利用表示来隔离开来的功能,这就是一个防腐层 莫名想到了Enum和Iterator的关系 对于这个组件的实现,可以采用切面编程或者提前的过滤器创建 关于这个组件的非功能性需求 1.要求延迟低,不能引用过于复杂的算法去计算如何区分 2.要求异常不影响,如果出现了取值错误或者计算错误,不能影响业务一同的正常调用 3.耦合度低,尽可能的低侵入,这一点可以利用切面或者过滤器实现 4.最好提供对应接口,能让用户实现如何获取到要拦截的值,配置文件书写的值如何去取
    2020-06-12
    6
  • test
    非功能需求: 1. 鲁棒性:不能因为灰度组件出错而导致请求报错; 2. 易用性:可以方便组合不同的灰度算法,使用不同的灰度对象。
    2020-06-12
    2
    5
  • liu_liu
    简单易用,对业务代码侵入尽可能小。框架异常时不影响业务代码。
    2020-06-12
    2
  • Geek_7e0e83
    易用性 通过配置文件进行配置,直接使用框架提供的类和接口完成灰度功能。简单上手,为了不让灰度的逻辑入侵业务代码,提供注解利用切面来完成灰度的功能。对于业务方更加易用 容错性 灰度功能有问题,可以降级回原本的方法继续执行。灰度框架中任何的异常都会调用旧方法去完成,保证系统的正常运行。 拓展性 支持多种灰度规则的配置 性能 灰度框架的逻辑不能耗用过多的时间和资源,全部走内存计算。
    2022-12-29归属地:广东
    1
  • Z宇锤锤
    非功能性 健壮可用 使用便捷
    2021-12-18
    1
  • djfhchdh
    灰度组件的非功能需求:易用性方面,最好支持热加载,不用重启应用,就可以重新加载修改后的灰度规则配置文件;性能方面,延迟要低;容错性方面,如果灰度判定接口出现异常,对这个异常也要有处理逻辑。
    2020-09-08
    1
  • Magic
    灰度组件异常时,安全起见,应该继续走老逻辑
    2020-08-16
    1
收起评论
显示
设置
留言
13
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部