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

若有-若無發表於2018-10-29

一、背景

內容是一個電商app不可或缺的組成部分。越來越多的人會使用碎片時間瀏覽手機app的內容,包含導購的帖子、短視訊、直播等。1688挑貨業務,打造了基於買家和商家之間老買賣關係的內容場。讓商家通過內容維繫老客戶,挖掘新客戶。讓買家能第一時間獲取到關注商家的上新、優惠、直播等資訊,為自己的採購等決策提供幫助。
從巨集觀的背景分析,挑貨業務有以下幾個特點:
  1. 基於1688的老買賣關係: 關注關係、客戶會員關係、星標關係、分銷關係
  2. 內容的產生源頭是供應商,供應商在1688網站的各種行為,都可以轉變成內容資訊
  3. 內容的消費源頭是供應商的老買家(與供應商有老買賣關係)
  4. 內容形式比較多樣:帖子、營銷活動、店鋪上新、商家動態、直播、短視訊等一系列商家產生的有效內容
  5. 內容產生形式:供應商的主動行為、供應商的被動行為
基於上面的業務特點,我們梳理下挑貨整體的業務架構。

二、業務框架

e5faa631388fc6b2d4acbcfd2836190b.png
  • 供應商在1688網站可以直接將動態和文章釋出到挑貨。
  • 供應商在1688網站的直播、店鋪上新、報名營銷活動、邀約客戶等行為,會被挑貨服務識別到,被動抓取到挑貨。
  • 挑貨將供應商產生的內容推送到供應商老買賣關係的買家收件箱中。
  • 買家訪問挑貨時,挑貨服務會從買家收件箱中將內容渲染成各種業務卡片,呈現到客戶手機端。
  • 買家可以對部分有時效性的內容(直播預告、未開始的互動)設定訂閱提醒,當直播開始、活動開始時,挑貨服務主動通過訊息告知買家。
  • 買家可以通過挑貨平臺去到供應商的店鋪和商品詳情去購買商品,產生交易訂單。
  • 挑貨中的優質內容,可以投放到1688網站的其他模組,新使用者看到後,能有效的產生交易和關係轉化。
  • 新使用者訪問挑貨時,挑貨服務會推薦部分優質供應商給使用者,使用者可以關注供應商,看到供應商的挑貨內容。
挑貨的業務價值在於可以維繫供應商的老買賣關係,提供買家快速獲取供應商資訊的內容,另外可以為供應商引入新的客戶,並沉澱為老買賣關係。而挑貨的優質內容可以投放到1688網站公域頻道,一方面節省運營成本,另一方面為供應商引入更多的新使用者。挑貨在1688公域、私域流轉上承擔著樞紐的作用。

三、技術框架

為了實現挑貨的業務架構,在1688無線領域孵化出多個技術方案。下面就其中關鍵的技術細節進行下描述。
挑貨總架構圖
fc25d7fe9e12c5733b59f1675c31b705.png
  • 業務對接方式:離線任務、訊息對接、實時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流引擎的架構圖:
e2cf14accc354949ea6e03adfd3d4f6b.png
  • 內容資料流入動態生成器,產生挑貨feeds,挑貨feeds生成後傳送metaq訊息,被執行在blink上推送任務監聽到,將動態索引寫入到使用者到收件箱。
下面3張比較細節的圖:
  1. 活躍使用者-推模式
    0e6a11fea5e39b4d77392457f591f50d.png

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

    7ca4882632fb7fa727726cc6d059f40e.png

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

    f9cf5120a6b25486a3f1a9437b241f57.png
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外投方案。
0702a2ea7a0730cb9a2be84eb0095ea3.jpg
而對於feeds列表的場景,我們如何升級能力做到“資料驅動ui”?這主要是升級List複雜容器的支援,list元件的特點是由資料決定有多少個cell。cybertron 的layoutprotocl 支援list元件宣告其cell的型別 ,根據服務端返回的list資料,結合cellMapping & datamapping規則,會生成一個個cell例項,並且在框架層支援了常見的分頁載入(page模式和offset模式)。
16b35c26aa09397f696faa6f2a041c3a.jpg
這樣,由搭建平臺配置元件和對映協議,業務服務端下發資料,通過cybert容器的客戶端sdk實現協議、資料解析進行頁面的動態渲染。
3. 挑貨個性化演算法對接(實時特徵計算)
  • 優化內容排序:使用者在1688手機阿里上各種訪問行為,特別是在挑貨的訪問行為,會被抽象成使用者的行為特徵。通過這些行為特徵,根據對應的演算法,將使用者收件箱中最感興趣的內容排序到最前面,增加使用者的閱讀體驗。
  • 提取優質的內容:使用者的對內容行為,通過一定的演算法,可以給內容進行評分,提煉出優質的內容。這些優質內容可以投放到其他公域場景,為商家帶來更多的價值。
4. 異構系統的監控體系
整個挑貨系統,資料在多個系統中流轉,一旦某個系統出現故障,很難排查和追蹤問題。現有的監控體系對同構的應用的鏈路監控已經支援的很完善。一旦涉及到線上應用、離線任務、實時流計算多個異構的系統,就無法有效的做到串聯。為了保證挑貨的穩定性,我們設定了全域性的uuid,將整個系統的日誌採集到雲日誌中。通過專門的監控系統,去分析日誌,做到鏈路預警和資料視覺化。
5. 資料統計系統
挑貨業務承接是1688整個買家的內容需求。從業務在挑貨的展現的PV、UV到具體的業務轉化率,再到新業務的AB效果對比,都離不開資料化支援。所以資料化是挑貨系統的必不可少的組成部分。我們實現思路,從規範業務打點方式入手,到資料日誌輸出規範、資料統計模組、視覺化系統,完成一個閉環的資料化系統。

四、未來發展

  • 內容對接平臺化(配置化、資料化):打造一個內容對接流程、內容資料展現、內容投放的配置後臺。
  • feeds引擎的抽象,支援更多的業務。
作者簡介
葛圓根,就職阿里巴巴,花名水鋒,採源寶和手機阿里挑貨技術負責人。13年起先後負責過1688內容平臺、阿里頭條、採源寶、挑貨等多個產品的架構和研發工作。在內容平臺的架構、電商app架構設計和開發、流式計算上經驗豐富。
1534419398608-c7f96240-1531-48ef-867b-48
如果您有實時報表/實時資料大屏/實時金融風控/實時電商推薦等相關實時化資料處理需求,可以加入如下釘釘交流群!
TB1HzWqB7CWBuNjy0FaXXXUlXXa-157-150.png


相關文章