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

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

getDarkFeature()
addProgrammedDarkFeature()
loadRule()
getDarkFeature()
setDarkFeatures()
addProgrammedDarkFeature()
dark()
enabled()
parseDarkRule()
getDarkFeature()
DarkRuleConfig
DarkFeatureConfig
getDarkFeature()
loadRule()
DarkLaunch
DarkRule
IDarkFeature
DarkFeature
DarkRule
DarkRuleConfig
DarkLaunch
灰度规则热更新
灰度规则的内存组织方式
灰度规则的语法格式
灰度规则的格式和存储方式
课堂讨论
项目实战环节总结
添加、优化灰度组件功能
实现灰度组件基本功能
灰度组件功能需求整理
重点回顾
实现篇:设计实现一个支持自定义规则的灰度发布组件

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

上两节课,我们讲解了灰度组件的需求和设计思路。不管是之前讲过的限流、幂等框架,还是现在正在讲的灰度组件,这些框架、组件、类库的功能性需求都不复杂,相反,非功能性需求是开发的重点、难点。
今天,我们按照上节课给出的灰度组件的设计思路,讲解如何进行编码实现。不过今天对实现的讲解,跟前面两个实战项目有所不同。在前面两个项目中,我都是手把手地从最基础的 MVP 代码讲起,然后讲解如何 review 代码发现问题、重构代码解决问题,最终得到一份还算高质量的代码。考虑到已经有前面两个项目的学习和锻炼了,你应该对开发套路、思考路径很熟悉了,所以,今天我们换个讲法,就不从最基础的讲起了,而是重点讲解实现思路。
话不多说,让我们正式开始今天的学习吧!

灰度组件功能需求整理

针对上两节课给出的开发需求和设计思路,我们还是按照老套路,从中剥离出 V1 版本要实现的内容。为了方便我讲解和你查看,我把灰度组件的开发需求和设计思路,重新整理罗列了一下,放到了这里。

1. 灰度规则的格式和存储方式

我们希望支持不同格式(JSON、YAML、XML 等)、不同存储方式(本地配置文件、Redis、Zookeeper、或者自研配置中心等)的灰度规则配置方式。实际上,这一点跟之前的限流框架中限流规则的格式和存储方式完全一致,代码实现也是相同的,所以在接下来的讲解中,就不重复啰嗦了,你可以回过头去看下第 92 讲
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了如何设计和实现一个支持自定义规则的灰度发布组件。作者首先回顾了前两节课讲解的灰度组件的需求和设计思路,强调了非功能性需求在开发中的重要性。接着,文章详细讲解了灰度组件的功能需求,包括灰度规则的格式和存储方式、灰度规则的语法格式、灰度规则的内存组织方式以及灰度规则的热更新。在V1版本中,作者计划先实现支持YAML格式本地文件的配置存储方式,然后逐步完善其他功能。 文章重点讲解了灰度组件的设计思路和实现思路,突出了技术实现的重要性。通过示例代码和详细解释,读者可以了解灰度组件的核心类和其功能,包括DarkLaunch类作为灰度组件的顶层入口类,DarkRuleConfig类用于将灰度规则映射到内存中,DarkRule类包含所有要灰度的业务功能的灰度规则,以及DarkFeature类表示每个要灰度的业务功能的灰度规则。 总体而言,本文提供了一个清晰的指南,帮助读者快速了解如何开发一个灰度发布组件,同时突出了技术实现的重要性。文章通过实例代码和详细解释,使读者能够深入了解灰度组件的设计和实现思路,从而在实际项目中应用相关技术。 文章还提到了项目实战环节的重要性,通过限流、幂等、灰度三个实战项目的学习,帮助读者理解功能性、非功能性需求分析和高质量代码实现的重要性。作者希望读者能够通过这些例子,学会思考代码复用和抽象成框架、类库、组件的能力,从而在实际项目中更好地应用所学知识。 总的来说,本文对灰度发布组件的设计和实现进行了详细的讲解,同时强调了项目实战环节的重要性,为读者提供了宝贵的学习资源。

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

全部留言(28)

  • 最新
  • 精选
  • Jagger
    DarkLaunch 构造器包含定时轮询,会不会影响单元测试?

    作者回复: 嗯嗯,会,最好是再声明一个构造函数,传递executor进去

    2020-08-07
    14
  • robincoin
    mq和数据库灰度是不是要对mq和数据库再封装一层,方便aop处理?

    作者回复: 支持! 封装来进一步简化开发!

    2020-06-17
    2
    8
  • 汝林外史
    好像dark方法中没有对区间的规则进行处理

    作者回复: 有呀,你说没有是指的哪部分?能详细说说吗

    2020-07-15
    2
    1
  • 小晏子
    这个DarkFeature类中灰度规则的解析代码不优雅的地方在于不够灵活,如果有新的灰度规则要加入,就需要再添加if else作处理,破坏了开闭原则,为了解决这一问题,可以使用工厂模式➕策略模式来保证开闭原则和消除if/else,使用工厂模式来实现针对每个灰度规则的处理,使用“查表法”的策略模式来消除if/else!
    2020-06-17
    1
    45
  • Lee
    可以使用解释器模式,将不同类型的规则解析拆分到不同的类中。
    2020-06-17
    1
    19
  • tingye
    可以考虑用职责链模式,将不同规则字符串的解析抽象为单独的handle类,依次解析直到完成处理,也方便扩展对新规则编写语法的解析
    2020-06-17
    16
  • Heaven
    在此类场景下,我们可以简单的使用工厂类去封装规则的解析, 但是我个人觉着,应该以配置文件中配置的规则为主,所以,第二版需要在配置文件中写上实现接口的全限定类名,反射获取实例,同样支持更新,这样配置文件的Map就可以移除了,而且可以将简单的原生三种解析规则也抽象为接口,利用策略类进行区分调用
    2020-06-17
    7
  • 强哥
    这个灰度组件感觉适用简单场景,规则之间的表达式、优先级等组合方式不支持,规则的定义很重要。热更新可以通过zk下放到服务器上,通过sdk将配置信息加载到内存中。
    2020-06-21
    4
  • Jxin
    1.定时任务在方法内部创建和使用,这样就没办法手动调定时任务的退出方法了。 2.感觉业务接口的路由规则的选型和路由规则的具体实现应该分离。DarkFear里面应该只要表明,哪个业务接口用哪个灰度规则,这个意图就好。至于灰度规则的具体实现,包括dsl的解析和灰度规则的执行都应该剥离出来单独封装。
    2020-06-17
    4
  • gogo
    可以考虑引入策略模式和工厂模式,消除if else
    2020-06-17
    4
收起评论
显示
设置
留言
28
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部