建站
咨詢
售后
建站咨詢
新聞中心
最近，在為 Coco 優(yōu)化分層架構(gòu)之時，我陷入了各種決策困難之中。所以我通過不斷地延遲決策，以摸清更適合現(xiàn)有系統(tǒng)的現(xiàn)狀。換個簡單來說，在危險邊緣徘徊，以期待能獲取最大的收益。
在設(shè)計新的架構(gòu)時，我們總會憑借原先的經(jīng)驗，并結(jié)合業(yè)務(wù)現(xiàn)狀的需求，并根據(jù)未來的需求做出我們的設(shè)計。即：
- 過去的經(jīng)驗。
- 現(xiàn)在的需求。
- 未來的方向。
種種因素的影響之下，它注定了我們無法設(shè)計一個滿足所有歷史時期的系統(tǒng)。未來會變成現(xiàn)在，現(xiàn)在會變成過去。
Coco 架構(gòu)設(shè)計：從過去到過去的未來
原先對于 Coca 的各種設(shè)計問題，以及 Golang 對于多平臺的支持問題等多方面的因素。迫使 Inherd 開源小組在 Coco 在初始階段，便考慮了為 Coco 設(shè)計插件系統(tǒng)。直到最近，我們實現(xiàn)了插件系統(tǒng)之后，發(fā)現(xiàn)了原來設(shè)計的分層架構(gòu)已經(jīng)不滿足現(xiàn)今的需求。
雖然，我已經(jīng)知道新的分層架構(gòu)應(yīng)該如何設(shè)計，但是我并不想朝那個方向過去。我走走彎路，再看看是否存在一些更有意思的設(shè)計。
原始形態(tài)：單體架構(gòu)
在設(shè)計初期，我在 Coco 中引入了類似于 Clean Architecture 的分層架構(gòu)設(shè)計(不包含 Cargo 模塊)：
- app，對應(yīng)于用例(usecases)。
- bin，對應(yīng)于 controller。在 Rust 的構(gòu)建系統(tǒng)中，bin 目錄的會被構(gòu)建出可執(zhí)行文件
- infrastructure，對應(yīng)于 基礎(chǔ)設(shè)施，如調(diào)用 Git 的接口、訪問文件系統(tǒng)等。
- domain，即業(yè)務(wù)實體、領(lǐng)域模式，包含了系統(tǒng)的業(yè)務(wù)設(shè)計。
在 domain 目錄下，根據(jù)了我們的四大基本業(yè)務(wù)，進行了二次劃分 ：
- cloc
- git
- framework
- architecture
- ……
盡管，我一直在說我采用的是類似于 Clean Architecture 的分層架構(gòu)。但是實際上，并沒有采用其中一些重要的設(shè)計，比如說通過依賴反轉(zhuǎn)來控制流向的問題。從個人的角度來看：
- 它帶來一定的架構(gòu)復(fù)雜度，需要不斷地傳遞相關(guān)的架構(gòu)知識，能否在開源項目中推廣，有待商榷。
- 后續(xù)可以通過重構(gòu)來轉(zhuǎn)換。我并非非常資深的架構(gòu)專家，所以以學(xué)習(xí)為出發(fā)點更方便。
作為一個單體應(yīng)用，這個分層結(jié)構(gòu)湊合著：
- 不算太復(fù)雜，還能讓開發(fā)人員知道哪的代碼往哪里放。
- 可以按需演化為 Clean Architecture。
- 模塊可以進一步按業(yè)務(wù)拆分。
故事的開始還是蠻美好的。
復(fù)用形態(tài)之模塊化
為了在多個不同的系統(tǒng)/應(yīng)用之間(即 Coco 項目的代碼提供給其它應(yīng)用)復(fù)用代碼 ，系統(tǒng)中產(chǎn)出一些獨立的模塊，如 psa、framework 等等。這也是一個非常常見的模塊化的場景。模塊化在不同的語言里都有一定的相似之處。
譬如：在使用方式上存在本地使用和遠程發(fā)布兩種模式。在本地使用時，無需關(guān)注語義化版本等一系列的事項，只需關(guān)注于代碼本身。一旦時機成熟，也就可以進化為可遠程發(fā)布的模塊。
從單體中出現(xiàn)模塊化的一種典型形式便是，在代碼庫中以與源碼同級的目錄呈現(xiàn)。如下：
- ├── framework
- ├── psa
- ├── src
- │ ├── app
- │ ├── bin
- │ ├── domain
- │ ├── infrastructure
- │ └── lib.rs
這里的 framework 和 psa 便是獨立的模塊，一旦其與其它模塊的依賴關(guān)系解耦開來，那么它就可以作為獨立的應(yīng)用發(fā)布。
復(fù)制 over 復(fù)用
順便提一句，對于模塊化的代碼復(fù)用來說，如果代碼量較少，那么可以嘗試復(fù)制一份代碼，而不是復(fù)用做代碼。這樣一來，我們可以通過此來解耦依賴。
插件化的架構(gòu)演變
同時，為了靈活地擴展系統(tǒng)的功能，我們設(shè)計了插件系統(tǒng)。(事實上，更多地從意圖上，我們只是為了減少包體積大小，這樣可以方便地從 GitHub 下載)
于是乎，我們創(chuàng)建了獨立的 plugins 目錄，并在其中創(chuàng)建了對應(yīng)的模塊，如下的 coco_xxxx 即是插件。同時，我們使用了 plugin_manager 來作為插件的管理器(事實上，后面證明了，這個 manager 不應(yīng)該獨立作為一個模塊存在)：
- ├── framework
- ├── plugin_manager
- ├── plugins
- │ ├── coco_container
- │ ├── coco_pipeline
- │ ├── coco_struct
- │ └── coco_swagger
- ├── psa
- ├── src
- │ ├── app
- │ ├── bin
- │ ├── domain
- │ ├── infrastructure
- │ └── lib.rs
從設(shè)計和演進的角度來看，問題并不多，也可以使用。
演進：未來的未來
好了，由于經(jīng)驗上的不足，我們就面臨了之前沒考慮到的問題。
提取核心模型
從設(shè)計思路上來看，我們本應(yīng)該在原先的架構(gòu)模型中，提供一個 core 模塊。而在這個 core 模塊里呢，則用于提供一些核心的代碼給插件和應(yīng)用。
所以，很快地我們就創(chuàng)建了一個 core_model 出來了。我的本義也就只是提供一個核心模型。我不想像一些插件化項目中，在 core 中提供大量非核心的代碼。
只是呢，隨著第一個模型復(fù)用需求的出現(xiàn)，很快地就有了第二部分、第三部分。
再次抉擇：基礎(chǔ)設(shè)施層的改造
而插件之間除了模型的復(fù)用，還會有基礎(chǔ)設(shè)施的復(fù)用。而這些代碼，我又不想放到 core 里，所以就又需要抽取中一個 infra 的模塊，用來共享基礎(chǔ)設(shè)施的代碼。那么問題來了，我們應(yīng)該如何選擇?
- 將原有的 infrastructure 提取到主目錄下，作為單獨的模塊存在。
- 雙層infrastructure，即只提取共用的代碼，到主目錄下，作為獨立的模塊。
從架構(gòu)設(shè)計的思想來看，我是支持雙層基礎(chǔ)設(shè)施的存在。過多的無意識地復(fù)制這些公共代碼，會導(dǎo)致這個包大小的進一步膨脹。一個典型的例子，就是我們在一個被稱為 common 包的 jar 包里，看到一個 common 子包下，還有 common 目錄的存在，即 xxx-common.common.common。
小結(jié)：架構(gòu)的持續(xù)演化
故事就到這里了。哪怕一個再小的項目，它的架構(gòu)模式也會隨著系統(tǒng)的開發(fā)，不斷地演化。如果不加以控制，那么系統(tǒng)可能會推動控制。而演進本身呢，也不會是一帆風(fēng)順的。
不過，我在思考一個新的東西，關(guān)于『分層架構(gòu)適應(yīng)度函數(shù)』。
Yiki：分層架構(gòu)適應(yīng)度函數(shù)
無論是在 Coco 還是在 Coca 里，我們都在嘗試對系統(tǒng)的分層進行一個評級。而這個評級的其中一個依據(jù)是通過依賴關(guān)系，來確認各個模塊之間的引用關(guān)系，從而判斷系統(tǒng)的分層架構(gòu)是否是符合需求的。
通過解析模塊之間的引用關(guān)系，可以幫效地幫助我們厘清系統(tǒng)模塊之間的合理度。
本文轉(zhuǎn)載自微信公眾號「phodal」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系phodal公眾號。
本文題目：分層架構(gòu)演化：從單體的插件化演化所引起的思考
標題URL：http://m.5511xx.com/article/dhojssi.html
