96 | 项目实战三:设计实现一个支持自定义规则的灰度发布组件(分析)
王争
该思维导图由 AI 生成,仅供参考
到现在为止,我已经带你学习了接口限流框架和接口幂等框架两个实战项目。接下来,我再带你实战一个新的项目:灰度发布组件。这也是我们专栏的最后一个实战项目。还是老套路,我们把它分为分析、设计、实现三个部分、对应三节课来讲解。今天,我们对灰度发布组件进行需求分析,搞清楚这个组件应该具有哪些功能性和非功能性需求。
话不多说,让我们正式开始今天的学习吧!
需求场景
还记得我们之前接口限流和幂等框架的项目背景吗?我们开发了一个公共服务平台,提供公共业务功能,给其他产品的后端系统调用,避免重复开发相同的业务代码。
最初,公共服务平台提供的是,基于某个开源 RPC 框架的 RPC 格式的接口。在上线一段时间后,我们发现这个开源 RPC 框架的 Bug 很多,多次因为框架本身的 Bug,导致整个公共服务平台的接口不可用,但又因为团队成员对框架源码不熟悉,并且框架的代码质量本身也不高,排查、修复起来花费了很长时间,影响面非常大。所以,我们评估下来,觉着这个框架的可靠性不够,维护成本、二次开发成本都太高,最终决定替换掉它。
对于引入新的框架,我们的要求是成熟、简单,并且与我们现有的技术栈(Spring)相吻合。这样,即便出了问题,我们也能利用之前积累的知识、经验来快速解决。所以,我们决定直接使用 Spring 框架来提供 RESTful 格式的远程接口。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
灰度发布组件设计与实现 本文介绍了一个支持自定义规则的灰度发布组件的设计与实现。作者首先从需求场景出发,讨论了在替换老的RPC服务为新的RESTful接口时,需要进行灰度发布以逐步验证新接口的可靠性。为解决这一问题,作者提出了使用功能开关来灵活切换新老接口调用方式,并通过配置文件或配置中心来优化灵活性。此外,还介绍了灰度功能的实现方式,包括针对请求携带的时间戳、业务ID等信息,按区间、比例或具体值来进行灰度。最后,作者建议在修改复杂功能或核心功能时,也应通过功能开关来灵活控制上下线,以实现快速回滚或新老代码逻辑的切换。 文章重点讲解了代码层面的灰度发布,通过编程来控制是否执行新的代码逻辑,以及灰度执行新的代码逻辑。灰度发布主要解决代码质量问题,通过逐渐放量灰度执行,来降低重大代码改动带来的风险。相对于系统层面的灰度,代码层面的灰度可以做得更加细粒度、灵活、简单、易维护,但也存在着代码侵入的问题,即灰度代码与业务代码耦合在一起。 总体而言,本文通过实际需求场景,介绍了灰度发布组件的设计与实现,为读者提供了一种解决灰度发布问题的思路和方法。文章还提到了灰度组件的功能性需求,包括灰度规则配置解析和提供编程接口判定是否灰度,以及留待下一节课中讨论的非功能性需求。 在下一节课中,读者将有机会进一步了解灰度组件的非功能性需求。整体而言,本文为读者提供了深入了解灰度发布组件设计与实现的基础知识,为灰度发布问题的解决提供了有益的思路和方法。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《设计模式之美》,新⼈⾸单¥98
《设计模式之美》,新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(13)
- 最新
- 精选
- 小晏子在易用性方面,框架接入要简单方便,学习成本低,尽量减少与业务代码的耦合,最 比如能以自动注入的方式提供开关配置。 在性能方面,因为每次请求要获取开关配置信息,所以要让灰度框架尽可能低延迟,尽可能减少对请求本身响应时间的影响。 在容错性方面,要保证不会因为灰度框架本身的异常引起整个请求异常,影响业务可用性,当灰度框架有异常的时候,请求要能回滚到原来的请求方式。2020-06-12134
- Jxin1.灰度代码不该和业务代码耦合在一起。 2.以替换rpc实现为例。为每个rpc接口都创建防腐层,业务代码依赖防腐层的接口来写逻辑。这样rpc实例的选择和使用就解耦开了。 a.在灰度发布的场景,可以在防腐层加这个功能开关,既与业务代码分离,且一处变更全局生效。 b.接口隔离,服务方提供的api一般功能都比较多,出入参也会比较臃肿。有防腐层,调用方就可以按需设计防腐层接口,用适配的方式隔离掉服务提供方接口的复杂性。 c.开发隔离,不用再等到服务提供方提供接口才能开发了。整个开发过程基于自己的防腐层写代码,写完用mock方式自测。项目经理再也不用担心我的进度被阻塞。 3.单个函数内部的代码逻辑做灰度。这个看情况,原业务逻辑很简单没几行代码,就耦合呗,问题不大。如果原逻辑比较复杂。那么就可能得抽局部功能的中间函数咯。使用侧依赖中间函数,中间函数做灰度切换,新老具体功能各自封装成函数。如此一来,与依赖接口编程异曲同工。隔离复杂性,一处改动全局生效。2020-06-1219
- 龙猫1、高性能,低延迟 2、容错性,组件异常不影响业务代码 3、易用性,配置简单容易理解 4、低耦合,与业务代码隔离2020-10-027
- Heaven本质上,这是一个将原本的老接口和新接口利用表示来隔离开来的功能,这就是一个防腐层 莫名想到了Enum和Iterator的关系 对于这个组件的实现,可以采用切面编程或者提前的过滤器创建 关于这个组件的非功能性需求 1.要求延迟低,不能引用过于复杂的算法去计算如何区分 2.要求异常不影响,如果出现了取值错误或者计算错误,不能影响业务一同的正常调用 3.耦合度低,尽可能的低侵入,这一点可以利用切面或者过滤器实现 4.最好提供对应接口,能让用户实现如何获取到要拦截的值,配置文件书写的值如何去取2020-06-126
- test非功能需求: 1. 鲁棒性:不能因为灰度组件出错而导致请求报错; 2. 易用性:可以方便组合不同的灰度算法,使用不同的灰度对象。2020-06-1225
- liu_liu简单易用,对业务代码侵入尽可能小。框架异常时不影响业务代码。2020-06-122
- Geek_7e0e83易用性 通过配置文件进行配置,直接使用框架提供的类和接口完成灰度功能。简单上手,为了不让灰度的逻辑入侵业务代码,提供注解利用切面来完成灰度的功能。对于业务方更加易用 容错性 灰度功能有问题,可以降级回原本的方法继续执行。灰度框架中任何的异常都会调用旧方法去完成,保证系统的正常运行。 拓展性 支持多种灰度规则的配置 性能 灰度框架的逻辑不能耗用过多的时间和资源,全部走内存计算。2022-12-29归属地:广东1
- Z宇锤锤非功能性 健壮可用 使用便捷2021-12-181
- djfhchdh灰度组件的非功能需求:易用性方面,最好支持热加载,不用重启应用,就可以重新加载修改后的灰度规则配置文件;性能方面,延迟要低;容错性方面,如果灰度判定接口出现异常,对这个异常也要有处理逻辑。2020-09-081
- Magic灰度组件异常时,安全起见,应该继续走老逻辑2020-08-161
收起评论