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