1. 引言

近年來(lái)，達(dá)人分銷模式推動(dòng)電商銷售額呈現(xiàn)爆發(fā)式增長(zhǎng)，其核心在于連接品牌商家與具有影響力的達(dá)人，通過(guò)內(nèi)容與商品撮合進(jìn)行精準(zhǔn)推廣觸達(dá)消費(fèi)者，實(shí)現(xiàn)流量變現(xiàn)和GMV快速增長(zhǎng)。B站達(dá)人帶貨業(yè)務(wù)發(fā)展快速，從系統(tǒng)平臺(tái)層面來(lái)看，面臨諸多挑戰(zhàn)：

• 歷史系統(tǒng)腐化影響：復(fù)雜業(yè)務(wù)場(chǎng)景支撐如（直播/視頻/圖文跨場(chǎng)景不同資源位的帶貨分銷玩法）及智能托管模式探索受到一定程度限制
• 協(xié)同成本相對(duì)較高：歷史模型分散且不穩(wěn)定，業(yè)務(wù)變更會(huì)頻繁引發(fā)上下游協(xié)同，迭代效率往往不達(dá)預(yù)期
• 平臺(tái)擴(kuò)展出現(xiàn)瓶頸：現(xiàn)有系統(tǒng)存儲(chǔ)耦合等技術(shù)債難以支撐億級(jí)數(shù)據(jù)量讀寫(xiě)，無(wú)法匹配當(dāng)前業(yè)務(wù)規(guī)模化發(fā)展

因此，在帶貨業(yè)務(wù)持續(xù)保持高速增長(zhǎng)的階段，構(gòu)建高效穩(wěn)定且具有較高擴(kuò)展性的達(dá)人分銷系統(tǒng)尤為重要。本文將詳細(xì)介紹UP主帶貨分銷平臺(tái)現(xiàn)狀，基于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）思想，如何對(duì)現(xiàn)有系統(tǒng)進(jìn)行平臺(tái)化重構(gòu)，實(shí)現(xiàn)分銷系統(tǒng)整體架構(gòu)的升級(jí)。

2. 現(xiàn)狀&目標(biāo)

2.1 現(xiàn)有系統(tǒng)痛點(diǎn)

B站帶貨分銷業(yè)務(wù)涉及直播、視頻、圖文等場(chǎng)域，當(dāng)前已覆蓋大部分資源位場(chǎng)景。業(yè)務(wù)快速發(fā)展的同時(shí)也歷經(jīng)團(tuán)隊(duì)組織的調(diào)整，形成了如下圖所示的系統(tǒng)調(diào)用鏈現(xiàn)狀。以用戶最基礎(chǔ)的操作場(chǎng)景為例，UP主在分銷平臺(tái)選擇不同內(nèi)容不同資源位進(jìn)行帶貨，由原來(lái)單一視頻場(chǎng)景擴(kuò)展到圖文、直播帶貨場(chǎng)景后，需要關(guān)聯(lián)多個(gè)應(yīng)用多種數(shù)據(jù)模型，超過(guò)數(shù)十張數(shù)據(jù)表的讀寫(xiě)，很小業(yè)務(wù)迭代和變更都會(huì)涉及不同應(yīng)用間的聯(lián)動(dòng)開(kāi)發(fā)，同時(shí)會(huì)引發(fā)下游不同團(tuán)隊(duì)（如引擎、數(shù)據(jù)等）協(xié)同變更支持，額外增加用戶端帶貨服務(wù)體驗(yàn)治理難度。

圖片

實(shí)際上的情況遠(yuǎn)比上圖所示鏈路復(fù)雜，從整體看，核心問(wèn)題主要有以下幾個(gè)方面。

• 架構(gòu)層面擴(kuò)展性低，煙囪式系統(tǒng)導(dǎo)致3套獨(dú)立數(shù)據(jù)模型、2種開(kāi)發(fā)語(yǔ)言并存，維護(hù)成本和迭代升級(jí)瓶頸大，復(fù)雜業(yè)務(wù)的支撐變的越來(lái)越困難。
• 服務(wù)耦合度高，系統(tǒng)歷史債重，多個(gè)業(yè)務(wù)深度耦合，邏輯分散在多個(gè)模塊，部分接口交織，改動(dòng)會(huì)直接影響底層調(diào)用及下游依賴（引擎/算法），系統(tǒng)穩(wěn)定性無(wú)法閉環(huán)。
• 存儲(chǔ)瓶頸嚴(yán)重，當(dāng)前存儲(chǔ)單表模式，核心數(shù)據(jù)表量級(jí)和日均慢查數(shù)均已遠(yuǎn)遠(yuǎn)超出上限，面對(duì)開(kāi)閉環(huán)分銷業(yè)務(wù)快速發(fā)展，難以承載接口性能和未來(lái)帶貨業(yè)務(wù)增量需求。

2.2 平臺(tái)化目標(biāo)

為從根本上改變系統(tǒng)現(xiàn)狀，解決以上痛點(diǎn)，需要重構(gòu)系統(tǒng)架構(gòu)，推行帶貨分銷系統(tǒng)平臺(tái)化升級(jí)，首先確立了幾個(gè)重要目標(biāo)。

• 提高系統(tǒng)擴(kuò)展性和可維護(hù)性：建立穩(wěn)定的帶貨分銷業(yè)務(wù)數(shù)據(jù)模型，抽象服務(wù)和流程，方案可覆蓋現(xiàn)有直播、視頻、圖文場(chǎng)域20多種帶貨場(chǎng)景。
• 獨(dú)立鏈路核心業(yè)務(wù)：通過(guò)DDD劃分領(lǐng)域，根據(jù)領(lǐng)域邊界拆分業(yè)務(wù)域，升級(jí)系統(tǒng)架構(gòu)，實(shí)現(xiàn)核心業(yè)務(wù)內(nèi)聚，關(guān)聯(lián)域解耦。
• 提升系統(tǒng)穩(wěn)定性：通過(guò)存儲(chǔ)隔離及分庫(kù)分表，升級(jí)中間件，統(tǒng)一業(yè)務(wù)框架和研發(fā)約定，實(shí)時(shí)感知觀測(cè)系統(tǒng)異常。

面對(duì)系統(tǒng)多年歷史的積累，黑盒面大，如何整體推動(dòng)是個(gè)比較大的問(wèn)題。根據(jù)系統(tǒng)預(yù)演和目標(biāo)優(yōu)先級(jí)，制定了分階段的演進(jìn)策略，如下所示，后文將會(huì)進(jìn)一步介紹平臺(tái)化實(shí)踐的一些關(guān)鍵過(guò)程和關(guān)鍵問(wèn)題。

第一步：建立統(tǒng)一模型和落地onebp方案，拆分解耦并遷移視頻帶貨業(yè)務(wù)

第二步：遷移圖文/直播帶貨應(yīng)用至新模型，完成域內(nèi)業(yè)務(wù)與服務(wù)統(tǒng)一

第三步：域外統(tǒng)一切至帶貨分銷新模型，一套模型N種業(yè)務(wù)場(chǎng)景，實(shí)現(xiàn)上下游一致表達(dá)

圖片

3. 業(yè)務(wù)建模與設(shè)計(jì)

分銷帶貨業(yè)務(wù)域相對(duì)不太聚焦，包括不僅限貨品管理、分銷關(guān)系、人貨場(chǎng)撮合、歸因跟蹤、分銷結(jié)算等。從全局視角看帶貨分銷業(yè)務(wù)，主要參與角色由商家、服務(wù)商、UP主、消費(fèi)者等，活動(dòng)在不同場(chǎng)域，當(dāng)前業(yè)務(wù)階段UP主是最核心的分銷者，如下圖所標(biāo)示區(qū)域。

本次平臺(tái)化升級(jí)一方面需要完全覆蓋重構(gòu)的幾個(gè)核心目標(biāo)，另一方面需要充分結(jié)合業(yè)務(wù)現(xiàn)狀和團(tuán)隊(duì)開(kāi)發(fā)人員的經(jīng)驗(yàn)情況，如何有效結(jié)合業(yè)務(wù)現(xiàn)狀和長(zhǎng)期演進(jìn)進(jìn)行建模是比較關(guān)鍵的問(wèn)題。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）作為微服務(wù)的主流設(shè)計(jì)方法，是通過(guò)領(lǐng)域模型捕捉領(lǐng)域知識(shí)，使用領(lǐng)域模型驅(qū)動(dòng)設(shè)計(jì)，主要目標(biāo)是解決復(fù)雜業(yè)務(wù)系統(tǒng)中的設(shè)計(jì)難題，提高系統(tǒng)的適應(yīng)性、可維護(hù)性和開(kāi)發(fā)效率，與當(dāng)前業(yè)務(wù)階段匹配?；谡w考慮，采用該設(shè)計(jì)思想，去推進(jìn)整體平臺(tái)化實(shí)踐，是比較有效的方式，但整個(gè)實(shí)施路徑不嚴(yán)格按照DDD方案論推進(jìn)，優(yōu)點(diǎn)在于：

• 能夠幫助團(tuán)隊(duì)統(tǒng)一語(yǔ)言，捕捉復(fù)雜業(yè)務(wù)邏輯，可以很好解決當(dāng)前分銷業(yè)務(wù)規(guī)則混亂以及場(chǎng)域多變依賴子域復(fù)雜的現(xiàn)狀。
• 通過(guò)領(lǐng)域劃分、聚合和限界上下文的設(shè)計(jì)，可以解耦系統(tǒng)，提高可維護(hù)性和擴(kuò)展性
• 結(jié)合實(shí)際考慮聚合事務(wù)邊界，降低建模復(fù)雜度，兼顧團(tuán)隊(duì)在經(jīng)驗(yàn)上的缺乏和ROI，避免貧血模型或過(guò)度設(shè)計(jì)的反模式，很容易地實(shí)現(xiàn)架構(gòu)演進(jìn)

3.1 邊界劃分

從業(yè)務(wù)視角出發(fā)，按照上文中提到的各角色的用例動(dòng)線，通過(guò)分析分銷業(yè)務(wù)流程和所有用例（局部用例圖如下圖所示）去識(shí)別業(yè)務(wù)域，進(jìn)而劃分子域，定義模型關(guān)系。

圖片

識(shí)別出系統(tǒng)中的主要業(yè)務(wù)域，并劃分出核心域（關(guān)鍵業(yè)務(wù)）、支撐域（輔助業(yè)務(wù)）和通用域（共享業(yè)務(wù)）如下圖。

圖片

3.2 領(lǐng)域模型

領(lǐng)域模型反映了業(yè)務(wù)領(lǐng)域中的實(shí)體、值對(duì)象、聚合、工廠和存儲(chǔ)庫(kù)等。在分銷業(yè)務(wù)中，通過(guò)構(gòu)建抽象模型，相對(duì)穩(wěn)定描述和解決業(yè)務(wù)問(wèn)題。對(duì)于UP分銷任務(wù)，關(guān)聯(lián)了內(nèi)容載體（視頻/直播/圖文等）和層級(jí)以及投放資源位信息，同時(shí)分銷者（UP主）多分銷任務(wù)可以被一個(gè)分銷計(jì)劃管理，內(nèi)容層級(jí)、資源位和商品（含虛擬品）核心信息構(gòu)成了投放的最小單元，該模型可以表達(dá)如下。

圖片

說(shuō)明：

• 內(nèi)容：內(nèi)容載體（稿件、圖文、專欄、直播等）
• 資源位：每個(gè)內(nèi)容載體有多個(gè)資源位，如視頻有浮層、彈幕、框下、評(píng)論、圖文等
• 商品：每個(gè)資源位可以掛多個(gè)商品（開(kāi)環(huán)商品、閉環(huán)商品、虛擬品等）
• 分銷任務(wù)：帶貨分銷單元，可關(guān)聯(lián)內(nèi)容資源位和多個(gè)商品
• 分銷計(jì)劃：由若干分銷任務(wù)構(gòu)成，用于任務(wù)單元管理層級(jí)的擴(kuò)展

任務(wù)單元對(duì)象關(guān)系如下，需要說(shuō)明的是，樣式Object按靜態(tài)類處理，用于模型的映射，支撐組件樣式在消費(fèi)者的展示。

圖片

3.2 事件驅(qū)動(dòng)

領(lǐng)域事件通過(guò)將業(yè)務(wù)動(dòng)作顯式化，促進(jìn)系統(tǒng)的高內(nèi)聚、低耦合，是構(gòu)建復(fù)雜業(yè)務(wù)系統(tǒng)的有效模式。在分銷域中，當(dāng)分銷任務(wù)聚合根狀態(tài)及核心信息發(fā)生變化時(shí)生成事件，保障任務(wù)事件與業(yè)務(wù)邏輯的緊密關(guān)聯(lián)性。在設(shè)計(jì)時(shí)，考慮了全局事件，比如創(chuàng)建分銷任務(wù)的事件定義如下

該事件通用消息報(bào)文定義如下：

{
    "contentTask":{
        private Long id
        // UP主mid賬號(hào)
        private Long mid;
        // 商業(yè)賬號(hào)id
        private Long merchantId;
        // 內(nèi)容id（評(píng)論/視頻/圖文等）
        private Long contentId;
        // 內(nèi)容類型（評(píng)論/視頻/圖文等）
        private Integer contentType;
        // 任務(wù)狀態(tài)
        private Integer taskStatus;
        ...
    },
    "goodsMappings":[{
        // 分銷任務(wù)id
        private Long taskId
        // 全局唯一商品id
        private Long itemId;
        // 跳轉(zhuǎn)鏈接,含歸因
        private String jumpUrl;
        ...
    },{...}]
}

3.3 狀態(tài)機(jī)

帶貨場(chǎng)域分銷狀態(tài)主要在于分銷任務(wù)狀態(tài)的流轉(zhuǎn)，如下圖所示，分銷帶貨任務(wù)從草稿態(tài)開(kāi)始到任務(wù)終態(tài)（包含刪除和審核不通過(guò)兩種狀態(tài)）。

圖片

業(yè)務(wù)階段狀態(tài)碼（終態(tài)、可更改態(tài)、未完成態(tài)）分別定義如下：

// 完成態(tài)
    public static final List<Integer> END_STATUS = Collections.unmodifiableList(Lists.newArrayList(
            DELETED.code, REJECT.code
    ));
    // 未完成態(tài)
    public static final List<Integer> NOT_FINISHED_STATUS = Collections.unmodifiableList(Lists.newArrayList(
            DRAFT.code, AUDITING.code, REJECT.code, LAUNCHING.code
    ));
    // 可更改態(tài)
    public static final List<Integer> CAN_UPDATE_STATUS = Collections.unmodifiableList(Lists.newArrayList(
            DRAFT.getCode(), LAUNCHING.getCode(), AUDITING.getCode()
    ));

3.4 存儲(chǔ)設(shè)計(jì)

3.4.1 分庫(kù)分表方案

在完成業(yè)務(wù)建模后，需要考慮存儲(chǔ)的整體設(shè)計(jì)。上文現(xiàn)狀部分已提到過(guò)單表數(shù)據(jù)量過(guò)億、數(shù)據(jù)模型不能完全表達(dá)分銷業(yè)務(wù)（和其他業(yè)務(wù)存儲(chǔ)耦合）、慢查詢數(shù)量日均十萬(wàn)級(jí)的情況，系統(tǒng)基本已無(wú)擴(kuò)展性?？偨Y(jié)下來(lái)，可采用的方案主要包括分庫(kù)分表、分區(qū)表、冷熱分離和分布式數(shù)據(jù)庫(kù)等4種方案，從實(shí)際的業(yè)務(wù)發(fā)展來(lái)看，QPS/TPS在評(píng)論等場(chǎng)景中持續(xù)增長(zhǎng)，為有效應(yīng)對(duì)單表億級(jí)數(shù)據(jù)的存儲(chǔ)與性能挑戰(zhàn)，同時(shí)為后續(xù)業(yè)務(wù)擴(kuò)展預(yù)留彈性空間，選擇分庫(kù)分表來(lái)做基礎(chǔ)存儲(chǔ)設(shè)計(jì)，那么問(wèn)題來(lái)了，分庫(kù)分表策略是什么？

通常分庫(kù)分表可以分為水平分片和垂直分片，不過(guò)通常分庫(kù)分表更多指水平分片，也就是將數(shù)據(jù)按某種規(guī)則分布到不同的庫(kù)或表中，常見(jiàn)的分片規(guī)則比如哈希取模、范圍分片、一致性哈希、按日期或時(shí)間分片、枚舉分片、地理位置分片、復(fù)合分片等?；氐綐I(yè)務(wù)用例場(chǎng)景，需要支持分銷者id（account_id)和分銷任務(wù)id（task_id）多維度的查詢，復(fù)合分片能很好解決，假如按4庫(kù)16張表為例，按照如下規(guī)則，那么根據(jù)task_id和account_id都能滿足大多數(shù)業(yè)務(wù)用例的查詢了。

3.4.2 中間件選型

確定分片策略后，進(jìn)一步考慮分庫(kù)分表中間件方案，這里給出了業(yè)內(nèi)常見(jiàn)中間件的對(duì)比分析，可參見(jiàn)下表。需要說(shuō)明的是，這里沒(méi)有提及TDDL和DRDS等商業(yè)或非開(kāi)源方案，涉及資源依賴等問(wèn)題。表中Akso-Proxy是B站分庫(kù)分表中間件的一種解決方案，目前對(duì)于不規(guī)則的分片策略暫未支持。在選型的考慮上有兩個(gè)點(diǎn)相對(duì)比較重要：

• 能支持復(fù)合分片的方案訴求，也即支持指定庫(kù)/表查詢（HINT），支持多字段分庫(kù)分表
• 輕量級(jí)低成本接入，能匹配項(xiàng)目節(jié)奏及部門當(dāng)前基建的應(yīng)用維護(hù)現(xiàn)狀

Sharding-JDBC是相對(duì)輕量級(jí)java框架，使用客戶端直連數(shù)據(jù)庫(kù)，無(wú)需額外部署和依賴，可被視為增強(qiáng)版JDBC驅(qū)動(dòng)。目前在部門交易域使用比較廣泛，也集成到腳手架，運(yùn)維升級(jí)可以統(tǒng)一管理，成本基本可忽略，結(jié)合優(yōu)勢(shì)和不足的權(quán)衡，Sharding-JDBC是當(dāng)前階段最為合適的選擇。

圖片

在實(shí)踐過(guò)程中，定義了分庫(kù)分表策略，繼承AbstractShardingAlgorithm，依賴關(guān)系如下，實(shí)現(xiàn)中間中ComplexKeysShardingAlgorithm中的interface方法doSharding，在 doSharding 方法中，根據(jù)分片鍵計(jì)算目標(biāo)數(shù)據(jù)庫(kù)和數(shù)據(jù)表，核心接口定義與基礎(chǔ)實(shí)現(xiàn)如下。

圖片

public class DatabaseShardingAlgorithm extends AbstractShardingAlgorithm {
    @Override
    public String doSharding(String shardingKey) {
        // 根據(jù)分片鍵計(jì)算目標(biāo)數(shù)據(jù)庫(kù)
        int hash = shardingKey.hashCode();
        int databaseIndex = Math.abs(hash % N); // 假設(shè)有N個(gè)數(shù)據(jù)庫(kù)
        return "db_" + databaseIndex;
    }
}

4. 架構(gòu)模式

軟件架構(gòu)從單機(jī)、集中式到分布式微服務(wù)架構(gòu)經(jīng)歷了三個(gè)階段的演進(jìn)，每個(gè)階段都以提高系統(tǒng)響應(yīng)為目標(biāo)，通過(guò)分離復(fù)雜度來(lái)實(shí)現(xiàn)業(yè)務(wù)優(yōu)化。傳統(tǒng)的軟件架構(gòu)大多都是三層架構(gòu)，如下圖所示，解決了程序內(nèi)代碼間調(diào)用復(fù)雜、代碼職責(zé)不清的問(wèn)題。但依然屬于邏輯分層概念，核心問(wèn)題就是技術(shù)建模和業(yè)務(wù)需求存在視角差異，隨著項(xiàng)目的迭代演進(jìn)，各層級(jí)與各模塊之間可能存在交叉引用。從分銷系統(tǒng)現(xiàn)狀來(lái)看，屬于典型的傳統(tǒng)三層架構(gòu)模式。

圖片

DDD（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)） 是一種處理高度復(fù)雜領(lǐng)域的設(shè)計(jì)思想，可以有效分離技術(shù)實(shí)現(xiàn)的復(fù)雜性，圍繞業(yè)務(wù)概念構(gòu)建領(lǐng)域模型來(lái)控制業(yè)務(wù)復(fù)雜度，非常適合微服務(wù)架構(gòu)的演進(jìn)。其分層架構(gòu)設(shè)計(jì)包括用戶接口層、應(yīng)用層、領(lǐng)域?qū)雍突A(chǔ)層，如下所示。每層都扮演著特定的角色，通過(guò)嚴(yán)格的分層原則實(shí)現(xiàn)松耦合，解決了三層架構(gòu)中核心業(yè)務(wù)邏輯混亂、代碼改動(dòng)相互影響大的問(wèn)題，大大簡(jiǎn)化持續(xù)性升級(jí)和維護(hù)。相比較六邊形架構(gòu)、洋蔥架構(gòu)、CQRS架構(gòu)等，其實(shí)現(xiàn)復(fù)雜度相對(duì)較低，作為當(dāng)前業(yè)務(wù)架構(gòu)解決方案更有效。

圖片

4.1 分層架構(gòu)

如何從三層架構(gòu)向DDD四層架構(gòu)演進(jìn)，需要根據(jù)建模階段，重新歸類要素、重新劃分層次、重新確定交互規(guī)則和職責(zé)邊界，主要集中在業(yè)務(wù)邏輯層和數(shù)據(jù)訪問(wèn)層的劃分，在實(shí)踐過(guò)程中分銷服務(wù)分層演進(jìn)過(guò)程和常見(jiàn)演進(jìn)方式類似，如下圖。

圖片

在設(shè)計(jì)視角上，根據(jù)業(yè)務(wù)功能歸屬，提前做好不同業(yè)務(wù)領(lǐng)域的拆分。在技術(shù)實(shí)現(xiàn)上，通過(guò)實(shí)現(xiàn)與接口分離，在 application 與 infrastructure 之間新增 domain 領(lǐng)域?qū)樱宒omain層盡量獨(dú)立，不耦合與任何模塊，下圖描述的是分銷平臺(tái)化從三層架構(gòu)現(xiàn)狀升級(jí)到四層DDD架構(gòu)的實(shí)踐情況。

圖片

四層架構(gòu)在平臺(tái)化項(xiàng)目工程中具體描述如下表所示

圖片

具體的依賴調(diào)用關(guān)系以分銷任務(wù)單元的生命周期為例，如下圖所示。這里需要指出的是，domain領(lǐng)域?qū)臃潜仨氁蕾囌{(diào)用層，通常在業(yè)務(wù)服務(wù)表達(dá)中，簡(jiǎn)單業(yè)務(wù)非核心領(lǐng)域的調(diào)用可以直接跨過(guò)，這樣簡(jiǎn)化了非核心領(lǐng)域的調(diào)用層級(jí)，靈活性高。

圖片

4.2 規(guī)范約定

確定分層架構(gòu)后，需要進(jìn)行相關(guān)技術(shù)層面的代碼約定和規(guī)范，主要是異常處理方案和錯(cuò)誤碼規(guī)范，這些作為系統(tǒng)平臺(tái)化可觀測(cè)能力的基礎(chǔ)條件。

對(duì)于異常處理方案，每一層（包括系統(tǒng)內(nèi)/系統(tǒng)間）僅捕獲當(dāng)前層處理的異常，跨系統(tǒng)間不拋出異常，默認(rèn)使用通用返回對(duì)象+錯(cuò)誤碼的形式管理。

對(duì)于錯(cuò)誤碼規(guī)范，按照8位約定，基礎(chǔ)枚舉定義如下。在規(guī)范要求中，需要統(tǒng)一遵循i18n，命名規(guī)范統(tǒng)一約束成 {平臺(tái)域/業(yè)務(wù)域}-{領(lǐng)域}-{系統(tǒng)名縮寫(xiě)}-{錯(cuò)誤類型}-{錯(cuò)誤碼數(shù)字編號(hào)}。舉個(gè)例子，在分銷任務(wù)業(yè)務(wù)用例中，敏感詞稿件評(píng)論分銷任務(wù)創(chuàng)建失敗，那么錯(cuò)誤碼則設(shè)定為：81211001，這樣就對(duì)上下游和域內(nèi)錯(cuò)誤異常進(jìn)行了全局的定義，可快速識(shí)別平臺(tái)異常根因。

圖片

5. 系統(tǒng)遷移策略

5.1 切流方案

切流和數(shù)據(jù)遷移這兩個(gè)部分是大項(xiàng)目中的關(guān)鍵，風(fēng)險(xiǎn)很高。切流指的是將流量從舊系統(tǒng)切換到新系統(tǒng)，而數(shù)據(jù)遷移則是將舊數(shù)據(jù)轉(zhuǎn)移到新系統(tǒng)中。這兩者都可能遇到很多問(wèn)題，比如數(shù)據(jù)不一致、服務(wù)中斷、兼容性等問(wèn)題，對(duì)于耦合依賴重的系統(tǒng)，更需要考慮切流與遷移成本以及整體項(xiàng)目節(jié)奏和進(jìn)度，這里面涉及眾多關(guān)鍵問(wèn)題。

5.1.1 雙向同步

在分銷系統(tǒng)中，涉及相當(dāng)多的上下游，比如引擎、算法、數(shù)據(jù)以及其他業(yè)務(wù)方依賴，實(shí)際過(guò)程中不可能做到各方節(jié)奏上同步性，因此多套老模型老庫(kù)表的業(yè)務(wù)數(shù)據(jù)和新模型必須保持高度的一致，否則就會(huì)出現(xiàn)線上故障。當(dāng)部分切流后，命中的用戶會(huì)請(qǐng)求到新系統(tǒng)，數(shù)據(jù)會(huì)直接寫(xiě)新，同時(shí)異構(gòu)寫(xiě)老，要做到對(duì)依賴方無(wú)影響；同時(shí)存在較多場(chǎng)景需要讀取和變更該用戶的存量數(shù)據(jù)，需要將老模型數(shù)據(jù)同步異構(gòu)至新模型庫(kù)表，當(dāng)然后者在切流100%后就不再需要了。所以從整體看，數(shù)據(jù)流是雙向同步的，這也決定了平臺(tái)化升級(jí)切流和數(shù)據(jù)同步就具備較高的復(fù)雜性。

圖片

歷史業(yè)務(wù)數(shù)據(jù)區(qū)分度較低，改動(dòng)也將會(huì)影響其他的業(yè)務(wù)方，如何進(jìn)行雙向同步？同時(shí)還要保障成本最低、風(fēng)險(xiǎn)最??？這里面有幾個(gè)關(guān)鍵性切流設(shè)計(jì)：

• 分銷任務(wù)單元的變更僅在一端發(fā)生：一旦數(shù)據(jù)同步期間發(fā)生意外，以發(fā)生變更側(cè)的狀態(tài)為準(zhǔn)，而變更側(cè)定義為數(shù)據(jù)產(chǎn)生端。這里在老庫(kù)表新增新模型的唯一id，在新庫(kù)表新增ref_id，如果unique_id或ref_id非0，則表示當(dāng)前的記錄是從對(duì)側(cè)同步過(guò)來(lái)的。
• 變更操作按新系統(tǒng)是否存在數(shù)據(jù)記錄來(lái)判斷：灰度期請(qǐng)求入口均在老系統(tǒng)，就可能存在兩套id，變更操作請(qǐng)求的處理，若新系統(tǒng)能查到，則創(chuàng)建正常處理，否則拒絕。
• binlog循壞問(wèn)題檢查：數(shù)據(jù)變更是不是因同步而改變，新增輔助flag字段，用于檢查同步流向。

圖片

5.1.2 實(shí)施方案

這里選擇視頻帶貨服務(wù)和平臺(tái)化升級(jí)后的新服務(wù)來(lái)說(shuō)明整個(gè)切流方案的實(shí)施過(guò)程（圖文帶貨和直播帶貨獨(dú)立服務(wù)均采用類似方案），其中mas代表視頻分銷應(yīng)用，cbp代表新應(yīng)用。

第一步，視為初始狀態(tài)，業(yè)務(wù)依舊100%在老系統(tǒng)。這里會(huì)有有兩個(gè)前置處理：

• mas數(shù)據(jù)庫(kù)同步cbp，也即完成mas數(shù)據(jù)的存量快照搬遷和mas數(shù)據(jù)的增量同步
• cbp準(zhǔn)備好，完成CbpToMas的部署和開(kāi)關(guān)配置，不接入實(shí)際流量

圖片

圖片

第二步，開(kāi)始切流階段，白名單的用戶走新系統(tǒng)，非白名單用戶走老系統(tǒng)。其中，編輯/讀取任務(wù)，取決于任務(wù)初始是在mas還是在cbp創(chuàng)建的 ，cbp里創(chuàng)建/編輯的任務(wù)會(huì)同步到mas。

圖片

第三步，切流100%階段，所有用戶創(chuàng)建任務(wù)都切到cbp，后續(xù)mas系統(tǒng)不再創(chuàng)建任務(wù)，因此mas的binlog里應(yīng)該不再有INSERT，而編輯/讀任務(wù)切流還根據(jù)任務(wù)的初始創(chuàng)建系統(tǒng)走。觀察穩(wěn)定后，會(huì)有個(gè)后置處理，翻轉(zhuǎn)refId，讓所有的請(qǐng)求均走新服務(wù)。

圖片

第四步，依賴方遷移，依賴?yán)舷到y(tǒng)接口業(yè)務(wù)方，可以直接切換cbp域名完成低成本切換，完成新老服務(wù)平緩切換。

圖片

5.1.3 回滾預(yù)案

分銷平臺(tái)化升級(jí)切流環(huán)節(jié)涉及數(shù)十服務(wù)和不同模塊，外部系統(tǒng)依賴性強(qiáng)，需要制定應(yīng)急回滾預(yù)案，確保系統(tǒng)的高可用性，盡可能降低對(duì)用戶對(duì)業(yè)務(wù)的負(fù)面影響，這里采用了系列前置動(dòng)作。

• 異常感知：切流過(guò)程，出現(xiàn)異常，在數(shù)據(jù)層和服務(wù)層通過(guò)對(duì)賬和流量回放等方式自動(dòng)觸發(fā)異常告警
• 動(dòng)態(tài)配置：異常一旦發(fā)生，切流不符預(yù)期，可動(dòng)態(tài)調(diào)整切流比例，配置化快速回滾，流量重新回到老系統(tǒng)，控制風(fēng)險(xiǎn)；
• 修復(fù)工具：當(dāng)切流產(chǎn)生異常數(shù)據(jù)，提供快速修復(fù)工具，進(jìn)行數(shù)據(jù)補(bǔ)償處理
• 回滾預(yù)演：上線前多次注入切流異常，進(jìn)行預(yù)演驗(yàn)證，實(shí)際上10min內(nèi)即可完成數(shù)據(jù)與應(yīng)用的回滾處理，結(jié)合小流量切流比例，影響相當(dāng)小

5.2 數(shù)據(jù)一致性保障

切流和數(shù)據(jù)同步過(guò)程對(duì)數(shù)據(jù)一致性要求比較高，一旦新老模型數(shù)據(jù)不一致，就會(huì)產(chǎn)生系統(tǒng)故障，這對(duì)模型對(duì)賬也提出了更高的要求：

• 完整性：確保所有數(shù)據(jù)（全量或增量）均從舊系統(tǒng)遷移到新系統(tǒng)，無(wú)遺漏。
• 一致性：新老系統(tǒng)的數(shù)據(jù)內(nèi)容（字段值、格式、關(guān)聯(lián)關(guān)系等）完全一致。
• 業(yè)務(wù)正確性：遷移后的數(shù)據(jù)能支持業(yè)務(wù)邏輯的正常運(yùn)行

除了離線全量對(duì)賬作為基礎(chǔ)，同時(shí)也設(shè)計(jì)了增量全套實(shí)時(shí)對(duì)賬流程，如下所示。

圖片

過(guò)程中的數(shù)據(jù)同步問(wèn)題及時(shí)監(jiān)控和告警，在上線前不斷演練，不斷修正歷史數(shù)據(jù)和不一致性問(wèn)題，約99%潛在問(wèn)題都能被發(fā)現(xiàn)和處理，如下實(shí)時(shí)告警。

圖片

另外結(jié)合回滾預(yù)案提到的恢復(fù)工具和回滾機(jī)制，充分控制切流遷移風(fēng)險(xiǎn)，最終保障項(xiàng)目穩(wěn)定切流，完成了億級(jí)數(shù)據(jù)全量遷移，期間域內(nèi)和關(guān)聯(lián)上下游未出現(xiàn)故障問(wèn)題，系統(tǒng)切流過(guò)程高可用質(zhì)量超出預(yù)期。

6. 總結(jié)與展望

6.1  階段總結(jié)

本文全面介紹了UP主帶貨分銷系統(tǒng)平臺(tái)化升級(jí)的實(shí)踐過(guò)程，最終完成了業(yè)務(wù)技術(shù)重構(gòu)和代碼結(jié)構(gòu)優(yōu)化。在整個(gè)推進(jìn)過(guò)程中，充分考慮了業(yè)務(wù)發(fā)展及系統(tǒng)當(dāng)前/未來(lái)的基礎(chǔ)平臺(tái)能力，如下圖所示，提出了平臺(tái)化升級(jí)的長(zhǎng)期目標(biāo)。

圖片

通過(guò)結(jié)合DDD基本設(shè)計(jì)思想，實(shí)現(xiàn)業(yè)務(wù)域劃分和分銷領(lǐng)域模型和事件的定義，然后在存儲(chǔ)和架構(gòu)分層上，提出了符合業(yè)務(wù)和團(tuán)隊(duì)現(xiàn)狀的實(shí)踐方案，最后設(shè)計(jì)了穩(wěn)定且低成本的切流遷移方案，完成了平臺(tái)階段性升級(jí)目標(biāo)，并達(dá)成如下預(yù)期成效：

• 系統(tǒng)擴(kuò)展性和可維護(hù)性增強(qiáng)，核心模型可覆蓋視頻/圖文/直播現(xiàn)有20多種帶貨場(chǎng)景，新場(chǎng)景擴(kuò)展接入從1-2周降至天級(jí)，維護(hù)成本大大降低
• 核心業(yè)務(wù)域完成部分拆分，實(shí)現(xiàn)了廣告/主站/結(jié)算/數(shù)據(jù)/引擎等眾多支撐域的解耦
• 系統(tǒng)穩(wěn)定性提升，新服務(wù)異常感知提升至分鐘級(jí)，慢sql幾乎未出現(xiàn)，核心模型接口讀寫(xiě)RT下降4倍左右（如任務(wù)單元?jiǎng)?chuàng)建從200ms+下降至40ms+）

這里需要提出的是，過(guò)程中引入DDD相對(duì)傳統(tǒng)架構(gòu)而言，可以幫助從業(yè)務(wù)角度更合理地劃分系統(tǒng)和業(yè)務(wù)邊界，找到并改進(jìn)現(xiàn)有架構(gòu)中的問(wèn)題。但在初期的架構(gòu)實(shí)現(xiàn)上存在更高的實(shí)現(xiàn)成本和復(fù)雜度，因此需要做到在合適的場(chǎng)景中選擇合適的方案，結(jié)合實(shí)際情況會(huì)更為有效。另外平臺(tái)化升級(jí)不僅是技術(shù)層面的重構(gòu)迭代，更是組織模式與業(yè)務(wù)思維向前走了一大步，整個(gè)項(xiàng)目團(tuán)隊(duì)積累了一定的實(shí)踐經(jīng)驗(yàn)。在系統(tǒng)穩(wěn)定性提升、復(fù)雜業(yè)務(wù)場(chǎng)景快速接入、資源利用率優(yōu)化等方面也達(dá)成了階段性成果。另外，也還有未完成的部分在途持續(xù)推進(jìn)，比如直播場(chǎng)域帶貨分銷模型遷移、商品等支撐域解耦等。

6.2 未來(lái)展望

從業(yè)務(wù)域應(yīng)用架構(gòu)現(xiàn)狀來(lái)看，如下圖所示，系統(tǒng)應(yīng)用調(diào)用關(guān)系尚較為復(fù)雜，長(zhǎng)期的治理和平臺(tái)化的目標(biāo)是保持一致的。后續(xù)隨著系統(tǒng)平臺(tái)化各域的深入演進(jìn)，將會(huì)進(jìn)一步推動(dòng)各子域和上下游，從分銷全局視角獲得最優(yōu)解。

圖片

而分銷業(yè)務(wù)域的平臺(tái)應(yīng)用架構(gòu)將也會(huì)不斷升級(jí)，從現(xiàn)有的20多個(gè)應(yīng)用整合縮簡(jiǎn)至幾大核心應(yīng)用，整體演進(jìn)規(guī)劃如下圖所示，可以看到還有相當(dāng)多的挑戰(zhàn)，需要在實(shí)踐中逐一去解。未來(lái)平臺(tái)化技術(shù)深入方向也將會(huì)以用戶價(jià)值為核心，持續(xù)提升用戶體驗(yàn)，支撐產(chǎn)品化能力，深化生態(tài)合作，充分優(yōu)化組織的迭代流程，不斷探索平臺(tái)智能化（AI托管等），確保在快速增長(zhǎng)和變化的業(yè)務(wù)探索中保持分銷平臺(tái)的領(lǐng)先性。

圖片