97 | 项目实战三：设计实现一个支持自定义规则的灰度发布组件（设计）
王争
该思维导图由 AI 生成，仅供参考
上一节课，我们介绍了灰度组件的一个需求场景，将公共服务平台的 RPC 接口，灰度替换为新的 RESTful 接口，通过灰度逐步放量，支持快速回滚等手段，来规避代码质量问题带来的不确定性风险。
跟前面两个框架类似，灰度组件的功能性需求也比较简单。上一节课我们做了简单分析，今天我们再介绍一下，这个组件的非功能性需求，以及如何通过合理的设计来满足这些非功能性需求。
话不多说，让我们正式开始今天的学习吧！
非功能性需求
上一节课中，我给你留了一个作业，参照限流框架，分析一下灰度组件的非功能性需求。对于限流框架，我们主要从易用性、扩展性、灵活性、性能、容错性这几个方面，来分析它的非功能性需求。对于灰度组件，我们同样也从这几个方面来分析。
易用性
在前面讲到限流框架和幂等框架的时候，我们都提到了“低侵入松耦合”的设计思想。因为框架需要集成到业务系统中使用，我们希望它尽可能低侵入，与业务代码松耦合，替换、移除起来更容易些。因为接口的限流和幂等跟具体的业务是无关的，我们可以把限流和幂等相关的逻辑，跟业务代码解耦，统一放到公共的地方来处理（比如 Spring AOP 切面中）。
但是，对于灰度来说，我们实现的灰度功能是代码级别的细粒度的灰度，而替代掉原来的 if-else 逻辑，是针对一个业务一个业务来做的，跟业务强相关，要做到跟业务代码完全解耦，是不现实的。所以，在侵入性这一点上，灰度组件只能做妥协，容忍一定程度的侵入。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了设计实现一个支持自定义规则的灰度发布组件的非功能性需求和框架设计思路。在非功能性需求方面，主要包括易用性、扩展性、灵活性、性能和容错性。在框架设计思路方面，重点讨论了如何支持更灵活、更复杂的灰度规则和实现灰度规则热更新。对于灰度规则的热更新，建议使用定时器定期从配置文件中读取灰度规则配置信息，并且解析加载到内存中，替换老的灰度规则。此外，文章还提到了支持更加灵活的、复杂的灰度规则的设计思路，包括使用规则引擎或支持编程实现灰度规则。总的来说，本文为读者提供了灰度发布组件设计和实现的思路和方法，对于需要实现灰度发布组件的开发人员具有一定的参考价值。文章还讲解了灰度组件的非功能性需求，主要包含易用性、扩展性、灵活性、性能、容错性这样几个方面，并且针对性地解释了对应的设计思路。在易用性方面，重点讲解了“低侵入、松耦合”的设计思想。在扩展性、灵活性方面，除了像限流框架那样，支持各种格式、存储方式的配置方式之外，灰度组件还希望能支持复杂的灰度规则。在性能方面，灰度组件没有需要特殊处理的地方。在容错性方面，限流框架要高度容错，容忍短暂、小规模的限流失效，但不容忍框架异常导致的接口响应异常。幂等框架正好相反，不容忍幂等功能的失效，一旦出现异常，幂等功能失效，我们的处理原则是让业务也失败。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《设计模式之美》，新⼈⾸单¥98
《设计模式之美》，新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(11)
- 最新
- 精选
汝林外史发布之前进行充分的测试不就行了吗？灰度测试是针对什么场景呢？作者回复: 即便是充分测试，也很难保证一点都不出问题呢
2020-07-1045
Jxin
1.这要看系统运行日志属不属于业务逻辑的一部分。我认为是属于的。毕竟我要的是可追溯的业务代码，而不是只有功能的业务代码。可追溯我认为是业务的一部分。同理还包括主动告警。 2.所以我认为算不上侵入。至于耦合，log的实现层是可以替换的，所以也没有耦合。2020-06-1529
，我在工作的过程中,遇到的常规业务方法大概是这样的: 1.权限校验,权限合法才能继续往下走,不合法就抛异常 2.参数校验,参数合法才能继续往下走,不合法就抛异常 3.业务处理,处理成功才能继续往下走,不成功就抛异常 4.业务附加处理(例如短信通知,记录业务日志),处理完成返回,失败则在第三方打印异常,这个部分一般不会出现异常 如果再加上课里面讲到的幂等框架,限流框架等,想要做到零侵入,低耦合,个人感觉并不现实,应该看项目的具体安排,如果时间紧任务重,以服务调用的方式也未尝不可,也就一行代码的事,侵入性并没有想象中的那么夸张,如果时间宽裕,做一个漂亮的切面,也是不错的 课后题: 打印日志算不算对业务代码的侵入,个人认为完全看对"业务代码"范围的定义。比如一次保存稿件的功能,有的人认为只有 save(docuemnt) 这一步才算业务,其他都属于附加功能,但有的人认为权限校验,参数校验,业务处理,业务附加处理全部加起来才算一个完整的业务流程,这时,关键性的业务日志打印/存储其实也属于业务范围内的事情了,权限校验和参数校验也一样。我还是倾向于认为第二种更接近"业务代码"范围的定义。 简而言之,我的观点是 日志打印/存储如果是为了debug,那么则不属于业务范围内,对代码有一定侵入性,如果是为了留档,方便以后的核对等工作,那么则属于业务范围内的事情,对代码没有侵入性。2020-06-1520
不惑ing低侵入松耦合，不是不侵入不耦合，所以Logger符合2020-07-174
testLogger需要用户控制打什么日志，在哪里打，算是牺牲了一定耦合度2020-06-154
守拙Logger框架是否符合"低侵入, 松耦合"要根据Logger框架的提供的功能来判定. 例如Logger框架提供全局配置的开关功能, 就体现了一定程度的低侵入. 因为不需要Log时全局关闭对业务没有丝毫影响. Logger框架是否做了足够的封装, 适用于多种场景: 本地log, log上传至Server, log写入db/文件系统; 是否支持多种格式的log: 纯文本, json格式, xml格式等是衡量Log易用性, 灵活性, 可扩展性的量化指标. 总结: 项目只要使用Log框架, 就无法避免耦合的情况. 既然Log对于项目是必须的, 我们就应该综合参考Log框架是否低侵入松耦合, 易用性, 扩展性, 性能, 可复用性等指标, 以量化的方式做框架的选型.2020-07-143
Heaven从耦合的角度来看,是在业务代码之中打印的,这是和业务代码耦合在了一起,但是和业务无关,需要删去的时候,不需要修改业务代码,只移除非业务代码,我的角度来看,是不属于对于业务代码的侵入耦合的2020-06-153
小晏子如果使用的是log4j，logback等这种基于实现类编程的框架，那么是有侵入，有耦合性的。 如果使用的是slf4j这种日志接口框架，那么多业务代码是无侵入的，低耦合的，因为底层具体实现的log框架可以无缝替换为另外一个。2020-06-152
只为更好老师，业务逻辑的灰度如何去做？如果业务代码写很多开关，也会降低代码的可维护性、可读性等，另外数据模型的调整，比如字段修改、删除如何做灰度呢2021-09-231
否极泰来不算，因为我们需要查看日志定位问题，我觉得是属于业务的一部分。2021-04-101
收起评论
