框架设计原则（梁飞）
大纲
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 中，使用行为进行传递，也就是会话域。
关于功能演进，请遵循开闭原则，但前提通常是有一个好的内核。
关于接口分离和模块分包，通常在后期重构能够达到更好的效果？
好了，洋洋洒洒说了不少，读者如有更好的见解，请与我分享，毕竟现在关注这块的人不多了。：）
正文到此结束
- 本文标签： API 插件 src MQ 云 质量 cat 管理 实例 dubbo IO eclipse 压力 解析 总结 bean 幂等 maven 线程 IDE 程序员 锁 监听器 Reactor 服务器 数据 CTO 开发 数据模型 原子类 web https 开发者 需求 mybatis 生命 架构设计 update ip UI 代码 阿里云 博客 模型 java tomcat 配置 Netty 软件 http id spring servlet 安全
- 版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
