導讀：大家經常看到手淘里面的第二個TAB 就是微淘了！目前有幾千萬 DAU，幾百億關注關系，每天幾十萬的商家生產內容，對系統的挑戰較大。產品形態上目前以關注 feeds 流為主，是商家非常重要的獲取流量陣地（自運營陣地），下面和小編一起看看微淘技術演進史。

內容生態對淘寶的價值

1.輔助購物，即幫助消費者做更好的購物決策：

比如搜索、猜你喜歡透出內容輔助你挑選哪個商品好，寶貝詳情的主圖視頻、買家秀、大咖點評、客服直播等等幫助你該不該下單。用戶在淘寶購物過程中總會出現各自各樣的需求（痛點），我們就會嘗試用內容的形式解決這些需求，這是大家在手淘里面看到最多的內容，也是內容對零售最基礎的價值，技術上我們構建了新零售內容平臺，以平臺化的方式支撐各種各樣的場景。

2.探索生活消費社區：

目前淘寶的心智主要是購物，大部分用戶都是想買什么才來，所以有“萬能的淘寶”“只有想不到、沒有買不到”的消費者心智，如何結合購物延展心智，服務更多消費者對淘寶是非常重要的。如果能有“想不到買什么，有事沒事空閑的時候來淘寶逛一逛” “解決上億中產階級有錢沒的花，找不到好東西”類似這樣的心智形成，那么我們離生活消費社區就更近一步了，微淘、洋桃社區等業務就在這方面做探索。

微淘的技術挑戰

內容消費業務通用的模型

基本上就這些模型，非常簡單，但一些細微差別會帶來的產品的心智完全不同，但大體上從工程架構看可以抽象為一套。

賬號：大V、機構、店鋪、消費者

內容類型：短圖文、長圖文、短視頻、直播

關系：BC 關系，CC 關系、單向雙向

內容互動：贊、收藏、評論、彈幕、負反饋（不感興趣）、舉報、拉黑。還有直播特有的連麥等實時互動

場景：關注流、發現流、熱門、附近等

當時做微淘時，也負責手淘的主要社區，對工程來說很類似，同時手淘其他社區場景的同學也希望能復用我們的服務，所以第一件事情是我們構建了。

淘寶社區 API 集

結合 PD ，統一了手淘所有的內容互動 API 以及關系、賬號 API ，完成了 “社區平臺雛形”為什么是雛形，因為這個平臺只有基礎 API ，當時思考是具體每個社區場景呈現都不一樣，所以上層業務需要基于 API 各自組織業務。整體研發效率上提升不少，用戶相關的內容互動、內容數據完成了統一。

timeline 引擎

微淘是基于關系的，幾年前 feeds 引擎業內是很火的，基本上 Facebook 、 Twitter 、微博等大公司都在探索，我們也伴隨著業務沉淀了一套，微淘業務與 timeline 引擎的關系如下：

拉引擎我們內部也叫基于關系的搜索引擎。

拉模式的適合場景是關注數和粉絲數數嚴重不對等的情況，比如微淘的場景，部分店鋪的粉絲數過千萬，但是用戶的關注上限是幾千，這里面如果一個大 V 發一條 feed ，走推模式要更新千萬的用戶 inbox ，顯然是不合理的。

但是對于關注數和粉絲數差不多的情況，不建議走拉模式。比如朋友圈，關注上限大概是500，粉絲數大概也是500，那么推模式更有效。

下面介紹下拉引擎（關系搜索引擎）的實現原理：

舉例：比如我的淘寶--店鋪關注列表里面對店鋪名稱的實時搜索。

從這里進去

對店鋪的標題建索引，輸入 a 可以查到有這么多關注的店鋪。

?

去取消關注后，再輸入 a 查詢，可以看到結果實時變化了~

**術語：inbox 用戶的收件箱，outbox 用戶的發件箱
**

兩者數據結構是一樣的，類似郵件，收件箱發件箱里面存了很多封郵件， 每封郵件就是 doc ，郵件有標題、副標題就是索引 index 。我們可以根據 index 來快速查找一個用戶有多少匹配的郵件，這個就是 inbox 的內部搜索；

郵件系統是用推模式實現的， 如果用拉模式來翻譯的話。

我關注了很多人，我想一次性根據某些索引查詢這些人的發件箱中滿足匹配的郵件，并且按照一定排序規則來匯總。

以上面的關注搜索店鋪名稱為例，店鋪的標題、認證、簡介等都是不同的 doc ，索引是標題字符串；

所以 outbox 就是 doc 數組。doc 則由 doc_id+index 數組 組成。

假設只有店鋪標題一個doc。

我們調用引擎把店鋪 id，doc [“xxx旗艦店”]寫入到引擎里面

對于每一個店鋪，我們把 doc 數據先更新到 db ，然后更新到分布式緩存店鋪的 outbox ，然后失效每臺機器的本地緩存 outbox 。（考慮到性能和時效性，我們對 outbox 的 doc 數量做了上限，doc 數量超過 3000 ，遠滿足一般性需求）

當店鋪的 outbox 第一次被訪問時，如果非熱門店鋪本地的堆外 LRU 緩存加載，如果是熱門店鋪，加載到靜態緩存區域。

熱門店鋪的判斷邏輯是：離線計算粉絲數最高的 TOP N 店鋪，然后定期更新名單庫，這里面由于大號的粉絲特別多，基本上熱門店鋪的關系數量占用全部的關系 50% 以上。

整個查詢邏輯如下：

整體本地內存命中率 95%，本地加遠程命中率 99.9%，未來改為持久化緩存則 100%；

堆外緩存可以大大減少FullGC概率。

另外 outbox 的壓縮和解壓縮非常關鍵，索引字段全部采用原生類型，先采用 Kyro 序列化，然后 ZIP 壓縮；

端測渲染引擎

業界內容業務的特點總是交互體驗創新層出不窮，在微淘也不例外。

微淘又是手淘一個 tab ，對性能要求更高，尤其低端機型的性能。

對業務方來說交互體驗差是無法接受的，對于隔一個月發一次版本勉強是可以的，但對于技術來說，研發效率提升是我們要不斷追求的。

所以整體微淘的端測渲染技術策略是體驗為主、效率為輔。

在今天如果端測的 UI 渲染技術同時能滿足體驗和效率，那就不用折騰了，但是很遺憾目前沒見到過。

下面是 2017 年初的現狀，灰色部分當時還沒有。

在以體驗為主，效率為輔的策略下，微淘端測動態化的幾個階段：

當時卡片組件化最大的問題是，限制了 UED 同學的視覺交互創新，往往一個細微的創新看似很簡單卻發現組件化改動很大。比如給整個內容大卡片套一個外框，則要求每個小卡片都做修改。過程中與 PD、UED 組件化的約定做了幾次，但是在創新面前還是敗了。

我們在 2017 年開始打造以體驗為主效率為輔的 TNode 引擎，DSL 從最初的客戶端語言到最后與前端共建升級到了 VUE ，有效的解決了端測研發效率問題，同時微淘性能在手淘主鏈路中保持中位數。

Tnode 的技術架構

這塊主要是淘云、重哥、水軍等同學實現，我簡單介紹下：

1、首屏性能優化，Duktape 引擎替換 WebView ，低內存高性能。提供端測表達式引擎，常規邏輯處理采用 Native 函數。

2、頁面完成渲染后，所有事件異步js驅動

3、DSL 二進制減少網絡、解析大小。DSL 中表達式預編譯。

4、Flex 層級優化，如采用虛擬節點等方式

目前 TNode 是前端開發，因為是效率為輔，他仍然存在很多效率問題，最大的兩個問題是：

不能完全滿足 W3C 協議（換句話來說以前端思維看這個還是很坑，像是早些年前端同學兼容 IE6 感覺一樣）。

與手淘前端主流的 RAX 以及封裝的 Weex Native 模塊不融合，這意味著沒有生態。

但 TNode 確實解決了那些以體驗為主效率為輔的場景，架構組在了解 TNode 架構后，基于 WEEX 生態，在 2019 年初基本完成了 WEEX-EAGLE，與微淘同學一起試點，試圖解決問題 2。

TNode 最大的價值是加速了整個手淘動態化演進的進程，如果把當前的動態化技術比作混合電動車時代，那他在市場上還是會存在一段時間，但是最終一定會過渡到電動車，讓所有消費者無顧慮的接受。對于當前動態化技術是一樣的，在體驗為主效率為輔的場景， 與在效率為主體驗要求不高的場景是兩種不同的方案。然后最終有一天會融為一體，甚至加上 BFF 三端一體，未來都是大前端領域范疇。

內容分發平臺

前面提到了我們構建了大量的社區基礎 API ，但是每個場景業務邏輯都不太一樣，場景層都要定制開發。

我們遇到了幾個問題：

1、系統比開發多：內容分發（社區）的場景是非常非常多的，前面提到我們要試圖解決用戶在購物路徑中的各種需求，而且業務升級頻率高，以往為了隔離都是一個業務一個系統，業務大升級又得來一個系統，久而久之業務系統比開發還多。

2、不同客戶端版本兼容成本高：客戶端老版本兼容，bug 修復帶來了大量的 ifelse ，而且好幾年內都不能下線，寫完后代碼過幾天自己也看不懂了，也不敢動了，也不想看到了。

3、業務代碼生命周期短、系統頻繁重構怪圈：徘徊于代碼復制和復用的糾結，如果新老業務代碼復用，復用代碼改變則要回歸很多歷史版本，在手淘開發中回歸歷史版本是一個很痛苦很低效率的事情，如果復制一堆重復的代碼則更亂。更進一步思考任何一個新系統在業務頻繁升級的情況下，代碼就會堆積，馬上就變得難以維護，然后系統啟動很慢然后又開始進入重構的循環，這個周期取決于業務需求數量，一般也就兩年左右就很臃腫了。

4、另一個背景是端測效率提升后，客戶端部分同學希望能更加的了解業務，能全棧，但是服務端的單元化、運維等很多東西很重，希望能給全棧同學更輕松的更高效的研發環境。

5、還有 AB 實驗效率問題，目前業務側的 AB 主要是新業務功能的 ab ，不是算法策略的 ab ，新功能的 ab 核心還是研發效率問題。比如微淘的頁面，坑位， Tab 新需求改動都要 ab 對比效果，都要有多份數據存儲；

為了解決上述問題，我們把業務代碼打包成一個業務 bundle ，做到業務和歷史業務隔離，業務和平臺隔離，結合內容分發業務現狀，集成 AB 、內容、分發策略、社區 API ，整體構建了內容分發平臺。

未來：定位上仍然是解決內容消費場景的數據展示需求，是一個業務平臺。主要核心是為了解決1、2、3的問題，第4點與現在流行的serverless有那么一點點關系，后面看serverless演進成熟度再看結合點。

搶阿里云新用戶專屬優惠權益，致電95187-1 ！

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的技术架构演进|0到千万DAU，微淘如何走过？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。