作者 | 興亮
來源 | 阿裡技術公衆号
本文的重點在于說明工作中所使用的設計模式，為了能夠更好的了解設計模式，首先簡單介紹一下業務場景。使用設計模式，可以簡化代碼、提高擴充性、可維護性和複用性。有哪些設計模式，這裡就不再介紹了，網上很多，本文隻介紹所用到設計模式。
一 線路檢查工具
1 意義
為什麼需要線路檢查工具呢，有以下幾個方面的原因：
- 每逢大促都需要進行各網絡和各行業的線路調整，調整完成之後，是否得到期望狀态，需要檢查确認。
- 上下遊應用之間資料的一緻性檢查，如果存在不一緻，可能會在訂單履行時造成卡單。
- 有些問題發生後，業務同學需要全面檢查一遍線路資料，判斷是否符合預期。
- 各領域之間的資料變更缺乏關聯性，導緻資源和線路出現不一緻。
為什麼要把線路檢查工具産品化呢，考慮如下：
- 以前每次大促，都是技術同學現場編寫代碼撈資料給到業務同學，而且因為人員流動性較大，代碼可複用性較低，導緻重複勞動。産品化後，可以友善地傳承下去，避免不必要的重複勞動。
- 每次因為時間緊急，現場寫的代碼都比較簡單，經常是直接将資料列印到标準輸出，然後複制出來，人工拆分轉成Excel格式；這樣的過程要進行多次，占用太多技術同學的時間。産品化後，解放了技術同學，業務同學可以自己在頁面操作。
- 很多資料檢查，是每次大促都會進行的，業務同學與技術同學之間來回溝通的成本較高。産品化後，可以避免這些耗時耗力的溝通，大家可以把更多的時間放在其他的大促保障工作上。
2 檢查項
根據2020年D11進行的資料檢查，本次共實作8項，下面列舉了4項，如下：
- 時效對齊檢查：確定履行分單正常。
- 弱控線路與表達網絡一緻性：確定履行和路由不會因為線路缺失而卡單。
- 資源映射和編碼映射一緻：前者是表達線路時所用，後者是訂單履約時所用，確定表達和履約能夠一緻。
- 檢查線路數量：統計現存線路的情況。
好了，了解了背景知識，下面開始介紹所用到的設計模式，以及為什麼要用、怎麼用。
二 設計模式
1 模闆方法模式+泛型
上述8項資料檢查工具，大緻的處理流程是類似的，如下：
針對不同的檢查工具，隻有“線路資料檢查”這一步是不一樣的邏輯，其他步驟都是相同的，如果每個檢查工具都實作這麼一套邏輯，必定造成大量的重複代碼，維護性較差。
模闆方法模式能夠很好地解決這個問題。模闆方法設計模式包含模闆方法和基本方法，模闆方法包含了主要流程；基本方法是流程中共用的邏輯，如建立檢查任務，結果輸出等等。
下圖是所實作的模闆方法模式的類繼承關系：
分析如下：
1）DataCheckProductService接口為對外提供的服務，dataCheck方法為統一的資料檢查接口。
2）AbstractDataCheckProductService是一個抽象類，設定模闆，即在dataCheck方法中設定好流程，包括如下：
- commonParamCheck方法：進行參數合法性檢查，不合法的情況下，直接傳回。
- createFileName方法：建立檔案名稱。
- createTaskRecord方法：建立檢查任務。
- runDataCheck方法：進行資料檢查，這是一個抽象方法，所有檢查工具都要實作此方法，以實作自己的邏輯。
- uploadToOSS方法：将檢查結果上傳到OSS，便于下載下傳。
- updateRouteTask方法：結束時更新任務為完成。
dataCheck方法為模闆方法，runDataCheck方法由各個子類去實作，其他方法是基本方法。還有一些其他方法，是各個檢查工具都需要使用的，是以就放在了父類中。
3）CheckSupplierAndCodeMappingService類、CheckLandingCoverAreaService類和CheckAncPathNoServiceService類為具體的檢查工具子類，必須實作runDataCheck方法
因為不同檢查項檢的查結果的格式是不一樣的，是以使用了泛型，使得可以相容不同的檢查結果。
簡化的代碼如下：
/**
* 資料檢查工具産品化對外服務接口
* @author xxx
* @since xxx
* */
public interface DataCheckProductService {
/**
* 資料檢查
* @param requestDTO 請求參數
* */
< T> BaseResult< Long> dataCheck(DataCheckRequestDTO requestDTO);
}
/**
* 資料檢查工具産品化服務
*
* @author xxx
* @since xxx
* */
public abstract class AbstractDataCheckProductService implements DataCheckProductService {
/**
* 資料檢查
* @param requestDTO 請求參數
* @return
* */
@Override
public < T> BaseResult< Long> dataCheck(DataCheckRequestDTO requestDTO){
try{
//1. 參數合法性檢查
Pair< Boolean,String> paramCheckResult = commonParamCheck(requestDTO);
if(!paramCheckResult.getLeft()){
return BaseResult.ofFail(paramCheckResult.getRight());
}
//2. 建立導出任務
String fileName = createFileName(requestDTO);
RouteTaskRecordDO taskRecordDO = createTaskRecord(fileName, requestDTO.getUserName());
//3. 進行資料檢查
List< T> resultList = Collections.synchronizedList(new ArrayList<>());
runDataCheck(resultList, requestDTO);
//4. 寫入檔案
String ossUrl = uploadToOSS(fileName,resultList);
//5. 更新任務為完成狀态
updateRouteTask(taskRecordDO.getId(),DDportTaskStatus.FINISHED.intValue(), resultList.size()-1,"",ossUrl);
return BaseResult.ofSuccess(taskRecordDO.getId());
}catch (Exception e){
LogPrinter.errorLog("dataCheck-error, beanName="+getBeanName(),e);
return BaseResult.ofFail(e.getMessage());
}
}
/**
* 進行資料檢查
* @param resultList 存放檢查結果
* @param requestDTO 請求參數
* @return
* */
public abstract < T> void runDataCheck(List< T> resultList, DataCheckRequestDTO requestDTO);
}
/**
* 檢查資源映射和編碼映射一緻
* @author xxx
* @since xxx
* */
public class CheckSupplierAndCodeMappingService extends AbstractDataCheckProductService{
@Override
public < T> void runDataCheck(List< T> resultList, DataCheckRequestDTO requestDTO){
//自己的檢查邏輯
}
}
/**
* 檢查區域内落地配必須三級全覆寫
* @author xxx
* @since xxx
* */
public class CheckLandingCoverAreaService extends AbstractDataCheckProductService{
@Override
public < T> void runDataCheck(List< T> resultList, DataCheckRequestDTO requestDTO){
//自己的檢查邏輯
}
}
/**
* 檢查資源映射和編碼映射一緻
* @author xxx
* @since xxx
* */
public class CheckAncPathNoServiceService extends AbstractDataCheckProductService{
@Override
public < T> void runDataCheck(List< T> resultList, DataCheckRequestDTO requestDTO){
//自己的檢查邏輯
}
} 使用模闆方法模式的好處是：
- 簡化了代碼，每個工具隻需要關心自己的核心檢查邏輯，不需要關注前置和後置操作。
- 提高了擴充性，可以友善地增加新的檢查工具。
- 統一的異常捕獲和處理邏輯，子類有異常，盡管往外抛出。
2 政策模式
之是以會用到政策模式，是因為一些檢查工具寫完之後，發現跑出來的結果資料太多，有幾萬、幾十萬等等，一方面，檢查比較耗時，結果檔案會很大，下載下傳耗時；另一方面，這麼多資料給到業務同學，他們也很難處理和分析，也許他們隻是想看一下總體情況，并不想看具體的到哪個地方的線路。為此，在原先方案設計的基礎上，增加了“統計資訊”的選項，讓使用者可以自行選擇“詳細資訊”還是“統計資訊”，對應到頁面上就是一個單選框，如下：
現在增加了一種檢查方式，今後是否還會有其他的檢查方式？完全有可能的。是以得考慮到擴充性，便于後面同學增加新的檢查方式。
此外，還有一種場景也可以使用政策模式，那就是業務系統中有很多業務網絡，不同網絡之間有一些差異；本次所實作的檢查工具，有幾個涉及到多個網絡，今後可能會涉及到所有網絡。
綜合以上兩種場景，最合适的就是政策模式了。“詳細資訊”和“統計資訊”各采用一種政策，不同網絡使用不同的政策，既便于代碼了解，又便于後續擴充。
“詳細資訊”和“統計資訊”兩種檢查結果的政策類圖如下：
解析：
- CompareModeStrategy對外提供統一的結果處理接口doHandle，政策子類必須實作此接口。
- SupplierAndCodeMappingStatisticsStrategy和SupplierAndCodeMappingDetailStrategy是檢查配送資源和編碼映射一緻性的兩種結果資訊方式，前者為統計方式，後者為詳細方式。
- LandingCoverAreaStatisticsStrategy和LandingCoverAreaDetailStrategy是檢查落地配覆寫範圍的兩種結果資訊方式，前者為統計方式，後者為詳細方式。
- 那AbstractCompareModeStrategy是幹什麼用的？它是一個抽象類，負責承接所有政策子類共用的一些方法。
/**
* 檢查結果政策對外接口
* @author xxx
* @since xxx
* */
public interface CompareModeStrategy {
/**
* 具體操作
*
* @param list
* @param requestDTO
* @return 結果集
* */
< T> List< T> doHandle(List< CompareBO> list, DataCheckRequestDTO requestDTO);
}
/**
* 政策公共父類
*
* @author xxx
* @since xxx
* @apiNote 主要是将子類共用方法和成員抽離出來
* */
public abstract class AbstractCompareModeStrategy implements CompareModeStrategy {
//子類的共用方法，可以放在此類中
}
/**
* 檢查落地配覆寫範圍 詳細資訊 政策類
* @author xxx
* @since xxx
* */
public class LandingCoverAreaDetailStrategy extends AbstractCompareModeStrategy{
@Override
public < T> List< T> doHandle(List< CompareBO> list, DataCheckRequestDTO requestDTO){
List< T> resultList = new ArrayList<>();
//檢查結果處理邏輯
return resultList;
}
}
/**
* 檢查落地配覆寫範圍 統計資訊 政策類
* @author xxx
* @since xxx
* */
public class LandingCoverAreaStatisticsStrategy extends AbstractCompareModeStrategy{
@Override
public < T> List< T> doHandle(List< CompareBO> list, DataCheckRequestDTO requestDTO){
List< T> resultList = new ArrayList<>();
//檢查結果處理邏輯
return resultList;
}
}
/**
* 檢查配送資源和編碼映射一緻 詳細資訊 政策類
* @author xxx
* @since xxx
* */
public class SupplierAndCodeMappingDetailStrategy extends AbstractCompareModeStrategy{
@Override
public < T> List< T> doHandle(List< CompareBO> list, DataCheckRequestDTO requestDTO){
List< T> resultList = new ArrayList<>();
//檢查結果處理邏輯
return resultList;
}
}
/**
* 檢查配送資源和編碼映射一緻 統計資訊 政策類
* @author xxx
* @since xxx
* */
public class SupplierAndCodeMappingStatisticsStrategy extends AbstractCompareModeStrategy{
@Override
public < T> List< T> doHandle(List< CompareBO> list, DataCheckRequestDTO requestDTO){
List< T> resultList = new ArrayList<>();
//檢查結果處理邏輯
return resultList;
}
} 同樣，不同網絡的處理政策類圖如下：
代碼與上面類似，就不展示了。
使用政策模式的好處是：
- 提高代碼擴充性，後續增加别的結果格式或别的網絡處理邏輯，可以在不修改其他政策的情況下直接新增。
- 提高代碼可讀性，取代了if...else，條理清晰。
- 不同系列采用不同的政策，政策與政策之間可以嵌套使用，形成政策的疊加效用。
3 工廠模式
工廠模式解決的是bean的生産問題，簡單工廠模式根據入參生産不同的bean，普通工廠模式針對每個bean都建構一個工廠，此兩者各有優劣，看需要。本方案采用的是簡單工廠模式。
之是以使用工廠模式，是因為有太多的bean需要構造，如果在業務邏輯中構造各種bean，則會顯得淩亂和分散，是以需要一個統一生成bean的地方，更好地管理和擴充。
本方案中主要有三類bean需要工廠來生成：
- 模闆方法模式中所用到的子類。
- 檢查結果格式政策中所用到的子類。
- 不同網絡處理政策中所用到的子類。
是以，使用三個工廠分别構造這三種類型的bean。另外，因為每個bean主要的功能都在方法中，不涉及類變量的使用，是以可以利用spring容器生成的bean，而不是我們自己new出來，這樣就使得bean可以重複使用。是以，這裡的工廠隻是bean的決策（根據參數決定使用哪個bean），不用自己new了。
三個工廠分别如下：
- DataCheckProductFatory：由getDataCheckProductService方法根據輸入參數決策使用哪個資料檢查工具。
- CompareModeStrategyFactory：用于決策使用哪種格式輸出，因為将輸出政策分為了2類（詳細資訊和統計資訊），是以需要傳入兩個參數才能決定使用哪種政策。
- DataCheckNetworkStrategyFactory：用于決策使用哪種網絡處理政策，因為将政策分為了2類（4PL網絡和其他網絡），是以需要傳入兩個參數才能決定使用哪種政策。
這三個工廠的代碼類似，這裡就以CompareModeStrategyFactory為例，簡化的代碼如下：
/**
* 比對結果集方式
* @author xxx
* @since xxx
* */
@Service
public class CompareModeStrategyFactory {
/************************ 詳細結果的bean **************************/
@Resource
private LandingCoverAreaDetailStrategy landingCoverAreaDetailStrategy;
@Resource
private SupplierAndCodeMappingDetailStrategy supplierAndCodeMappingDetailStrategy;
/************************ 統計結果的bean **************************/
@Resource
private LandingCoverAreaStatisticsStrategy landingCoverAreaStatisticsStrategy;
@Resource
private SupplierAndCodeMappingStatisticsStrategy supplierAndCodeMappingStatisticsStrategy;
/**
* 擷取比對結果的政策
* */
public CompareModeStrategy getCompareModeStrategy(DataCheckProductEnum productEnum, DataCompareModeEnum modeEnum){
CompareModeStrategy compareModeStrategy = null;
switch (modeEnum){
case DETAIL_INFO:
compareModeStrategy = getDetailCompareModeStrategy(productEnum);
break;
case STATISTICS_INFO :
compareModeStrategy = getStatisticsCompareModeStrategy(productEnum);
break;
default:;
}
return compareModeStrategy;
}
/**
* 擷取 資訊資訊 政策對象
* */
private CompareModeStrategy getDetailCompareModeStrategy(DataCheckProductEnum productEnum){
CompareModeStrategy compareModeStrategy = null;
switch (productEnum){
case CHECK_LANDING_COVER_AREA:
compareModeStrategy = landingCoverAreaDetailStrategy;
break;
case CHECK_SUPPLIER_AND_CODE_MAPPING:
compareModeStrategy = supplierAndCodeMappingDetailStrategy;
break;
default:;
}
return compareModeStrategy;
}
/**
* 擷取 統計資訊 政策對象
* */
private CompareModeStrategy getStatisticsCompareModeStrategy(DataCheckProductEnum productEnum){
CompareModeStrategy compareModeStrategy = null;
switch (productEnum){
case CHECK_LANDING_COVER_AREA:
compareModeStrategy = landingCoverAreaStatisticsStrategy;
break;
case CHECK_SUPPLIER_AND_CODE_MAPPING:
compareModeStrategy = supplierAndCodeMappingStatisticsStrategy;
break;
default:;
}
return compareModeStrategy;
}
} 使用工廠模式的好處是：
- 便于bean的管理，所有的bean都在一處建立（或決策）。
- 條理清晰，便于閱讀和維護。
4 “代理模式”
這個代理模式是打着雙引号的，因為不是真正的代理模式，隻是從實作方式上來說，具有代理模式的意思。為什麼需要用到代理模式？是因為類太多了，業務邏輯分散在各個類中，有的在模闆子類中，有的在網絡政策中，有的在結果輸出格式政策中，而這些業務邏輯都需要多線程執行和異常捕獲。如果有個代理類，能夠收口這些處理邏輯，隻需增加前置多線程處理和後置異常處理即可。
Java語言中的函數式程式設計，具備這種能力。所謂函數式程式設計，是指能夠将方法當做參數傳遞給方法，前面“方法”是業務邏輯，後面“方法”是代理，将業務邏輯傳遞給代理，就實作了統一收口的目的。
能夠實作此功能的接口有四個，分别是：Consumer、Supplier、Predicate與Function，怎麼使用可以網上查詢。本方案使用的是Consumer，因為它是用來消費的，即需要傳入一個參數，沒有傳回值，符合本方案的設計。
簡化後的代碼如下：
@Service
public class CheckLandingCoverAreaService extends AbstractDataCheckProductService {
@Override
public < T> void runDataCheck(List< T> resultList, DataCheckRequestDTO requestDTO){
dataCheckUtils.parallelCheckByFromResCodes(requestDTO,requestDTO.getFromResCodeList(),fromResCode->{
ExpressNetworkQuery query = new ExpressNetworkQuery();
query.setNs(NssEnum.PUB.getId());
query.setStatus(StatusEnum.ENABLE.getId());
query.setGroupNameList(requestDTO.getGroupNameList());
query.setBrandCodeList(requestDTO.getBrandCodeList());
query.setFromResCode(fromResCode);
List< TmsMasterExpressNetworkDO> masterExpressNetworkDOS = tmsMasterExpressNetworkService.queryExpressNetworkTimeList(query);
startCompareWithAnc(resultList,requestDTO,masterExpressNetworkDOS,fromResCode,solutionCodeMap);
});
}
}
@Service
public class DataCheckUtils {
/**
* 并行處理每個倉
* @param requestDTO 請求參數
* @param fromResCodeList 需要檢查的倉清單
* @param checkOperation 具體的業務處理邏輯
* */
public < T> void parallelCheckByFromResCodes(DataCheckRequestDTO requestDTO, List< String> fromResCodeList, Consumer< String> checkOperation){
List< CompletableFuture> futureList = Collections.synchronizedList(new ArrayList<>());
fromResCodeList.forEach(fromResCode->{
CompletableFuture future = CompletableFuture.runAsync(() -> {
try{
checkOperation.accept(fromResCode);
}catch (Exception e){
LogPrinter.errorLog("parallelCheckByFromResCodes-error, taskId="+requestDTO.getTaskId(),e);
recordErrorInfo(requestDTO.getTaskId(),e);
}
}, DATA_CHECK_THREAD_POOL);
futureList.add(future);
});
//等待所有線程結束
futureList.forEach(future->{
try{
future.get();
}catch (Exception e){
LogPrinter.errorLog("parallelCheckByFromResCodes-future-get-error",e);
}
});
}
} 可以看出，Consumer所代表的就是一個方法，将此方法作為parallelCheckByFromResCodes方法的一個參數，在parallelCheckByFromResCodes中進行多線程和異常處理，既能統一收口，又大大減少了重複代碼。
代理模式的好處是：
- 統一收口多種不同的業務邏輯，統一做日志和異常處理。
- 減少重複代碼，提高了代碼品質。
- 可維護性較強。
5 其他
像結果輸出格式政策模式那樣，雖然AbstractCompareModeStrategy沒有實際的業務邏輯，但仍然把它作為一個基類，目的是所有子類共用的邏輯或方法，能夠放在此類中，減少代碼量，提升維護性。
但是有的時候，不是繼承自同一個基類的子類們，仍然要共用一些邏輯或方法（如parallelCheckByFromResCodes方法），但Java語言限制一個類隻能繼承一個基類，怎麼辦呢？簡單的辦法就是把這些共用邏輯或方法放到一個工具類（如DataCheckUtils）中。
三 思考&感悟
在做這個項目的過程中，剛開始沒有很好的設計，也沒有想的很全面，導緻代碼改了又改，雖然耽誤點時間，但覺得是值得的。總結以下幾點：
- 将提升代碼可讀性、可擴充性和可維護性的意識注入到平時的項目中，便于自己，利于他人。如果項目緊急沒時間考慮很多，希望之後有時間時能夠改善和優化。
- 工作不僅是為了完成任務，更是提升自己的過程。能力要用将來進行時。
阿裡雲官方鏡像站更新上線
阿裡雲官方鏡像站完成更新上線，免費提供Linux鏡像下載下傳服務，擁有Ubuntu、Deepin、MongoDB、Apache、Maven、Composer等多種開源軟體鏡像源，此外還提供域名解析DNS、網絡授時NTP等服務，緻力于為網際網路使用者提供全面，高效和穩定的基礎服務。
點選這裡，快去看看吧~