從單體的插件化演化的過程分析

這篇文章主要講解了“從單體的插件化演化的過程分析”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“從單體的插件化演化的過程分析”吧！

最近，在為 Coco  優化分層架構之時，我陷入了各種決策困難之中。所以我通過不斷地延遲決策，以摸清更適合現有系統的現狀。換個簡單來說，在危險邊緣徘徊，以期待能獲取最大的收益。

在設計新的架構時，我們總會憑借原先的經驗，并結合業務現狀的需求，并根據未來的需求做出我們的設計。即：

• 過去的經驗。

• 現在的需求。

• 未來的方向。

種種因素的影響之下，它注定了我們無法設計一個滿足所有歷史時期的系統。未來會變成現在，現在會變成過去。

Coco 架構設計：從過去到過去的未來

原先對于 Coca 的各種設計問題，以及 Golang 對于多平臺的支持問題等多方面的因素。迫使 Inherd 開源小組在 Coco  在初始階段，便考慮了為 Coco 設計插件系統。直到最近，我們實現了插件系統之后，發現了原來設計的分層架構已經不滿足現今的需求。

雖然，我已經知道新的分層架構應該如何設計，但是我并不想朝那個方向過去。我走走彎路，再看看是否存在一些更有意思的設計。

原始形態：單體架構

在設計初期，我在 Coco 中引入了類似于 Clean Architecture 的分層架構設計(不包含 Cargo 模塊)：

• app，對應于用例(usecases)。

• bin，對應于 controller。在 Rust 的構建系統中，bin 目錄的會被構建出可執行文件

• infrastructure，對應于 基礎設施，如調用 Git 的接口、訪問文件系統等。

• domain，即業務實體、領域模式，包含了系統的業務設計。

在 domain 目錄下，根據了我們的四大基本業務，進行了二次劃分 ：

• cloc

• git

• framework

• architecture

• ……

盡管，我一直在說我采用的是類似于 Clean Architecture  的分層架構。但是實際上，并沒有采用其中一些重要的設計，比如說通過依賴反轉來控制流向的問題。從個人的角度來看：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 它帶來一定的架構復雜度，需要不斷地傳遞相關的架構知識，能否在開源項目中推廣，有待商榷。

3. 后續可以通過重構來轉換。我并非非常資深的架構專家，所以以學習為出發點更方便。

作為一個單體應用，這個分層結構湊合著：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 不算太復雜，還能讓開發人員知道哪的代碼往哪里放。

3. 可以按需演化為 Clean Architecture。

4. 模塊可以進一步按業務拆分。

故事的開始還是蠻美好的。

復用形態之模塊化

為了在多個不同的系統/應用之間(即 Coco 項目的代碼提供給其它應用)復用代碼 ，系統中產出一些獨立的模塊，如 psa、framework  等等。這也是一個非常常見的模塊化的場景。模塊化在不同的語言里都有一定的相似之處。

譬如：在使用方式上存在本地使用和遠程發布兩種模式。在本地使用時，無需關注語義化版本等一系列的事項，只需關注于代碼本身。一旦時機成熟，也就可以進化為可遠程發布的模塊。

從單體中出現模塊化的一種典型形式便是，在代碼庫中以與源碼同級的目錄呈現。如下：

├── framework ├── psa ├── src │   ├── app │   ├── bin │   ├── domain │   ├── infrastructure │   └── lib.rs

這里的 framework 和 psa 便是獨立的模塊，一旦其與其它模塊的依賴關系解耦開來，那么它就可以作為獨立的應用發布。

復制 over 復用

順便提一句，對于模塊化的代碼復用來說，如果代碼量較少，那么可以嘗試復制一份代碼，而不是復用做代碼。這樣一來，我們可以通過此來解耦依賴。

插件化的架構演變

同時，為了靈活地擴展系統的功能，我們設計了插件系統。(事實上，更多地從意圖上，我們只是為了減少包體積大小，這樣可以方便地從 GitHub 下載)

于是乎，我們創建了獨立的 plugins 目錄，并在其中創建了對應的模塊，如下的 coco_xxxx 即是插件。同時，我們使用了  plugin_manager 來作為插件的管理器(事實上，后面證明了，這個 manager 不應該獨立作為一個模塊存在)：

├── framework ├── plugin_manager ├── plugins │   ├── coco_container │   ├── coco_pipeline │   ├── coco_struct │   └── coco_swagger ├── psa ├── src │   ├── app │   ├── bin │   ├── domain │   ├── infrastructure │   └── lib.rs

從設計和演進的角度來看，問題并不多，也可以使用。

演進：未來的未來

好了，由于經驗上的不足，我們就面臨了之前沒考慮到的問題。

提取核心模型

從設計思路上來看，我們本應該在原先的架構模型中，提供一個 core 模塊。而在這個 core 模塊里呢，則用于提供一些核心的代碼給插件和應用。

所以，很快地我們就創建了一個 core_model 出來了。我的本義也就只是提供一個核心模型。我不想像一些插件化項目中，在 core  中提供大量非核心的代碼。

只是呢，隨著第一個模型復用需求的出現，很快地就有了第二部分、第三部分。

再次抉擇：基礎設施層的改造

而插件之間除了模型的復用，還會有基礎設施的復用。而這些代碼，我又不想放到 core 里，所以就又需要抽取中一個 infra  的模塊，用來共享基礎設施的代碼。那么問題來了，我們應該如何選擇?

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 將原有的 infrastructure 提取到主目錄下，作為單獨的模塊存在。

3. 雙層infrastructure，即只提取共用的代碼，到主目錄下，作為獨立的模塊。

從架構設計的思想來看，我是支持雙層基礎設施的存在。過多的無意識地復制這些公共代碼，會導致這個包大小的進一步膨脹。一個典型的例子，就是我們在一個被稱為  common 包的 jar 包里，看到一個 common 子包下，還有 common 目錄的存在，即 xxx-common.common.common。

小結：架構的持續演化

故事就到這里了。哪怕一個再小的項目，它的架構模式也會隨著系統的開發，不斷地演化。如果不加以控制，那么系統可能會推動控制。而演進本身呢，也不會是一帆風順的。

不過，我在思考一個新的東西，關于『分層架構適應度函數』。

Yiki：分層架構適應度函數

無論是在 Coco 還是在 Coca  里，我們都在嘗試對系統的分層進行一個評級。而這個評級的其中一個依據是通過依賴關系，來確認各個模塊之間的引用關系，從而判斷系統的分層架構是否是符合需求的。

通過解析模塊之間的引用關系，可以幫效地幫助我們厘清系統模塊之間的合理度。

感謝各位的閱讀，以上就是“從單體的插件化演化的過程分析”的內容了，經過本文的學習后，相信大家對從單體的插件化演化的過程分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！