《设计模式之美》运用学过的设计原则和思想完善之前讲的性能计数器项目（下）

最新推荐文章于 2024-07-15 14:15:31 发布

linglongwunv

最新推荐文章于 2024-07-15 14:15:31 发布

阅读量108

点赞数

分类专栏：课程学习笔记文章标签：设计模式

本文链接：https://blog.csdn.net/linglongwunv/article/details/109099279

版权

72 篇文章 6 订阅

订阅专栏

代码重构优化

我们可以将 ConsoleReporter 和 EmailReporter 中的相同代码逻辑，提取到父类 ScheduledReporter 中，以解决代码重复问题。
上一步的重构之后，EmailReporter 中的 startDailyReport() 函数的核心逻辑已经被抽离出去了，较复杂的、容易出 bug 的就只剩下计算 firstTime 的那部分代码了。我们可以将这部分代码继续抽离出来，封装成一个函数 trimTimeFieldsToZeroOfNextDay()，然后，单独针对这个函数写单元测试。
但我们发现这个函数的可测试性仍然不好，因为它强依赖当前的系统时间。解决方法是将强依赖的部分通过参数传递进来，对TimeFieldsToZeroOfNextDay() 函数进行重构。

版本3已经实现了大部分的功能，还有以下几个小的功能点没有实现：
- 被动触发统计的方式，也就是需求中提到的通过网页展示统计信息。我们可以复用框架现在的代码，编写一些展示页面和提供获取统计数据的接口即可。
- 对于自定义显示终端，只需要提供一些获取统计数据的接口，监控平台通过这些接口拉取数据来显示即可。
- 自定义显示格式。将显示终端和显示格式的代码分离，让显示终端支持配置不同的显示格式。

框架的使用者将框架集成到自己的系统中时，主要用到MetricsCollector 和 EmailReporter、ConsoleReporter 这几个类。
为了让框架用起来更加简单（能将组装的细节封装在框架中，不暴露给框架使用者），又不失灵活性（可以自由组装不同的 MetricsStorage 实现类、StatViewer 实现类到 ConsoleReporter 或 EmailReporter），也不降低代码的可测试性（通过依赖注入来组装类，方便在单元测试中 mock），我们可以额外地提供一些封装了默认依赖的构造函数，让使用者自主选择使用哪种构造函数来构造对象。
RedisMeticsStorage 和 EmailViewer 还需要另外一些配置信息才能构建成功，我们可以将这些配置信息放到配置文件中。

第一个问题是采集和存储要异步来执行。我们在 MetricsCollector 中引入GoogleGuavaEventBus 来解决。
第二个问题是大数据量导致内存溢出。当统计的时间间隔较大的时候，我们可以将其划分为一些小的时间区间（比如10分钟作为一个统计单元），针对每个小的时间区间分别进行统计，然后将统计得到的结果再进行聚合，得到最终整个时间区间的统计结果。对于percentile的统计要稍微复杂一些，我们分批从 Redis 中读取数据，然后存储到文件中，再根据响应时间从小到大利用外部排序算法来进行排序，排序完成之后，再从文件中读取第 count*percentile（count 表示总的数据个数，percentile 就是百分比，99百分位就是0.99）个数据，就是对应的 percentile 响应时间。

框架在兼顾易用性的同时，也可以灵活地替换各种类对象，比如 MetricsStorage、StatViewer。举个例子来说，如果我们要让框架基于 HBase 来存储原始数据而非Redis，那我们只需要设计一个实现 MetricsStorage 接口的 HBaseMetricsStorage 类，传递给 MetricsCollector 和 ConsoleReporter、EmailReporter 类即可。

除了接口统计这样一个需求，这个框架还可以适用到其他哪些场景中。比如是否还可以处理其他事件的统计信息，比如 SQL 请求时间的统计、业务统计（比如支付成功率）等。

关注