一、背景

vivo官方商城經(jīng)過(guò)了七年的迭代，從單體架構(gòu)逐步演進(jìn)到微服務(wù)架構(gòu)，我們的開(kāi)發(fā)團(tuán)隊(duì)沉淀了許多寶貴的技術(shù)與經(jīng)驗(yàn)，對(duì)電商領(lǐng)域業(yè)務(wù)也有相當(dāng)深刻的理解。

去年初，團(tuán)隊(duì)承接了O2O商城的建設(shè)任務(wù)，還有即將成立的禮品中臺(tái)，以及官方商城的線上購(gòu)買(mǎi)線下門(mén)店送貨需求，都需要搭建底層的商品、交易和庫(kù)存能力。

為節(jié)約研發(fā)與運(yùn)維成本，避免重復(fù)造輪子，我們決定采用平臺(tái)化的思想來(lái)搭建底層系統(tǒng)，以通用能力靈活支撐上層業(yè)務(wù)的個(gè)性化需求。

包括交易平臺(tái)、商品平臺(tái)、庫(kù)存平臺(tái)、營(yíng)銷(xiāo)平臺(tái)在內(nèi)的一整套電商平臺(tái)化系統(tǒng)應(yīng)運(yùn)而生

本文將介紹交易平臺(tái)的架構(gòu)設(shè)計(jì)理念與實(shí)踐，以及上線后持續(xù)迭代過(guò)程中的挑戰(zhàn)與思考。

二、整體架構(gòu)

2.1 架構(gòu)目標(biāo)

除了高并發(fā)、高性能、高可用這三高外，還希望做到：

1. 低成本
   注重模型與服務(wù)的可重用性，靈活支撐各業(yè)務(wù)的個(gè)性化需求，提高開(kāi)發(fā)效率，降低人力成本。
2. 高擴(kuò)展
   系統(tǒng)架構(gòu)簡(jiǎn)單清晰，應(yīng)用系統(tǒng)間耦合低，容易水平擴(kuò)展，業(yè)務(wù)功能增改方便快捷。

2.2 系統(tǒng)架構(gòu)

（1）電商平臺(tái)整體架構(gòu)中的交易平臺(tái)

（2）交易平臺(tái)系統(tǒng)架構(gòu)

2.3 數(shù)據(jù)模型

三、關(guān)鍵方案設(shè)計(jì)

3.1 多租戶(hù)設(shè)計(jì)

（1）背景和目標(biāo)

• 交易平臺(tái)面向多個(gè)租戶(hù)（業(yè)務(wù)方），需要能夠存儲(chǔ)大量訂單數(shù)據(jù)，并提供高可用高性能的服務(wù)。
• 不同租戶(hù)的數(shù)據(jù)量和并發(fā)量可能有很大區(qū)別，要能根據(jù)實(shí)際情況靈活分配存儲(chǔ)資源。

（2）設(shè)計(jì)方案

• 考慮到交易系統(tǒng)OLTP特性和開(kāi)發(fā)人員熟練程度，采用MySQL作為底層存儲(chǔ)、ShardingSphere作為分庫(kù)分表中間件，將用戶(hù)標(biāo)識(shí)(userId)作為分片鍵，保證同一個(gè)用戶(hù)的訂單落在同一個(gè)庫(kù)中。
• 接入新租戶(hù)時(shí)約定一個(gè)租戶(hù)編碼(tenantCode)，所有接口都要帶上這個(gè)參數(shù)；租戶(hù)對(duì)數(shù)據(jù)量和并發(fā)量進(jìn)行評(píng)估，分配至少滿(mǎn)足未來(lái)五年需求的庫(kù)表數(shù)量。
• 租戶(hù)與庫(kù)表的映射關(guān)系：租戶(hù)編碼 -> {庫(kù)數(shù)量,表數(shù)量,起始庫(kù)編號(hào),起始表編號(hào)}。

通過(guò)上面的映射關(guān)系，可以為每個(gè)租戶(hù)靈活分配存儲(chǔ)資源，數(shù)據(jù)量很小的租戶(hù)還能復(fù)用已有的庫(kù)表。

示例一：

新租戶(hù)接入前已有4庫(kù)*16表，新租戶(hù)的訂單量少且并發(fā)低，直接復(fù)用已有的0號(hào)庫(kù)0號(hào)表，映射關(guān)系是：租戶(hù)編碼-> 1,1,0,0

示例二：

新租戶(hù)接入前已有4庫(kù)*16表，新租戶(hù)的訂單量多但并發(fā)低，用原有的0號(hào)庫(kù)中新建8張表來(lái)存儲(chǔ)，映射關(guān)系是：租戶(hù)編碼-> 1,8,0,16

示例三：

新租戶(hù)接入前已有4庫(kù)*16表，新租戶(hù)的訂單量多且并發(fā)高，用新的4庫(kù)*8表來(lái)存儲(chǔ)，映射關(guān)系是：租戶(hù)編碼-> 4,8,4,0

用戶(hù)訂單所屬庫(kù)表計(jì)算公式

庫(kù)序號(hào) = Hash(userId) / 表數(shù)量 % 庫(kù)數(shù)量 + 起始庫(kù)編號(hào)
表序號(hào) = Hash(userId) % 表數(shù)量 + 起始表編號(hào)

可能有小伙伴會(huì)問(wèn)：為什么計(jì)算庫(kù)序號(hào)時(shí)要先除以表數(shù)量？下面的公式會(huì)有什么問(wèn)題？

庫(kù)序號(hào) = Hash(userId) % 庫(kù)數(shù)量 + 起始庫(kù)編號(hào)
表序號(hào) = Hash(userId) % 表數(shù)量 + 起始表編號(hào)

答案是，當(dāng)庫(kù)數(shù)量和表數(shù)量存在公因數(shù)時(shí)，會(huì)存在傾斜問(wèn)題，先除以表數(shù)量就能剔除公因數(shù)。

以2庫(kù)4表為例，對(duì)4取模等于1的數(shù)，對(duì)2取模也一定等于1，因此0號(hào)庫(kù)的1號(hào)表中不會(huì)有任何數(shù)據(jù)，同理，0號(hào)庫(kù)的3號(hào)表、1號(hào)庫(kù)的0號(hào)表、1號(hào)庫(kù)的2號(hào)表中都不會(huì)有數(shù)據(jù)。

路由過(guò)程如下圖所示：

（3）局限性和應(yīng)對(duì)辦法

• 全局唯一ID

問(wèn)題：分庫(kù)分表后，數(shù)據(jù)庫(kù)自增主鍵不再全局唯一，不能作為訂單號(hào)來(lái)使用。且很多內(nèi)部系統(tǒng)間的交互接口只有訂單號(hào)，沒(méi)有用戶(hù)標(biāo)識(shí)這個(gè)分片鍵。

方案：如下圖所示，參考雪花算法來(lái)生成全局唯一訂單號(hào)，同時(shí)將庫(kù)表編號(hào)隱含在其中（兩個(gè)5bit分別存儲(chǔ)庫(kù)表編號(hào)），這樣就能在沒(méi)有用戶(hù)標(biāo)識(shí)的場(chǎng)景下，從訂單號(hào)中獲取庫(kù)表編號(hào)。

• 全庫(kù)全表搜索

問(wèn)題：管理后臺(tái)需要根據(jù)各種篩選條件，分頁(yè)查詢(xún)所有滿(mǎn)足條件的訂單。

方案：將訂單數(shù)據(jù)冗余存儲(chǔ)一份到搜索引擎Elasticsearch中，滿(mǎn)足各種場(chǎng)景下的快速靈活查詢(xún)需求。

3.2 狀態(tài)機(jī)設(shè)計(jì)

（1）背景

• 之前做官方商城時(shí)，由于是定制化業(yè)務(wù)開(kāi)發(fā)，各類(lèi)型的訂單和售后單的狀態(tài)流轉(zhuǎn)都是寫(xiě)死的，比如常規(guī)訂單在下單后是待付款，付款后是待發(fā)貨，發(fā)貨后是待收貨；虛擬商品訂單不需要發(fā)貨，沒(méi)有待發(fā)貨狀態(tài)。
• 現(xiàn)在要做的是平臺(tái)系統(tǒng)，不可能再為每個(gè)業(yè)務(wù)方做定制化開(kāi)發(fā)，否則會(huì)導(dǎo)致頻繁改動(dòng)發(fā)版，代碼錯(cuò)綜冗余。

（2）目標(biāo)

• 引入訂單狀態(tài)機(jī)，能為每個(gè)業(yè)務(wù)方配置多套差異化的訂單流程，類(lèi)似于流程編排。
• 新增訂單流程時(shí)，盡可能不改動(dòng)代碼，實(shí)現(xiàn)狀態(tài)和操作的可復(fù)用性。

（3）方案

• 在管理后臺(tái)為每個(gè)租戶(hù)維護(hù)一系列訂單類(lèi)型，數(shù)據(jù)轉(zhuǎn)化為JSON格式存儲(chǔ)在配置中心，或存儲(chǔ)在數(shù)據(jù)庫(kù)并同步到本地緩存中。
• 每個(gè)訂單類(lèi)型的配置包括：初始訂單狀態(tài)，以及每個(gè)狀態(tài)下允許的操作和操作之后的目標(biāo)狀態(tài)。
• 當(dāng)訂單在執(zhí)行某個(gè)動(dòng)作時(shí)，使用訂單狀態(tài)機(jī)來(lái)修改訂單狀態(tài)。
  訂單狀態(tài)機(jī)的公式是：
  StateMachine（E,S —> A , S’）
  表示訂單在事件E的觸發(fā)下執(zhí)行動(dòng)作A，并從原狀態(tài)S轉(zhuǎn)化為目標(biāo)狀態(tài)S’
• 每個(gè)訂單類(lèi)型配置完成后，生成數(shù)據(jù)的結(jié)構(gòu)是

/**
 * 訂單流程配置
 **/
@Data
public class OrderFlowConfig implements Serializable {
    /**
     * 初始訂單狀態(tài)編碼
     **/
    private String initStatus;
    /**
     * 每個(gè)訂單狀態(tài)下，可執(zhí)行的操作及執(zhí)行操作后的目標(biāo)狀態(tài)
     * Map<原狀態(tài)編碼, Map<訂單操作類(lèi)型編碼, 目標(biāo)狀態(tài)編碼>>
     */
    private Map<String, Map<String, String>> operations;
}

• 訂單商品行狀態(tài)機(jī)、售后單狀態(tài)機(jī)，也用同樣的方式實(shí)現(xiàn)

3.3 通用操作觸發(fā)器

（1）背景

業(yè)務(wù)中通常都會(huì)有這樣的延時(shí)需求，我們之前往往通過(guò)定時(shí)任務(wù)來(lái)掃描處理。

• 下單后多久未支付，自動(dòng)關(guān)閉訂單
• 申請(qǐng)退款后商家多久未審核，自動(dòng)同意申請(qǐng)
• 訂單簽收后多久未確認(rèn)收貨，自動(dòng)確認(rèn)收貨

（2）目標(biāo)

• 業(yè)務(wù)方有類(lèi)似的延時(shí)需求時(shí)，能夠有通用的方式輕松實(shí)現(xiàn)

（3）方案

設(shè)計(jì)通用操作觸發(fā)器，具體步驟為：

1. 配置觸發(fā)器，粒度是狀態(tài)機(jī)的流程類(lèi)型。
2. 創(chuàng)建訂單/售后單時(shí)或訂單狀態(tài)變化時(shí)，如果有滿(mǎn)足條件的觸發(fā)器，發(fā)送延遲消息。
3. 收到延遲消息后，再次判斷執(zhí)行條件，執(zhí)行配置的操作。

觸發(fā)器的配置包括：

1. 注冊(cè)時(shí)間：可選訂單創(chuàng)建時(shí)，或訂單狀態(tài)變化時(shí)
2. 執(zhí)行時(shí)間：可使用JsonPath表達(dá)式選取訂單模型中的時(shí)間，并可疊加延遲時(shí)間
3. 注冊(cè)條件：使用QLExpress配置，滿(mǎn)足條件才注冊(cè)
4. 執(zhí)行條件：使用QLExpress配置，滿(mǎn)足條件才執(zhí)行操作
5. 執(zhí)行的操作和參數(shù)

3.4 分布式事務(wù)

對(duì)交易平臺(tái)而言，分布式事務(wù)是一個(gè)經(jīng)典問(wèn)題，比如：

• 創(chuàng)建訂單時(shí)，需要同時(shí)扣減庫(kù)存、占用優(yōu)惠券，取消訂單時(shí)則需要進(jìn)行回退。
• 用戶(hù)支付成功后，需要通知發(fā)貨系統(tǒng)給用戶(hù)發(fā)貨。
• 用戶(hù)確認(rèn)收貨后，需要通知積分系統(tǒng)給用戶(hù)發(fā)放購(gòu)物獎(jiǎng)勵(lì)的積分。

我們是如何保證微服務(wù)架構(gòu)下數(shù)據(jù)一致性的呢？首先要區(qū)分業(yè)務(wù)場(chǎng)景對(duì)一致性的要求。

（1）強(qiáng)一致性場(chǎng)景

比如訂單創(chuàng)建和取消時(shí)對(duì)庫(kù)存和優(yōu)惠券系統(tǒng)的調(diào)用，如果不能保證強(qiáng)一致，可能導(dǎo)致庫(kù)存超賣(mài)或優(yōu)惠券重復(fù)使用。

對(duì)于強(qiáng)一致性場(chǎng)景，我們采用Seata的AT模式來(lái)處理，下面的示意圖取自seata官方文檔。

（2）最終一致性場(chǎng)景

比如支付成功后通知發(fā)貨系統(tǒng)發(fā)貨，確認(rèn)收貨后通知積分系統(tǒng)發(fā)放積分，只要保證能夠通知成功即可，不需要同時(shí)成功同時(shí)失敗。

對(duì)于最終一致性場(chǎng)景，我們采用的是本地消息表方案：在本地事務(wù)中將要執(zhí)行的異步操作記錄在消息表中，如果執(zhí)行失敗，可以通過(guò)定時(shí)任務(wù)來(lái)補(bǔ)償。

3.5 高可用與安全設(shè)計(jì)

• 熔斷

使用Hystrix組件，對(duì)依賴(lài)的外部系統(tǒng)添加熔斷保護(hù)，防止某個(gè)系統(tǒng)故障的影響擴(kuò)大到整個(gè)分布式系統(tǒng)中。

• 限流

通過(guò)性能測(cè)試找出并解決性能瓶頸，掌握系統(tǒng)的吞吐量數(shù)據(jù)，為限流和熔斷的配置提供參考。

• 并發(fā)鎖

任何訂單更新操作之前，會(huì)通過(guò)數(shù)據(jù)庫(kù)行級(jí)鎖加以限制，防止出現(xiàn)并發(fā)更新。

• 冪等性

所有接口均具備冪等性，上游調(diào)用我們接口如果出現(xiàn)超時(shí)之類(lèi)的異常，可以放心重試。

• 網(wǎng)絡(luò)隔離

只有極少數(shù)第三方接口可通過(guò)外網(wǎng)訪問(wèn)，且都有白名單、數(shù)據(jù)加密、簽名驗(yàn)證等保護(hù)，內(nèi)部系統(tǒng)交互使用內(nèi)網(wǎng)域名和RPC接口。

• 監(jiān)控和告警

通過(guò)配置日志平臺(tái)的錯(cuò)誤日志報(bào)警、調(diào)用鏈的服務(wù)分析告警，再加上公司各中間件和基礎(chǔ)組件的監(jiān)控告警功能，讓我們能夠能夠第一時(shí)間發(fā)現(xiàn)系統(tǒng)異常。

3.6 其他考慮

• 是否用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)

考慮到團(tuán)隊(duì)非敏捷型組織架構(gòu)，又缺少領(lǐng)域?qū)＜遥虼藳](méi)有采用

• 高峰期性能瓶頸問(wèn)題

大促和推廣期間，特別是爆款搶購(gòu)時(shí)的流量可能會(huì)觸發(fā)限流，導(dǎo)致部分用戶(hù)被拒之門(mén)外。因?yàn)闊o(wú)法準(zhǔn)確預(yù)估流量，難以提前擴(kuò)容。

可以通過(guò)主動(dòng)降級(jí)方案增加并發(fā)量，比如同步入庫(kù)切為異步入庫(kù)、db查詢(xún)轉(zhuǎn)為cache查詢(xún)、只能查到最近半年的訂單等。

考慮到業(yè)務(wù)復(fù)雜度和數(shù)據(jù)量級(jí)還處在初期，團(tuán)隊(duì)規(guī)模也難以支撐，這些設(shè)計(jì)有遠(yuǎn)期計(jì)劃，但暫時(shí)還沒(méi)做。（架構(gòu)的合適性原則，殺雞用牛刀，你愿意也行）。

四、總結(jié)與展望

我們?cè)谠O(shè)計(jì)系統(tǒng)時(shí)并沒(méi)有一味追求前沿技術(shù)和思想，面對(duì)問(wèn)題時(shí)也不是直接采用業(yè)界主流的解決方案，而是根據(jù)團(tuán)隊(duì)和系統(tǒng)的實(shí)際狀況來(lái)選取最合適的辦法。好的系統(tǒng)不是在一開(kāi)始就被大牛設(shè)計(jì)出來(lái)的，而是隨著業(yè)務(wù)的發(fā)展和演進(jìn)逐漸被迭代出來(lái)的。

目前交易平臺(tái)已上線一年多，接入了三個(gè)業(yè)務(wù)方，系統(tǒng)運(yùn)行平穩(wěn)，公司內(nèi)有交易/商品/庫(kù)存等需求的新業(yè)務(wù)，以及存量業(yè)務(wù)在遇到系統(tǒng)瓶頸需要升級(jí)時(shí)，都可以復(fù)用這塊能力。

上游業(yè)務(wù)方數(shù)量的增加和版本的迭代，對(duì)平臺(tái)系統(tǒng)的需求源源不斷，平臺(tái)的功能得到逐漸完善，架構(gòu)也在不斷演進(jìn)，我們正在將履約模塊從交易平臺(tái)中剝離出來(lái)，進(jìn)一步解耦，為業(yè)務(wù)持續(xù)發(fā)展做好儲(chǔ)備。