1. 引言

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

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

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

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

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

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

圖片

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

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

2.2 平臺化目標(biāo)

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

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

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

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

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

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

圖片

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

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

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

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

3.1 邊界劃分

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

圖片

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

圖片

3.2 領(lǐng)域模型

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

圖片

說明：

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

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

圖片

3.2 事件驅(qū)動

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

該事件通用消息報文定義如下：

{
    "contentTask":{
        private Long id
        // UP主mid賬號
        private Long mid;
        // 商業(yè)賬號id
        private Long merchantId;
        // 內(nèi)容id（評論/視頻/圖文等）
        private Long contentId;
        // 內(nèi)容類型（評論/視頻/圖文等）
        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ī)

帶貨場域分銷狀態(tài)主要在于分銷任務(wù)狀態(tài)的流轉(zhuǎn)，如下圖所示，分銷帶貨任務(wù)從草稿態(tài)開始到任務(wù)終態(tài)（包含刪除和審核不通過兩種狀態(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 存儲設(shè)計

3.4.1 分庫分表方案

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

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

3.4.2 中間件選型

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

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

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

圖片

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

圖片

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

4. 架構(gòu)模式

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

圖片

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

圖片

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

圖片

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

圖片

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

圖片

4.2 規(guī)范約定

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

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

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

圖片

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

5.1 切流方案

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

5.1.1 雙向同步

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

圖片

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

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

圖片

5.1.2 實施方案

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

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

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

圖片

圖片

第二步，開始切流階段，白名單的用戶走新系統(tǒng)，非白名單用戶走老系統(tǒng)。其中，編輯/讀取任務(wù)，取決于任務(wù)初始是在mas還是在cbp創(chuàng)建的 ，cbp里創(chuàng)建/編輯的任務(wù)會同步到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)定后，會有個后置處理，翻轉(zhuǎn)refId，讓所有的請求均走新服務(wù)。

圖片

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

圖片

5.1.3 回滾預(yù)案

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

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

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

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

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

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

圖片

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

圖片

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

6. 總結(jié)與展望

6.1  階段總結(jié)

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

圖片

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

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

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

6.2 未來展望

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

圖片

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

圖片