框架设计原则(梁飞)

大纲

1 模块分包原则
2 框架扩展原则
3 领域划分原则
4 接口分离原则
5 组件协作原则
6 功能演进原则

我将对每个原则进行自己的解读,如有不对,还请指教 :)


1 模块分包原则

说说我的理解。这里其实是从框架结构的解读来解读,这里的包指的是 Maven 的 module。

复用度,指的是 maven 包的复用。可以理解为工具类。这个工具类不应该变化无常。

稳定度:被依赖的包应该保持稳定,或者说,被依赖者应当比依赖者稳定,且不能成环状依赖。如果不稳定,将会影响其他的包。

抽象度,越抽象,越稳定。越具体,越容易变化。

同时,梁飞给出了一个公式,但是实践起来有点麻烦…….

关于模块分包,可以参见更详细的博客。 以HTTL为例讲讲模块分包&领域模型&扩展框架


2 框架扩展原则

这是其实是说的比较多的东西了。

什么是微核心 + 插件?按照作者的说法,核心只负责装配插件。这样,无论是作者自己的功能,还是第三方的功能,都是平等的,再多的插件也不会影响软件架构,因为没有硬编码,且都是可以卸载的。甚至微核也是可以扩展的。:)

同时,插件的组装规则是统一的。说到这里,你应该想到了 IDEA,Maven,Eclipse 等等。

然后说外置生命周期。这个其实我是有一点不理解的。按照作者的说法,其实是说,框架只负责管理对象,对象的出生和死亡不由框架负责。即,用户应将实例注册到框架中。

但 Spring 似乎不是这么做的。同时,如果使用注册机制,那么就需要硬编码。或者说,Spring 本身就是管理 Bean 生命周期的框架,而 Dubbo 的职责不在于此?

最少化概念模型,这个其实是一种优化。

一致化数据模型:例如 URL 这种对象,就是一致化数据模型,拒绝使用 String 拼接,解析。


3 领域划分原则

这是在框架设计中,是非常重要的。

PPT 中已经说的非常清楚,我就不再说明。其中,Invocation 一定要轻量。否则,对 GC 来说,将是很大的压力(使用对象池?性能不好。)

说说他的好处:

  1. 结构清晰,这个不必讲吧。
  2. 充血模型……这个怎么理解?
  3. 可变和不可变状态分离,可变状态集中。通常实体域都是只读的,即不变状态。会话域都是可变状态。
  4. 所有领域模型线程安全。无锁编程(lock-free 非常重要)。

关于他们的线程安全性:

  1. 服务域无状态,天生线程安全。
  2. 实体域属性只读,线程安全。
  3. 会话域工作在栈中,线程安全。

所以,需要保证他们是这么设计的,才能实现无锁编程。


4 接口分离原则

关于接口分离,我认为是单一职责的一种实现。

其中提到 API 和 SPI,API 面向用户,SPI 面向开发者。两者必须分离。

声明式 API 和过程式 SPI ,没看懂,看懂的说一下。:)

API 可配置,一定可编程,这个不用说吧。

区分命令和查询,例如,不应该有 updateAndGet 这个方法(不包括原子类),应该分成 2 个方法,保证 get 方法幂等。

对称性接口:很简单,有 get 方法,就应该有 set 方法,有 add 就由 remove,称之为对称性和完备性。这样用户能自行推导出接口。

兼容性:如果接口加方法,应该是增加子接口的方式。其他的没看明白…….


5 组件协作原则

这个就比较爽了,我们知道 Dubbo 是管道式设计。一个 Invoker 贯通整个流程,事实上,web 服务器都是这么设计的。例如 Tomcat ,Netty。

关于派发,还记得 Spring 的 dispatchServlet 吗?

关于状态的共享:

  • 分布是什么?即通过行为传递(适合交互性系统)。
  • 共享是什么?通过一个固定的点获取,称之为仓库(适合管理状态的系统)。

主过程拦截,还记得 Mybatis 留给我们的插件吗?还记得 Spring 留给我们的拦截器吗?框架要在关键节点留出拦截点供用户扩展。

事件派发:观察者模式,Reactor 模式,另外提到 Proactor 模式,查了一下,通常在 GNU 编程中,由 OS 支持。

Dubbo 暴露、引用、调用事件,都预留了监听器。

关键路径,即在管道使用职责连模式进行拦截,保证每个拦截器职责单一。

非关键路径,需要有监听机制,不能影响主流程运行。

关于协作防御,我理解为防御性编程。

  1. 分离可靠操作和不可靠操作。不可靠操作尽量范围要小。
  2. 状态分离,尽量无状态。状态要尽可能小。
  3. 对状态要尽早验证,因为如果失败,通常无人回滚。前后断言验证状态正确性。
  4. 异常防御,应该是预见性的异常,异常包含环境信息。
  5. 降低修改成本,防止埋雷:不要根据异常类型做分支判断。保持 null 和 empty 一致。

6 功能演进原则

第一就是开闭原则,微核心加插件机制能够支持。
软件质量的下降,来源于修改。

加功能的姿势:应该是增量式,而不是扩充式,即不在原有基础上修改,而是新增加功能。

关于高阶:顶层接口尽量抽象,且不能依赖底层实现。这样,当底层实现变化时,高层无需变化。

例如 Dubbo 泛化,在顶层就足够抽象,底层实现方式不影响高层。


总结

以上是梁飞总结。

今天说的框架设计和现在大部分人喜欢说的架构设计有所不同,现在似乎只需要再 processon 上放几个阿里云组件,再连几条线,就是架构设计了 :)

我个人认为,框架设计更能考验一个程序员对程序的抽象和管理能力(也许措辞不当?)

然后,再说说我的总结:关于一个系统的设计,这里应该指的是框架的设计,首先要知道用户需求(废话)。根据需求抽象出模型,再变成代码,且是可扩展,可复用的代码。

这里提到的 6 个原则,应该算是比较成熟的原则了。

微核 + 插件,非常理想化,例如 SOFA,也有自己的扩展机制。

关于领域模型设计,这 3 个模型的职责一定要划分清楚,同时实现无锁编程,这个对于系统的性能非常重要。

关于组件协作,一个系统有多个组件,通常需要进行状态的共享,在 Dubbo 中,使用行为进行传递,也就是会话域。

关于功能演进,请遵循开闭原则,但前提通常是有一个好的内核。

关于接口分离和模块分包,通常在后期重构能够达到更好的效果?

好了,洋洋洒洒说了不少,读者如有更好的见解,请与我分享,毕竟现在关注这块的人不多了。:)

EOF


框架设计原则(梁飞)
http://thinkinjava.cn/2018/10/20/2018/2018-10-20-框架设计原则(梁飞)/
作者
莫那·鲁道
发布于
2018年10月20日
许可协议