移動端工程架構與後端工程架構的思想摩擦之旅
此文已由作者黎星授權網易雲社群釋出。
歡迎訪問 網易雲社群 ，瞭解更多網易技術產品運營經驗
記資源投放後端工程的架構調整與優化
架構思考
一直以來對軟體工程架構有著極大的興趣，無論是之前負責的移動端Android工程，亦或是現在轉到後端開發後維護的資源投放工程。可以說一個團隊中並非每個開發都能夠深入掌握架構知識，但需要每個人能夠擁有軟體架構的意識。架構是對工程整體結構與元件的抽象描述，是軟體工程的基礎骨架。架構在工程層面不分領域，且思想是通用的。引用維基百科對於軟體架構的定義 ^1 ：
軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築專案的設計原則和目標，作為繪圖員畫圖的基礎一樣，軟體架構師或者系統架構師陳述軟體架構以作為滿足不同客戶需求的實際系統設計方案的基礎。從和目的、主題、材料和結構的聯絡上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來實施和管理軟體產品的高階設計。軟體架構師定義和設計軟體的模組化，模組之間的互動，使用者介面風格，對外介面方法，創新的設計特性，以及高層事物的物件操作、邏輯和流程。
架構的合理設計可以解決面對複雜系統時可能面臨的很多問題，例如：
- 業務邊界與模組職責劃分問題
- 程式碼許可權控制問題（資料庫不應直接被業務方呼叫）
- 程式碼重複，邏輯分支多，壞味道多的問題
- 由於考慮不周，可能存在隱藏bug
- 修改一個邏輯需要修改N個地方程式碼邏輯
從實際的實踐來看，的確如此。以前在移動端做的架構設計流程，在後端重新得到了實踐。
移動端架構思考
尚未接觸到強大的Spring容器之前，我一直探索著在移動端有一種能夠在編譯期暴露服務宣告，執行時自動注入實現類的做法；接觸到Spring以後，得以理解這其實就是IoC容器的概念。Android的元件化思想，以及網上釋出的各類元件化的技術文章，給了我很多值得借鑑的思路。客戶端的程式碼一般是以module來組織的。一個module，既可以配置成為一個獨立釋出的庫，也可以編譯成一個單獨的apk。元件化的概念正是利用了module這一特點，將一個大工程中的業務拆分成一個個module，各個module間的業務相對獨立，元件間通過各自暴露的業務介面實現通訊。基於此思想的移動端架構模型可以使用下圖來表示。
該架構模型由5個部分組成，分別是Toolkit/ToolkitSDK module、基礎元件庫/基礎元件庫module、基礎服務介面/業務服務介面module、服務排程中心module以及業務module。
- Toolkit/Toolkit SDK
Toolkit是工具類及與工具類相關的SDK的集合。工具類屬於工程架構裡最基礎的模組，提供了通用的方法與工具類服務（工具類服務是指可以被抽象成一個獨立的與業務無關的基礎服務，如快取、資料庫操作等）。工具類通常作為最底層的module，被其他所有模組引用。
- 基礎元件庫/基礎元件SDK
基礎元件庫是基礎元件及相關SDK的集合。基礎元件庫提供與業務相關的基礎元件，是構建一個移動端應用所需要的通用元件的集合。它與工具類的區別在於基礎元件庫可能會包含少量業務邏輯程式碼，是無法拆分給其他應用使用的；另一方面，基礎元件庫是基礎服務介面的實現，是不對業務層暴露的，避免了業務層與基礎SDK打交道，有利於整體替換底層基礎框架的實現（例如Volley替換為OkHttp、Fresco替換為Glide）。
- 基礎服務介面/業務服務介面
基礎服務介面聲明瞭一組通用的基礎服務，業務層通過基礎服務介面獲取基礎服務，如網路請求、圖片載入等。業務服務介面聲明瞭一組該模組提供給其他模組的服務，業務之間的通訊也是通過服務介面來完成的。例如首頁模組需要獲取購物車的商品數量，首先通過服務排程中心獲取購物車的服務介面，再通過服務介面呼叫購物車獲取商品數量的介面方法即可。
- 服務排程中心
服務排程中心，是一個介面收集與管理的容器。服務排程中心將所有基礎服務介面與業務介面收集起來，通過一定的方式與它們的實現類進行繫結。所有的業務都需要通過服務排程中心才能夠獲取到服務。服務的註冊與發現和Spring容器的IoC思想是類似的。
- 業務層
業務層是每個業務的具體實現的集合。業務層的業務之間是沒有直接引用關係的，業務層提供了業務服務介面中暴露的服務的具體實現。業務之間的通訊需要通過服務排程中心獲取其他業務的服務介面。
移動端架構小結
通過介面服務架構模型，模組之間是高度解耦的。業務負責人唯一需要維護的公共部分便是這個模組在業務服務介面中暴露的服務。對於業務服務的介面功能增改變得非常方便，業務實現的邏輯更改、程式碼優化等，只要不改變服務介面的簽名，就不需要其他業務方改動任何程式碼即可完成，由此團隊的開發效率是非常高的。
後端架構思考
對於後端工程來說，架構的設計與實現必定是與工程的業務難度及複雜程度相關的，如果只是很簡單的業務模型，就沒有必要弄得太過複雜，避免得不償失。本人只接觸了幾個月後端知識，對於後端的架構體系與演進過程處於不斷地學習和探索中。投放系統是我接觸到的第一個完整的後端工程，其中Web工程採用傳統的MVC架構 ^2 ，對我具有很大地學習和借鑑意義，專案架構如下圖所示。
該架構縱向劃分成展示層、控制層、服務層、物件關係對映層和資料服務層5個部分，層級間通過AOP的方式插入了業務監控、日誌、許可權控制、統計分析等功能。
- 展示層（View）
展示層是系統與使用者打交道的地方，提供與使用者互動的介面。對於使用者而言，只有展示層是可見的、可操作的。展示層對於某些工程來說不是必須的，例如提供純後臺服務的工程。
- 控制層（Controller）
主要負責與Model和View打交道，但同時又保持其相對獨立。Controller決定使用哪些Model，對Model執行什麼操作，為檢視準備哪些資料，是MVC中溝通的橋樑。在Controller層提供了http服務供展示層呼叫。在依賴管理中，控制層需要依賴服務層提供服務。
- 服務層（Service/Facade）
服務層是業務邏輯實現的地方，上層需要使用的功能都在服務層來實現具體的業務邏輯。服務層就是將底層的資料通過一定的條件和方式進行資料組裝並提供給上層呼叫。服務層可以拆分為業務介面和業務實現，業務實現可以對外部隱藏。在投放工程中，控制層既依賴了業務介面，又依賴了業務實現。後面的改造我們可以看到，編譯期紅色線依賴是完全沒有必要的。服務層需要依賴資料關係對映層與持久層的資料打交道。
- 物件關係對映層（ORM）
物件關係對映層的作用是在持久層和業務實體物件之間作一層資料實體的對映，這樣在具體操作業務物件時，只需簡單的操作物件的屬性和方法，不需要去和複雜的SQL語句打交道。ORM使得業務不需要關心底層資料庫的任何細節，包括使用的資料庫型別、資料庫連線與釋放細節等。物件關係對映層只依賴資料服務層提供服務。
- 資料服務層（Data Server）
資料服務就是提供資料來源的地方。資料服務可以提供持久化資料及快取資料。持久，即把資料（如記憶體中的物件）儲存到可永久儲存的儲存裝置中（如磁碟）。持久化的主要應用是將記憶體中的資料儲存在關係型的資料庫中，當然也可以儲存在磁碟檔案中、XML資料檔案中等等。而快取是將資訊（資料或頁面）放在記憶體中以避免頻繁的資料庫儲存或執行整個頁面的生命週期，直到快取的資訊過期或依賴變更才再次從資料庫中讀取資料或重新執行頁面的生命週期。資料服務層是資料來源頭，處於架構的最底層。
後端架構小結
後端工程，更加註重層級的概念，每一層的職責非常明確。展示層負責與使用者進行頁面互動，控制層合併業務資料並控制View的展示，服務層則是實現業務邏輯的聚集地，物件關係對映層在業務層和資料服務層之間建立通道，而資料服務層則提供資料。總體而言，投放工程的MVC架構給我的感覺是比移動端架構複雜，層級多，職責分工明確，帶來的問題是層級間的互動也比較麻煩。另外服務層裡承載了幾乎所有的業務邏輯，層級偏重，如果沒有好好地梳理業務邏輯劃清邊界，很容易把服務層搞成一鍋粥。清晰的模組職責劃分，可以幫助服務層更好地為控制層服務。
架構思想的摩擦
可以看到，客戶端與後端有著非常相似的架構模型。
- 從程式碼組織的角度：以module作為層級程式碼組織的基本工具，分為工具庫、基礎元件庫（中介軟體）、服務介面/API、服務層/業務層、檢視層等。module間的依賴關係幾乎是一樣的。
- 從業務模型的角度：後端工程分為交易組、商品組、售後組、客服組等，對應移動端的交易鏈路浮層、商品詳情頁、售後詳情頁、幫助與客服頁等，每個業務是由不同的組負責的，業務之間通過約定的介面相互提供服務，各種各樣的業務模型聚合成了整個系統。
- 從功能服務的角度：分為業務服務介面的暴露、業務服務實現的隔離、業務服務的查詢與註冊。
下面從功能服務的角度，詳細說明本文在思想摩擦過程中想要表達的觀點。
業務介面的作用
業務介面，可以認為是這組業務向外暴露其功能的一套標準。標準一旦形成併發布，就需要業務方持續維護這套標準，使得標準變得完善和穩定。同時標準可以更新升級，可以通過版本來實現，提供新的功能。業務介面一般具備以下特性：
- 業務介面包含一組Java的介面集合以及與這些介面相關的POJO，通常打包成一個JAR/AAR包。
- 業務介面只提供介面功能的定義，不包含任務業務邏輯。
- 業務介面可以進行版本管理，一旦版本釋出，則該版本的介面不再可變。業務需要新增功能時，只需要在原有業務介面的基礎上，增加新的功能介面或方法，同時升級業務介面版本號併發布。
其他業務方需要使用該業務的功能，只需要引入該業務的JAR/AAR包，通過服務排程中心獲取該服務介面即可。
業務邏輯的存放
業務介面僅提供了功能的定義，不包含任何業務邏輯。那麼，業務邏輯（即介面的實現類）放哪裡呢？不管是移動端架構還是後端架構，在工程領域，業務邏輯在任何時候都不應該對業務的使用方暴露。這樣做有兩個好處：
- 業務方只關心功能，不關心功能實現的過程。隱藏業務的實現邏輯可以降低業務方使用該功能的成本及複雜度。
- 業務功能的後端邏輯改動及必要的技術優化、效能優化，只要不更改介面簽名，則不會影響當前的業務方使用。
一般情況下，業務的邏輯實現會放在單獨的業務模組中，該業務模組僅限工程內部引用。後端傳統的MVC工程架構把業務的實現邏輯放在了Service/Facade層，層級之間的類不相互引用；而基於驅動領域的設計模型把業務的實現邏輯限定在了一個領域/子域裡，領域之間通過界限上下文繫結。在移動端，時下較為熱門的眾多元件化方案，也是將一個獨立的功能模組作為單獨的module，module可以獨立編譯為apk，也可以通過aar的方式整合到主Application中。
業務邏輯的隔離
業務的使用方包括工程內部的上層業務和外部服務，業務介面與業務邏輯有必要進行程式碼級別的隔離，這樣才能避免上層業務引用到業務邏輯的程式碼。通常，工程的每個模組負責不同的功能，模組之間的引用關係通過依賴管理工具（如Maven或Gradle）來配置。我們可以巧用依賴管理工具的runtime compile機制來實現執行時依賴。即在編寫對外介面的時候，不直接引用包含業務邏輯的module，等到編譯的時候再把業務邏輯程式碼一起編譯進來，然後在執行時通過一定的方式呼叫對應的業務邏輯。
下面的兩張圖簡單介紹了後端工程和移動端工程基於業務邏輯隔離的工程架構思路。其中，虛線表示runtime compile依賴，實線表示正常的依賴關係。
工程的啟動入口幾乎不包含業務程式碼，只包含配置檔案。Controller層是一組RestfulApi的集合，給前端和客戶端提供http請求服務，業務介面/API是一組dubbo介面，給其他工程業務方提供RPC呼叫。Controller層在編碼的時候只依賴Service/Facade介面，在編譯期依賴Service和Facade介面的實現。這樣設計還有一個好處是對DAO層的保護，DAO層只和Service層打交道，Controller以及對外提供的dubbo介面是引用不到的，更好地保護資料安全。
在移動端的架構中，單Application+多module已經成為主流。每個module負責一塊獨立的業務，如首頁、訂單、購物車等，核心模組也可以拆分為獨立模組，如網路引擎、圖片引擎。這些獨立的模組可以抽離出BusinessService/CoreService服務介面，模組間的互動只需要通過Service介面通訊即可，業務對於其他的p_CoreSDK/Business的邏輯實現是不可見的。
業務介面的註冊
有了業務介面和業務實現，還需要一種在執行時把它們“粘合”起來的工具，這一過程可以稱為業務介面的註冊。當業務方訪問業務介面時，這個工具需要幫助我們查詢到對應的業務實現。控制反轉（IoC）或依賴注入（DI）的思想給我們提供瞭解決辦法。
在後端工程中，Spring是最為常用的IoC容器之一。Spring在執行時根據配置檔案或註解動態生成物件，再由變數註解通過Java反射注入到對應的例項中。因此程式碼中只需要通過在全域性變數宣告相應的註解即可完成業務介面的註冊。
移動端由於有限的硬體資源，更多地把CPU時間分配給了頁面渲染，保證應用體驗流暢，不太可能在應用啟動的過程中大量通過反射生成例項物件，因此移動端並沒有出現Spring框架。儘管如此，依賴注入的思想是通用的。通常移動端只需要保證在執行時能夠獲取到對應的業務實現，幾乎沒有在執行時動態改變業務實現的需求，聰明的工程師想到了把服務的註冊提前到編譯期進行，這一過程可以使用JDK提供的 Annocation Processing Tool 完成（例如 Dagger2 ），也可以在編譯生成Class位元組碼以後使用ASM操作位元組碼註冊實現（如 ARouter ）。
投放工程架構調整
有了前面的“理論基礎”，以及躍躍欲試的心動，我們來對投放工程的架構做一次調整和優化，原則是不改變原有的業務邏輯，目的是使投放工程的業務邊界和業務功能更為清晰。
舊工程架構
資源投放系統一共分為4個工程，分別是
- 後端前臺工程： kaola-resource-app
- 後端離線工程： kaola-resource-offline
- 後端後臺Web工程： kaola-resource-web
- 前端後臺fed工程： kaola-resource-fed
其中，kaola-resource-app和kaola-resource-offline提供純dubbo服務。app提供前臺服務，負責給其他業務線上獲取投放的素材資訊；offline提供離線服務，負責給其他業務的後臺系統獲取投放相關的資料。kaola-resource-web和kaola-resource-fed分別是投放系統的Web後端和前端工程，資源的分配、稽核、投放都在該系統完成。kaola-resource-fed屬於前端工程，不在本文討論範圍內，下面介紹三個後端工程的架構體系。
工程依賴關係
工程依賴關係如圖所示，主要分為幾類，分別是工具模組、介面模組、業務模組以及啟動模組，箭頭表示依賴關係。
- 工具模組
kaola-common-cache：主要包含Solo快取中介軟體的封裝，JVM快取相關的不在該模組裡。
kaola-common-util：工具類，包括常量、異常資訊及util類。
kaola-resource-search->kaola-resource-generic：ndir索引服務工程。
kaola-resource-schema（圖中未列出）：存放投放自帶部分模板xml的地方，暫無其他工程引用。
- 介面模組
kaola-resource-api：提供線上和離線服務的dubbo介面。
kaola-resource-generic：通過mybatis與資料庫打交道，提供資料的工程，相當於DAO層。
kaola-resource-facade->kaola-resource-generic：提供Web層的facade介面，相當於Service層。
- 業務實現
kaola-resource-cache->kaola-resource-api、kaola-resource-generic、kaola-common-cache：提供業務報警、disconf配置、JVM快取、NCR快取、熔斷、業務監控、執行緒池管理等功能，且提供resource-api部分facade介面的實現、Service介面定義與實現，是resource-app工程的業務實現工程。
kaola-resource-provider->kaola-resource-facade、kaola-resource-api、kaola-service-util、kaola-resource-search、kaola-resource-generic：提供web工程facade介面的實現、Service介面定義與實現。
kaola-resource-service->kaola-resource-generic、kaola-resource-api：提供offline工程facade介面的實現、Service介面定義與實現。
kaola-service-util->kaola-resource-facade、kaola-common-util、kaola-resource-api：主要包含外部模板XML校驗業務的工程。
- 啟動模組
kaola-resource-app->kaola-resource-cache、kaola-common-cache、kaola-resource-api、kaola-resource-generic：app工程啟動入口，SpringBoot配置。
kaola-resource-offline->kaola-resource-service、kaola-resource-generic、kaola-resource-api：offline工程啟動入口，SpringBoot配置。
kaola-resource-fed：前端後臺工程
kaola-resource-web->kaola-resource-facade、kaola-resource-provider、kaola-resource-facade、kaola-resource-api、kaola-service-util、kaola-resource-search、kaola-resource-generic、kaola-common-util：web工程啟動入口，提供http服務。
現有工程問題
- 工程模組命名混亂
剛接觸投放工程的時候完全不知道從何入手，只能根據啟動工程的依賴關係找到對應的業務模組。總工程裡有4個小工程，通常找一個模組的業務實現不知道去哪個模組去找。例如，從命名上來看，並不知道kaola-resource-facade是web工程的業務介面，kaola-resource-provider是web工程的業務實現，kaola-resource-service是offline工程的業務實現，對新人來說命名不夠友好。
- 模組職責不清晰
由上面梳理的模組功能可以知道，kaola-resource-cache工程不僅承擔了快取管理、業務報警、熔斷等基礎業務，也是app工程的業務實現；kaola-resource-service既提供了業務介面，又提供了業務實現；kaola-common-util沒有發揮它作為工具類應該提供的職責和義務。總體而言，模組的職責可以通過一定的修改變得更為清晰。
- 工具類、常量類管理混亂
目前幾乎每個工程下面都有一個util包，且工程包含多個BusinessException/ParameterException類，帶來的問題是使用時不知道用哪個類。工具類與常量類應統一為一個工具類模組，統一管理。
- 版本依賴管理
每個工程的依賴目前都是獨立管理的，存在不同工程依賴中介軟體版本不一致的情況。主工程的pom管理機制可以優化一下，比如disconf是每個工程都要使用的，可以放在父工程使用dependencyManagement統一管理。
- 業務程式碼分支多
當前工程存在很多業務分支，遇到業務分支時大部分是通過if/else判斷的，修改一個業務點需要修改很多地方，通常很容易遺漏，造成隱藏的bug。
新工程架構
考慮到現有工程架構的特點，在新工程的設計上採用平滑過渡的方式，後端主體還是分為web/offline/app三個小工程，這三個小工程分別採用傳統的MVC架構。前端工程由於與後端工程關係不大，後續可以遷移到新工程裡。
工程依賴關係調整
針對舊工程中存在的不合理的點，以及工程中存在的問題，我們對工程及工程的依賴關係進行了如下調整。
紅色背景為刪除或整合的模組，包括kaola-service-util、kaola-common-util、kaola-common-cache。 黃色背景為重新命名的模組，目的是使模組功能定位更清晰，包括
- kaola-resource-provider->kaola-resource-web-provider，表示web工程的業務實現
- kaola-resource-facade->kaola-resource-web-facade，表示web工程的業務介面
- kaola-resource-generic->kaola-resource-dao，表示物件關係對映，即DAO層
- kaola-resource-service->kaola-resource-offline-provider，表示offline工程的業務實現
綠色背景為新增模組，包括kaola-resource-util、kaola-resource-offline-facade、kaola-resource-app-provider、kaola-resource-app-facade，模組的定義也比較明確。 紅色的線為可以移除的依賴關係，黃色的線表示修改為runtime依賴，綠色的線表示新增依賴。
經過上述調整後，一張更為清晰的投放工程架構圖便展現出來了。
工程架構基本思想
新的工程架構，模組間的職責與依賴關係更為清晰。
從模組的職責來說，淺藍色表示底層提供的工具類（包括各種util、快取、索引服務等）；綠色表示資料物件關係對映服務層；黃色表示對第三方暴露的api；粉紅色表示對內提供的業務介面；土黃色表示業務介面的真正實現；深藍色則是工程的啟動入口，包含各種配置檔案。
從模組的依賴關係來說，啟動工程在編譯期僅依賴業務介面，執行時才會依賴業務實現以及與業務實現相關的底層服務，這一操作通過maven的scope標籤完成，編譯期編譯使用的標籤為 <scope>compile</scope> ，執行時編譯使用的標籤為 <scope>runtime</scope> 。索引、快取、工具類作為基礎服務以獨立的模組存在，需要與資料庫打交道的模組則直接依賴kaola-resource-dao即可。
對於當前的架構還不是最完美的，存在兩個問題。
- kaola-resource-cache提供了kaola-resource-api的實現，應將這一部分的業務邏輯移至kaola-resource-app-provider中。
- 業務介面依賴了kaola-resource-dao，這一部分因為介面使用了dao層的Entity，需要重新規劃建模，去除對dao層的依賴。
該架構的設計可以做到業務層僅和介面打交道，在業務層實現業務邏輯時，不關心底層服務的實現。業務層也沒有辦法直接和dao層打交道，避免資料被業務層無故修改。
工程模組劃分
- 基礎模組/服務
kaola-resource-fed：前端工程單獨拆出，不與後端工程公用同一個git倉庫
kaola-resource-util：工具類、異常類、常量，可以被所有子工程引用
kaola-resource-cache：快取相關的模組，需要使用快取的工程引用此module
kaola-resource-index：索引工程服務
kaola-resource-dao：資料庫dao層
kaola-resource-api：暴露對第三方提供的所有服務api，包括online和offline介面
kaola-resource-facade-base：存放所有facade工程的基礎介面和異常類，上述流程圖沒有展示出來，但確實是有必要的基礎模組。
- web工程
kaola-resource-web-facade：web工程服務暴露，僅提供facade介面和資料實體類
kaola-resource-web-provider：web工程服務實現，根據需要自定義service層元件
kaola-resource-web：web工程啟動類，compile依賴facade，runtime依賴provider
- offline工程
kaola-resource-offline-facade：offline工程內部服務，僅提供介面和資料實體類
kaola-resource-offline-provider：offline工程服務實現，及部分kaola-resource-api實現，提供dubbo provider
kaola-resource-offline：offline工程啟動類，compile依賴facade，runtime依賴provider
- app工程
kaola-resource-app-facade：app工程內部服務，僅提供介面和資料實體類
kaola-resource-app-provider：app工程服務實現，及部分kaola-resource-api實現，提供dubbo provider
kaola-resource-app-starter：app工程啟動類，compile依賴facade，runtime依賴provider
現有工程改造方案
工程模組改造
在上述改造原則基礎上，投放工程的模組改造計劃可以清晰地列出來。針對基礎模組來說，需要進行如下改造：
- 新增kaola-resource-facade-base工程，存放facade的異常類
- kaola-common-cache重新命名為kaola-resource-cache
- kaola-common-util重新命名為kaola-resource-util
- kaola-resource-generic重新命名為kaola-resource-dao
- 新增kaola-resource-facade-base工程，存放facade的異常類
剩餘的三個工程，以resource-web工程為例，需要進行如下改造：
- 將kaola-resource-facade重新命名為kaola-resource-web-facade，存放對web工程提供的服務介面，將BusinessException和ParameterException移除放到facade-base工程中
- kaola-resource-provider重新命名為kaola-resource-web-provider，將模組中的util遷移至resource-util工程
- kaola-service-util中非業務相關的所有util全部移動到kaola-resource-util這個module中，剩餘業務相關的，移動到kaola-resource-web-provider工程
- kaola-resource-web，將web對provider的依賴由compile改為runtime
offline和app工程採用類似的方案，不再贅述。
maven依賴改造
maven依賴改造的目的，一是減少由於版本依賴不一致帶來的新坑，方便第三方中介軟體的統一管理；二是對工程許可權有所約束，不至於程式碼亂放，難以維護。
-
共有的jar包依賴管理 在父pom增加dependencyManagement標籤，把常用的Spring、log、guava、junit、jsonserializer、disconf和網易自研的中介軟體等jar包統一進行版本管理。子工程需要相關元件時，僅需引入依賴，無需指定版本。
-
模組依賴許可權管理 由改造後的工程架構可知，啟動工程是沒有辦法接觸到業務實現的，這需要依靠runtime時再依賴業務實現模組來實現。因此，對於每個需要依賴*-provider的工程，都需要通過runtime來依賴。
-
api版本釋出管理 需要對外發布的包，依賴儘量使用provided引入。在父pom增加本地api釋出的版本，子工程如需依賴api或實現api的業務，需要引用父pom的api版本，api版本的升級，需要同時升級父pom和api模組工程兩個地方 resource-util工程與api工程管理一致。
TODO
- kaola-resource-api遷移所有page相關的api介面
- kaola-resource-fed遷移使用新的git工程
- kaola-resource-cache邏輯遷移
- kaola-resource-dao業務介面的依賴去除
架構調整總結
架構永遠是聊不完的話題，特別是涉獵了知識面較廣的後端以後，越發感覺需要學習的東西越來越多。本文分別從移動端和後端的架構思想談起，從中探索共同點，結合微服務的思想，探索過程中對多端架構有了思想的摩擦，總結了一套業務介面與業務實現的規範，能夠更好地為其他業務提供服務。在此基礎上，將這一套規範運用在投放工程上，完成從舊架構的問題分析，到新架構的優化設計與實現的整個過程。從結果來看，模組的職責更為清晰，程式碼的許可權與邊界得到了比較好的控制，對以後業務的縱橫向擴充套件、程式碼的健壯性都有了質的保障。
參考連結
- https://zh.wikipedia.org/wiki/%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84
- https://zh.wikipedia.org/wiki/MVC
- https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
- https://docs.gradle.org/current/userguide/dependency_types.html
免費領取驗證碼、內容安全、簡訊傳送、直播點播體驗包及雲伺服器等套餐
更多網易技術、產品、運營經驗分享請點選。