天貓雙11前端分享系列(二)：天貓雙11頁面服務容災方案大揭秘
天貓雙11前端分享系列（三）：淺談 React Native與雙11
天貓雙11前端分享系列（六）：大規模 Node.js 應用（續）
天貓前端基礎技術體系MAP簡介
1 年前
文章前面先打個廣告：我們還在招聘哦，歡迎各種簡歷，butian.wth[at]http://taobao.com
前端基礎技術體系是一個非常寬泛的概念，涉及到非常多的點，前端這個行業本身易入門難精通的一部分原因也是每一次的技術深入都需要技術廣度上有提升，這些廣度以前覆蓋了HTTP、其他后端語言、操作系統、印刷設計等，現在由于移動設備的興起，廣度要求的點做了更多的擴充，移動設備多樣化、國際化、Native技術等等。列舉這些不是想說明前端有多復雜，而是技術體系本身就不是一個獨立的存在，需要結合更多其他領域才能有更好的發展，其實其他技術的發展也是類似。下面就是流水賬了。
歷史
在我2011年剛加入口碑前端團隊的時候，三七一直在強調，我們現在的前端團隊是國內最棒的。得益于當時YUI成熟的體系，我們在業務中落地了在當時非常“潮”的技術。比如本地的模塊構建和發布工具att、CDN的combo服務，YUI的模塊版本化管理機制（KISSY模塊規范的原型），基于Base/Attribute/Plugin/Widget的模塊生命周期管理等等。而使用YUI3開發web應用這篇文章里對web模塊開發的思考在現在依然不會過時。
YUI和jQuery的最大區別就是體系和庫的區別，對于龐大的淘系業務，只有體系化的技術方案才能保證研發效率和工作流的穩定，保證線上質量和用戶體驗。YUI體系在傳統庫的基礎上，涵蓋了YQL（瀏覽器端類sql實現）、YETI（瀏覽器端自動測試）、YUI-Target-Environments等等。
當時前端基礎體系強調的核心是兼容性和性能，我們需要大量的復雜龐大的庫來保證一套代碼能夠多瀏覽器運行，而低效的瀏覽器執行能力和緩慢的網速也讓前端展現部分稱為用戶訪問速度的瓶頸。于是有了：
CDN解決圖片在線優化、同域名連接數、Combo及多地域資源加載問題
前端發布工具雛形，自動sprite、base64、文件合并
css/js分開管理到css和js之間開始存在明確的依賴關系
ajax解決刷新頁面重新請求所有資源緩慢的問題（雖然有緩存）
MAP 1.0
2012年，天貓啟動了MAP項目(Tmall Front-end Architechture & Publish Mechanism)。
當時團隊面臨了一些大部分前端團隊都困擾的難題，這部分階段稱為MAP 1.0。
團隊有一定規模，但是開發規范、工具、流程不一致，團隊之間缺少溝通。
原始的發布機制和開發工具，覆蓋式發布。
多套模塊庫TML、MUI，KISSY版本繁雜，代碼共用少。
前端工作流不明確不一致，效率低，前端在業務中非常被動。
MAP 2.0 - 扁平化、細粒度
基于上述MAP1.0時代的問題，MAP2.0做了針對性的調整：
CDN靜態文件路徑語義化和非覆蓋版本化管理，解決了前后端發布的順序問題
Base(KISSY 1.3 + MUI 2.0) + App(業務代碼) 扁平化雙層結構
前后端一致的靜態文件引用方式feloader.use，覆蓋java端應用
git+本地開發工具，統一的工作流，代碼可管理且高效
MAP 3.0 - 扁平化、細粒度、跨平臺
因為智能終端設備的普及，原來的前端目標環境從多瀏覽器變成了多終端，整個I/O交互的變化對前端體系提出了多端構建的要求。
多終端帶來的1套數據多套view，對前后端分離的要求更加嚴格
native和web界限模糊，前端模塊需要覆蓋Native App
無線環境對頁面性能和體驗要求更高
跨終端的MAP 3.0計劃啟動，為了保證一致的模塊體系和模塊快速開發和落地，跨終端組件的技術方案基礎還是KISSY 1.4（KISSY 1.3升級1.4），大批組件開始支持移動端，各類頻道活動也開始全面覆蓋移動端。
同時，基于Node渲染服務在經歷2014雙11的考驗后，開始全面走向業務，前端的模塊渲染不滿足于當前簡單的異步渲染，畢竟同步輸出渲染結果始終是最快的方式，于是我們對前端模塊的規范進行了擴充：前端模塊應該是包含js+css+模板+schema
關于Node服務的介紹可以參考文章：天貓雙11前端分享系列（四）：大規模 Node.js 應用
其中，模板可以在發布的時候編譯成模板文件和一個模板腳本，分別支持在服務端渲染和瀏覽器端異步渲染。渲染所依賴的數據格式根據schema文件來約束。
還有一些其他的變更包括：
本地發開工具gulp化，業務有更強的定制能力，實現弱中心和靈活的開發環境
從if到schema，端到端數據接口規范形成，模塊通過數據實現業務化
還有，ReactNativ在2015雙11落地，實現了同個模塊多端構建的能力。前端模塊的規范變成：js+css+模板+native模板+schema。獨立native模板的主要原因還是目前沒有好的解決方案來實現普通web模板到native模板的編譯，或者換個順序也不行，所以還是獨立維護一份Native的版本。
模塊的規范基本成形，現在我們的模塊開發目錄大概是這樣的：
- build- src--- index-pc.js--- index.js--- index-native.js--- index-pc.less--- index.less--- schema.json--- seed.json
關于ReactNative的詳細可以參考：天貓雙11前端分享系列（三）：淺談 React Native與雙11
同時Native組件在web中調用也是正在嘗試的方向，將web中一些非常復雜容易有性能問題的模塊直接替換成Native，可以實現頁面切換時部分組件不刷新等功能，提升用戶體驗。
MAP 4.0（現在）
MAP 3.0對于2015年來說是相對比較完善的方案了，但是暴露了大量的問題。
比如文章2015天貓雙11前端分享系列（一）：活動頁面的性能優化里的描述，統一基于KISSY 1.4的模塊在無線端已經成為性能瓶頸，引用文章里的一句話：腳本體積過大，目前基礎腳本文件大小在100k上，占了我們規范標準的一半以上體積。
當時而言，最簡單的實現方案就是無線的模塊獨立一套基礎庫，比如使用zepto或者kissy mini，而pc的模塊繼續沿用KISSY。但是，一方面KISSY本身相對社區解決方案已經不夠新鮮，pc/無線不一致的技術體系對開發效率來說也是一個負擔，更會造成大量的技術方案重復實現。
擁抱社區
React還是原生
團隊的第一反應是React，一方面是社區的成熟，另一方面ReactNative實踐下來確實能滿足業務需求，如果基于React構建模塊，然后編譯結合ReactNative，解決模塊在Native下運行的方案，看起來非常美好。也算是真正實現了一次開發，多端運行的能力。
但是問題依然也比較明顯：
React本身無法解決所有問題，渲染之外依然需要大量其他工具lib支持，這些lib無法做到多端運行，或者說即使可以，也是一個非常私有的實現，后續更新也是問題。
React本身的腳本還是太大，對于簡單的無線頁面依然是一個負擔
React本身有服務端解決方案，可以實現同步加載，但是同步瀏覽器、客戶端的State本身復雜度上較高，無法工程化解決的話，長期來說也是一個坑。
審視React的過程中，最大的收獲其實是Babel。通過gulp-babel + babel-polyfill的方案，我們可以在本地開發最新ES標準的代碼，并在IE8及以上都能順利運行（雖然有一些坑）。剛好2015雙11之后，天貓已經徹底拋棄IE6/7，于是babel的引入就成為最先敲定的方案。
同時，基于commonjs規范進行本地開發也是一個共識，基于有編譯過程，本地開發完全可以和Node一致采用commonjs規范，至于最后編譯成amd、cmd或者是其他瀏覽器模塊運行規范可以由構建工具決定。
接下來，引入Babel之后，前端是不是可以完全基于規范開發，不要再引入各種框架/庫什么的？
然而，基本不可能，沒有公共庫就沒有復用，就會有大量重復代碼，而社區有大量的lib庫，顯然比內部寫的公共庫更加完善。參與社區模塊的建設顯然比悶聲造輪子更有意義。而React本身也可以作為模塊庫中的一個模塊存在，復雜業務可以使用React，簡單業務也可以基于原生開發。
于是最后，我們確定：
babel+commonjs作為基于標準開發解決方案
顆粒化引入社區lib，react也是lib之一
簡單業務基于原生+zepto，足夠簡單靈活但是不重復
復雜業務基于react解耦，加上其他通用lib來補全功能
npm還是cdn combo
問題并沒有結束，引入社區lib是不是意味著要引入類似webpack的打包機制？KISSY 6已經擁抱npm，這也是社區模塊的最佳實踐。下面是一些對比。
npm的優勢：
npm
模塊內聚性高，對外API統一
執行期無seed，降低運行期復雜度
cdn combo
模塊被調用方式不可控
seed體積龐大，也是性能上的負擔
cdn combo的優勢：
npm
無法按需加載，頁面公共部分無法動態更新
組件間存在重復代碼
cdn combo
支持按需加載、多端加載
顆粒化拼裝，少重復代碼，可跨頁面緩存
combo還是打包本質的區別是 動態打包 還是 靜態打包；combo其實也是一種打包，只是是一種url顯性表達合并配置的打包方案。
從模塊顆粒化及頁面性能考慮，cdn combo還是主要的方案，畢竟對于天貓的活動、頻道頁面來說，保證首屏體驗是性能優化非常重要的一部分，只有基于combo才能動態按需地實現首屏同步加載，非首屏動態異步加載。npm方式也能做但是對于頁面級需要有一個構建過程，而cdn combo只需要模塊構建，頁面只是一個模塊的組合而不需要構建。
基于CDN combo，未來可以做更多的優化：
最大化公用緩存，尤其是在mobile可以控制容器的場景如zcache（可緩存的容量是有限制的如果沒限制打包更簡單）
未來基于數據分析動態化精細化跨頁面資源加載（例如希望針對部分地區首先加載a,b 對另一部分地區首先加載 abc，打包就必須針對每種case打出不同內容）
同時，基于npm打包的優勢也需要考慮引入到體系中。 比如一個組件內不需要暴露外面的util.js 一定是和組件其他文件被外界使用，此時被combo反而帶來的合并及讀取的開銷，此時更適合打包對外統一暴露一個文件出口。所以有復用價值的combo才合適
綜合下來其實是combo和打包配合的方案，combo用來完成有復用價值部分的管理，打包用來完成無復用價值的內聚。
而seed體積精簡可以通過服務端的動態seed合并及去掉已同步加載模塊的seed來實現，保證頁面上seed的內容一定是會使用到的。
由于開發期引入了babel，調試時就不能簡單綁定host到本地了，需要引入source map，但是sourcemap對combo后的url無法解析，所以需要在機制上實現調試時解combo，客戶端和服務端都支持一下就可以了，具體實現可以見后面加載機制里的設計。
多端加載能力
如上面描述，確認了前端工作流的大部分細節：
模塊使用CDN combo實現按需加載
ES + commonjs的開發規范
基于原生規范的顆粒化組件，簡單lib如zepto解決簡單業務，react組件解決復雜業務數據解耦問題
接下來就是多端加載的解決了。
第一步就是需要一個Loader，這里需要把Native組件一起考慮進來，于是我們提供了這樣的Loader加載策略，feloader是目前加載器的名字，wormhole是服務端模板渲染服務。
無論是開發Native還是Web，都采用一樣的方式生成配置文件，基于配置文件，模塊之間的調用關系就可以明確，然后服務端可以根據依賴表輸出combo uri及直接對Native模塊進行組合。
瀏覽器端目前由于無法直接運行commonjs規范的腳本，解決方案也非常簡單，在構建工具打包的時候，包上一層define(modName, deps, function(require, exports, module))即可。
Node渲染服務也需要實現基于模塊配置的依賴分析，生成combo uri，如果是native模塊，則直接分析完依賴后，將模塊內容拼接成一個大的腳本返回。
MAP 4.0體系下的前端開發
疑問
1）從KISSY遷移到目前的開發模式，改動很大，以后還會不會有這樣的大范圍升級？
答案是，升級肯定會有，保持依賴模塊和使用技術的新鮮才能提升業務效率，畢竟用戶環境、外部社區也是在不斷升級。但是不會有大范圍的升級：一方面我們采用基于瀏覽器標準規范的方式開發，這一部分屬于相對比較穩定，變化不會對研發造成負面影響，另一方面模塊本身顆粒化，升級一樣也是顆粒化，快速迭代的方式，而不是所有模塊一起選一個特定時間集中式改造，減少對業務的影響，讓升級融入到業務開發中。
2）基礎體系變化怎么大，如何解決兼容問題？
兼容問題確實比較大，首先Node容器和本地開發工具都需要向前兼容，這個是必須的。
而對于前端開發的模塊，我們提供了一個kissy-polyfill方案讓AMD模塊在KISSY頁面上運行，這樣可以讓大家快速開始基于新的方式開發模塊，然后這個模塊可以在老頁面上運行。
具體實現也很簡單
define -> KISSY.add
require -> KISSY.use
require.config -> KISSY.config
其他就是一些加載器細節的patch，比如已經加載模塊的配置可以重寫什么的。
3）目前MUI體系引入了zepto作為基礎DOM/event的解決方案，如何支持IE8/9？是不是依然需要無線PC兩套基礎庫？
目前我們是這么解決的：
開發時統一使用zepto
feloader中有這么一段處理：ie8/9下將zepto alias到jquery，這里會有一些細微的差別，但是目前看這個模式是可行且確實對開發者來說基本無感知
結尾
很多人其實覺得前端基礎技術體系已經很難有突破，但是雖然MAP升級了那么多版本，ES規范也在不停升級，但是很多背后的思想還是一致，只是在原來的基礎上不斷優化細節，然后提高擴展性。這也是為什么前端一直在強調基礎的重要性，CSS2，ES3依然是基礎的重要組成部分，工具框架只是外殼，理解為什么這么設計遠重要于知道如何使用。
最后，歡迎加入天貓前端：），nodejs/web/native方向都需要，簡歷到butian.wth[at]http://taobao.com，期待你的加入
PC與無線齊飛，Web共Native一色——天貓首頁全解密
1 年前
某天突然看到了這個問題淘寶和天貓首頁都用到了哪些技巧或者技術？ - 岳逢楽的回答，作為天貓首頁的負責人薛定諤，我也只好解剖一把天貓首頁，讓大家看看它的骨肉血皮到底是怎個模樣。人格擔保雖然有該回答下有擼文狂魔小胡子哥珠玉在前，但本文絕對有不一樣的地方喲~
比如……如何快速響應需求，解放生產力。
比如……移動端首頁和WeeX首頁的落地經驗。
比如……廣告，天貓前端團隊正在誠意招資深前端開發工程師（社招），簡歷請發到yueyuan.cx@alibaba-inc.com
從14年實習開始參與PC首頁的開發，到15年正式入職同時負責無線端的首頁，至今已經兩年的時間。期間歷經了6次改版、php到Node端的遷移、ReactNative的嘗試、無線端性能優化、進入ES6時代、WeeX的嘗試等等，不一而足，感觸頗多，與大家分享。
也是一篇難得的長文，先放提綱。
一、天貓首頁的定位
二、天貓首頁的技術架構變遷史
1. 從PHP到Node的蛻變
2. 從靜到動，從PC到移動端的飛躍
3. 光影融合，Web與客戶端的交匯
三、疾如風——天貓首頁的性能優化
四、侵略如火——大膽的Native化嘗試
1. ReactNative的初登場
2. WeeX的回歸
五、不動如山——天貓首頁的穩定性保障
六、小結
一、天貓首頁的定位
在了解天貓首頁的技術架構之前，先讓我們問自己一個問題：首頁到底是什么？是用戶關于這個網站的第一印象嗎？還是所有業務的起始點？
簡而言之，天貓首頁有著以下三個特點：
面向最廣大消費者的標桿與門面。
流量的入口與中轉站。
輕耦合，新技術的試驗田。
作為天貓的門面，往往決定了消費者對于天貓的第一印象，所以天貓首頁一直在性能優化上有著孜孜不倦的追求，優化加載性能、交互體驗、減少流量消耗、Native等多種方式給于消費者更好的體驗。
作為流量的中轉站，首頁賦予了運營非常多靈活機動的能力，例如節日氛圍的營造、機動區塊的變化能力，并且全面鋪開個性化，能夠基于人群、地區推薦更加適合用戶的商品，導流效率遙遙領先于其他頁面。
作為新技術試驗田，天貓首頁一直處于開放的態度，敢打敢沖，率先嘗鮮新技術并落地：2014年9月份率先從PHP遷移到Node、天貓內第一個嘗試ReactNative、第一個進入ES6時代、第一個落地WeeX的重要業務。在這一過程中，天貓首頁往往會克服非常多先行者的困難，并反哺新技術的優化與成熟。
二、天貓首頁的技術架構變遷史
天貓首頁的技術架構變遷，主要是基于兩個部分：內部搭建系統&模板渲染系統的變更、業務重點的變更。
1. 從PHP到Node的蛻變
在PHP時代，主要存在以下問題：
老舊的服務端實時渲染架構。渲染性能差、服務集群龐大使得文件同步生效慢。
舊搭建系統規范使得效率低。需要手動在php文件中挖出供運營填寫數據的位置，該數據位難以定義其他校驗規范。
php文件和css/js文件不屬于同一套部署系統，需要手動控制順序，先發布新版本css/js文件到cdn，再發布php文件更新引用css/js文件的版本，容易出現發布手誤。
在Node時代，上述問題都得到了解決，在首頁完成遷移Node的嘗試后，我們擁有了新的內部搭建系統斑馬和模板渲染系統Wormhole：
在使用『Cache集群緩存渲染好的HTML』這一架構后，性能、抗壓能力、可擴展性都有了極大的提升(關于這一點詳細可以看@Barret李靖的回答)。
接入schema規范系統，建立數據位置的代碼與前端代碼解耦。
隔離職能。HTML模板代碼專注于渲染，不再處理其他事情。
部署系統統一。不再出現需要關注文件發布順序、手動升級版本的情況。
關于Node應用的更多信息，可以：關注前天貓Node負責人@死馬的回答Node.js 在雙十一中有哪些應用，表現如何？ - 死馬的回答以及現天貓Node負責人@ngot的回答如何看待天貓徹底拋棄PHP？ - ngot 的回答
2. 從靜到動，從PC到移動的轉身
從2014年開始，天貓開始集體轉型，迎接移動端時代的來臨，直到2015年雙十一，移動端成交占比已達到68%。
無線時代有甜也有苦：
不需要糾結坑爹的IE兼容性，但是老版本的安卓兼容起來更加痛苦
因為安卓的碎片化，響應式也是需要考慮的重要問題
高清化的處理方案
部分方案需要優化如iconfont，因為可能會發送多個請求，影響性能
糟糕的網絡環境、機器性能、系統特性對于性能有著更加極致的需求
因為移動端和PC端用戶的使用習慣差距較大，同時考慮后續維護的方便性，移動端的天貓首頁的UI設計上并未使用傳統概念上的響應式(PC和移動端一套代碼)，而是與天貓客戶端保持一致。
這一前提使得移動端Web首頁可以和客戶端共用接口，共享同一份數據來源，避免運營填寫多份數據，節省運營成本，又因為移動端大量個性化推薦的需求，千人千面的展現方式，所以移動端Web首頁采用了異步渲染的方案——頁面進入只載入框架，再調用接口獲取數據和模板，在瀏覽器端進行渲染。這樣做也有諸多好處：客戶端中訪問可以使用離線包、更少的流量消耗、更細粒度的ABTest、對接其他數據源更方便等等。
同時還實現了一套可以快速滿足區塊調整需求的動態化布局方案，完美地支持了多次需求變更而無需前端代碼發布，詳細可見發表在天貓前端團隊博客的這篇文章，讓需求來得再猛烈些——快速響應需求的天貓H5首頁新架構 · Issue #35 · tmallfe/tmallfe.github.io · GitHub
3. 光影融合，Web和客戶端的交匯
相比起客戶端業務迭代的成本、體積和發版劣勢，Web的低成本、迭代快、跨平臺的特性，使得絕大多數客戶端的業務都會選擇嵌入Web的方式。而客戶端的黏性，使得這個Web頁面相當大一部分的流量都來源于客戶端。
那么一個新的問題來了：『客戶端中的Web頁面如何利用客戶端的能力？是不是可以將Web和客戶端進行融合，獲取更好的體驗？』
最初嘗試了幾個方案：
Hybrid API。
跳轉部分高頻頁面根據Url規則攔截到Native頁（如商品詳情頁）。
復用客戶端建立的網絡鏈路
離線包等等
都取得了一定的效果，但是還需要一套更加完整徹底的方案。所以在2015年7月React Native如火如荼的時候，天貓首頁立刻開啟了嘗試的項目，相關內容后文詳述。
三、疾如風——天貓首頁性能優化
性能一直是首頁所需要關注的要點，希望能給用戶更好的體驗。
首先明確一點，有很多優化不是單純的前端團隊能夠完成的，有CDN團隊和服務端團隊的支持，讓前端同學感覺像生活在極樂天國。《高性能網站建設指南》這本書里提到的方法都比較基礎了，在此略過。
除此之外，我們還做了以下對于性能有著顯著影響的事情：
css/js文件combo。我們的CDN和前端Loader支持實時url的combo，可以實現按需加載。如果CDN沒這個條件，也可以使用webpack等前端工具進行合并打包。
懶加載。優先渲染首屏內容，其余模塊資源延后或者用戶有交互的時候加載。
Webp圖片格式。對比這兩張圖，可以發現Webp格式的圖小得多，WebP格式的圖：https://img.alicdn.com/tps/TB1labeKXXXXXaaapXXXXXXXXXX-1130-500.jpg_.webp；jpg格式的圖：https://img.alicdn.com/tps/TB1labeKXXXXXaaapXXXXXXXXXX-1130-500.jpg。感謝（圖片存儲系統的同學）。
裁剪合適尺寸的圖片。如果某一張圖片運營投放的尺寸過大，可以根據實際的尺寸，加上后綴截取，如『https://img.alicdn.com/tps/TB1labeKXXXXXaaapXXXXXXXXXX-1130-500.jpg_100x100.jpg』。
拍扁所有請求。每個模塊渲染所需要的請求不能是兩個請求串行。
數據請求支持自由合并。（感謝服務端同學）
前端首屏只請求后端一個請求，由后端做對接其他系統的并行請求。
利用動態化布局保證模塊之間的高復用。
圖片域名收斂。因為CDN支持SPDY協議，所以收斂域名可以有效節省DNS解析時間。
天貓前端組件規范整體升級，移動端去KISSY，變得更加輕量，減少流量消耗。
離線包。如果頁面是純異步渲染，可以考慮在客戶端中設置離線包。只有當用戶處于wifi且網絡空閑時，客戶端才會去下載離線包，二次訪問效果拔群。
再讓我用一張圖說明頁面渲染各個階段可以做的優化。
除了加載性能外，還需要考慮交互性能，例如頁面滾動時的幀率。
除了用requestAnimationFrame來將模塊渲染切片，避免UI線程阻塞。如果頁面的hover和mouseenter效果過多，還可以在用戶滾動時，設置全局的pointer-event:none，避免在滾動的時候觸發大量hover效果，實測效果拔群。
四、侵略如火——大膽的Native化嘗試
相比起Web而言，APP有著更好的體驗；但相比APP，Web的開發效率和發版優勢毋庸置疑，如何融合兩者，一直是前端的重要探索方向之一。
1. ReactNative的初登場
2015年7月，天貓首頁立刻進行了ReactNative的嘗試。
但在嘗試過程中遇到了非常多的問題，滿滿的坑和血淚：
一方面是ReactNative彼時并不完善，調試體驗非常糟糕，莫名其妙紅屏不知原因，還有升級0.8.0后會順手升級iojs為3.x,和2.x的iojs并不兼容。
另一方面是當時考慮并不完備。工程化落地一個技術需要考慮的因素非常多：多版本降級&兼容方案、開發調試工具、環境一致性、埋點、測試、監控、后續維護成本等等，需要考慮一系列的方案。
因為沒有拿到數據和結果，并且沒有足夠的人力維護多一個版本的頁面時，RN版的首頁選擇了停止維護。但是ReactNative在天貓和雙十一還有大范圍的應用，詳細可以看《天貓雙11前端分享系列（三）：淺談 React Native與雙11》天貓雙11前端分享系列（三）：淺談 React Native與雙11 · Issue #27 · tmallfe/tmallfe.github.io · GitHub
2. WeeX的回歸
正如灰太狼被打飛時常說的一句話——『我還會回來的』，在手淘團隊推出了一套新的Native化方案WeeX以后，天貓首頁又死性不改蠢蠢欲動地進行了嘗試。
這一次考慮較為全面，上述RN落地時沒考慮的方案都有一定的考慮和解決，例如：
自動構建Web版本以降低維護成本
多Weex版本的降級方案
Cache集群部署Detector自動識別請求是否支持WeeX并返回對應內容。
實際體驗優于Web，從業務數據上來看也取得了較好的結果。
感興趣的同學可以使用iOS手機淘寶客戶端5.7.0以上版本掃碼下述圖片體驗。
https://img.alicdn.com/tps/TB1GAYMKXXXXXcTaXXXXXXXXXXX-260-260.png
Weex頁面非常精簡，gzip后首頁JSBundle的大小大概是13K，是Web的十五分之一。
WeeX即將開源，敬請期待。
五、不動如山——天貓首頁的穩定性與保障
大概是心有靈犀吧，天貓首頁和淘寶首頁也采用了非常類似的容災和監控機制，有小胡子哥的詳述，我在此就一筆帶過。
1.在容災方面：
如果接口請求失敗，會依次加載本地緩存、訪問CDN的備份文件等。
對于運營填寫的數據內容質量，投放系統配置了詳細的校驗，如最大字數等等。
2. 在監控方面：
有全量監控的埋點方案。能夠全網統計到各個模塊的運行狀況和接口調用的健康情況。
有客戶端層面的監控方案。能夠拿到更多Web運行時無法自己拿到的信息，如當前頁面某一鏈接404。
有業務監控的方案。能夠保障頁面的業務內容一定是符合預期的。因為首頁的數據來源相當多，一個頁面對應幾十個運營，對于數據內容的質量是一定要保障的。
六、小結
接下來天貓首頁還會做的事情大概有：
賦能運營。接入個性化合圖系統，免去了運營找設計師做圖的成本等等；
國際化。為了方便弱網地區用戶的訪問，對于性能有更高的要求，對于設計、素材也有更高的要求。
提筆匆忙，感覺虎頭蛇尾，還請見諒。
如果有不明白的地方歡迎指出，歡迎和我一起來完善這篇文章哈哈。
最后，天貓前端團隊正在誠意招資深前端開發工程師，簡歷請發到yueyuan.cx@alibaba-inc.com
