系統模塊劃分設計的思考

前言

首先明確一下，這里所說的系統模塊劃分，是針對client，service，common這樣的技識訓分，而不是針對具體業務的模塊劃分，避免由于歧義，造成你的時間浪費，

直接原因

公司內部某技術團隊，在參考我們系統的client包時，啟動失敗，
失敗原因是由于client下有一個cache相關的依賴，其注入失敗導致的，

然后，就發出了這樣一個疑問：我只是希望使用一個hsf介面，為什么還要引入諸如快取，web處理工具等不相關的東西，

這也就自然地引出了前輩對我的一句教導：對外的client需要盡可能地輕便，

很明顯，我們原有的client太重了，包含了對外的RPC介面，相關模型（如xxxDTO），工具包等等，

可能有人就要提出，直接RPC+模型一個包，其它內容一個包不就OK了嘛？

問題真的就這么簡單嘛？

根本原因

其實出現上述問題，是因為在系統設計之初，并沒有深入思考client包的定位，以及日后可能遇到的情況，

這也就導致了今天這樣的局面，所幸目前的外部參考并不多，更多是內部參考，及時調整，推廣新的依賴，與相關規范為時不晚，

常見模塊拆分

先說說我以前的模塊拆分，最早的拆分是每個業務模塊主要拆分為：

• xxx-service：具體業務實作模塊，
• xxx-client：對外提供的RPC介面模塊，
• xxx-common：對外的工具，以及模型，

這種拆分方式，是我早期從一份微服務教程中看到的，優點是簡單明了，呼叫方可選擇性地選擇需要的模塊引入，

至于一些通用的組件，如統一回傳格式（如ServerResponse，RtObject），則放在了最早的核心（功能核心，但內容很少）模塊上，

后來，認為這樣并不合適，不應該將通用組件放在一個業務模塊上，所以建立了一個base模塊，用來將通用的組件，如工具，統一回傳格式等都放入其中，

另外，將每個服務都有的xxx-common模塊給取消了，將其中的模型，放入了xxx-client，畢竟是外部呼叫需要的，將其中的工具，根據需要進行拆分：

• base：多個服務都會使用的，
• xxx-service：只有這個服務本身使用
• xxx-client：有限的服務使用，并且往往是服務提供方和服務呼叫方都要使用，但是往往這種情況，大多是由于介面設計存在問題導致的，所以多為過渡方案，

上述這個方案，也就是我在負責某物聯網專案時采用的最終模塊劃分方式，

在當時的業務下，該方案的優點是模塊清晰，較為簡潔，并且盡可能滿足了迪米特原則（可以參考《阿里Java開發手冊相關實踐》），缺點則是需要一定的技術水平，對組件的功能域認識清晰，并且需要有一定的設計思考與能力（如上述工具拆分的第三點-xxx-client，明白為什么這是設計缺陷導致，并能夠解決），

新的問題

那么，既然上述的方案挺不錯的，為什么不復用到現在的專案呢？

因為業務變了，導致應用場景變了，而這也帶來了新的問題，新的考慮角度，

原先的物聯網業務規模并不大，所以依賴也較為簡單，也并不需要進行依賴的封裝等，所以針對主要是client的內/外這一維度考慮的，

但是現有的業務場景，由于規模較大，模塊依賴層級較多，導致上層模塊引入過多的依賴，如有一個快取模塊，依賴tair-starter（一個封裝的key-value的存盤），然后日志模塊依賴該快取模塊（進行性能優化），緊接著日志模塊作為一個通用模塊，被放入了common模塊中，依賴鏈路如下：

呼叫方 -> common模塊 -> 日志模塊 -> 快取模塊 -> tair-starter依賴

但是有的呼叫方表示，根本就不需要日志模塊，卻引入了tair-starter這一重依賴（starter作為封裝，都比較重），甚至由于tair-starter的內部依賴與自身原有依賴沖突，得去排查依賴，進行exclude，
但是同時，也有的呼叫方，系統通過rich客戶端，達到性能優化等目標，

所以，現有的業務場景除了需要考慮client的內/外這一維度，還需要考慮client的pool/rich這一維度，

可能有的小伙伴，看到這里有點暈乎乎的，這兩個維度考量的核心在哪里？

內/外，考慮的是按照內外這條線，盡量將client設計得簡潔，避免給呼叫方引入無用依賴，

而pool/rich，考慮的是性能，用戶的使用成本（是否開箱即用）等，

最終解決方案

最終的解決方案是對外提供3+n

• xxx-client（1個）：所有外部系統參考都需要的內容，如統一回傳格式等，
• xxx-yyy-client（n個）：對具體業務依賴的參考，進行了二次拆分，如xxx-order-client（這里是用訂單提花那你一下，大家理解意思就OK），
• xxx-pool-client（1個）：系統參考所需要的基本依賴，如Lindorm的依賴等，
• xxx-rich-client（1個）：系統參考所需要的依賴與對應starter，如一些自定義的自動裝載starter（不需要用戶進行配置），

這個方案，換個思路，理解也簡單，
我們提供相關的能力，具體如何選擇，交給呼叫方決定，

其實，討論中還提到了BOM方案（通過DependentManagement進行jar包版本管理），不過分析后，我們認為BOM方案更適合那些依賴集比較穩定的client，如一些中間件，而我們目前的業務系統，還在快速發展，所以并不適用，

總結

簡單來說，直接從用戶需求考慮（這里的用戶就是呼叫方）：

• 外部依賴：
  • 額外引入的依賴盡可能地少，最好只引入二方依賴（我們提供的jar），不引入第三方依賴，
  • 引入的二方依賴不“夾帶”私貨（如二方jar引入了一堆大第三方依賴），
• 自動配置：
  • 可以傻瓜式使用，如引入對應的starter依賴，就可以自動裝配對應默認配置，
  • 也可以自定義配置，用戶可以在自定義配置，并不用引入無效的配置（因為starter經常引入不需要的依賴），
• 性能：
  • 可以通過starter，提供一定的封裝，保證一定的性能（如介面快取，請求合并等），
  • 可以自定義實作基礎功能，因為有些人并不放心功能封裝（雖然只是少數，但是穩定性前輩提出的），

補充

這里補充一點，我對討論中一個問題的回答，這里提一下，

有人提到工具類，應該如何劃分，因為有的工具類，是不依賴于服務狀態的，如CookieUtil進行Cookie處理，有的工具類，是依賴于服務狀態的，如RedisUtil包含RedisPool狀態，直連Redis，處理Redis請求與回應，

其實這里有兩個細節：

• 工具應該按照上面的方式進行劃分為兩種，單一模塊系統，不依賴服務狀態的工具往往置于util包，依賴服務狀態的工具往往置于common包中，這里還有一個明顯的區分點：前者的方法可以設為static，而后者并不能（因為依賴于new出來的狀態），
• 依賴于狀態的工具類，其實是一種拆分不完全的體現，如RedisUtil，可以拆分為連接狀態管理的RedisPool與請求回應處理的RedisUitl，兩者的組合方式有很多，取決于使用者的需要，以后有機會寫一篇相關的博客，不過，我希望大家記住 面向介面編程的原則，

愿與諸君共進步，

標籤：架構設計

上一篇：springcloud 專案原始碼 微服務 分布式 Activiti6 作業流 vue.js html 跨域 前后分離

下一篇：谷歌瀏覽器中預覽海康大華等監控視頻的思路與方法