98 | 项目实战三:设计实现一个支持自定义规则的灰度发布组件(实现)
该思维导图由 AI 生成,仅供参考
灰度组件功能需求整理
1. 灰度规则的格式和存储方式
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何设计和实现一个支持自定义规则的灰度发布组件。作者首先回顾了前两节课讲解的灰度组件的需求和设计思路,强调了非功能性需求在开发中的重要性。接着,文章详细讲解了灰度组件的功能需求,包括灰度规则的格式和存储方式、灰度规则的语法格式、灰度规则的内存组织方式以及灰度规则的热更新。在V1版本中,作者计划先实现支持YAML格式本地文件的配置存储方式,然后逐步完善其他功能。 文章重点讲解了灰度组件的设计思路和实现思路,突出了技术实现的重要性。通过示例代码和详细解释,读者可以了解灰度组件的核心类和其功能,包括DarkLaunch类作为灰度组件的顶层入口类,DarkRuleConfig类用于将灰度规则映射到内存中,DarkRule类包含所有要灰度的业务功能的灰度规则,以及DarkFeature类表示每个要灰度的业务功能的灰度规则。 总体而言,本文提供了一个清晰的指南,帮助读者快速了解如何开发一个灰度发布组件,同时突出了技术实现的重要性。文章通过实例代码和详细解释,使读者能够深入了解灰度组件的设计和实现思路,从而在实际项目中应用相关技术。 文章还提到了项目实战环节的重要性,通过限流、幂等、灰度三个实战项目的学习,帮助读者理解功能性、非功能性需求分析和高质量代码实现的重要性。作者希望读者能够通过这些例子,学会思考代码复用和抽象成框架、类库、组件的能力,从而在实际项目中更好地应用所学知识。 总的来说,本文对灰度发布组件的设计和实现进行了详细的讲解,同时强调了项目实战环节的重要性,为读者提供了宝贵的学习资源。
《设计模式之美》,新⼈⾸单¥98
全部留言(28)
- 最新
- 精选
- JaggerDarkLaunch 构造器包含定时轮询,会不会影响单元测试?
作者回复: 嗯嗯,会,最好是再声明一个构造函数,传递executor进去
2020-08-0714 - robincoinmq和数据库灰度是不是要对mq和数据库再封装一层,方便aop处理?
作者回复: 支持! 封装来进一步简化开发!
2020-06-1728 - 汝林外史好像dark方法中没有对区间的规则进行处理
作者回复: 有呀,你说没有是指的哪部分?能详细说说吗
2020-07-1521 - 小晏子这个DarkFeature类中灰度规则的解析代码不优雅的地方在于不够灵活,如果有新的灰度规则要加入,就需要再添加if else作处理,破坏了开闭原则,为了解决这一问题,可以使用工厂模式➕策略模式来保证开闭原则和消除if/else,使用工厂模式来实现针对每个灰度规则的处理,使用“查表法”的策略模式来消除if/else!2020-06-17145
- Lee可以使用解释器模式,将不同类型的规则解析拆分到不同的类中。2020-06-17119
- tingye可以考虑用职责链模式,将不同规则字符串的解析抽象为单独的handle类,依次解析直到完成处理,也方便扩展对新规则编写语法的解析2020-06-1716
- Heaven在此类场景下,我们可以简单的使用工厂类去封装规则的解析, 但是我个人觉着,应该以配置文件中配置的规则为主,所以,第二版需要在配置文件中写上实现接口的全限定类名,反射获取实例,同样支持更新,这样配置文件的Map就可以移除了,而且可以将简单的原生三种解析规则也抽象为接口,利用策略类进行区分调用2020-06-177
- 强哥这个灰度组件感觉适用简单场景,规则之间的表达式、优先级等组合方式不支持,规则的定义很重要。热更新可以通过zk下放到服务器上,通过sdk将配置信息加载到内存中。2020-06-214
- Jxin1.定时任务在方法内部创建和使用,这样就没办法手动调定时任务的退出方法了。 2.感觉业务接口的路由规则的选型和路由规则的具体实现应该分离。DarkFear里面应该只要表明,哪个业务接口用哪个灰度规则,这个意图就好。至于灰度规则的具体实现,包括dsl的解析和灰度规则的执行都应该剥离出来单独封装。2020-06-174
- gogo可以考虑引入策略模式和工厂模式,消除if else2020-06-174