系統模塊劃分設計的思考

系統模塊劃分設計的思考

前言

首先明確一下，這裏所說的系統模塊劃分，是針對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。二者的組合方式有不少，取決於使用者的須要，之後有機會寫一篇相關的博客。不過，我但願你們記住 面向接口編程的原則。

願與諸君共進步。