背景

帶貨作為近年來一種新興、高效的營銷形式，在商業(yè)側(cè)最早以耦合在必選和邀約廣告的業(yè)務(wù)形態(tài)中存在，直到22年中開始作為明確的業(yè)務(wù)探索方向。從初步確定帶貨業(yè)務(wù)的基本定位，到短短的一年多時間，業(yè)務(wù)極速發(fā)展，無論是帶貨up數(shù)還是帶貨收益以及平臺收益層面，均有較快的增長，到目前已形成初具規(guī)模的業(yè)務(wù)體量。期間對于技術(shù)側(cè)而言，面對相當(dāng)多的困難，特別是在幾乎無任何基礎(chǔ)無獨立系統(tǒng)的歷史狀況下，如何構(gòu)建高效穩(wěn)定的平臺體系去支撐帶貨業(yè)務(wù)的快速迭代和發(fā)展需求，存在極大的挑戰(zhàn)。

現(xiàn)狀與問題

業(yè)務(wù)場景

帶貨屬于典型的人貨場型業(yè)務(wù)，對于B站而言，其場景相對較多且交互復(fù)雜，包含視頻、圖文、直播等十幾種公私域不同場景。要實現(xiàn)從內(nèi)容到種草的轉(zhuǎn)化，構(gòu)建用戶交易心智和構(gòu)建良性帶貨電商生態(tài)的目標(biāo)，早期的系統(tǒng)完全無法支持。

圖片

 問題分析

早期的帶貨核心服務(wù)，均耦合在最早的商業(yè)互選業(yè)務(wù)中，僅存在最基本的帶貨流程，業(yè)務(wù)產(chǎn)品的需求支持幾乎也只能串行對接。面對幾乎負(fù)向的現(xiàn)存系統(tǒng)，多涉及最基礎(chǔ)的需求開發(fā)，對于相對復(fù)雜的項目支持，難度較大，很難有效支撐。究其核心原因，在于業(yè)務(wù)領(lǐng)域不清晰，采用面向需求開發(fā)的方式，抱著能用即可的態(tài)度與目標(biāo)，導(dǎo)致系統(tǒng)耦合嚴(yán)重，極其混亂，缺乏整體的方案設(shè)計。

在該狀態(tài)下，面對帶貨業(yè)務(wù)突然的強(qiáng)勢增長，產(chǎn)研形成了相對較大的矛盾沖突，開發(fā)效率低，業(yè)務(wù)支撐難，交付質(zhì)量差，是當(dāng)時幾代解決的問題。如何徹底解決這些風(fēng)險與挑戰(zhàn)？從研發(fā)視角來看，需要考慮四個維度的綜合平衡：基礎(chǔ)建設(shè)、平臺能力、統(tǒng)一標(biāo)準(zhǔn)、成本效率。基于業(yè)務(wù)目標(biāo)與研發(fā)現(xiàn)狀，全面梳理所有涉及帶貨的服務(wù)與接口后，我們提出平臺化的整體解決方案。由當(dāng)前技術(shù)債重的業(yè)務(wù)系統(tǒng)快速向平臺化演進(jìn)，從0到1進(jìn)行帶貨業(yè)務(wù)體系平臺化的全面建設(shè)。

平臺架構(gòu)

帶貨業(yè)務(wù)核心涉及到貨端、人端以及應(yīng)用場景端， 整個平臺體系化的建設(shè)需要充分兼容通用場景，支撐好業(yè)務(wù)構(gòu)建和關(guān)鍵能力建設(shè)，最重要的是從業(yè)務(wù)本身出發(fā)，需要回答幾個關(guān)鍵問題：業(yè)務(wù)場景是什么？平臺解決誰的問題？平臺能力如何聚合，邊界如何清晰定義？在全面分析帶貨業(yè)務(wù)域及業(yè)務(wù)目標(biāo)基礎(chǔ)上，從最初的煙囪式交叉服務(wù)，設(shè)計了如圖方向的平臺體系化架構(gòu)。

圖片

在該平臺架構(gòu)全景中，其本質(zhì)需要解決帶貨業(yè)務(wù)體系中的幾大核心問題和關(guān)鍵業(yè)務(wù)構(gòu)建及業(yè)務(wù)能力

• 貨從哪里來？由商品中臺體系支撐
• 貨要怎么帶？由帶貨平臺能力來支持
• 貨要怎么管？由運營平臺能力支撐
• 貨該怎么出？由帶貨引擎/廣告引擎聯(lián)合支撐
• 人貨場如何聯(lián)動？由標(biāo)準(zhǔn)帶貨鏈路（人端/貨端/數(shù)據(jù)端/算法）整體解決

針對這些核心問題，從系統(tǒng)分層、模型領(lǐng)域分解、標(biāo)準(zhǔn)化交互協(xié)議等層面，進(jìn)行了帶貨平臺技術(shù)架構(gòu)的全面設(shè)計，整體方案如下圖。如何在早期技術(shù)債較重的狀態(tài)下，一步步從0-1推進(jìn)帶貨業(yè)務(wù)體系平臺化的建設(shè)，將在下文中逐一介紹。

圖片

平臺建設(shè)

確立了體系化的建設(shè)目標(biāo)后，我們不再從單一的用戶視角或需求視角去思考，而是結(jié)合平臺化視角去看整體的帶貨業(yè)務(wù)體系。在業(yè)務(wù)的快速推進(jìn)過程中，如何快速落地整體方案的核心模塊，快速轉(zhuǎn)化為生產(chǎn)力，尤為重要。在建設(shè)過程中，需要支撐現(xiàn)有業(yè)務(wù)的迭代，我們采取業(yè)務(wù)技術(shù)雙驅(qū)動的方式，對帶貨領(lǐng)域模型進(jìn)行分解，將人端、貨端、流量端的核心能力進(jìn)行抽象聚合，確立建設(shè)和決策四大核心方向的路徑，主要包括商品中臺、平臺能力、交互模型、平臺化治理等，核心解決平臺的業(yè)務(wù)交付效率和系統(tǒng)質(zhì)量等問題。

商品中臺

在帶貨業(yè)務(wù)體系中，商品域是貨端的核心域，貨品作為業(yè)務(wù)源頭，其重要性不言而喻。早期系統(tǒng)幾乎缺失了商品層概念，只是通過簡單API方式去調(diào)用開環(huán)渠道淘寶以及公司內(nèi)閉環(huán)渠道（會員購、工房等）的商品服務(wù)，和帶貨主體、帶貨行為全部耦合在一起，就開發(fā)本身而言，每新增一種商品類型或接入一種商品渠道，整個流程均需要改動，風(fēng)險高開發(fā)周期長，完全無法滿足業(yè)務(wù)的期望，如何解決通用的貨端能力成為急需解決的問題。

從業(yè)務(wù)本身出發(fā)，我們決定從0-1搭建商品中臺，構(gòu)建帶貨體系的貨品供應(yīng)中臺服務(wù)能力，全面解決貨從哪來以及貨到哪里去的問題。該中臺和傳統(tǒng)意義的商品中臺差別很大，非傳統(tǒng)的貨架概念。就B站而言，絕大部分貨品來源于頭部電商生態(tài)，另一部分主要是B站內(nèi)部的電商商品，帶貨場景的貨端中臺不需要關(guān)注商品供應(yīng)鏈層面，更需要關(guān)注的是渠道的復(fù)雜性與多樣性及公司級商品服務(wù)能力。

圖片

這里面有幾個難點需要解決：如何快速高效接入貨品渠道？怎樣抽象并構(gòu)建商品域底層模型？商品庫零故障遷移及一致性如何保障？

渠道方案

貨品渠道的快速接入對于直播帶貨、視頻帶貨及廣告帶貨等場景相當(dāng)重要，通過對接不同電商渠道聯(lián)盟及企業(yè)內(nèi)部渠道，提供帶貨貨源商品池。而在早期的鏈路中，接入每個渠道（如京東、淘寶等）均需定制化接入個性化處理，對接成本高，維護(hù)相對難，規(guī)則較混亂，貨品校驗缺失，臟數(shù)據(jù)易混淆，邏輯無分層，極其影響業(yè)務(wù)穩(wěn)定及效率。因此接入生態(tài)媒體（京東、淘寶等）和接入內(nèi)部電商商品（會員購、工房等）的通用化解決方案尤為重要，直接決定了在業(yè)務(wù)需求進(jìn)展中的推進(jìn)效率。基于此，在商品渠道的接入過程，我們提出了動態(tài)配置的貨品渠道接入方案，整體架構(gòu)如下所示。

圖片

該方案將不同的貨品渠道抽象成不同的供給端，按照數(shù)據(jù)流方式進(jìn)行校驗、加工、標(biāo)準(zhǔn)化存儲。在實際工程實踐中如下圖，建立渠道工廠（factory）通過渠道配置組件（channelConfig）建立不同渠道源的商品數(shù)據(jù)連接行為，再經(jīng)過校驗器（validater）、轉(zhuǎn)換裝飾器（convertor）標(biāo)準(zhǔn)化商品數(shù)據(jù)，按照設(shè)計的實體模型完成商品庫的存儲。

圖片

模型及存儲

商品實體模型該如何設(shè)計，直接關(guān)系到商品中臺讀寫服務(wù)的基礎(chǔ)能力。早期的讀寫均采用es作為存儲，問題很多，讀寫混亂，無法對業(yè)務(wù)事務(wù)進(jìn)行回滾，拓展性幾乎為零，維護(hù)成本也相對較高。核心原因就在于商品庫的讀寫模型幾乎是無約束式的增刪，缺乏領(lǐng)域模型，為解決此問題，進(jìn)行了全面的改造，以商品核心表、商品拓展表、商品應(yīng)用表、商品貨架表為核心模型承載，構(gòu)建了商品庫底層基本領(lǐng)域模型如下。

圖片

從簡單的商品屬性線性關(guān)系存儲方式到領(lǐng)域化的升級，最大的問題就是商品庫的存儲，一方面需要考慮存量異構(gòu)，另一方面需要考慮數(shù)據(jù)一致性問題。首先，對于es的存量數(shù)據(jù)，進(jìn)行底層模型的重構(gòu)，寫入mysql業(yè)務(wù)模型表，考慮到商品的搜索性能，通過訂閱binlog構(gòu)建商品索引庫，提供商品讀寫分離的能力，如圖所示。

圖片

但這又帶來了新的問題，在強(qiáng)一致性讀的商品場景中，如在變更商品別名保存后，因為binlog消費的延時等原因，會導(dǎo)致用戶體驗不一致的問題。因此對于強(qiáng)一致性讀直接讀取mysql表，對實時要求不高的場景或搜索場景直接由索引庫提供。另外mysql同步至es索引也有可能出現(xiàn)數(shù)據(jù)不一致，一方面通過retry和死信隊列來異步保障寫失敗導(dǎo)致的不一致，另一方面通過引入對賬機(jī)制進(jìn)行小時級和天級對賬補償保障。而在實際過程中，實現(xiàn)了零故障的商品數(shù)據(jù)模型遷移。在整體改造后，實現(xiàn)了具備讀寫分離、事務(wù)控制、獨立模型的拓展性高的商品庫，成為整個商品中臺的底層模型和穩(wěn)定性存儲。

平臺能力

平臺能力是平臺化建設(shè)的重中之重，核心解決貨怎么帶的問題，負(fù)責(zé)支撐帶貨業(yè)務(wù)平臺的所有核心能力，如自然帶貨、投流帶貨、直播帶貨所有服務(wù)應(yīng)用及能力輸出。早期的服務(wù)，和其他業(yè)務(wù)基本都是耦合在一起，僅提供了帶貨的基本鏈路，缺乏業(yè)務(wù)能力沉淀，特別是多個應(yīng)用相互依賴，相當(dāng)混亂，如圖所示。這直接導(dǎo)致了很多問題和沖突，需求支持效率極低，開發(fā)上線風(fēng)險很高，交付質(zhì)量也難以符合業(yè)務(wù)預(yù)期，難以滿足業(yè)務(wù)的快速發(fā)展。

圖片

為徹底解決系統(tǒng)幾乎為零的平臺化能力，結(jié)合業(yè)務(wù)本身和發(fā)展的情況，就業(yè)務(wù)能力進(jìn)行全面的聚合分析。首先從帶貨鏈路看，在保障了商品源頭的供給，關(guān)鍵在于人貨場的建立，即對up主、貨品及場景的撮合，來解決人端、貨端的聯(lián)動，如下圖業(yè)務(wù)的撮合途徑和業(yè)務(wù)底層能力訴求。

圖片

如何構(gòu)建對應(yīng)的平臺能力去支撐人貨的撮合？這是需要急待解決的重要問題。一方面從系統(tǒng)本身出發(fā)，對于歷史債進(jìn)行全面的模塊化梳理，整合核心的業(yè)務(wù)能力和通用的基礎(chǔ)服務(wù)，明確各系統(tǒng)應(yīng)用的上下文邊界。同時，對于帶貨系統(tǒng)核心應(yīng)用建立統(tǒng)一的分層架構(gòu)規(guī)范（包含client/service/common/starter）如下圖核心業(yè)務(wù)層規(guī)范，徹底解決歷史應(yīng)用間調(diào)用混亂，相互依賴的問題。

圖片

另一方面，從業(yè)務(wù)領(lǐng)域考慮，進(jìn)一步抽象核心能力，建立帶貨平臺底層模型，包括權(quán)限模型、投放模型、結(jié)算模型、pid模型，數(shù)據(jù)模型等，從投流帶貨、視頻帶貨、直播帶貨、社區(qū)種草等場景，全面構(gòu)建平臺化投放帶貨能力，支撐復(fù)雜場景以及多用戶不同形態(tài)的帶貨需求，如下圖所示，從0-1逐步系統(tǒng)化建立的業(yè)務(wù)平臺能力。

圖片

交互模型

平臺能力除了業(yè)務(wù)場景的支撐需要，更要考慮如何高效穩(wěn)定支撐帶貨底層數(shù)據(jù)的交互。帶貨引擎，解決貨怎么出的問題，支撐帶貨投放的索引構(gòu)建能力及C端（評論/視頻）廣告檢索端的服務(wù)交互能力，同時負(fù)責(zé)帶貨業(yè)務(wù)服務(wù)針對主站的透出。早期的帶貨引擎利用廣告引擎建立了基本的鏈路，但和業(yè)務(wù)底層耦合嚴(yán)重，需要訂閱大量的底層數(shù)據(jù)表，引擎的構(gòu)建效率和業(yè)務(wù)整體支撐效率較差。交互模型鏈接了帶貨的關(guān)鍵通路，業(yè)務(wù)模型的解耦與重構(gòu)，尤為重要。

一方面考慮到歷史其他業(yè)務(wù)在稿件投放維度的交互方式，另一方面為后續(xù)圖文投放帶貨標(biāo)準(zhǔn)化交互方式，因此，我們把稿件類（框下、浮層、彈幕）、圖文類（評論、專欄、動態(tài)等）分別作為最基礎(chǔ)的交互模型。但是，當(dāng)各個資源位上的帶貨稿件發(fā)生變更時，稿件的帶貨屬性也會發(fā)生動態(tài)變化，而這一變化引擎無法實時感知，就會出現(xiàn)非帶貨稿件的錯誤分發(fā)。有兩種解決方案，要么是建立實時稿件屬性API方式，要么構(gòu)建帶貨屬性實時交互表，前者直接提供C端的大流量實時請求，對于API的壓力極大，同時需要時時聚合各資源位的實際情況，相對復(fù)雜，而后者則將實時信息通過db方式進(jìn)行交互，交由索引構(gòu)建后來感知稿件帶貨屬性，可以較為靈活控制。因此，整體的帶貨底層形成了下圖的標(biāo)準(zhǔn)交互模型。

圖片

上文提到，構(gòu)建帶貨屬性實時交互表，需要對各資源位下的帶貨情況分別統(tǒng)計聚合。而帶貨場景相對復(fù)雜，我們通過帶貨識別層的引入，如下圖，形成標(biāo)準(zhǔn)統(tǒng)一的帶貨屬性底表供實時訂閱，采用異步解耦，對于業(yè)務(wù)幾乎零入侵。對于引擎索引的構(gòu)建及業(yè)務(wù)效率均有顯著的正向提升，另外對于下游的算法、數(shù)據(jù)等依賴方提供了統(tǒng)一的判斷數(shù)據(jù)源，也完全解決了稿件帶貨動態(tài)的一致性問題。

圖片

平臺化治理

平臺化建設(shè)的過程中，整個平臺體系的穩(wěn)定性和健康度尤為重要。早期系統(tǒng)線上服務(wù)質(zhì)量較差，客訴相對較多，業(yè)務(wù)支撐的質(zhì)量無法有效衡量，特別是系統(tǒng)存在大量無效的報警，系統(tǒng)的穩(wěn)定性存在很大的挑戰(zhàn)，這也直接導(dǎo)致業(yè)務(wù)項目需求的交付質(zhì)量很難達(dá)預(yù)期，同時也需要投入額外的資源跟進(jìn)，交付效率受到很大影響。面對復(fù)雜快速的業(yè)務(wù)發(fā)展節(jié)奏，整個平臺體系的穩(wěn)定性保障與風(fēng)險治理成為當(dāng)前業(yè)務(wù)較大的矛盾，如何有效推進(jìn)平臺化治理方向尤為關(guān)鍵。

存儲穩(wěn)定性

帶貨業(yè)務(wù)的存儲早期相對混亂，歷史債務(wù)極重。一方面核心投放模型表和其他多個商業(yè)業(yè)務(wù)共庫共表，而這些單表已達(dá)近億條記錄，另一方面帶貨本身的業(yè)務(wù)表相對分散，部分散落在廣告業(yè)務(wù)庫。二者直接帶來的影響較大，億級表查詢常常會超時，同時頻繁讀寫，出現(xiàn)死鎖的概率相對較高，對線上業(yè)務(wù)系統(tǒng)造成相當(dāng)大的風(fēng)險，因此我們將存儲穩(wěn)定性作為首要治理的方向。

面臨兩個問題：其一，部分表和廣告業(yè)務(wù)庫參雜在一起；其二，近億級單表記錄的多業(yè)務(wù)查詢。問題一會受到廣告庫自身穩(wěn)定性影響，一旦廣告庫鏈接打滿，帶貨服務(wù)因散落在廣告庫的權(quán)限表、類目表等連接異常就會發(fā)生線上用戶故障。首先進(jìn)行db解耦，將廣告庫的數(shù)據(jù)預(yù)加載至緩存，每天reload一次，避免廣告庫的讀故障問題，另外將權(quán)限、類目等領(lǐng)域統(tǒng)一，逐步遷移至帶貨主庫，這樣徹底節(jié)解耦了與廣告庫的歷史關(guān)聯(lián)問題，將該類問題直接降為零。最麻煩的是問題二，億級核心表所涉業(yè)務(wù)相對較多，面臨兩個選擇：要么直接遷走，要么保留現(xiàn)狀。遷走將意味著上下游全部需要重新切換，涉及方極多，有限的資源和目標(biāo)完成時間風(fēng)險均太大，最后決定保留現(xiàn)狀治理。在全面分析大表后，從增量和存量兩個維度推進(jìn)。增量層面結(jié)合最大的業(yè)務(wù)增量記錄，發(fā)現(xiàn)部分歷史業(yè)務(wù)在野蠻生長，而該業(yè)務(wù)已基本停滯，拉齊產(chǎn)運研決定下線，使得降低了近20%的增量。存量層面進(jìn)行數(shù)據(jù)歸檔，我們按時間跨度分步推進(jìn)歸檔。系列的治理核心表數(shù)據(jù)量，如下所示，整體降低了50%多，容量倍降，使得db的查詢掃描記錄整體降低50%，平均查詢性能倍增，整個業(yè)務(wù)的服務(wù)體驗得到較大提升。

圖片

業(yè)務(wù)監(jiān)控體系

平臺的監(jiān)控能力是最基本的要求，早期帶貨業(yè)務(wù)體系，盡管有一些監(jiān)控報警，分布十分零散，大量無效的報警占比高達(dá)95%，基本可視為早期零監(jiān)控狀態(tài)。在業(yè)務(wù)體系的服務(wù)健康度和穩(wěn)定性基本無從感知的現(xiàn)狀下，提出了從0-1構(gòu)建業(yè)務(wù)平臺體系的監(jiān)控和預(yù)警能力。

采用什么方案進(jìn)行體系化建設(shè)成為最為關(guān)鍵的問題，在調(diào)研多種監(jiān)控方案后，結(jié)合B站本身的一些公共基建能力以及技術(shù)業(yè)務(wù)目標(biāo)訴求，我們決定不重復(fù)造輪子，選用了基于prometheus和grafana結(jié)合的數(shù)據(jù)監(jiān)控解決方案，其中prometheus架構(gòu)原理如下所示。這里面需要解決三件事情，通用埋點方式的建立，目標(biāo)數(shù)據(jù)的采集和展示，指標(biāo)定義和預(yù)警能力。

圖片

通用埋點如何解決？我們自定義了一套通用的埋點標(biāo)準(zhǔn)sdk，通過AOP方式實現(xiàn)日志數(shù)據(jù)的統(tǒng)一生產(chǎn)。數(shù)據(jù)的采集部分，通過prometheus采集組件對sdk的日志、接口、請求等統(tǒng)一收集。過程中我們發(fā)現(xiàn)，采集存儲到es的業(yè)務(wù)日志在數(shù)據(jù)量達(dá)到較高的狀態(tài)，無法百分百采集，可能會造成重要業(yè)務(wù)日志的丟失，因此我們首先將es存儲方式遷移至clickhouse存儲，整體的遷移極大降低了es的存儲成本，更重要的是保障了業(yè)務(wù)日志的全量性。展示維度指標(biāo)結(jié)合業(yè)務(wù)的需要，主要對商品中臺、服務(wù)調(diào)用、平臺應(yīng)用、異常日志、直播服務(wù)等核心模塊確定監(jiān)控指標(biāo)，包含服務(wù)RT、服務(wù)qps、錯誤率、調(diào)用量等如下所示。

圖片

圖片

根據(jù)對應(yīng)指標(biāo)，有效的報警機(jī)制對業(yè)務(wù)端相當(dāng)重要，否則會出現(xiàn)大量的無效報警，造成真正的問題被掩蓋，起不到預(yù)警的作用。針對核心的服務(wù)，進(jìn)行了分組并梯度劃分，按照不同的業(yè)務(wù)屬性如C端服務(wù)、B端服務(wù)、用戶讀寫等不同場景，分別通過RT組別、API錯誤數(shù)以及NPE數(shù)三個核心緯度進(jìn)行預(yù)警通知，如下規(guī)則所示。

圖片

業(yè)務(wù)監(jiān)控體系形成后，對于整體業(yè)務(wù)而言，有了系統(tǒng)體系化的健康指導(dǎo)，更重要的是提前發(fā)現(xiàn)了較多線上潛在的問題，為平臺體系問題的提前發(fā)現(xiàn)和干預(yù)以及后續(xù)的優(yōu)化方向提供了有力保障。

服務(wù)穩(wěn)定性

平臺體系的服務(wù)穩(wěn)定性，更多的是服務(wù)層面在tp99及tp95線的表現(xiàn)。一方面需要有足夠的qps承受性能，同時對服務(wù)的RT也有一定的要求。在監(jiān)控體系構(gòu)建后，觀測到整體服務(wù)的超時異常并不少，嚴(yán)重影響了用戶體驗和系統(tǒng)穩(wěn)定性。因此，針對該方向的治理，持續(xù)重點推進(jìn)。

在對tp95線的超時現(xiàn)象進(jìn)行統(tǒng)計分析后，主要集中在db慢查詢以及緩存失效兩個層面。慢查詢在存儲治理后得到了較大的改善，但是依然存在偶發(fā)現(xiàn)象。深究下來，業(yè)務(wù)多表join查詢以及索引失效的情況下，在并發(fā)操作的一些場景出現(xiàn)頻率明顯升高。因此，我們將索引問題和join慢查詢分別治理，對于前者，將所有大量復(fù)雜查詢均重新添加聯(lián)合索引，并不斷測試索引的命中情況不斷優(yōu)化。對于后者，進(jìn)行業(yè)務(wù)邏輯拆解，盡量保持單表索引查詢。治理完成后，整體的慢查詢問題得到相當(dāng)大程度的解決，基本由原來每天多case幾乎降至為零，查詢性能平均提升3倍，如下圖所示。

圖片

緩存失效的現(xiàn)象，主要是因歷史系統(tǒng)依賴的公共緩存集群內(nèi)存不足，時常超過整體的95%。另外老集群因機(jī)器原因，無法擴(kuò)容。更深入后，發(fā)現(xiàn)存在大量不合理的大key以及持久化的key，引起緩存濫用，致使內(nèi)存飽和，影響到業(yè)務(wù)對緩存的依賴。從兩個角度，針對大key刪除和優(yōu)化，針對持久化key增加合理的過期時間，最后統(tǒng)一遷移至新的帶貨緩存集群，整體的緩存容量從近乎95%的風(fēng)險值降低到平均30%的健康狀態(tài)。

圖片

圖片

特別在一些C端核心服務(wù)接口，通過db、緩存及服務(wù)本身的持續(xù)優(yōu)化推進(jìn)，tp95線超時率大大降低如下圖，評論種草API 優(yōu)化前后對比。同時，平臺體系的服務(wù)穩(wěn)定性顯著倍增。

圖片

決策平衡

在帶貨體系平臺化建設(shè)推進(jìn)過程中，因整體業(yè)務(wù)發(fā)展太快，近一年來，業(yè)務(wù)增量較大，無論是投流收入、帶貨gmv還是帶貨up的活躍情況均呈現(xiàn)出極大的增長趨勢，如下圖所示。

圖片

面對極速的業(yè)務(wù)增勢，在有限且緊張的人力情況下，通常情況下，決策的主要矛盾就凸顯出來。一方面需要保障業(yè)務(wù)項目需求的快節(jié)奏推進(jìn)達(dá)成業(yè)務(wù)目標(biāo)，同時還需要投入額外的資源消化歷史的技術(shù)債以及應(yīng)對線上相當(dāng)多的客訴問題，另一方面平臺體系化的建設(shè)已刻不容緩，如果僅僅只是支撐需求而不全面規(guī)劃并推進(jìn)技術(shù)各層面能力建設(shè)，一段時間后將很可能沒法支持業(yè)務(wù)的發(fā)展訴求。所以我們在實際的過程中，面對業(yè)務(wù)的超量需求，如何保障業(yè)務(wù)項目支撐同時去平衡技術(shù)方向的決策，成為技術(shù)側(cè)較大的挑戰(zhàn)。

從一開始我們就確定了多線推進(jìn)的策略，大方向以業(yè)務(wù)目標(biāo)保障為優(yōu)先，技術(shù)優(yōu)化并行。但如何并行？我們按照全局架構(gòu)和局部改造的方式，分別決策了監(jiān)控體系、商品中臺、平臺能力、服務(wù)治理等核心方向，先確定每個子方向的階段性技術(shù)推進(jìn)目標(biāo)后，結(jié)合業(yè)務(wù)的節(jié)奏，尋找契機(jī)穿插并行推進(jìn)。如直播選品融合業(yè)務(wù)項目同時啟動商品中臺商品域模型改造，如評論帶貨業(yè)務(wù)項目中并行啟動了接口穩(wěn)定性治理等技術(shù)項目。這樣，在大的構(gòu)架及整體技術(shù)方向上，結(jié)合更多的業(yè)務(wù)項目，客服資源和交付周期等因素影響，進(jìn)行子模塊和實際業(yè)務(wù)需求的抽象和統(tǒng)一，形成底層能力，并在技術(shù)層面0-1落地。

經(jīng)過近一年來并行推近重點技術(shù)項目的建設(shè)，整體業(yè)務(wù)的支撐效率很好的實現(xiàn)了倍增，如渠道商品標(biāo)準(zhǔn)化接入專項的落地，業(yè)務(wù)的開發(fā)周期從早期的46人日降低至5人日，交付質(zhì)量也顯著大大提升，如線上問題case數(shù)從早期日均3個以上幾乎降低至零。從早期幾乎無法支撐的業(yè)務(wù)服務(wù)化開發(fā)狀態(tài)，不斷持續(xù)地平衡業(yè)務(wù)和技術(shù)雙線推進(jìn)決策，已經(jīng)具備較好業(yè)務(wù)體系平臺化的能力，整體的支撐效率及交付質(zhì)量在一定程度上很好滿足了階段性的業(yè)務(wù)發(fā)展需求，但對于后續(xù)的業(yè)務(wù)體量和增速，仍然存在一定的挑戰(zhàn)。

未來演進(jìn)

帶貨體系平臺化的建設(shè)，從歷史債務(wù)嚴(yán)重的耦合性系統(tǒng)開始，結(jié)合帶貨業(yè)務(wù)生態(tài)體系，階段性決策了平臺加小中臺的平臺體系化建設(shè)方向，搭建并落地了整體的平臺化架構(gòu)。首先從0到1探索并構(gòu)建了公司級商品中臺，徹底解決貨從哪里來的問題，為帶貨提供源頭支撐。其次抽象業(yè)務(wù)模型，沉淀業(yè)務(wù)能力，建立了人貨場的平臺撮合能力，解決貨怎么帶的問題。接著在貨怎么出的問題層面，一方便依賴帶貨引擎和廣告引擎的通路，另一方面逐步建立底層交互模型的標(biāo)準(zhǔn)和統(tǒng)一，為自然流量和商業(yè)流量的出貨問題建立穩(wěn)定高效的交互機(jī)制。最后進(jìn)行平臺化的治理，以平臺的穩(wěn)定性為目標(biāo)，0到1建立帶貨業(yè)務(wù)監(jiān)控預(yù)警體系，同時全面治理業(yè)務(wù)存儲和持續(xù)優(yōu)化服務(wù)穩(wěn)定性，為整個系統(tǒng)的質(zhì)量和健康度提供了較大保障。盡管當(dāng)前平臺化已取得了較為顯著的成果，但目前僅僅只是完成了從0到1這個階段的建設(shè)，相對市場競對，未來的演進(jìn)之路依然漫長。如何從1到n？如何更好支撐未來百億級gmv及高速增長的營收目標(biāo)，還有相當(dāng)大的困難與挑戰(zhàn)，還有相當(dāng)多的方向需要持續(xù)投入深入建設(shè)與探索。

1. 業(yè)務(wù)網(wǎng)關(guān)、數(shù)據(jù)中心、業(yè)務(wù)能力如統(tǒng)一投放能力等目前還較薄弱，未來圖文帶貨、數(shù)據(jù)參謀等較多的業(yè)務(wù)發(fā)展更需要逐步深入建設(shè)；
2. 商品中臺將會面對從百萬級向千萬級的演變，如何更高效的通用性接入和精選聯(lián)盟等業(yè)務(wù)應(yīng)用以及搜品推品能力的支撐，也將需要更可靠和更穩(wěn)定的中臺基礎(chǔ)支撐；
3. 業(yè)務(wù)中臺化的領(lǐng)域模型演進(jìn)與探索，以及底層業(yè)務(wù)交互模型以及開閉環(huán)歸因領(lǐng)域也需有更高的要求和演進(jìn)；
4. 從1到n的系統(tǒng)穩(wěn)定性建設(shè)也將持續(xù)思考和不斷推進(jìn)落地，加速拉齊在重要領(lǐng)域與行業(yè)競對的差距，持續(xù)實現(xiàn)平臺體系的高可用、高性能、可擴(kuò)展等現(xiàn)存及潛在的諸多問題。

本期作者

周植宇嗶哩嗶哩資深開發(fā)工程師