关于软件架构设计的一些思考--通用架构设计模式

最近在着手设计一个服务发布，治理的框架，参考了几个主流框架的代码，比如阿里的Dubbo，传输层的Netty，容器层的Tomcat等等，有一些体会。

经典的《面向对象分析与设计》一书中阐述了为什么设计是按层次划分的，种种好处自己去翻书，总结这么多框架，有一些架构设计的基本模式可以抓住。

通用的设计，尤其是大型的框架可以分为4层：接口层，抽象层，流程实现与适配层，具体实现层。

接口层定义了整个框架所具备的功能，最好都用接口实现，不要用抽象类。接口的扩展性优于抽象类。Thrift采用了抽象类来设计顶层的功能，后期想扩展其实挺难的。

关于接口层的设计有一些要点：

1. 接口的粒度要小，参考单一职责原则

2. 用一个较大的接口适配多个小接口，而不要设计一个大接口。小接口的扩展性优于大接口

3. 接口的设计只需要考虑要具备的功能，不需要考虑类的属性，如何实现等等，这些在抽象层和实现层扩展

抽象层定义了实现接口的抽象类，都用抽象类实现，主要的功能有：

1. 给接口提供默认实现

2. 提供新的抽象方法扩展接口

3. 给子类提供公共的属性，方法

4. 比如定义调用的基本流程，这个在设计大型框架，底层采用第三方实现的时候尤其重要。参考模板模式

流程实现与适配层，这层采用普通类实现，继承抽象层，主要的功能有：

1. 实现抽象层和接口层定义的抽象方法

2. 定义框架调用的具体流程

3. 如果底层采用第三方框架，那么需要做适配和装饰层，参考适配器模式和装饰器模式

具体实现层，这层采用普通类实现，主要是实现具体的功能，但是不要参与到框架调用的流程。

这个4层结构是一个可扩展的，健壮的设计，接口层定义功能，抽象层和流程实现与适配层定义了框架调用的流程，具体实现层是可插拔的，可以采用多种实现。

实际的设计可以根据框架要实现的功能进行裁剪，比如不会有多种实现，就可以把3，4层合并。如果是像Dubbo这种底层支持多种传输层和协议层的框架，就需要完整的4层结构，并且需要好好设计抽象层和流程层，因为框架具体的流转是在这两层，只是涉及到底层时，才会调用具体的第三方实现。