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

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

最近，在為 Coco  優(yōu)化分層架構(gòu)之時(shí)，我陷入了各種決策困難之中。所以我通過不斷地延遲決策，以摸清更適合現(xiàn)有系統(tǒng)的現(xiàn)狀。換個(gè)簡(jiǎn)單來說，在危險(xiǎn)邊緣徘徊，以期待能獲取最大的收益。

在設(shè)計(jì)新的架構(gòu)時(shí)，我們總會(huì)憑借原先的經(jīng)驗(yàn)，并結(jié)合業(yè)務(wù)現(xiàn)狀的需求，并根據(jù)未來的需求做出我們的設(shè)計(jì)。即：

• 過去的經(jīng)驗(yàn)。

• 現(xiàn)在的需求。

• 未來的方向。

種種因素的影響之下，它注定了我們無法設(shè)計(jì)一個(gè)滿足所有歷史時(shí)期的系統(tǒng)。未來會(huì)變成現(xiàn)在，現(xiàn)在會(huì)變成過去。

Coco 架構(gòu)設(shè)計(jì)：從過去到過去的未來

原先對(duì)于 Coca 的各種設(shè)計(jì)問題，以及 Golang 對(duì)于多平臺(tái)的支持問題等多方面的因素。迫使 Inherd 開源小組在 Coco  在初始階段，便考慮了為 Coco 設(shè)計(jì)插件系統(tǒng)。直到最近，我們實(shí)現(xiàn)了插件系統(tǒng)之后，發(fā)現(xiàn)了原來設(shè)計(jì)的分層架構(gòu)已經(jīng)不滿足現(xiàn)今的需求。

雖然，我已經(jīng)知道新的分層架構(gòu)應(yīng)該如何設(shè)計(jì)，但是我并不想朝那個(gè)方向過去。我走走彎路，再看看是否存在一些更有意思的設(shè)計(jì)。

原始形態(tài)：?jiǎn)误w架構(gòu)

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

• app，對(duì)應(yīng)于用例(usecases)。

• bin，對(duì)應(yīng)于 controller。在 Rust 的構(gòu)建系統(tǒng)中，bin 目錄的會(huì)被構(gòu)建出可執(zhí)行文件

• infrastructure，對(duì)應(yīng)于 基礎(chǔ)設(shè)施，如調(diào)用 Git 的接口、訪問文件系統(tǒng)等。

• domain，即業(yè)務(wù)實(shí)體、領(lǐng)域模式，包含了系統(tǒng)的業(yè)務(wù)設(shè)計(jì)。

在 domain 目錄下，根據(jù)了我們的四大基本業(yè)務(wù)，進(jìn)行了二次劃分 ：

• cloc

• git

• framework

• architecture

• ……

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 它帶來一定的架構(gòu)復(fù)雜度，需要不斷地傳遞相關(guān)的架構(gòu)知識(shí)，能否在開源項(xiàng)目中推廣，有待商榷。

3. 后續(xù)可以通過重構(gòu)來轉(zhuǎn)換。我并非非常資深的架構(gòu)專家，所以以學(xué)習(xí)為出發(fā)點(diǎn)更方便。

作為一個(gè)單體應(yīng)用，這個(gè)分層結(jié)構(gòu)湊合著：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

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

4. 模塊可以進(jìn)一步按業(yè)務(wù)拆分。

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

復(fù)用形態(tài)之模塊化

為了在多個(gè)不同的系統(tǒng)/應(yīng)用之間(即 Coco 項(xiàng)目的代碼提供給其它應(yīng)用)復(fù)用代碼 ，系統(tǒng)中產(chǎn)出一些獨(dú)立的模塊，如 psa、framework  等等。這也是一個(gè)非常常見的模塊化的場(chǎng)景。模塊化在不同的語言里都有一定的相似之處。

譬如：在使用方式上存在本地使用和遠(yuǎn)程發(fā)布兩種模式。在本地使用時(shí)，無需關(guān)注語義化版本等一系列的事項(xiàng)，只需關(guān)注于代碼本身。一旦時(shí)機(jī)成熟，也就可以進(jìn)化為可遠(yuǎn)程發(fā)布的模塊。

從單體中出現(xiàn)模塊化的一種典型形式便是，在代碼庫(kù)中以與源碼同級(jí)的目錄呈現(xiàn)。如下：

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

這里的 framework 和 psa 便是獨(dú)立的模塊，一旦其與其它模塊的依賴關(guān)系解耦開來，那么它就可以作為獨(dú)立的應(yīng)用發(fā)布。

復(fù)制 over 復(fù)用

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

插件化的架構(gòu)演變

同時(shí)，為了靈活地?cái)U(kuò)展系統(tǒng)的功能，我們?cè)O(shè)計(jì)了插件系統(tǒng)。(事實(shí)上，更多地從意圖上，我們只是為了減少包體積大小，這樣可以方便地從 GitHub 下載)

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

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

從設(shè)計(jì)和演進(jìn)的角度來看，問題并不多，也可以使用。

演進(jìn)：未來的未來

好了，由于經(jīng)驗(yàn)上的不足，我們就面臨了之前沒考慮到的問題。

提取核心模型

從設(shè)計(jì)思路上來看，我們本應(yīng)該在原先的架構(gòu)模型中，提供一個(gè) core 模塊。而在這個(gè) core 模塊里呢，則用于提供一些核心的代碼給插件和應(yīng)用。

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

只是呢，隨著第一個(gè)模型復(fù)用需求的出現(xiàn)，很快地就有了第二部分、第三部分。

再次抉擇：基礎(chǔ)設(shè)施層的改造

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

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

從架構(gòu)設(shè)計(jì)的思想來看，我是支持雙層基礎(chǔ)設(shè)施的存在。過多的無意識(shí)地復(fù)制這些公共代碼，會(huì)導(dǎo)致這個(gè)包大小的進(jìn)一步膨脹。一個(gè)典型的例子，就是我們?cè)谝粋€(gè)被稱為  common 包的 jar 包里，看到一個(gè) common 子包下，還有 common 目錄的存在，即 xxx-common.common.common。

小結(jié)：架構(gòu)的持續(xù)演化

故事就到這里了。哪怕一個(gè)再小的項(xiàng)目，它的架構(gòu)模式也會(huì)隨著系統(tǒng)的開發(fā)，不斷地演化。如果不加以控制，那么系統(tǒng)可能會(huì)推動(dòng)控制。而演進(jìn)本身呢，也不會(huì)是一帆風(fēng)順的。

不過，我在思考一個(gè)新的東西，關(guān)于『分層架構(gòu)適應(yīng)度函數(shù)』。

Yiki：分層架構(gòu)適應(yīng)度函數(shù)

無論是在 Coco 還是在 Coca  里，我們都在嘗試對(duì)系統(tǒng)的分層進(jìn)行一個(gè)評(píng)級(jí)。而這個(gè)評(píng)級(jí)的其中一個(gè)依據(jù)是通過依賴關(guān)系，來確認(rèn)各個(gè)模塊之間的引用關(guān)系，從而判斷系統(tǒng)的分層架構(gòu)是否是符合需求的。

通過解析模塊之間的引用關(guān)系，可以幫效地幫助我們厘清系統(tǒng)模塊之間的合理度。

感謝各位的閱讀，以上就是“從單體的插件化演化的過程分析”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)從單體的插件化演化的過程分析這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！