公司新來一個架構(gòu)師, 將消費(fèi)金融系統(tǒng)重構(gòu)了
1、背景
1.2 業(yè)務(wù)重組與合并
隨著需求不斷迭代,轉(zhuǎn)轉(zhuǎn)消費(fèi)分期整體出現(xiàn)了一些調(diào)整,并提出了新的產(chǎn)品方向,在此背景下,對于經(jīng)歷了久經(jīng)滄桑的歷史服務(wù),已經(jīng)逐漸不適合未來的產(chǎn)品規(guī)劃。面對新的業(yè)務(wù)整合和重組,急需新的架構(gòu)和思想來承載未來的業(yè)務(wù)。
1.2 解決技術(shù)債務(wù)
現(xiàn)階段存在的主要問題:
- 代碼模塊之間邊界感不強(qiáng),需要通過模塊拆分、服務(wù)拆分來區(qū)分業(yè)務(wù)邊界。
- 代碼實現(xiàn)缺少層次感,設(shè)計模式單一,一層到底的冗長代碼。
此前,微服務(wù)拆分原則是按消費(fèi)分期、合作方分期產(chǎn)品等維度進(jìn)行整體拆分的,優(yōu)點(diǎn)是明確了項目職責(zé),簡單的從需求維度進(jìn)行服務(wù)拆分,確實是一種行之有效的方式,缺點(diǎn)是沒有對基礎(chǔ)功能進(jìn)行剝離,以至于很多場景需要維護(hù)重復(fù)的代碼,增加了項目的維護(hù)成本。
1.3 影響開發(fā)效率
即使我們接手項目已經(jīng)有一段時間,并對項目足夠了解時,但排查問題起來依然費(fèi)力費(fèi)時,而且系統(tǒng)內(nèi)部代碼錯綜復(fù)雜,調(diào)用鏈路交錯,難以正常維護(hù),從長遠(yuǎn)的開發(fā)效率考慮,盡快提出新型方案來代替現(xiàn)有結(jié)構(gòu)。
1.4 監(jiān)控體系不夠完善
線上異常機(jī)制不夠敏感,缺少關(guān)鍵業(yè)務(wù)指標(biāo)的告警看板,作為一個業(yè)務(wù)開發(fā),應(yīng)保持對核心指標(biāo)數(shù)據(jù)的敏感性。
2、重構(gòu)目標(biāo)
- 不影響業(yè)務(wù)的正常運(yùn)轉(zhuǎn)和迭代;
- 改善現(xiàn)有代碼結(jié)構(gòu)設(shè)計,讓代碼易于擴(kuò)展,提升開發(fā)效率;
- 采用新工程逐步替代原有接口,舊工程逐漸廢棄。
3、設(shè)計
3.1 調(diào)研
開始重構(gòu)之前,調(diào)研了互聯(lián)網(wǎng)消金通用的架構(gòu)解決方案:
通用方案
由于是外部調(diào)研的通用架構(gòu)設(shè)計,所以并非完全契合轉(zhuǎn)轉(zhuǎn)消費(fèi)分期產(chǎn)品,但可以借鑒其分層架構(gòu)設(shè)計的思想,在代碼設(shè)計階段,可以先對核心模塊進(jìn)行拆解和規(guī)劃。
3.2 規(guī)劃
前端頁面與后端重構(gòu)計劃分兩次迭代進(jìn)行,分階段進(jìn)行,可以有效分?jǐn)偛⒔档晚椖可暇€風(fēng)險,第一次迭代圍繞后端主要模塊進(jìn)行剝離重新設(shè)計并上線;第二次重構(gòu)目的是解決產(chǎn)品需求,對接前端新頁面。
3.3 修繕者模式
作為一個一線的業(yè)務(wù)開發(fā),需要開展重構(gòu)工作的同時還得保證產(chǎn)品需求的正常迭代,修繕者模式無疑是最佳選擇。 第一次迭代歷程,對于歷史工程邊緣邏輯保留并隔離,只對核心代碼進(jìn)行重構(gòu)后轉(zhuǎn)移到到新工程,新工程逐步接手老舊邏輯,并對老工程提供RPC接口,逐漸取代。此方案整體風(fēng)險最低,同時能兼顧到正常的需求迭代。
第二次迭代歷程,經(jīng)歷了第一次迭代后,新系統(tǒng)運(yùn)行穩(wěn)定,同時也具備接手新產(chǎn)品的能力,新工程開始與前端對接、聯(lián)調(diào),在此之后,V2版本也正式上線。
3.4 領(lǐng)域設(shè)計(橫向拆分)
模塊拆分
- 聚合業(yè)務(wù):涵蓋了消費(fèi)分期主要業(yè)務(wù),根據(jù)其各自產(chǎn)品需求特點(diǎn),作為上層業(yè)務(wù)代碼,對前端、收銀臺提供聚合接口。
- 基礎(chǔ)服務(wù):用戶信貸所產(chǎn)生的數(shù)據(jù)、或依托合作方數(shù)據(jù),圍繞金融分期服務(wù)提供的數(shù)據(jù)支持。
- 三方對接:基于轉(zhuǎn)轉(zhuǎn)標(biāo)準(zhǔn)API下的邏輯實現(xiàn),同時具備靈活接入合作方接口的能力。
3.5 模塊設(shè)計(縱向拆分)
基于以往項目存在的問題,再結(jié)合消費(fèi)分期的特點(diǎn),我們對分期購買到賬單還款結(jié)清的整個流程進(jìn)行拆解:用戶主動填寫申請信息,提交授信申請并獲額,挑選商品分期下單,生成還款計劃,提供綁卡、賬單還款等功能。以上就是一個簡單的分期購物流程,基于以上流程,我們把消費(fèi)分期所包含的公共模塊,如授信前獲額、用信、賬單還款,這些富有金融服務(wù)屬性的功能進(jìn)行剝離。消費(fèi)分期作為轉(zhuǎn)轉(zhuǎn)的產(chǎn)品原型,在聚合層中各自維護(hù),互不影響。
設(shè)計原則:在不改變原有代碼邏輯的情況下,根據(jù)單一職責(zé)和依賴倒置原則的思想:對系統(tǒng)進(jìn)行模塊拆分與合并,以明確項目職責(zé)降低耦合度;對包進(jìn)行重新規(guī)劃,劃分包與包之間的邊界,進(jìn)一步減少代碼間的耦合。
3.6 代碼設(shè)計
好的代碼重構(gòu)一定離不開設(shè)計模式,基于原有單一的策略模式,我們把合作方對接模塊與基礎(chǔ)服務(wù)模塊進(jìn)行了拆解,采用雙層模板、策略、工廠模式的組合,分別對授信、用信、貸后幾個模塊單獨(dú)設(shè)計接口,維護(hù)好對合作方通用標(biāo)準(zhǔn)API接口,同時具備靈活接入的特點(diǎn),舉個例子,以下為授信模塊主要代碼類圖:
第一層作為基礎(chǔ)服務(wù)的策略模式;
第二層作為合作方對接的策略模式。
主要類圖設(shè)計:
在定義接口與實現(xiàn)類后,形成了對合作方對接層依賴,同時對訂單、用信、授信等核心數(shù)據(jù)進(jìn)行落地,對消費(fèi)分期提供數(shù)據(jù)支撐,舉個例子,以下為授信模塊主要代碼:
- 基礎(chǔ)服務(wù)接口定義
/**
* 授信接口定義
**/
public interface ICreditService {
/**
* appId,資方定義的一個唯一ID
*/
String getAppId();
/**
* app名稱
*
* @return zz or zlj
*/
String getAppName();
/**
* 獲取授信結(jié)果
*
* @return result
*/
CreditResult creditResult(String logStr, Long uid);
}
- 標(biāo)準(zhǔn)流程抽象
/**
* 標(biāo)準(zhǔn)API對接實現(xiàn)
*
**/
public abstract class AbstractCreditService implements ICreditService {
/**
* 標(biāo)準(zhǔn)API對接
*
* @return IBaseApiService
*/
protected abstract IBaseApiService getApiThirdService();
@Override
public AppConfig getPartner() {
return commonConfigUtil.getAppConfig(getAppId());
}
@Override
public CreditResult creditResult(String logStr, Long uid) {
CreditResultInput input = new CreditResultInput();
input.setUid(uid);
ResponseProtocol<CreditResultOutput> output = getApiThirdService().creditResult(logStr, input);
String creditStatus = TransformUtil.approvalStatusTransform(output.getData());
return CreditResult.builder().result(creditStatus).build();
}
}
/**
* 合作方差異化接入
*/
@Service
@Slf4j
public class ZZABCCreditServiceImpl extends AbstractABCCreditService {
@Resource
ZZABCThirdServiceImpl abcThirdService;
@Override
public String getAppId() {
return PartnerEnum.ABC_ZZ_API.getAppId();
}
@Override
public String getAppName() {
return AppNameEnum.ZZ.getValue();
}
@Override
protected IABCThirdService getABCThirdService() {
return abcThirdService;
}
}
- 標(biāo)準(zhǔn)API對接
/**
* 標(biāo)準(zhǔn)API對接
*
* @author Rouse
* @date 2022/4/24 13:57
*/
public interface IBaseApiService {
/**
* 標(biāo)準(zhǔn)API,獲取appId
*
* @return appId
*/
String getAppId();
/**
* 獲取授信結(jié)果
*/
ResponseProtocol<CreditResultOutput> creditResult(CreditResultInput input);
}
- 內(nèi)部標(biāo)準(zhǔn)API實現(xiàn)
/**
* 合作方,標(biāo)準(zhǔn)API對接實現(xiàn)
*
* @author Rouse
* @date 2022/4/24 14:04
*/
@Slf4j
public abstract class AbstractBaseApiService implements IBaseApiService {
@Override
public ResponseProtocol<CreditResultOutput> creditResult(CreditResultInput input) {
// 通用加解密
return getDataResponse(logStr, getAppConf().getUrl4CreditResult(), input, CreditResultOutput.class);
}
}
- 差異化合作方接入
/**
* ABC合作方接口封裝
**/
public interface IABCThirdService extends IBaseApiService {
/**
* 標(biāo)準(zhǔn)API,獲取appId
*
* @return appId
*/
String getAppId();
/**
* 獲取授信結(jié)果
*/
ResponseProtocol<ABCCreditResultOutput> creditResult(ABCCreditResultInput input);
}
/**
* 合作方抽象方法封裝
**/
@Slf4j
public abstract class AbstractABCThirdService extends AbstractBaseApiService implements IABCThirdService {
@Override
public ResponseProtocol<ABCCreditResultOutput> creditResult(ABCCreditResultInput input) {
// 加解密差異化實現(xiàn)
return getDataResponse(logStr, getAppConf().getUrl4CreditResult(), input, ABCCreditResultOutput.class);
}
}
/**
* ABC合作方對接
*
*/
@Service
@Slf4j
public class ZZABCThirdServiceImpl extends AbstractABCThirdService{
@Override
public String getAppId() {
return PartnerEnum.ABC_API_ZZ.getAppId();
}
@Override
public String getAppName() {
return AppNameEnum.ZZ.getValue();
}
}
4、上線過程
對于老系統(tǒng)的重構(gòu),新系統(tǒng)上線過度期也至關(guān)重要,因為采用了新的表結(jié)構(gòu)進(jìn)行重新設(shè)計,涉及到數(shù)據(jù)的同步,我們采用單向數(shù)據(jù)同步,逐漸棄用老系統(tǒng)數(shù)據(jù),如果灰度期間需要回滾,首先對數(shù)據(jù)進(jìn)行回滾,優(yōu)先保證線上服務(wù)穩(wěn)定。
以下是經(jīng)歷兩次重構(gòu)迭代的過程:
5、監(jiān)控
- 項目重構(gòu)監(jiān)控先行,這次我們采用了轉(zhuǎn)轉(zhuǎn)告警機(jī)制和Prometheus線上監(jiān)控,另外搭建了一套線上看板,及時發(fā)現(xiàn)各個模塊的潛在隱患。
- 日志,一個完美的系統(tǒng)離不開合理的日志,日志往往是定位問題最便捷的工具。
6、總結(jié)
通過此次技術(shù)重構(gòu),我們不僅解決了過去存在的技術(shù)債務(wù)問題,還提升了服務(wù)的穩(wěn)定性和用戶體驗,也提升產(chǎn)品交付效率。
技術(shù)重構(gòu)并非一蹴而就,但只要我們有堅定的信念和不懈的努力,終將取得成功。引用一句名言:”不要因為懶惰而拒絕重構(gòu),不要因為無暇重構(gòu)而成為你拖延的理由 。” 是的,重構(gòu)是持續(xù)優(yōu)化代碼質(zhì)量和可維護(hù)性的過程,需要我們時刻關(guān)注并付諸行動。
我認(rèn)為,重構(gòu)的另一種價值:一個重構(gòu)好的系統(tǒng)、往往具備通用性,可移植性。簡單說就是我們重構(gòu)后的系統(tǒng)以最小的改動且能在同行中快速復(fù)用,因為你創(chuàng)造了一個穩(wěn)定可靠的“輪子”,如果做到這點(diǎn),無非你是這個行業(yè)技術(shù)解決方案的專家。
關(guān)于作者
羅思,金融技術(shù)部后端研發(fā)工程師。轉(zhuǎn)轉(zhuǎn)消費(fèi)分期業(yè)務(wù)開發(fā)。