帶貨業務體系平臺化建設與探索
背景
帶貨作為近年來一種新興、高效的營銷形式，在商業側最早以耦合在必選和邀約廣告的業務形態中存在，直到22年中開始作為明確的業務探索方向。從初步確定帶貨業務的基本定位，到短短的一年多時間，業務極速發展，無論是帶貨up數還是帶貨收益以及平臺收益層面，均有較快的增長，到目前已形成初具規模的業務體量。期間對于技術側而言，面對相當多的困難，特別是在幾乎無任何基礎無獨立系統的歷史狀況下，如何構建高效穩定的平臺體系去支撐帶貨業務的快速迭代和發展需求，存在極大的挑戰。
現狀與問題
業務場景
帶貨屬于典型的人貨場型業務，對于B站而言，其場景相對較多且交互復雜，包含視頻、圖文、直播等十幾種公私域不同場景。要實現從內容到種草的轉化，構建用戶交易心智和構建良性帶貨電商生態的目標，早期的系統完全無法支持。
圖片
問題分析
早期的帶貨核心服務，均耦合在最早的商業互選業務中，僅存在最基本的帶貨流程，業務產品的需求支持幾乎也只能串行對接。面對幾乎負向的現存系統，多涉及最基礎的需求開發，對于相對復雜的項目支持，難度較大，很難有效支撐。究其核心原因，在于業務領域不清晰，采用面向需求開發的方式，抱著能用即可的態度與目標，導致系統耦合嚴重，極其混亂，缺乏整體的方案設計。
在該狀態下，面對帶貨業務突然的強勢增長，產研形成了相對較大的矛盾沖突，開發效率低，業務支撐難，交付質量差，是當時幾代解決的問題。如何徹底解決這些風險與挑戰？從研發視角來看，需要考慮四個維度的綜合平衡：基礎建設、平臺能力、統一標準、成本效率。基于業務目標與研發現狀，全面梳理所有涉及帶貨的服務與接口后，我們提出平臺化的整體解決方案。由當前技術債重的業務系統快速向平臺化演進，從0到1進行帶貨業務體系平臺化的全面建設。
平臺架構
帶貨業務核心涉及到貨端、人端以及應用場景端， 整個平臺體系化的建設需要充分兼容通用場景，支撐好業務構建和關鍵能力建設，最重要的是從業務本身出發，需要回答幾個關鍵問題：業務場景是什么？平臺解決誰的問題？平臺能力如何聚合，邊界如何清晰定義？在全面分析帶貨業務域及業務目標基礎上，從最初的煙囪式交叉服務，設計了如圖方向的平臺體系化架構。
圖片
在該平臺架構全景中，其本質需要解決帶貨業務體系中的幾大核心問題和關鍵業務構建及業務能力
- 貨從哪里來？由商品中臺體系支撐
- 貨要怎么帶？由帶貨平臺能力來支持
- 貨要怎么管？由運營平臺能力支撐
- 貨該怎么出？由帶貨引擎/廣告引擎聯合支撐
- 人貨場如何聯動？由標準帶貨鏈路（人端/貨端/數據端/算法）整體解決
針對這些核心問題，從系統分層、模型領域分解、標準化交互協議等層面，進行了帶貨平臺技術架構的全面設計，整體方案如下圖。如何在早期技術債較重的狀態下，一步步從0-1推進帶貨業務體系平臺化的建設，將在下文中逐一介紹。
圖片
平臺建設
確立了體系化的建設目標后，我們不再從單一的用戶視角或需求視角去思考，而是結合平臺化視角去看整體的帶貨業務體系。在業務的快速推進過程中，如何快速落地整體方案的核心模塊，快速轉化為生產力，尤為重要。在建設過程中，需要支撐現有業務的迭代，我們采取業務技術雙驅動的方式，對帶貨領域模型進行分解，將人端、貨端、流量端的核心能力進行抽象聚合，確立建設和決策四大核心方向的路徑，主要包括商品中臺、平臺能力、交互模型、平臺化治理等，核心解決平臺的業務交付效率和系統質量等問題。
商品中臺
在帶貨業務體系中，商品域是貨端的核心域，貨品作為業務源頭，其重要性不言而喻。早期系統幾乎缺失了商品層概念，只是通過簡單API方式去調用開環渠道淘寶以及公司內閉環渠道（會員購、工房等）的商品服務，和帶貨主體、帶貨行為全部耦合在一起，就開發本身而言，每新增一種商品類型或接入一種商品渠道，整個流程均需要改動，風險高開發周期長，完全無法滿足業務的期望，如何解決通用的貨端能力成為急需解決的問題。
從業務本身出發，我們決定從0-1搭建商品中臺，構建帶貨體系的貨品供應中臺服務能力，全面解決貨從哪來以及貨到哪里去的問題。該中臺和傳統意義的商品中臺差別很大，非傳統的貨架概念。就B站而言，絕大部分貨品來源于頭部電商生態，另一部分主要是B站內部的電商商品，帶貨場景的貨端中臺不需要關注商品供應鏈層面，更需要關注的是渠道的復雜性與多樣性及公司級商品服務能力。
圖片
這里面有幾個難點需要解決：如何快速高效接入貨品渠道？怎樣抽象并構建商品域底層模型？商品庫零故障遷移及一致性如何保障？
渠道方案
貨品渠道的快速接入對于直播帶貨、視頻帶貨及廣告帶貨等場景相當重要，通過對接不同電商渠道聯盟及企業內部渠道，提供帶貨貨源商品池。而在早期的鏈路中，接入每個渠道（如京東、淘寶等）均需定制化接入個性化處理，對接成本高，維護相對難，規則較混亂，貨品校驗缺失，臟數據易混淆，邏輯無分層，極其影響業務穩定及效率。因此接入生態媒體（京東、淘寶等）和接入內部電商商品（會員購、工房等）的通用化解決方案尤為重要，直接決定了在業務需求進展中的推進效率。基于此，在商品渠道的接入過程，我們提出了動態配置的貨品渠道接入方案，整體架構如下所示。
圖片
該方案將不同的貨品渠道抽象成不同的供給端，按照數據流方式進行校驗、加工、標準化存儲。在實際工程實踐中如下圖，建立渠道工廠（factory）通過渠道配置組件（channelConfig）建立不同渠道源的商品數據連接行為，再經過校驗器（validater）、轉換裝飾器（convertor）標準化商品數據，按照設計的實體模型完成商品庫的存儲。
圖片
模型及存儲
商品實體模型該如何設計，直接關系到商品中臺讀寫服務的基礎能力。早期的讀寫均采用es作為存儲，問題很多，讀寫混亂，無法對業務事務進行回滾，拓展性幾乎為零，維護成本也相對較高。核心原因就在于商品庫的讀寫模型幾乎是無約束式的增刪，缺乏領域模型，為解決此問題，進行了全面的改造，以商品核心表、商品拓展表、商品應用表、商品貨架表為核心模型承載，構建了商品庫底層基本領域模型如下。
圖片
從簡單的商品屬性線性關系存儲方式到領域化的升級，最大的問題就是商品庫的存儲，一方面需要考慮存量異構，另一方面需要考慮數據一致性問題。首先，對于es的存量數據，進行底層模型的重構，寫入mysql業務模型表，考慮到商品的搜索性能，通過訂閱binlog構建商品索引庫，提供商品讀寫分離的能力，如圖所示。
圖片
但這又帶來了新的問題，在強一致性讀的商品場景中，如在變更商品別名保存后，因為binlog消費的延時等原因，會導致用戶體驗不一致的問題。因此對于強一致性讀直接讀取mysql表，對實時要求不高的場景或搜索場景直接由索引庫提供。另外mysql同步至es索引也有可能出現數據不一致，一方面通過retry和死信隊列來異步保障寫失敗導致的不一致，另一方面通過引入對賬機制進行小時級和天級對賬補償保障。而在實際過程中，實現了零故障的商品數據模型遷移。在整體改造后，實現了具備讀寫分離、事務控制、獨立模型的拓展性高的商品庫，成為整個商品中臺的底層模型和穩定性存儲。
平臺能力
平臺能力是平臺化建設的重中之重，核心解決貨怎么帶的問題，負責支撐帶貨業務平臺的所有核心能力，如自然帶貨、投流帶貨、直播帶貨所有服務應用及能力輸出。早期的服務，和其他業務基本都是耦合在一起，僅提供了帶貨的基本鏈路，缺乏業務能力沉淀，特別是多個應用相互依賴，相當混亂，如圖所示。這直接導致了很多問題和沖突，需求支持效率極低，開發上線風險很高，交付質量也難以符合業務預期，難以滿足業務的快速發展。
圖片
為徹底解決系統幾乎為零的平臺化能力，結合業務本身和發展的情況，就業務能力進行全面的聚合分析。首先從帶貨鏈路看，在保障了商品源頭的供給，關鍵在于人貨場的建立，即對up主、貨品及場景的撮合，來解決人端、貨端的聯動，如下圖業務的撮合途徑和業務底層能力訴求。
圖片
如何構建對應的平臺能力去支撐人貨的撮合？這是需要急待解決的重要問題。一方面從系統本身出發，對于歷史債進行全面的模塊化梳理，整合核心的業務能力和通用的基礎服務，明確各系統應用的上下文邊界。同時，對于帶貨系統核心應用建立統一的分層架構規范（包含client/service/common/starter）如下圖核心業務層規范，徹底解決歷史應用間調用混亂，相互依賴的問題。
圖片
另一方面，從業務領域考慮，進一步抽象核心能力，建立帶貨平臺底層模型，包括權限模型、投放模型、結算模型、pid模型，數據模型等，從投流帶貨、視頻帶貨、直播帶貨、社區種草等場景，全面構建平臺化投放帶貨能力，支撐復雜場景以及多用戶不同形態的帶貨需求，如下圖所示，從0-1逐步系統化建立的業務平臺能力。
圖片
交互模型
平臺能力除了業務場景的支撐需要，更要考慮如何高效穩定支撐帶貨底層數據的交互。帶貨引擎，解決貨怎么出的問題，支撐帶貨投放的索引構建能力及C端（評論/視頻）廣告檢索端的服務交互能力，同時負責帶貨業務服務針對主站的透出。早期的帶貨引擎利用廣告引擎建立了基本的鏈路，但和業務底層耦合嚴重，需要訂閱大量的底層數據表，引擎的構建效率和業務整體支撐效率較差。交互模型鏈接了帶貨的關鍵通路，業務模型的解耦與重構，尤為重要。
一方面考慮到歷史其他業務在稿件投放維度的交互方式，另一方面為后續圖文投放帶貨標準化交互方式，因此，我們把稿件類（框下、浮層、彈幕）、圖文類（評論、專欄、動態等）分別作為最基礎的交互模型。但是，當各個資源位上的帶貨稿件發生變更時，稿件的帶貨屬性也會發生動態變化，而這一變化引擎無法實時感知，就會出現非帶貨稿件的錯誤分發。有兩種解決方案，要么是建立實時稿件屬性API方式，要么構建帶貨屬性實時交互表，前者直接提供C端的大流量實時請求，對于API的壓力極大，同時需要時時聚合各資源位的實際情況，相對復雜，而后者則將實時信息通過db方式進行交互，交由索引構建后來感知稿件帶貨屬性，可以較為靈活控制。因此，整體的帶貨底層形成了下圖的標準交互模型。
圖片
上文提到，構建帶貨屬性實時交互表，需要對各資源位下的帶貨情況分別統計聚合。而帶貨場景相對復雜，我們通過帶貨識別層的引入，如下圖，形成標準統一的帶貨屬性底表供實時訂閱，采用異步解耦，對于業務幾乎零入侵。對于引擎索引的構建及業務效率均有顯著的正向提升，另外對于下游的算法、數據等依賴方提供了統一的判斷數據源，也完全解決了稿件帶貨動態的一致性問題。
圖片
平臺化治理
平臺化建設的過程中，整個平臺體系的穩定性和健康度尤為重要。早期系統線上服務質量較差，客訴相對較多，業務支撐的質量無法有效衡量，特別是系統存在大量無效的報警，系統的穩定性存在很大的挑戰，這也直接導致業務項目需求的交付質量很難達預期，同時也需要投入額外的資源跟進，交付效率受到很大影響。面對復雜快速的業務發展節奏，整個平臺體系的穩定性保障與風險治理成為當前業務較大的矛盾，如何有效推進平臺化治理方向尤為關鍵。
存儲穩定性
帶貨業務的存儲早期相對混亂，歷史債務極重。一方面核心投放模型表和其他多個商業業務共庫共表，而這些單表已達近億條記錄，另一方面帶貨本身的業務表相對分散，部分散落在廣告業務庫。二者直接帶來的影響較大，億級表查詢常常會超時，同時頻繁讀寫，出現死鎖的概率相對較高，對線上業務系統造成相當大的風險，因此我們將存儲穩定性作為首要治理的方向。
面臨兩個問題：其一，部分表和廣告業務庫參雜在一起；其二，近億級單表記錄的多業務查詢。問題一會受到廣告庫自身穩定性影響，一旦廣告庫鏈接打滿，帶貨服務因散落在廣告庫的權限表、類目表等連接異常就會發生線上用戶故障。首先進行db解耦，將廣告庫的數據預加載至緩存，每天reload一次，避免廣告庫的讀故障問題，另外將權限、類目等領域統一，逐步遷移至帶貨主庫，這樣徹底節解耦了與廣告庫的歷史關聯問題，將該類問題直接降為零。最麻煩的是問題二，億級核心表所涉業務相對較多，面臨兩個選擇：要么直接遷走，要么保留現狀。遷走將意味著上下游全部需要重新切換，涉及方極多，有限的資源和目標完成時間風險均太大，最后決定保留現狀治理。在全面分析大表后，從增量和存量兩個維度推進。增量層面結合最大的業務增量記錄，發現部分歷史業務在野蠻生長，而該業務已基本停滯，拉齊產運研決定下線，使得降低了近20%的增量。存量層面進行數據歸檔，我們按時間跨度分步推進歸檔。系列的治理核心表數據量，如下所示，整體降低了50%多，容量倍降，使得db的查詢掃描記錄整體降低50%，平均查詢性能倍增，整個業務的服務體驗得到較大提升。
圖片
業務監控體系
平臺的監控能力是最基本的要求，早期帶貨業務體系，盡管有一些監控報警，分布十分零散，大量無效的報警占比高達95%，基本可視為早期零監控狀態。在業務體系的服務健康度和穩定性基本無從感知的現狀下，提出了從0-1構建業務平臺體系的監控和預警能力。
采用什么方案進行體系化建設成為最為關鍵的問題，在調研多種監控方案后，結合B站本身的一些公共基建能力以及技術業務目標訴求，我們決定不重復造輪子，選用了基于prometheus和grafana結合的數據監控解決方案，其中prometheus架構原理如下所示。這里面需要解決三件事情，通用埋點方式的建立，目標數據的采集和展示，指標定義和預警能力。
圖片
通用埋點如何解決？我們自定義了一套通用的埋點標準sdk，通過AOP方式實現日志數據的統一生產。數據的采集部分，通過prometheus采集組件對sdk的日志、接口、請求等統一收集。過程中我們發現，采集存儲到es的業務日志在數據量達到較高的狀態，無法百分百采集，可能會造成重要業務日志的丟失，因此我們首先將es存儲方式遷移至clickhouse存儲，整體的遷移極大降低了es的存儲成本，更重要的是保障了業務日志的全量性。展示維度指標結合業務的需要，主要對商品中臺、服務調用、平臺應用、異常日志、直播服務等核心模塊確定監控指標，包含服務RT、服務qps、錯誤率、調用量等如下所示。
圖片
圖片
根據對應指標，有效的報警機制對業務端相當重要，否則會出現大量的無效報警，造成真正的問題被掩蓋，起不到預警的作用。針對核心的服務，進行了分組并梯度劃分，按照不同的業務屬性如C端服務、B端服務、用戶讀寫等不同場景，分別通過RT組別、API錯誤數以及NPE數三個核心緯度進行預警通知，如下規則所示。
圖片
業務監控體系形成后，對于整體業務而言，有了系統體系化的健康指導，更重要的是提前發現了較多線上潛在的問題，為平臺體系問題的提前發現和干預以及后續的優化方向提供了有力保障。
服務穩定性
平臺體系的服務穩定性，更多的是服務層面在tp99及tp95線的表現。一方面需要有足夠的qps承受性能，同時對服務的RT也有一定的要求。在監控體系構建后，觀測到整體服務的超時異常并不少，嚴重影響了用戶體驗和系統穩定性。因此，針對該方向的治理，持續重點推進。
在對tp95線的超時現象進行統計分析后，主要集中在db慢查詢以及緩存失效兩個層面。慢查詢在存儲治理后得到了較大的改善，但是依然存在偶發現象。深究下來，業務多表join查詢以及索引失效的情況下，在并發操作的一些場景出現頻率明顯升高。因此，我們將索引問題和join慢查詢分別治理，對于前者，將所有大量復雜查詢均重新添加聯合索引，并不斷測試索引的命中情況不斷優化。對于后者，進行業務邏輯拆解，盡量保持單表索引查詢。治理完成后，整體的慢查詢問題得到相當大程度的解決，基本由原來每天多case幾乎降至為零，查詢性能平均提升3倍，如下圖所示。
圖片
緩存失效的現象，主要是因歷史系統依賴的公共緩存集群內存不足，時常超過整體的95%。另外老集群因機器原因，無法擴容。更深入后，發現存在大量不合理的大key以及持久化的key，引起緩存濫用，致使內存飽和，影響到業務對緩存的依賴。從兩個角度，針對大key刪除和優化，針對持久化key增加合理的過期時間，最后統一遷移至新的帶貨緩存集群，整體的緩存容量從近乎95%的風險值降低到平均30%的健康狀態。
圖片
圖片
特別在一些C端核心服務接口，通過db、緩存及服務本身的持續優化推進，tp95線超時率大大降低如下圖，評論種草API 優化前后對比。同時，平臺體系的服務穩定性顯著倍增。
圖片
決策平衡
在帶貨體系平臺化建設推進過程中，因整體業務發展太快，近一年來，業務增量較大，無論是投流收入、帶貨gmv還是帶貨up的活躍情況均呈現出極大的增長趨勢，如下圖所示。
圖片
面對極速的業務增勢，在有限且緊張的人力情況下，通常情況下，決策的主要矛盾就凸顯出來。一方面需要保障業務項目需求的快節奏推進達成業務目標，同時還需要投入額外的資源消化歷史的技術債以及應對線上相當多的客訴問題，另一方面平臺體系化的建設已刻不容緩，如果僅僅只是支撐需求而不全面規劃并推進技術各層面能力建設，一段時間后將很可能沒法支持業務的發展訴求。所以我們在實際的過程中，面對業務的超量需求，如何保障業務項目支撐同時去平衡技術方向的決策，成為技術側較大的挑戰。
從一開始我們就確定了多線推進的策略，大方向以業務目標保障為優先，技術優化并行。但如何并行？我們按照全局架構和局部改造的方式，分別決策了監控體系、商品中臺、平臺能力、服務治理等核心方向，先確定每個子方向的階段性技術推進目標后，結合業務的節奏，尋找契機穿插并行推進。如直播選品融合業務項目同時啟動商品中臺商品域模型改造，如評論帶貨業務項目中并行啟動了接口穩定性治理等技術項目。這樣，在大的構架及整體技術方向上，結合更多的業務項目，客服資源和交付周期等因素影響，進行子模塊和實際業務需求的抽象和統一，形成底層能力，并在技術層面0-1落地。
經過近一年來并行推近重點技術項目的建設，整體業務的支撐效率很好的實現了倍增，如渠道商品標準化接入專項的落地，業務的開發周期從早期的46人日降低至5人日，交付質量也顯著大大提升，如線上問題case數從早期日均3個以上幾乎降低至零。從早期幾乎無法支撐的業務服務化開發狀態，不斷持續地平衡業務和技術雙線推進決策，已經具備較好業務體系平臺化的能力，整體的支撐效率及交付質量在一定程度上很好滿足了階段性的業務發展需求，但對于后續的業務體量和增速，仍然存在一定的挑戰。
未來演進
帶貨體系平臺化的建設，從歷史債務嚴重的耦合性系統開始，結合帶貨業務生態體系，階段性決策了平臺加小中臺的平臺體系化建設方向，搭建并落地了整體的平臺化架構。首先從0到1探索并構建了公司級商品中臺，徹底解決貨從哪里來的問題，為帶貨提供源頭支撐。其次抽象業務模型，沉淀業務能力，建立了人貨場的平臺撮合能力，解決貨怎么帶的問題。接著在貨怎么出的問題層面，一方便依賴帶貨引擎和廣告引擎的通路，另一方面逐步建立底層交互模型的標準和統一，為自然流量和商業流量的出貨問題建立穩定高效的交互機制。最后進行平臺化的治理，以平臺的穩定性為目標，0到1建立帶貨業務監控預警體系，同時全面治理業務存儲和持續優化服務穩定性，為整個系統的質量和健康度提供了較大保障。盡管當前平臺化已取得了較為顯著的成果，但目前僅僅只是完成了從0到1這個階段的建設，相對市場競對，未來的演進之路依然漫長。如何從1到n？如何更好支撐未來百億級gmv及高速增長的營收目標，還有相當大的困難與挑戰，還有相當多的方向需要持續投入深入建設與探索。
- 業務網關、數據中心、業務能力如統一投放能力等目前還較薄弱，未來圖文帶貨、數據參謀等較多的業務發展更需要逐步深入建設；
- 商品中臺將會面對從百萬級向千萬級的演變，如何更高效的通用性接入和精選聯盟等業務應用以及搜品推品能力的支撐，也將需要更可靠和更穩定的中臺基礎支撐；
- 業務中臺化的領域模型演進與探索，以及底層業務交互模型以及開閉環歸因領域也需有更高的要求和演進；
- 從1到n的系統穩定性建設也將持續思考和不斷推進落地，加速拉齊在重要領域與行業競對的差距，持續實現平臺體系的高可用、高性能、可擴展等現存及潛在的諸多問題。
本期作者
周植宇嗶哩嗶哩資深開發工程師
