實時計算助力1688打造「實時挑貨」系統

摘要： 一、背景 內容是一個電商app不可或缺的組成部分。越來越多的人會使用碎片時間瀏覽手機app的內容，包含導購的帖子、短視訊、直播等。1688挑貨業務，打造了基於買家和商家之間老買賣關係的內容場。讓商家通過內容維繫老客戶，挖掘新客戶。讓買家能第一時間獲取到關注商家的上新、優惠、直播等資訊，為自...

一、背景

內容是一個電商app不可或缺的組成部分。越來越多的人會使用碎片時間瀏覽手機app的內容，包含導購的帖子、短視訊、直播等。1688挑貨業務，打造了基於買家和商家之間老買賣關係的內容場。讓商家通過內容維繫老客戶，挖掘新客戶。讓買家能第一時間獲取到關注商家的上新、優惠、直播等資訊，為自己的採購等決策提供幫助。

從巨集觀的背景分析，挑貨業務有以下幾個特點：

1. 基於1688的老買賣關係: 關注關係、客戶會員關係、星標關係、分銷關係

2. 內容的產生源頭是供應商，供應商在1688網站的各種行為，都可以轉變成內容資訊

3. 內容的消費源頭是供應商的老買家(與供應商有老買賣關係)

4. 內容形式比較多樣：帖子、營銷活動、店鋪上新、商家動態、直播、短視訊等一系列商家產生的有效內容

5. 內容產生形式：供應商的主動行為、供應商的被動行為

基於上面的業務特點，我們梳理下挑貨整體的業務架構。

二、業務框架

• 供應商在1688網站可以直接將動態和文章釋出到挑貨。

• 供應商在1688網站的直播、店鋪上新、報名營銷活動、邀約客戶等行為，會被挑貨服務識別到，被動抓取到挑貨。

• 挑貨將供應商產生的內容推送到供應商老買賣關係的買家收件箱中。

• 買家訪問挑貨時，挑貨服務會從買家收件箱中將內容渲染成各種業務卡片，呈現到客戶手機端。

• 買家可以對部分有時效性的內容（直播預告、未開始的互動）設定訂閱提醒，當直播開始、活動開始時，挑貨服務主動通過訊息告知買家。

• 買家可以通過挑貨平臺去到供應商的店鋪和商品詳情去購買商品，產生交易訂單。

• 挑貨中的優質內容，可以投放到1688網站的其他模組，新使用者看到後，能有效的產生交易和關係轉化。

• 新使用者訪問挑貨時，挑貨服務會推薦部分優質供應商給使用者，使用者可以關注供應商，看到供應商的挑貨內容。

挑貨的業務價值在於可以維繫供應商的老買賣關係，提供買家快速獲取供應商資訊的內容，另外可以為供應商引入新的客戶，並沉澱為老買賣關係。而挑貨的優質內容可以投放到1688網站公域頻道，一方面節省運營成本，另一方面為供應商引入更多的新使用者。挑貨在1688公域、私域流轉上承擔著樞紐的作用。

三、技術框架

為了實現挑貨的業務架構，在1688無線領域孵化出多個技術方案。下面就其中關鍵的技術細節進行下描述。

挑貨總架構圖

• 業務對接方式：離線任務、訊息對接、實時rpc

• feeds流的推拉引擎：feeds動態生成器、feeds的收件箱推送、架構圖未包含非活躍使用者走拉的模式、feeds流查詢服務

• 動態元件的對接方案Cybert：業務模型和元件UI分離、動態生成native元件

• 個性化演算法對接方案（未包含）

• 異構系統的監控體系（未包含）：多種中介軟體平臺實現同一個業務時，異構系統的監控成為一大難題。在挑貨中，已經設計出了方案，目前正在對接中。

• 資料統計系統

1. feeds流推拉結合的引擎

挑貨的內容從供應商產生，到供應商的買家去消費，是典型的feeds場景。實現一個feeds流業界比較流行的主要是推模式、拉模式、或者是推拉結合的模式。

推模式：內容產生後，會為每一個訂閱內容的粉絲複製一份內容，放入粉絲獨有的收件箱中。

• 優點：粉絲讀取內容非常快，只是一個表查詢。在寫的過程中可以做很多業務干預。

• 缺點：寫的成本比較高，需要很多耗費儲存，資料冗餘。

拉模式：內容產生後，只會存入內容產生者的發件箱。讀取時，需要粉絲讀取每一個被關注使用者的發件箱，實時將內容聚合到一起排序，最終展現給粉絲。

• 優點：儲存耗費少，寫入速度快。

• 缺點：查詢都需要耗費很多計算資源做內容聚合，業務干預規則多時，會更加加重查詢複雜度，查詢效能會下降。

推拉模式：綜合推模式、拉模式的優缺點使用的方案。

我們從挑貨業務的特點和已有的技術積累兩個方面，選取了推拉結合，以推為主、拉為輔的技術方案。

• 1688有獨立的關係團隊維護了1688所有的老買賣關係資料，已經成為1688底層基礎服務。而微淘的關係和微淘的內容之前是在一個團隊孵化出來的。目前1688關係是B類的老買賣關係，和淘系的關係沒有打通。基於老買賣關係的挑貨不能直接複用微淘關係的技術。

• 微淘開發的timeline的拉引擎，使用多級快取，很好的支援了微淘業務的發展，在feeds流拉模式上有很強的專業性。而集團搜尋團隊的igraph圖資料引擎也能很好支援資料多維度拉取功能。igraph有詳細的文件、成體系化的接入和運維方案、專業的答疑。從對接的成本和後期運維角度，我們選擇了igraph作為拉引擎。

• 選擇以推為主，拉為輔的策略的原因：

  1. 資料規模比較小：1688的老買賣關係總量在4億，一個粉絲比較多的供應商的粉絲數量級在幾十萬，而在挑貨頻道活躍的粉絲，對應一個供應商量級在5萬以下。更多的在幾百到上千。所以這種量級的資料，使用推模式能很好的支援查詢效能。

  2. 集團的中介軟體平臺非常成熟：在blink平臺開發feeds流的收件箱推送功能，能根據資料規模擴縮容資源，有效的支援大規模資料的推送。tablestore是一個單表支援10PB資料的nosql，作為挑貨買家收件箱非常合適。

  3. 業務的規則干預比較多：需要支援遮蔽動態這樣干預feeds展現的業務規則。

• 內容資料流入動態生成器，產生挑貨feeds，挑貨feeds生成後傳送metaq訊息，被執行在blink上推送任務監聽到，將動態索引寫入到使用者到收件箱。

下面3張比較細節的圖：

1. 活躍使用者-推模式

   

   2.非活躍使用者-拉模式

   

   3.非活躍使用者啟用策略

   

2. 動態元件的對接方案Cybert

Feeds列表原有純native的技術解決方案，對業務的核心痛點就在於發版週期和覆蓋率的限制；1. 半個月的發版週期嚴重限制了業務日常營銷活動、使用者活躍提升的運作方式，業務更希望營銷類的活動卡片做到快上快下，不跟隨發版節奏；2. 純native卡片還是依託與發版，新的營銷活動為了達到最佳效果，還期望於版本的覆蓋率，雖然目前安卓、ios的新版本覆蓋週期已經越來越短，但不代表可以做到像weex一樣立馬全版本覆蓋。

鑑於這些業務痛點，我們可以採用的技術方案有兩種1. 全weex化；2. native動態化。先從weex化來說起，去年整個營銷場在整體完成效能優化後，我們已經做到ios95%會場秒開，安卓超過85%，這個秒開率對於挑貨feeds來說已經足夠。但當時沒有采用全weex化的方案更多出於以下幾點考慮：1. 互動或者後期的tabview支援，挑貨feeds作為第二個主tab效能、互動、穩定性都必須去強保證，會場一些tab切換層面我們可以接受刷頁面的方案，但在核心主tab我們還希望做到更佳的使用者體驗；2. 改造成本，原有native卡片化的方式，如果整體切換就意味這頁面全部重做，這個改造成本不小。因此，我們考慮是否可以把應用在首頁、工作臺的native動態元件化方案做能力擴充套件，支援類似挑貨這類列表元件由“資料驅動ui”的渲染方式，老卡片仍然採用native方案，新元件採用dinamic元件插入，既做到老方案相容，有做到新元件動態釋出。在技術改造成本、動態性、業務支撐、互動體驗多個點上做平衡。

這裡，我先簡單介紹下目前首頁cyber動態元件化方案的業務價值、技術架構和能力。CyberT原生孵化於首頁，核心點就是native元件化方案，後續因為業務對於動態效能力的要求，支援了weex元件、dinamic元件的擴充套件，兩個動態化元件化方案看dinamic元件在首頁的效能從渲染耗時、記憶體開銷上更優。由服務端下發頁面佈局協議、元件ui協議、服務端資料協議來驅動端上的渲染，同時在ui協議上打平後可以做到元件單端投入雙端生效，後續也在進一步支援h5外投方案。

而對於feeds列表的場景，我們如何升級能力做到“資料驅動ui”？這主要是升級List複雜容器的支援，list元件的特點是由資料決定有多少個cell。cybertron 的layoutprotocl 支援list元件宣告其cell的型別 ，根據服務端返回的list資料，結合cellMapping & datamapping規則，會生成一個個cell例項，並且在框架層支援了常見的分頁載入（page模式和offset模式）。

這樣，由搭建平臺配置元件和對映協議，業務服務端下發資料，通過cybert容器的客戶端sdk實現協議、資料解析進行頁面的動態渲染。

3. 挑貨個性化演算法對接（實時特徵計算）

• 優化內容排序：使用者在1688手機阿里上各種訪問行為，特別是在挑貨的訪問行為，會被抽象成使用者的行為特徵。通過這些行為特徵，根據對應的演算法，將使用者收件箱中最感興趣的內容排序到最前面，增加使用者的閱讀體驗。

• 提取優質的內容：使用者的對內容行為，通過一定的演算法，可以給內容進行評分，提煉出優質的內容。這些優質內容可以投放到其他公域場景，為商家帶來更多的價值。

4. 異構系統的監控體系

整個挑貨系統，資料在多個系統中流轉，一旦某個系統出現故障，很難排查和追蹤問題。現有的監控體系對同構的應用的鏈路監控已經支援的很完善。一旦涉及到線上應用、離線任務、實時流計算多個異構的系統，就無法有效的做到串聯。為了保證挑貨的穩定性，我們設定了全域性的uuid，將整個系統的日誌採集到雲日誌中。通過專門的監控系統，去分析日誌，做到鏈路預警和資料視覺化。

5. 資料統計系統

挑貨業務承接是1688整個買家的內容需求。從業務在挑貨的展現的PV、UV到具體的業務轉化率，再到新業務的AB效果對比，都離不開資料化支援。所以資料化是挑貨系統的必不可少的組成部分。我們實現思路，從規範業務打點方式入手，到資料日誌輸出規範、資料統計模組、視覺化系統，完成一個閉環的資料化系統。

四、未來發展

• 內容對接平臺化（配置化、資料化）：打造一個內容對接流程、內容資料展現、內容投放的配置後臺。

• feeds引擎的抽象，支援更多的業務。

作者簡介

葛圓根，就職阿里巴巴，花名水鋒，採源寶和手機阿里挑貨技術負責人。13年起先後負責過1688內容平臺、阿里頭條、採源寶、挑貨等多個產品的架構和研發工作。在內容平臺的架構、電商app架構設計和開發、流式計算上經驗豐富。