设计模式：如何对非业务的通用框架开发进行需求分析和设计

一、通用框架设计方法

1、对于非业务通用框架的开发，我们在做需求分析的时候，除了功能性需求分析之外，

还需要考虑框架的非功能性需求。比如框架的易用性，性能，扩展性，容错性，通用性等。

（1）易用性

易用性表现在是否易集成，易插拔，跟业务代码是否松耦合，提供的接口是否够灵活等

（2）性能

框架本身不能影响业务系统性能，一个要低延迟（对接口响应时间影响小），另一个要对内存消耗不能太大。

（3）扩展性

使用者可以在不修改框架源码，甚至不拿到框架源码的情况下，为框架扩展新的功能。

（4）容错性

不能因为框架的异常导致接口请求出错，所以要对框架可能存在的各种异常情况考虑全面，对外暴露的接口抛出所有运行时，非运行时异常都要进行捕获处理。

（5）通用性

为了提高框架的复用性，能够灵活应用到各种场景中。框架在设计时，要尽可能通用。

2、对于复杂的框架的设计，很多人往往觉得无从下手。

小技巧：画产品线框图，聚焦简单应用场景，设计实现最小原型，画系统设计图等。

这些技巧的目的都是为了让问题简化，具体，明确，提供一个迭代设计开发的基础，逐步推进。

二、通用框架案例：性能计数器项目

1、最小原型设计：

2、框架流程：

（1）数据采集：负责打点采集原始数据，包括记录每次接口请求的响应时间和请求时间。数据采集过程要高度容错，不能影响到接口本身的可用性。除此之外，因为这部分功能是暴露给框架的使用者的，所以在设计数据采集 API 的时候，我们也要尽量考虑其易用性。

（2）存储：负责将采集的原始数据保存下来，以便后面做聚合统计。数据的存储方式有多种，比如：Redis、MySQL、HBase、日志、文件、内存等。数据存储比较耗时，为了尽量地减少对接口性能（比如响应时间）的影响，采集和存储的过程采用异步方式完成。

（3）聚合统计：负责将原始数据聚合为统计数据。比如：max、min、avg、pencentile、count、tps 等。为了支持更多的聚合统计规则，代码希望尽可能灵活、可扩展。

（4）显示：负责将统计数据以某种格式显示到终端。比如：输出到命令行、邮件、网页、自定义显示终端等。

3、框架实现

（1）写代码的过程本就是一个修修改改，不停调整的过程，肯定不是一气呵成。你看到的那些大牛开源项目的设计和实现，也都是在不停优化，修改过程中产生的。

比如，我们熟悉的unix系统，第一版很简单，粗糙，代码不到1万行。所以，迭代思想很重要，不要刚开始就追求完美。

（2）面向对象设计和实现要做的事情，就是把合适的代码放到合适的类中。至于到底哪种划分方法，判定的标准是让代码尽量地满足低耦合，高内聚，单一职责，对扩展开放对修改关闭等。之前讲的各种设计原则和思想，尽量地做到代码可复用，易读，易扩展，易维护。