基于Oracle數(shù)據(jù)庫(kù)的讀寫(xiě)分離電子商務(wù)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

聶理多 趙衛(wèi)東 婁聰

摘要：該文參考阿里巴巴等大型電商系統(tǒng)的架構(gòu)設(shè)計(jì)，提出了基于Oracle數(shù)據(jù)庫(kù)的讀寫(xiě)分離方案，針對(duì)電商所獨(dú)有的業(yè)務(wù)場(chǎng)景，也即讀多寫(xiě)少，進(jìn)行數(shù)據(jù)訪問(wèn)層在高并發(fā)場(chǎng)景下的性能優(yōu)化;同時(shí)基于JavaEE Spring Boot對(duì)后端服務(wù)進(jìn)行基于領(lǐng)域模型的服務(wù)化劃分，配套Consul 的服務(wù)治理與發(fā)現(xiàn)，以及Kafka消息隊(duì)列對(duì)服務(wù)進(jìn)行解耦與削峰。從而使得整個(gè)系統(tǒng)具有在企業(yè)業(yè)務(wù)發(fā)展過(guò)程中進(jìn)行平緩擴(kuò)容的能力，以及高可用，高并發(fā)的體系結(jié)構(gòu)。

關(guān)鍵詞：Oracle;服務(wù)化;高并發(fā);讀寫(xiě)分離;電子商務(wù)

中圖分類號(hào)：TP311? 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2021）29-0033-04

1背景

近年來(lái)，電子商務(wù)的發(fā)展在我國(guó)愈演愈烈，在我們的日常生活中，諸如阿里巴巴，京東，亞馬遜這樣的電子商務(wù)平臺(tái)早已耳熟能詳，各種促銷活動(dòng)鋪天蓋地。但隨之而來(lái)的，是平臺(tái)背后的服務(wù)支撐體系的巨大的挑戰(zhàn)，無(wú)論是在技術(shù)，運(yùn)營(yíng)還是相關(guān)配套的物流，在線支付等方面。目前企業(yè)級(jí)市場(chǎng)成熟的Java EE Spring Boot微服務(wù)框架，提供基于領(lǐng)域模型的服務(wù)化系統(tǒng)切分與解耦，各服務(wù)間職責(zé)分明，可以由不同的開(kāi)發(fā)組進(jìn)行維護(hù)與支持，從而非常適合企業(yè)級(jí)項(xiàng)目在業(yè)務(wù)、人員增長(zhǎng)的情況下的精細(xì)化，流水線化的分工[1];同時(shí)針對(duì)電商數(shù)據(jù)庫(kù)讀多寫(xiě)少的業(yè)務(wù)場(chǎng)景，配合Oracle數(shù)據(jù)庫(kù)的讀寫(xiě)分離技術(shù)，進(jìn)行數(shù)據(jù)的冗余備份，提供數(shù)據(jù)訪問(wèn)層的高并發(fā)，高可用性支持[2];針對(duì)電商用戶端界面，我們引入BFF（Backends For Frontends）層，BFF層主要用于模板渲染，使用前端工程師友好的Nodejs 進(jìn)行編寫(xiě)，并與后端服務(wù)通過(guò)RPC進(jìn)行通信。完善并實(shí)現(xiàn)各架構(gòu)模式，技術(shù)落地，同時(shí)對(duì)體系關(guān)鍵流程節(jié)點(diǎn)與鏈路進(jìn)行局部的壓力測(cè)試。

通過(guò)合理的體系架構(gòu)，充分利用企業(yè)的各種資源，每個(gè)角色都做自己最擅長(zhǎng)的領(lǐng)域，從而實(shí)現(xiàn)最快的開(kāi)發(fā)，最高的效率;在體系的每一層，都提供高并發(fā)，高可用性支持，滿足企業(yè)級(jí)應(yīng)用對(duì)安全的需求。

2基于數(shù)據(jù)庫(kù)讀寫(xiě)分離的架構(gòu)設(shè)計(jì)

本設(shè)計(jì)在數(shù)據(jù)存儲(chǔ)方面使用Oracle數(shù)據(jù)庫(kù)并基于其 Data Guard技術(shù)進(jìn)行主從冗余備份，配置一臺(tái)讀實(shí)例和一臺(tái)寫(xiě)實(shí)例;在JavaEE的數(shù)據(jù)訪問(wèn)層使用Spring Dynamic DataSource Rout?ing進(jìn)行應(yīng)用層的讀寫(xiě)分離。

2.1 Oracle Data Guard

Oracle Data Guard 簡(jiǎn)單來(lái)說(shuō)就是利用某種同步機(jī)制（SQLApply 或者 Log Apply）將數(shù)據(jù)實(shí)時(shí)或者近實(shí)時(shí)的同步至另一臺(tái)服務(wù)器，原理是將主庫(kù)上的變化在備庫(kù)上重做一遍。因?yàn)槠渚哂蟹€(wěn)定、可靠、維護(hù)簡(jiǎn)單的特點(diǎn)，所以在生產(chǎn)環(huán)境下被廣泛使用，如數(shù)據(jù)容災(zāi)、數(shù)據(jù)庫(kù)遷移、數(shù)據(jù)庫(kù)升級(jí)、SQL 審查測(cè)試等場(chǎng)景。

Oracle Data Guard架構(gòu)場(chǎng)景如圖1所示，主庫(kù)數(shù)據(jù)同步至同機(jī)房的備庫(kù)1，備庫(kù)2和備庫(kù)3有可能是位于同城機(jī)房或異地機(jī)房，通過(guò)網(wǎng)絡(luò)進(jìn)行日志的傳輸與同步。

2.2數(shù)據(jù)訪問(wèn)層設(shè)計(jì)

針對(duì)Oracle數(shù)據(jù)庫(kù)的讀寫(xiě)分離配置，對(duì)應(yīng)我們工程的數(shù)據(jù)訪問(wèn)層也要做相應(yīng)的調(diào)整，從而支持多數(shù)據(jù)源，以及區(qū)分讀庫(kù)與寫(xiě)庫(kù)。由于我們的工程是基于 Spring加Hibernate進(jìn)行構(gòu)建的，故我們也以此進(jìn)行說(shuō)明。如圖2所示，我們有兩個(gè)Oracle數(shù)據(jù)實(shí)例，也即Spring數(shù)據(jù)訪問(wèn)層的兩個(gè)數(shù)據(jù)源，Oracle主從實(shí)例間通過(guò)上面所提到的Data Guard技術(shù)進(jìn)行冗余。應(yīng)用將寫(xiě)操作執(zhí)行到主庫(kù)，將讀操作執(zhí)行到冗余庫(kù)，完成讀寫(xiě)分離的應(yīng)用層設(shè)計(jì)。那么現(xiàn)在所要解決的就是從應(yīng)用到數(shù)據(jù)庫(kù)實(shí)例之間的訪問(wèn)與分離的問(wèn)題。

3系統(tǒng)功能

3.1用戶中心

用戶中心是電商運(yùn)營(yíng)關(guān)鍵的一環(huán)，因?yàn)槠涑休d了用戶幾乎所有的記錄，對(duì)于電商精細(xì)化運(yùn)營(yíng)非常關(guān)鍵。

用戶中心主要負(fù)責(zé)維護(hù)用戶模型，用戶收藏模型，用戶設(shè)置模型。

如圖3為用戶中心表結(jié)構(gòu)，用戶表主要維護(hù)用戶基本信息（USERS）、用戶地址表（USER_ADDRIESS）主要維護(hù)用戶添加的地址信息，用于用戶下單快遞配送、用戶收藏表（USER_COL? LECTION）維護(hù)用戶收藏的商品信息。

對(duì)外提供基于用戶模型，用戶地址模型，用戶收藏模型的RPC調(diào)用接口。

3.2商品中心

商品中心管理的是電商的核心內(nèi)容，即售賣的商品，其主要負(fù)責(zé)新品立項(xiàng)、商品上下架、類目管理等。

如圖4為商品中心表結(jié)構(gòu)，商品中心主要維護(hù)SPU與SKU 表，然后是圍繞SPU與SKU 的一系列的屬性擴(kuò)展表。其一維護(hù)規(guī)格，規(guī)格與SKU對(duì)應(yīng)，直接決定價(jià)格，如蘋(píng)果手機(jī)的內(nèi)存，也就是圖4-3的規(guī)格表（SPECIFICATION）、規(guī)格選項(xiàng)表（SPECOP? TION）以及SKU規(guī)格關(guān)聯(lián)表（SKUSPECBIND），規(guī)格表描述規(guī)格詳細(xì)信息，規(guī)格選項(xiàng)表主要是商品所對(duì)應(yīng)的具體的規(guī)格的值，如64G 內(nèi)存，128G 內(nèi)存;其二是維護(hù)屬性，可以認(rèn)為屬性是不決定價(jià)格的規(guī)格，如衣服的尺碼，由屬性表（ATTRIBUTE）、屬性選項(xiàng)表（ATTRIBUTEOPTION）和 SKU 屬性關(guān)聯(lián)表（SKUAT? TRIBIND）組成，各表的邏輯和作用和規(guī)格表組類似;然后是商品分類，由于商城為網(wǎng)上商超場(chǎng)景，并非諸如淘寶、京東的大型市場(chǎng)，故只有一級(jí)類目，但區(qū)分前后臺(tái)類目，前端類目經(jīng)常調(diào)整，后端類目相對(duì)穩(wěn)定，涉及前臺(tái)類目表（FEDCATEGORY），后臺(tái)類目表（BEDCATEGORY），前后臺(tái)類目關(guān)聯(lián)表（BEDFEDCAT? BIND），前臺(tái)類目表存放前臺(tái)類目，后臺(tái)類目表存放后臺(tái)類目，關(guān)聯(lián)表存放前后臺(tái)關(guān)聯(lián)關(guān)系。最后，品牌表維護(hù)商品品牌。

對(duì)外提供基于商品前后臺(tái)類目，SPU，SKU模型的 RPC調(diào)用接口。

3.3數(shù)據(jù)庫(kù)

本設(shè)計(jì)在數(shù)據(jù)存儲(chǔ)方面使用Oracle數(shù)據(jù)庫(kù)并基于其 Data Guard技術(shù)進(jìn)行主從冗余備份，配置一臺(tái)讀實(shí)例和一臺(tái)寫(xiě)實(shí)例;在JavaEE的數(shù)據(jù)訪問(wèn)層使用Spring Dynamic DataSource Rout?ing進(jìn)行應(yīng)用層的讀寫(xiě)分離。

Oracle Data Guard 簡(jiǎn)單來(lái)說(shuō)就是利用某種同步機(jī)制（SQL Apply 或者 Log Apply）將數(shù)據(jù)實(shí)時(shí)或者近實(shí)時(shí)的同步至另一臺(tái)服務(wù)器，原理是將主庫(kù)上的變化在備庫(kù)上重做一遍。因?yàn)槠渚哂蟹€(wěn)定、可靠、維護(hù)簡(jiǎn)單的特點(diǎn)，所以在生產(chǎn)環(huán)境下被廣泛使用，如數(shù)據(jù)容災(zāi)、數(shù)據(jù)庫(kù)遷移、數(shù)據(jù)庫(kù)升級(jí)、SQL 審查測(cè)試等場(chǎng)景。

Oracle Data Guard架構(gòu)場(chǎng)景如圖5所示，主庫(kù)數(shù)據(jù)同步至同機(jī)房的備庫(kù)1，備庫(kù)2和備庫(kù)3有可能是位于同城機(jī)房或異地機(jī)房，通過(guò)網(wǎng)絡(luò)進(jìn)行日志的傳輸與同步。

4關(guān)鍵技術(shù)

4.1 Spring 多數(shù)據(jù)源配置

基于Java 的javax.sql.DataSource，Spring 為我們提供了Ab?stractRoutingDatasource。通過(guò)AbstractRoutingDatasource，我們可以實(shí)現(xiàn)在運(yùn)行時(shí)針對(duì)不同的操作來(lái)決定所使用的數(shù)據(jù)源。繼承AbstractRoutingDatasource抽象類，并實(shí)現(xiàn)determineCur?rentLookupKey方法，返回lookupKey，在每次Spring需要數(shù)據(jù)池中的連接時(shí)，Spring都會(huì)去調(diào)用這個(gè)方法，從而決定當(dāng)前該使用哪個(gè)數(shù)據(jù)源。代碼如下所示：

public class DynamicRoutingDataSource extends Abstrac?tRoutingDataSource {

@Override

protected ectdetermineCurrentLookupKey（）{

return DynamicRoutingContextHolder.getRouteStrategy（）;}

}

同時(shí)，這里有一點(diǎn)需要強(qiáng)調(diào)的是，我們Java應(yīng)用層的每一個(gè)事務(wù)，其所對(duì)應(yīng)的都是一個(gè)獨(dú)立的線程。這也是我們后面配置的關(guān)鍵。

數(shù)據(jù)源路由策略枚舉：

public enumRoutingStrategy {

Master（true， "master"）， Slave（false， "slave"）;

private boolean write;

private String key;

RoutingStrategy（boolean write， String key）{

this.write = write;

this.key = key;

}

public booleanisWrite（）{

return write;

}

public String getKey（）{

return key;

}

}

數(shù)據(jù)源策略set，get類：

package com.lancelou.gt.yhooms.ds;

import org.springframework.util.Assert;

public class DynamicRoutingContextHolder {

private static final ThreadLocal<RoutingStrategy> context? Holder =

new ThreadLocal<>（）;

public static void setRouteStrategy（RoutingStrategy custom?erType）{

if（customerType == null）{

throw new NullPointerException（）;

}

contextHolder.set（customerType）;

}

public static RoutingStrategygetRouteStrategy（）{

return （RoutingStrategy） contextHolder.get（）;

}

public static void clearRouteStrategy（）{

contextHolder.remove（）;

}

}

至此，我們已經(jīng)配置了多數(shù)據(jù)源，且能夠設(shè)置當(dāng)前事務(wù)所屬線程的數(shù)據(jù)源，通過(guò)業(yè)務(wù)層手動(dòng)調(diào)用DynamicRoutingContext? Holder類來(lái)設(shè)置當(dāng)前所使用的數(shù)據(jù)源策略即可。但這種方式存在不足，一是數(shù)據(jù)源設(shè)置代碼不應(yīng)該存在于業(yè)務(wù)代碼中，二是我們還需要進(jìn)行異常處理。

4.2 Spring Aop加注解優(yōu)化讀寫(xiě)數(shù)據(jù)源配置

其實(shí)我們需要做的，無(wú)非是在我們的Service層業(yè)務(wù)代碼執(zhí)行的時(shí)候，設(shè)置線程當(dāng)前的數(shù)據(jù)源策略，在代碼運(yùn)行結(jié)束后，清除線程當(dāng)前的策略。這讓我們想到Spring 的另一強(qiáng)勢(shì)：Aop（面向切面編程）。 Spring 攔截器ReadOnlyConnectionInterceptor，其實(shí)具體的邏輯也就是我們開(kāi)始提到的，這里不贅述：

public class ReadOnlyConnectionInterceptor implements Or?dered {

private int order;

@Value（"20"）

public void setOrder（int order）{

this.order = order;

}

@Override

public int getOrder（）{

return order;

}

@Pointcut（value="execution（public **（..））"）? public void anyPublicMethod（）{ }?????? @Around（"@annotation（readOnlyConnection）"）

public ect proceed（ProceedingJoinPointpjp， ReadOnly? Connection readOnlyConnection） throws Throwable {

try {

DynamicRoutingContextHolder. setRouteStrategy（Rout?ingStrategy.Slave）;

ect result = pjp.proceed（）;???????????? DynamicRoutingContextHolder.clearRouteStrategy（）; return result;

} finally {

// restore state

DynamicRoutingContextHolder.clearRouteStrategy（）;

}

}

}

對(duì)應(yīng)的readOnlyConnection注解接口：??????&nbsp; @Target（{ElementType.METHOD， ElementType.TYPE}）@Retention（RetentionPolicy.RUNTIME）

public @interface ReadOnlyConnection {

}

至此，讀寫(xiě)分離的數(shù)據(jù)層訪問(wèn)設(shè)計(jì)配置完畢，在業(yè)務(wù)代碼中，我們只需通過(guò)readOnlyConnection注解來(lái)對(duì)需要訪問(wèn)從庫(kù)的Service方法進(jìn)行注解即可;對(duì)于需要訪問(wèn)主庫(kù)的Service方法，我們無(wú)需做任何處理，默認(rèn)即可。

4.3后臺(tái)技術(shù)選型

作為管理系統(tǒng)，我們選擇業(yè)界較為成熟的中后臺(tái)系統(tǒng)解決方案Ant Design。Ant Design是一個(gè)服務(wù)于企業(yè)級(jí)產(chǎn)品的設(shè)計(jì)體系，基于“確定”和“自然”的設(shè)計(jì)價(jià)值觀和模塊化的解決方案，讓設(shè)計(jì)者專注于更好的用戶體驗(yàn)。Ant Design 為一系列的中后臺(tái)設(shè)計(jì)需求提供支持，內(nèi)部包含一系列基礎(chǔ)的;業(yè)務(wù)弱相關(guān)的;開(kāi)箱即用的組件，極大地方便了中后臺(tái)系統(tǒng)的設(shè)計(jì)與開(kāi)發(fā)。

Ant Design基于React，在本設(shè)計(jì)管理系統(tǒng)的技術(shù)選型中，毫不猶豫地選擇了React，正是因?yàn)樯厦嫣岬降墓芾硐到y(tǒng)的一系列業(yè)務(wù)場(chǎng)景，也正是諸如 React這類庫(kù)所發(fā)揮作用的地方?？偨Y(jié)來(lái)說(shuō)管理系統(tǒng)有下列這些特點(diǎn)，抑或場(chǎng)景，使得我們能夠部署React這樣的庫(kù)：

管理系統(tǒng)非常適合做SPA（單頁(yè)面應(yīng)用），因?yàn)橄到y(tǒng)大多運(yùn)行于內(nèi)網(wǎng)，于有線的PC機(jī)上，對(duì)網(wǎng)絡(luò)的加載，頁(yè)面的性能相對(duì)來(lái)說(shuō)要求較低;

管理系統(tǒng)的普遍的模式是，菜單、界面、操作，每一個(gè)操作界面內(nèi)部的DOM變更頻換，那么此時(shí)基于React 的組件狀態(tài)管理以及聲明式編程就有了非常大的優(yōu)勢(shì);

5軟件測(cè)試

軟件測(cè)試是軟件開(kāi)發(fā)流程中非常重要的一個(gè)環(huán)節(jié)[3]，本設(shè)計(jì)在測(cè)試方法上使用了單元測(cè)試以及壓力測(cè)試，分別用于測(cè)試系統(tǒng)各模塊的邏輯與功能的完整性、可靠性以及整個(gè)系統(tǒng)架構(gòu)的響應(yīng)能力。

單元測(cè)試：又稱為模塊測(cè)試， 是針對(duì)程序模塊（軟件設(shè)計(jì)的最小單位）來(lái)進(jìn)行正確性檢驗(yàn)的測(cè)試工作[4]。程序單元是應(yīng)用的最小可測(cè)試部件。在過(guò)程化編程中，一個(gè)單元就是單個(gè)程序、函數(shù)、過(guò)程等;對(duì)于面向?qū)ο缶幊?，最小單元就是方法，包括基類（超類）、抽象類或者派生類（子類）中的方法[5]。我們一般會(huì)針對(duì)后端項(xiàng)目的 Service 和 Dao進(jìn)行單元測(cè)試，針對(duì)每一個(gè) Service 和Dao都會(huì)編寫(xiě)測(cè)試類，當(dāng)我們項(xiàng)目編寫(xiě)完成時(shí)，我們亦可以通過(guò)運(yùn)行項(xiàng)目的所有單元測(cè)試來(lái)檢驗(yàn)項(xiàng)目的測(cè)試覆蓋率。

壓力測(cè)試：壓力測(cè)試是檢驗(yàn)軟件性能表現(xiàn)的一項(xiàng)重要測(cè)試技術(shù)，軟件能夠承載多大的并發(fā);峰值是多少;響應(yīng)時(shí)間處在何種水平等等都能通過(guò)壓力測(cè)試進(jìn)行較為準(zhǔn)確的量化。是軟件測(cè)試環(huán)節(jié)，特別是高并發(fā)業(yè)務(wù)場(chǎng)景流程測(cè)試中不可或缺的一部分。

針對(duì)本設(shè)計(jì)的讀寫(xiě)分離方案，我們使用WebBench進(jìn)行了在開(kāi)啟和關(guān)閉讀寫(xiě)分離的場(chǎng)景下的壓力測(cè)試。如圖6所示，為兩種場(chǎng)景3000并發(fā)下的性能表現(xiàn)，我們可以看到，在3000并發(fā)量下關(guān)閉讀寫(xiě)分離的性能表現(xiàn)（每分鐘響應(yīng)請(qǐng)求數(shù)和每秒傳輸字節(jié)數(shù)）相對(duì)于開(kāi)啟的表現(xiàn)有降低，且有兩個(gè)失敗的請(qǐng)求。可能不是很明顯，我們加大并發(fā)量。

如圖7所示，為8000并發(fā)量時(shí)兩種場(chǎng)景的對(duì)比，可以看到，讀寫(xiě)分離的應(yīng)用依然對(duì)高并發(fā)的處理表現(xiàn)出了明顯的優(yōu)勢(shì)。

6結(jié)束語(yǔ)

電子商務(wù)的發(fā)展是對(duì)技術(shù)體系架構(gòu)考驗(yàn)非常大的一個(gè)場(chǎng)景，其實(shí)原因我們也很容易去考究，無(wú)不外乎并發(fā)高，體量大，業(yè)務(wù)線繁雜等等。基于JavaEE的電子商務(wù)系統(tǒng)服務(wù)化的實(shí)現(xiàn)，可以作為以及與之配套的服務(wù)治理與服務(wù)發(fā)現(xiàn)的應(yīng)用;同時(shí)基于 Oracle 數(shù)據(jù)庫(kù) Data Guard 技術(shù)的讀寫(xiě)分離方案以及基于 Spring Dynamic DataSource Routing 應(yīng)用層配套方案;基于 BFF 模式的前后端分離，后端服務(wù)化，也可作為及其配套的RPC與 NodeJS企業(yè)級(jí)應(yīng)用。并且完善并實(shí)現(xiàn)了各架構(gòu)模式，技術(shù)落地，同時(shí)對(duì)體系關(guān)鍵流程節(jié)點(diǎn)與鏈路進(jìn)行局部的壓力測(cè)試，我們的系統(tǒng)有極其穩(wěn)定的性能表現(xiàn)，發(fā)展?jié)摿薮?。可以肯定，基于高并發(fā)，高可用，讀寫(xiě)分離的分布式架構(gòu)是未來(lái)軟件系統(tǒng)發(fā)展的方向，未來(lái)發(fā)展前景極好。

參考文獻(xiàn)：

[1] 李軍 . 高并發(fā) Web 系統(tǒng)的設(shè)計(jì)與優(yōu)化[D]. 北京：北京交通大學(xué)，2009.

[2] 劉浩.基于負(fù)載均衡的存儲(chǔ)架構(gòu)研究與應(yīng)用[D].濟(jì)南：山東大，2011.

[3] 羅健萍.高校行政辦公自動(dòng)化系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].成都：電子科技大學(xué)，2012.

[4] 閆煜瑤.用友金融商業(yè)平臺(tái)設(shè)計(jì)與實(shí)現(xiàn)[D].北京：北京交通大學(xué)，2019.

[5] 趙曉東.基于Google云的B2C網(wǎng)站后臺(tái)管理模塊實(shí)現(xiàn)[D].成都：電子科技大學(xué)，2011.

【通聯(lián)編輯：謝媛媛】