框架設計原則（梁飛）

大綱

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 關於接口分離和模塊分包，一般在後期重構可以達到更好的效果？

好了，洋洋灑灑說了很多，讀者若有更好的看法，請與我分享，畢竟如今關注這塊的人很少了。：）期待和對此感興趣的人一塊兒討論