框架设计原则（梁飞）

大纲

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 个原则，应该算是比较成熟的原则了。

1 微核 + 插件，很是理想化，例如 SOFA，也有本身的扩展机制。

2 关于领域模型设计，这 3 个模型的职责必定要划分清楚，同时实现无锁编程，这个对于系统的性能很是重要。

3 关于组件协做，一个系统有多个组件，一般须要进行状态的共享，在 Dubbo 中，使用行为进行传递，也就是会话域。

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

5 关于接口分离和模块分包，一般在后期重构可以达到更好的效果？

好了，洋洋洒洒说了很多，读者若有更好的看法，请与我分享，毕竟如今关注这块的人很少了。：）期待和对此感兴趣的人一块儿讨论