框架设计原则（梁飞）
大纲
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 来说，将是很大的压力（使用对象池？性能不好。）
说说他的好处：
- 结构清晰，这个不必讲吧。
- 充血模型……这个怎么理解？
- 可变和不可变状态分离，可变状态集中。通常实体域都是只读的，即不变状态。会话域都是可变状态。
- 所有领域模型线程安全。无锁编程（lock-free 非常重要）。
关于他们的线程安全性：
- 服务域无状态，天生线程安全。
- 实体域属性只读，线程安全。
- 会话域工作在栈中，线程安全。
所以，需要保证他们是这么设计的，才能实现无锁编程。
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 暴露、引用、调用事件，都预留了监听器。
关键路径，即在管道使用职责连模式进行拦截，保证每个拦截器职责单一。
非关键路径，需要有监听机制，不能影响主流程运行。
关于协作防御，我理解为防御性编程。
- 分离可靠操作和不可靠操作。不可靠操作尽量范围要小。
- 状态分离，尽量无状态。状态要尽可能小。
- 对状态要尽早验证，因为如果失败，通常无人回滚。前后断言验证状态正确性。
- 异常防御，应该是预见性的异常，异常包含环境信息。
- 降低修改成本，防止埋雷：不要根据异常类型做分支判断。保持 null 和 empty 一致。
6 功能演进原则
第一就是开闭原则，微核心加插件机制能够支持。 软件质量的下降，来源于修改。
加功能的姿势：应该是增量式，而不是扩充式，即不在原有基础上修改，而是新增加功能。
关于高阶：顶层接口尽量抽象，且不能依赖底层实现。这样，当底层实现变化时，高层无需变化。
例如 Dubbo 泛化，在顶层就足够抽象，底层实现方式不影响高层。
总结
以上是梁飞总结。
今天说的框架设计和现在大部分人喜欢说的架构设计有所不同，现在似乎只需要再 processon 上放几个阿里云组件，再连几条线，就是架构设计了 ：）
我个人认为，框架设计更能考验一个程序员对程序的抽象和管理能力（也许措辞不当？）
然后，再说说我的总结：关于一个系统的设计，这里应该指的是框架的设计，首先要知道用户需求（废话）。根据需求抽象出模型，再变成代码，且是可扩展，可复用的代码。
这里提到的 6 个原则，应该算是比较成熟的原则了。
微核 + 插件，非常理想化，例如 SOFA，也有自己的扩展机制。
关于领域模型设计，这 3 个模型的职责一定要划分清楚，同时实现无锁编程，这个对于系统的性能非常重要。
关于组件协作，一个系统有多个组件，通常需要进行状态的共享，在 Dubbo 中，使用行为进行传递，也就是会话域。
关于功能演进，请遵循开闭原则，但前提通常是有一个好的内核。
关于接口分离和模块分包，通常在后期重构能够达到更好的效果？
好了，洋洋洒洒说了不少，读者如有更好的见解，请与我分享，毕竟现在关注这块的人不多了。：）
正文到此结束
- 本文标签： 软件 http id spring servlet 安全 Netty 插件 src MQ 云 质量 cat API dubbo IO eclipse 压力 管理 实例 总结 bean 幂等 maven 线程 IDE 解析 锁 监听器 Reactor 服务器 数据 程序员 开发 数据模型 原子类 web https 开发者 CTO mybatis 生命 架构设计 update ip UI 需求 阿里云 博客 模型 java tomcat 配置 代码
- 版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
