建站
咨詢
售后
建站咨詢
新聞中心
- 從 Maven 到 Gradle。原因是靈活的自定義 task，還有自帶的增量構(gòu)建等。
- 依賴庫的更新。
- 系統(tǒng)從微服務(wù)到單體。
- 構(gòu)建規(guī)范和對應(yīng)的規(guī)范工具化
- 持續(xù)交付。結(jié)合 GitHub Action、Docker Hub 等一系列的 DevOps 開源基礎(chǔ)設(shè)施，進行全自動化的構(gòu)建。
- ……
其中，最有意思的一個故事莫過于：從微服務(wù)到單體架構(gòu)。因為，它是一種反主流的形式，又或者是反主流的技術(shù)架構(gòu)。
創(chuàng)新互聯(lián)建站制作網(wǎng)站網(wǎng)頁找三站合一網(wǎng)站制作公司,專注于網(wǎng)頁設(shè)計,成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè),網(wǎng)站設(shè)計,企業(yè)網(wǎng)站搭建,網(wǎng)站開發(fā),建網(wǎng)站業(yè)務(wù),680元做網(wǎng)站,已為1000+服務(wù),創(chuàng)新互聯(lián)建站網(wǎng)站建設(shè)將一如既往的為我們的客戶提供最優(yōu)質(zhì)的網(wǎng)站建設(shè)、網(wǎng)絡(luò)營銷推廣服務(wù)!
遺留微服務(wù)系統(tǒng)的挑戰(zhàn)
在我們經(jīng)過了一系列的內(nèi)部會議之后，決定了將 ArchGuard 開源。隨后，看到了代碼庫，我們發(fā)現(xiàn)了一系列的挑戰(zhàn)：
- 過多的服務(wù)/模塊。這個在內(nèi)部開發(fā)多年的系統(tǒng)，由多個微服務(wù)組成 + 代碼庫組成，
- 知識缺少沉淀。先前并沒有留下太多的開發(fā)文檔，不了解當(dāng)時做的一系列技術(shù)決策，需要從 Git 歷史中汲取。
- 復(fù)雜的部署架構(gòu)。同樣是工具，對比于 Jenkins/Sonarqube 的部署方式，相對較為復(fù)雜。
- 不一定合理的服務(wù)劃分。我們需要部署一系列的服務(wù)，但是只有掃描器(Arch Scanner)才需要彈性伸縮這樣的特性。
于是呢，我們重新思考合理的后端服務(wù)(微服務(wù))的顆粒度應(yīng)該是怎樣的?所以，參考于過去總結(jié)的什么用微服務(wù)?以及有多少個微服務(wù)更合理?先前的一個結(jié)論，類似于：
- 微服務(wù)的數(shù)量不超過開發(fā)人員的數(shù)量。
- 滿足康威定律。微服務(wù)與開發(fā)團隊對齊。
- 兩個比薩團隊原則 —— 開發(fā)團隊的人員數(shù)量維護在 3 \~ 12 人。一個微服務(wù)只由一個開發(fā)團隊維護。
- 高內(nèi)聚，低耦合。單個服務(wù)與其它服務(wù)依賴少。如：兩個服務(wù)存在相互調(diào)用，耦合度相對較高，可以考慮合為一個服務(wù)。
- 收益大于開銷。創(chuàng)建服務(wù)的開銷是否超過了獨立成服務(wù)的好處。
- 你不一定需要微服務(wù)?？紤]采用 DDD (領(lǐng)域驅(qū)動設(shè)計)分層架構(gòu)來劃分，以方便未來拆分為微服務(wù)。
在這個場景之下，幾乎違反了上面的一系列規(guī)則。所以，我就回到了上述的 6 中去，采用 DDD 的分層架構(gòu)模式。每個資源/聚合/服務(wù)在各自的包下管理(common 除外)：
├── Application.kt
├── clazz
├── code
├── common
├── config
├── evaluation_bak
├── evolution
├── method
├── metrics
├── module
├── packages
├── qualitygate
├── report
├── report_bak
├── scanner
├── scanner2
└── system_info
由于是合并的代碼，所以代碼中除在于 _bak 還有 scanner2 這樣看似重復(fù)，又或者是遷移中的代碼。
為什么單體更適合當(dāng)前?
再回到多年以前， Martin Fowler 寫了那篇《Monolithic First》，意在告訴人們在團隊微服務(wù)能力和技術(shù)不夠成熟的時候，你不應(yīng)該采用微服務(wù)。這里的場景和上述的這個場景并不是一樣的。對于系統(tǒng)的最終形態(tài)來說，單體并不一定適合這個系統(tǒng)，但是當(dāng)于當(dāng)前的我們來說，單體是最合適的。原因諸如于：
- 單體部署架構(gòu)決定應(yīng)用架構(gòu)。使用 Docker，盡管 Saas 也是更友好的。但是，作為一個剛起步的開源項目，并不會資金來支撐這種規(guī)模的 SaaS 服務(wù)。
- 最終用戶是開發(fā)者。軟件的使用者本身又可能成為開發(fā)者，所以能一次啟動就應(yīng)該一次啟動。
- 開發(fā)者體驗優(yōu)先。開源與面向開發(fā)者決定了 ArchGuard 是一個開發(fā)者體驗優(yōu)先的系統(tǒng)。如果一個參與到 ArchGuard 項目的開發(fā)者，要在多個項目中切換， 那么這中體驗是非常差的。在開源社區(qū)里，一直都是單體優(yōu)先，如 Gradle、Spring 等。
- 首次部署速度。
- setup 速度。
總體來說，作為一個開源應(yīng)用/工具，軟件工程的模式受限于其合作模式。所以，常規(guī)的軟件開發(fā)架構(gòu)，并不一定適用，我們需要一些更好的模式。
那么，我們還有別的選擇嗎?
我們的目標架構(gòu)是單體嗎?
從某種意義上，就當(dāng)前來說，它是的。但是，如果管理有所不善的話，它會變成一個大泥球架構(gòu)。回顧一下，一個多倉庫/多模塊的微服務(wù)系統(tǒng)，它與一個單體系統(tǒng)在物理形態(tài)上的主要區(qū)別在于：
- 微服務(wù)使用的是進程間調(diào)用，單體是進程內(nèi)調(diào)用。
- 微服務(wù)最終有多個制品包，而單體只有一個或者是插件化的一帶多。
所以，只要我們用相似的形態(tài)來構(gòu)建一個單體應(yīng)用，那么它在部署形態(tài)上就可以變成是微服務(wù)架構(gòu)。簡單來說，就是：
- 代碼庫內(nèi)，包(package、service)間的調(diào)用使用 HTTP 調(diào)用，而不是函數(shù)調(diào)用。
- 通過自定義的構(gòu)建腳本，在構(gòu)建時拆分代碼庫，生成多個服務(wù)制品，并進行部署。
從結(jié)果來說，便是將系統(tǒng)放置在一種臨界狀態(tài)。以讓人們根據(jù)自己的需要，做出不同的選擇。如在 SaaS 化的時候，這就可以變成微服務(wù)的形態(tài)，單體部署時，則可以變成單體的狀態(tài)。唯一麻煩的是，需要開發(fā)者對于構(gòu)建系統(tǒng)有足夠的了解，并設(shè)計好充足的自動化測試設(shè)施。
如何遷移 ?
接著，我們就開始合并多個代碼倉庫，其中的一些
- 保留歷史提交記錄的合并。主要是結(jié)合 git-filer-repo 來進行過濾和選擇路徑。
- 構(gòu)建配置的全集。對 Application.properties 等進行統(tǒng)一。
- 使用相同的依賴版本。由于不同的年代的原因，所以選擇的依賴版本也有所不同，需要嘗試先統(tǒng)一，才能合并代碼。
- 解決沖突。因為，只合并了 src 目錄下的內(nèi)容，如果包名有問題，如沖突了，需要重置。類似的問題，還有：Application 重復(fù)、Bean 沖突、Service 沖突。
就遷移過程來說，它并不復(fù)雜，就是耗時。
還有其它選項嗎?
相似的場景，如果一個開發(fā)人員多個微服務(wù)，并且在不考慮單機部署的情況下，Monorepo 是一個更好的選擇，把所有微服務(wù)項目的代碼放在一個倉庫里。
畢竟，Google 都可以把所有的代碼倉庫放一起，我們又有什么不可以的。當(dāng)然了，Google 使用的技術(shù)原理是不一樣的。不過，它能提供一個足夠強壯的理由。
其它
回過頭來看，對于小的團隊來說，單體會不會是更合適的選擇?那么大的團隊呢?
分享標題：回到單體架構(gòu)：一個開源項目的重構(gòu)
鏈接分享：http://fisionsoft.com.cn/article/dhhoejo.html
