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

一、背景

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

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

1. 基于1688的老買賣關系: 關注關系、客戶會員關系、星标關系、分銷關系
2. 内容的産生源頭是供應商，供應商在1688網站的各種行為，都可以轉變成内容資訊
3. 内容的消費源頭是供應商的老買家(與供應商有老買賣關系)
4. 内容形式比較多樣：文章、營銷活動、店鋪上新、商家動态、直播、短視訊等一系列商家産生的有效内容
5. 内容産生形式：供應商的主動行為、供應商的被動行為

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

https://yuque.antfin-inc.com/blink-uc-team/use_case_for_lc/knbac9#yg68hy 二、業務架構

• 供應商在1688網站可以直接将動态和文章釋出到挑貨。
• 供應商在1688網站的直播、店鋪上新、報名營銷活動、邀約客戶等行為，會被挑貨服務識别到，被動抓取到挑貨。
• 挑貨将供應商産生的内容推送到供應商老買賣關系的買家收件箱中。
• 買家通路挑貨時，挑貨服務會從買家收件箱中将内容渲染成各種業務卡片，呈現到客戶手機端。
• 買家可以對部分有時效性的内容（直播預告、未開始的互動）設定訂閱提醒，當直播開始、活動開始時，挑貨服務主動通過消息告知買家。
• 買家可以通過挑貨平台去到供應商的店鋪和商品詳情去購買商品，産生交易訂單。
• 挑貨中的優質内容，可以投放到1688網站的其他子產品，新使用者看到後，能有效的産生交易和關系轉化。
• 新使用者通路挑貨時，挑貨服務會推薦部分優質供應商給使用者，使用者可以關注供應商，看到供應商的挑貨内容。

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

https://yuque.antfin-inc.com/blink-uc-team/use_case_for_lc/knbac9#hstcax 三、技術架構

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

https://yuque.antfin-inc.com/blink-uc-team/use_case_for_lc/knbac9#bqu1xn 挑貨總架構圖

• 業務對接方式：離線任務、消息對接、實時rpc
• feeds流的推拉引擎：feeds動态生成器、feeds的收件箱推送、架構圖未包含非活躍使用者走拉的模式、feeds流查詢服務
• 動态元件的對接方案Cybert：業務模型群組件UI分離、動态生成native元件
• 個性化算法對接方案（未包含）
• 異構系統的監控體系（未包含）：多種中間件平台實作同一個業務時，異構系統的監控成為一大難題。在挑貨中，已經設計出了方案，目前正在對接中。
• 資料統計系統

https://yuque.antfin-inc.com/blink-uc-team/use_case_for_lc/knbac9#0krvwd 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，挑貨feeds生成後發送metaq消息，被運作在blink上推送任務監聽到，将動态索引寫入到使用者到收件箱。

下面3張比較細節的圖：

1. 活躍使用者-推模式

   

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

   

   3.非活躍使用者激活政策

   

https://yuque.antfin-inc.com/blink-uc-team/use_case_for_lc/knbac9#13c4ik 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實作協定、資料解析進行頁面的動态渲染。

https://yuque.antfin-inc.com/blink-uc-team/use_case_for_lc/knbac9#i59ppi 3. 挑貨個性化算法對接（實時特征計算）

• 優化内容排序：使用者在1688手機阿裡上各種通路行為，特别是在挑貨的通路行為，會被抽象成使用者的行為特征。通過這些行為特征，根據對應的算法，将使用者收件箱中最感興趣的内容排序到最前面，增加使用者的閱讀體驗。
• 提取優質的内容：使用者的對内容行為，通過一定的算法，可以給内容進行評分，提煉出優質的内容。這些優質内容可以投放到其他公域場景，為商家帶來更多的價值。

https://yuque.antfin-inc.com/blink-uc-team/use_case_for_lc/knbac9#uwy7rp 4. 異構系統的監控體系

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

https://yuque.antfin-inc.com/blink-uc-team/use_case_for_lc/knbac9#plp1xh 5. 資料統計系統

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

https://yuque.antfin-inc.com/blink-uc-team/use_case_for_lc/knbac9#1ik3id 四、未來發展

• 内容對接平台化（配置化、資料化）：打造一個内容對接流程、内容資料展現、内容投放的配置背景。
• feeds引擎的抽象，支援更多的業務。

https://yuque.antfin-inc.com/blink-uc-team/use_case_for_lc/knbac9#lgrucz 作者簡介

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

如果您有實時報表／實時資料大屏／實時金融風控／實時電商推薦等相關實時化資料處理需求，可以加入如下釘釘交流群！