背景
如題，最近接到的一個技術需求：優化老項目的代碼，需求已經結束了，覆盤一下整個過程和方案，大致的背景是：目前我所負責的項目中的商品，庫存以及訂單等數據需要和供應商做數據同步，商品數據和庫存數據需要即時從供應商處獲取，訂單數據需要推送給供應商發貨，並且後續持續同步物流數據。
如圖所示，模式並不複雜，可以說是簡單清晰，那麼有什麼可以優化的呢？
實際情況比圖示要複雜的多，做過類似事情的朋友應該都知道，對接外部系統遠遠要比自己寫代碼複雜的多，情況也更加多變，更不可控制，所以目前主要的問題有以下幾個：
-
代碼複用差。由於歷史原因，目前在項目中，四家供應商四套代碼，四套定時任務，這樣的代碼冗餘嚴重，維護也很困難，再加上下半年要接入多家供應商，所以需要統一接口，理想的結果就是所有的供應商使用同一套代碼。
當然了，理想情況是這樣，畢竟之所以有現在這個現狀就是因爲雖然數據大體是一致的，但是在接口對接的細節上各個供應商的差異很大。
所以目前對結果的最優預期是：所有供應商統一一套接口，代碼實現部分酌情統一，儘可能的剝離差異點，實現核心代碼的複用
-
代碼性能差。雖然定時任務不需要太在意性能，但是現在的代碼沒有注意過任何性能問題，也不太合適，例如：查詢到供應商數據之後是遍歷一條一條更新數據庫的，性能着實有點太差了。再例如所有代碼都是同步單線程的，不能很好的利用系統的性能，最好異步多線程。
-
其他的細節問題：
1. 請求優化，應該可配置每次請求的數據數量
2. 幾乎所有的數據都需要輪表，那麼查詢要優化，不能出現selecAll的情況，可能OOM
3. 做好關鍵數據的記錄，涉及到庫存，訂單等數據的改動，要做好記錄，並且不能影響主流程
等等
方案分析
通過以上的簡單說明，我相信大家應該對問題有了基本瞭解。那麼說一下第一期的優化方案吧。
關於這次項目優化，核心目的是三個，1.所有供應商接口要進行統一，2.所有的數據庫操作環節要保證性能，3.複用 複用 還是複用。
數據庫更新優化
首先優化的內容是供應商數據請求和數據庫操作，這兩個部分和具體的業務實際上沒有關係。
關於數據庫操作，以庫存數據爲例
簡單分析
-
異步改造
1. 現在的代碼是先調用供應商接口查詢到所有數據，然後再進行數據庫添加操作，且不說性能如何，大對象多了容易OOM。所以查詢操作和數據庫添加操作應該是互相分離的，一邊查詢一邊添加數據庫，同時進行。
2. 如圖所示，查詢到庫存數據之後，需要進行三個數據庫操作，一個主流程操作，剩下兩個對主要業務影響不大，那麼就需要讓後兩個操作不影響主流程，解耦。
-
批量更新。這一點沒什麼可說的，數據庫修改應該是批量的，性能更好。
確定方案
-
針對第一點，最終採用了觀察者模式。具體分析和實現後續文章展開來講
-
針對第二點，Mybatis 動態sql + Spring重試機制可以解決問題。具體分析和實現後續文章展開來講
接口統一封裝
統一所有代碼和定時任務，倒沒有什麼太細節的方案，接口抽象，一個Java程序員基本的素質，只能說面向對象 yyds。
最終實現了所有供應商使用同一套接口，而不同供應商差異部分做對應SDK的封裝處理。同樣具體分析和實現後續文章展開來講
結束
本文先介紹一下相關的背景和方案，後續文章再來講細節實現展開，同時由於各位看官老爺的技術背景不同，實現中的相關技術設計模式，重試機制，批量更新，反射封裝等也會有相關教程提供，保證各位能夠學有所獲。
作爲秋溢路某廠不知名 Java 專家，實戰經驗還是有一些的，所以本系列文章不同於以前的文章，將會圍繞自己開發中的相關問題進行展開，希望大家可以增加項目經驗和解決問題的方案角度，暫定的文章更新順序爲：
-
供應商系統優化
-
IM 和 推送系統 設計開發優化
-
結算中心 設計開發優化
本文分享自微信公衆號 - 鹿小洋的Java筆記（lulaoshiJava）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。