前言

只有光頭才能變強。

文本已收錄至我的GitHub精選文章，歡迎Star：https://github.com/ZhongFuCheng3y/3y

最近在整合各種的系統，在這個過程中遇到了各種的問題，三歪今天來分享一下關于「項目結構」或者說「二方包」的事。

我們先不聊「二方包」，因為初學或者還沒工作的同學可能沒聽過這個詞。

初學的時候或者剛做項目的時候，我們的項目架構是怎么樣的呢？我翻出了我在大學的時候寫的小Demo：

可以看到的是，我們的項目只有一個Module，里邊我們分各種的包：dao/service/controller/utils...等等。

這看起來好像沒啥問題吧？

我們去到公司里邊，可能看到的項目都分了多個Module，比如下圖：

有什么區別呢？我們用一個Module在里邊分各種的子包，看起來也還行。為什么我們要分多個Module呢？

我個人認為原因是這樣的：Maven本身就支持多模塊（Module）的管理，將不同的層分出來，項目看起來更加清晰，在改動的時候針對某個模塊去變更就好了。

• 比如，我把dao層分成一個模塊，當我變更dao這個模塊的時候，我只需要關心這個模塊就好了，不需要關心service模塊或者web模塊
• 舉個例子：每層幾乎都會有自己的配置信息(配置文件)，數據訪問層會有數據庫的配置文件、業務層也會有對應的配置文件。我們抽出多個Module（不同的Module放屬于自己的配置文件），從代碼結構層面上會顯得更加清晰。

我們寫完的代碼是需要維護的，可維護性很重要。

很多編程方式客觀上沒有對錯之分，一致性很重要，可讀性很重要，團隊溝通效率很重要。程序員天生需要團隊協作，而協作的正能量要放在問題的有效溝通上。個性化應盡量表現在系統架構和算法效率的提升上，而不是在合作規范上進行糾纏不休的討論、爭論，最后沒有結論。

二方包

當年我看《阿里巴巴開發手冊》的時候也寫過一篇總結，當時的文章也提到了那時候不咋懂二方包，現在我回來填坑了。

首先來科普一下什么是二方庫？（二方庫也叫·）

• 一方庫指的是本項目中的依賴
• 二方庫指的是公司內部其他項目提供的依賴
• 三方庫指的是其他組織、公司等來自第三方的依賴

如果看過我之前文章的同學都知道，三歪在公司目前維護的是消息管理平臺，全公司發送的消息都會經過我的系統。

我會打個「二方包」到公司的Maven倉庫，然后他們引入我的pom依賴，調用我的接口去下發消息。

假如我沒有分Module，所有的代碼都寫在同一個Module下，那我發到公司的Maven倉庫會發生什么？打包(deploy)這個過程是沒毛病的。

如果他們依賴了我這個沒有處理過的二方包，相當于把我整個工程給依賴進去了，這是非常可怕的。

如果有從零搭過系統或者整合過系統的同學會知道，這個過程有會有多「版本」的坑。只要版本不一致，就會出現一大堆奇奇怪怪的問題，并且這些問題都不太好解決。

所以，一般我們的二方包都應該是很清爽的。比如我提供的二方包，它就只有接口和接口所需要的實體，沒有雜余的繁瑣依賴。

業務方是不關心接口的實現的，我們只需要暴露接口就好了。

三歪一次經歷

最近三歪在整合系統嘛，分享一次經歷。

我負責的消息管理平臺系統的架構是這樣的：

可以看到，我所負責的系統是分得很細的（很符合分布式的理念）。從功能上看，這些系統變成一個大工程也不是什么問題，只是這個系統會非常非常大。

消息管理平臺除了上面的系統，還有其他的子系統，比如說「ID映射」。這里當初設計的時候也把它當做一個系統給抽出去了。

「ID映射」應該不難理解：業務方傳入的是站內的userId，但要發的是短信。我這邊要把userId轉換成手機號，可以簡單理解這個系統就做的這么一個ID轉換的功能。

現在要規劃把這個「ID映射」給整合起來，原有的機器要下線了，要把這個服務的功能給整到消息管理平臺的系統中。（為啥要整到我這個架構上？因為本身這個系統就只有我這邊在頻繁使用）

為啥要整合？現在的潮流可能是把單個系統拆出多個系統做”微服務“，但真正系統多起來未必是一件好事。

一些小的功能其實沒必要單獨分出來一個系統，這是需要成本的，至少我們機器成本是有的（一個系統我們至少會有四臺機器）->兩臺線上，一臺預發，一臺線下

OK，說完背景了以后，我們再來看看「ID映射」這個系統的代碼架構：

說白了，就是這個工程下有這三個Module，如果你要問我為什么沒看到dao層的Module，而是直接放到core 層，問就是當初設計不合理。依我的理解，應該至少是要把數據訪問層抽出一個Module。

可以看到的是，這個「ID映射」系統其實也是一個完整的系統，從后臺管理頁面到數據庫都是完整的。

現在要把這個系統給整到消息管理平臺的架構下，如果是你，你會怎么弄呢？

其實就兩種方式：

把這個「ID映射」系統整個搬到某一個系統中

把這個「ID映射」系統通過模塊拆出來，分到各個系統中。

最簡單的做法肯定是把這個系統的代碼搬到另一個系統，然后就可以run起來了。但前人已經把系統分得那么干凈了，如果我這樣干了，后面接手的人會不會錘我呢？

三歪認為服務相關的代碼，應該就整合到專門提供服務的系統。后臺相關的代碼，就應該整合到后臺相關的系統。即便我后臺系統發布了，絲毫不影響對外提供的服務。

所以，我決定把「ID映射」的各個Module抽出來，分到不同的系統中。把api層和部分core層的代碼的Module分到service系統中，把web層的Module分到admin系統中。

看似是挺完美的，我當初也是這樣執行的，于是我順利把api和core的代碼整合到service系統之后，正打算把web的代碼整合到admin系統中，遇到了一個問題。

web的代碼是controller層，它顯然會依賴service層的代碼，service層的代碼也顯然會依賴dao的代碼。

現在我已經把api/core層的代碼大多數已經遷到了service系統，而admin系統是沒有這些代碼和依賴的，我需要整個系統是能跑通的，我能怎么辦？

此時能想到的有兩種方案：

把service系統的代碼再到admin系統中實現。

現在service系統已經實現好了，打個二方包，然后讓admin系統依賴。這里也有兩個方案：

二方包不做任何處理，admin系統直接依賴其所有的實現。

把admin系統所依賴的接口再出一個api層，admin系統只需要依賴api層，實現遠程調用

如果是你，你會選擇哪種？我們來分析一下：

• 第一種方案：service系統的代碼再到admin系統實現，這肯定會有代碼冗余的情況。畢竟service系統肯定會依賴dao層的，而admin系統最終也是需要依賴dao層。dao層沒有完全抽出，在前期就肯定會有代碼冗余的情況
• 第二種方案分支①：將service系統已實現的代碼直接打成二方包，admin系統直接引入就沒有任何代碼冗余的問題。但這會引發其他問題：
  • 直接打成二方包意味著要把所有的實現依賴都打進去，admin系統在引入的時候需要針對這個二方包做一系列的排包操作。（這個非常蛋疼）
  • 其實最致命的是我們干不了。我們的系統在發布的時候是分環境的（線上、預發、線下），我們會在發布的時候根據不同的環境使用不同的配置。如果我們此時直接打個二方包，我們是需要指定環境的，這說明我們只能用一個環境的配置，這是行不通的。
• 第二種方案分支②：把admin系統所依賴的接口再出一個api層，實現遠程調用。從字面上，這是最優雅的方案，但如果admin系統依賴的接口眾多的時候，實際踐行的時候會發現這工作量巨大。
  • admin系統所依賴的接口有40+個，這些接口所依賴的實體有80+個。我搞了大半天，發現完全搞不動，工作量巨大！！這是單純的體力活

第二個方案的分支①三歪再來聊聊為什么說干不了，首先我們的實現是有配置的

我們在deploy的時候就必須指定一個環境，比如我們默認選擇線上環境的配置好了。打完包以后，這個包默認的環境就是給線上使用的。但是admin系統他還需要在線下環境啟動，怎么辦？沒辦法吧？

假設環境配置的問題能解決，等著我們還有各種依賴的問題。admin系統和二方包的依賴沖突了怎么辦？

比如說：相同的配置項，不同的配置信息。在service系統上能兼容（畢竟代碼都在同一個工程下），但直接打成二方包就沒法跟admin系統兼容了。

這只能刪除沖突的部分，然后再發包了吧？但沖突是admin系統沖突的，跟我service系統的有啥關系呢？這我要做成一個完美兼容admin和service系統的Module嗎？老實說，不太現實。

扯了一大堆，三歪最終選擇的是第一個方案。

在初期現在dao層的代碼肯定是在admin和service系統上冗余的。service層不好抽取，但dao層還是相對好抽取的啊。

為什么dao和service層的代碼不一樣？明明我在上面已經講了怎么多直接抽取二方包的不可行性了。

dao層的代碼相較于service層的代碼要簡單多了，一個合格dao層應該是只管訪問數據庫，不應該有dao層的代碼去調service層的代碼的。

代碼的簡單意味著依賴會很少，比如我們的dao層就應該只有Mybatis和Spring相關的依賴，其余的就不應該有。而前面提到的環境配置的問題，我們可以交給業務方去實現，不在dao層上做任何配置信息，開個hook給業務方去做。

像三歪這種”微服務“系統，本應該要把dao層給抽出來。再回看我的系統架構圖，可以發現會有幾個系統都需要依賴dao，如果沒有抽出來，這必會冗余，冗余的代碼意味著不好維護。

規范

之前看不懂的阿里巴巴開發手冊，現在能看懂了。我建議有空的時候還是可以看看的，都說得挺有道理的。

阿里大佬們踩了一堆坑，然后總結出來的規范。

【強制】二方庫的新增或升級，保持除功能點之外的其它 jar 包仲裁結果不變。如果有改變，

必須明確評估和驗證，建議進行 dependency:resolve 前后信息比對，如果仲裁結果完全不一

致，那么通過 dependency:tree 命令，找出差異點，進行<excludes>排除 jar 包。

【參考】為避免應用二方庫的依賴沖突問題，二方庫發布者應當遵循以下原則：

1）精簡可控原則。移除一切不必要的 API 和依賴，只包含 Service API、必要的領域模型對

象、Utils 類、常量、枚舉等。如果依賴其它二方庫，盡量是 provided 引入，讓二方庫使用

者去依賴具體版本號；無 log 具體實現，只依賴日志框架。

2）穩定可追溯原則。每個版本的變化應該被記錄，二方庫由誰維護，源碼在哪里，都需要能

方便查到。除非用戶主動升級版本，否則公共二方庫的行為不應該發生變化。

…

三歪瞎扯

為什么我們會用多模塊(Module)？其實就是讓我們的項目代碼變得更加清晰，像對外服務的api層就必須要抽出一個精簡的Module給別人使用。

不知道你們如果能看完這篇文章能不能有所啟發，反正我已經寫完了。如果你們感興趣的話，等我整合完這些系統我再來寫一篇關于這段時間的感受。

我是三歪，一個要成為光頭強的男人，下期見。給三歪點個贊，對三歪真的非常重要！**

總結

以上是生活随笔為你收集整理的用实战项目经验告诉你什么是二方包！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。