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

王争《设计模式之美》学习笔记

回顾版本1的设计与实现

• MetricsCollector：负责打点采集原始数据，包括记录每次接口请求的响应时间和请求时间戳，并调用 MetricsStorage 提供的接口来存储这些原始数据。
• MetricsStorage 和 RedisMetricsStorage：负责原始数据的存储和读取。
• Aggregator：是一个工具类，负责各种统计数据的计算，比如响应时间的最大值、最小值、平均值、百分位值、接口访问次数、tps。
• ConsoleReporter 和 EmailReporter：相当于一个上帝类（GodClass），定时根据给定的时间区间，从数据库中取出数据，借助Aggregator类完成统计工作，并将统计结果输出到相应的终端，比如命令行、邮件。

gregator 类存在的问题

• Aggregator 类里面只有一个静态函数，有50行左右的代码量，负责各种统计数据的计算。
• 当要添加新的统计功能的时候，我们需要修改 aggregate() 函数代码。一旦越来越多的统计功能添加进来之后，这个函数的代码量会持续增加，可读性、可维护性就变差了。

ConsoleReporter 和 EmailReporter这两个类存在的问题

• 从数据库中取数据、做统计的逻辑都是相同的，可以抽取出来复用，否则就违反了DRY原则。
• 整个类负责的事情比较多，不相干的逻辑糅合在里面，职责不够单一。特别是显示部分的代码逻辑可以剥离出来，设计成一个独立的类。
• 代码中涉及线程操作，并且调用了 Aggregator 的静态函数，所以代码的可测试性也有待提高。

针对版本1的问题进行重构

• 把统计显示所要完成的功能逻辑细分一下，主要包含下面4点：
  • 根据给定的时间区间，从数据库中拉取数据；
  • 根据原始数据，计算得到统计数据；
  • 将统计数据显示到终端（命令行或邮件）；
  • 定时触发以上三个过程的执行。
• 我们可以将上帝类做的很轻量级，把核心逻辑都剥离出去，形成独立的类，上帝类只负责组装类和串联执行流程。
• 具体的重构工作包含以下4个方面：
  • 第1个逻辑：根据给定时间区间，从数据库中拉取数据。这部分逻辑已经被封装在 MetricsStorage 类中了，所以这部分不需要处理。
  • 第2个逻辑：根据原始数据，计算得到统计数据。我们可以将这部分逻辑移动到 Aggregator 类中。这样Aggregator类就不仅仅是只包含统计方法的工具类了。
  • 第3个逻辑：将统计数据显示到终端。我们将这部分逻辑剥离出来，设计成两个类：ConsoleViewer 类和 EmailViewer 类，分别负责将统计结果显示到命令行和邮件中。
  • 第4个逻辑：组装类并定时触发执行统计显示。在将核心逻辑剥离出来之后，这个类的代码变得更加简洁、清晰，只负责组装各个类（MetricsStorage、Aggegrator、StatViewer）来完成整个工作流程。
• 我们需要在应用启动的时候，创建好 ConsoleReporter 对象，并且调用它的 startRepeatedReport() 函数，来启动定时统计并输出数据到终端。同理，我们还需要创建好 EmailReporter 对象，并且调用它的 startDailyReport() 函数，来启动每日统计并输出数据到制定邮件地址。我们通过 MetricsCollector 类来收集接口的访问情况，这部分收集代码会跟业务逻辑代码耦合在一起，或者统一放到类似SpringAOP的切面中完成。

Review版本2的设计与实现

• 重构之后，MetricsStorage 负责存储，Aggregator 负责统计，StatViewer（ConsoleViewer、EmailViewer）负责显示，三个类各司其职。
• ConsoleReporter 和 EmailReporter 负责组装这三个类，将获取原始数据、聚合统计、显示统计结果到终端这三个阶段的工作串联起来，定时触发执行。
• Aggregator 类从一个只包含一个静态函数的工具类，变成了一个普通的聚合统计类。现在，我们可以通过依赖注入的方式，将
  其组装进 ConsoleReporter 和 EmailReporter 类中，这样就更加容易编写单元测试。