建站
咨詢
售后
建站咨詢
新聞中心
最近，在為 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è)人的角度來看：
- 它帶來一定的架構(gòu)復(fù)雜度，需要不斷地傳遞相關(guān)的架構(gòu)知識(shí)，能否在開源項(xiàng)目中推廣，有待商榷。
- 后續(xù)可以通過重構(gòu)來轉(zhuǎn)換。我并非非常資深的架構(gòu)專家，所以以學(xué)習(xí)為出發(fā)點(diǎn)更方便。
作為一個(gè)單體應(yīng)用，這個(gè)分層結(jié)構(gòu)湊合著：
- 不算太復(fù)雜，還能讓開發(fā)人員知道哪的代碼往哪里放。
- 可以按需演化為 Clean Architecture。
- 模塊可以進(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)模塊化的一種典型形式便是，在代碼庫中以與源碼同級(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)該如何選擇?
- 將原有的 infrastructure 提取到主目錄下，作為單獨(dú)的模塊存在。
- 雙層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)模塊之間的合理度。
本文轉(zhuǎn)載自微信公眾號(hào)「phodal」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系phodal公眾號(hào)。
當(dāng)前名稱：分層架構(gòu)演化：從單體的插件化演化所引起的思考
標(biāo)題URL：http://www.dlmjj.cn/article/dhojssi.html
