手機淘寶構架演化實踐

手機淘寶構架演化實踐

 

李敏主要負責淘寶無線客戶端和無線網站基礎服務、購物主鏈路的架構、研發方面的工做。從09年開始參與手機淘寶研發團隊的組建和線上產品研發，前後負責過無線部門的社區、會員、營銷、交易等多條產品線的技術工做，構建和發展了阿里無線技術體系中包括交易鏈路、百億級別高性能API網關、WebApp平臺等多個重要技術產品，經歷和見證了阿里巴巴無線從開始之初到成爲日活上億級別電商應用技術變遷和積累。

　　本文即根據李敏的演講整理而成。

　　發展階段

　　從2009年開始，DAU從100萬增加到超過1億，面臨的問題、包括研發支撐所須要解決的事情各不相同。在用戶量和業務複雜度的線性遞增下，架構也進行了相應的演進。以下圖所示，具體能夠分爲四個階段：

• 第一階段，手淘的前身WAP網站，業務初立、變化快，須要快速發佈，採起HTML模板和單一應用，最大程度知足快速發佈和修改的須要；甚至不須要改動後端的業務代碼，在前面的模板上作一些修改就能夠了。
• 第二階段，DAU的快速增加，WAP/Android/iOS多個平臺的業務起來了，須要在多個平臺上進行快速的業務複製和業務管控，統一API網關出現。
• 第三階段，DAU進一步增加，線上系統愈來愈多，業務的多樣性需求更多的體現出來，基於HTML5的一整套解決方案上線，更多的HTML5和Native混合的業務形態，API網關進行進一步優化和擴展，更方便的接入方式。
• 第四階段，當DAU達到100M的時候，全集團的業務都須要在手淘透出，API網關被部署到更多的IDC機房，如何更有體系化的進行有效的研發、接入更多業務、並進行更有效的業務監控，須要更加體系化的架構治理。

　　API網關

　　作WAP的時候沒有所謂的API網關，爲何要用API網關呢？

　　隨着應用數量的增多，每一個應用分別暴露的API出口不少，修改的話邏輯很複雜，這時候應該引入一個統一的網關。

　　但隨着DAU的增加，API網關會成爲一個單點。開發團隊在中間作了不少技術和架構上的努力，主要有幾個關鍵點。一是後端接入不少應用，其實API網關只是通路，理論上不存在調用的上限，只要內存夠大，包括網卡的流量夠的話均可以上來。二是有必要的機制作到寬闊的調用網關。還有一點，當後端業務要通過API網關時，其實如今業界不少都是典型的RPC的模式，RPC的模式有一個繞不開的問題，就是可能要設定一些東西，這時後端服務跟API會有必定程度上的耦合。現階段要接入服務，後端服務器隨時都會變化，不可能後端服務變化的時候都對API作相應的發佈，這是不現實的。因此有一套本身的RPC機制，解除了這種強類型的約束。

　　此外，能夠在網關上附加不少功能，好比安全、審計，還有一些日誌、審查等。

　　到了如今這個階段，要進行異地部署，不少IDC，這樣的話引入API網關極可能會帶來問題。包括今年的雙11或者是雙12，要在多個異地機房支撐手機淘寶的業務，會有不少API網關。

　　好比說像APP能夠在中心網關上面詢問，應該去哪一個真正的API網關。而後中心API網關會告訴它結果，它再鏈接到所在地的API網關上，而後再向後端API發起調用，全部API的服務網關都受管控中心統一管控。好比說增長一些新的功能，上線一些新的API，包括一些引流、切換，這些指令都會在管理平臺上向各個API網關發送。

　　手機端

　　1. Bundle

　　去年下半年，開發團隊對整個手機淘寶的架構作了比較大的調整，以下圖所示，左側是運行時的架構分佈，右側是工程代碼級別的分佈。在運行的時候，其餘的業務團隊提供的都是一個個的業務Bundle，這是可部署的單元，包括UI、服務和標準中間件的調用代碼，下面有一個總線程，負責管理和開發好統一的UI服務，包括消息服務的總線。再下面是運行容器，上面跑的的是全部的Bundle的東西，對應運行時的東西，右側是真正在開發時候的結構。好比說聚划算，它要開發它的業務，就作一個單獨的工程，而後去開發；它只用開發本身的，開發到差很少的時候，就將其代碼打成一個Bundle提供過來，而後一塊兒打包發出去。

　　2. WebApp

　　下圖是如今手機淘寶上關於HTML5的總體框架圖。手機淘寶上的方案大體分爲兩部分，中間那一部分是手機淘寶本身開發的HTML5的運行容器，它負責在上面跑各類各樣的WebApp，在線上有一個統一發布管理系統，它可能對性能進行檢測，包括CDN是否符合規格，HTML自己有沒有異常等狀況，通過這些必要的檢測，包括審查以後，它統一發到CDN上。容器自己其實也會接受運行時的信息，容器接收到這兩邊的指令以後，它本身會作一些更新配置，也可能會裝載運行，從線上系統下發新的WebApp。此外，還能夠運行WebApp或者是作URL的導航攔截，甚至作一些交互。

　　3. PackageApp

　　這是今年新的建設，整個系統是基於前面整個體系來作的，稱之爲PackageApp。

　　這個跟前面最大的區別就是讓用戶感知不到前面同步下載的過程，大概的作法是：把HTML5以及WebApp在發版以前先作一些預知放到客戶端裏面，前面會作兩件事情，首先按照原來的邏輯運行，其次就是在右側的藍圖裏面，它會去作一些UI的攔截，發現用戶點擊的icon進去以後，整個URL是符合用戶規範的，它會啓動檢測機制去檢查線上是否是有新的版本須要下載，若是有的話會啓動異步更新模塊，從CDN上拉取新的WebApp版本，不然會走到原來的地方，最後既不影響用戶去使用WebApp，又能把本身最新的版本更新到所指望的版本，這由統一的管理平臺去發佈。

　　在方案設計之初，還思考了三個方面，首先它是標準的URL，在點擊進去以後是導航的URL，對於前端工程師來講，他設計研發WebApp跟客戶端或者是線上跟HTML5的網站是一致的。其次，手機淘寶本身的容器，制定了本身的規範，在底層的容器上面能夠實現手淘定義的規範。第三，「不一樣網絡、全量、差量更新」，這點很重要，在移動互聯網場景下，到底要發起幾條連接拉取資源，在WIFI下怎麼拉取資源，其實都是不同的。在不一樣網絡下面，對策都不太同樣。

　　下面是採用PackageApp後業務模塊LoadTime對比圖：

　　支撐體系

　　除了前面介紹的內容，比較大的電商App，還須要一個很完備的支撐體系。若是沒有的話，在線上運行的狀況是不可感知的。手淘在不一樣的維度也作了不少支撐的工具。

　　1. 研發支撐

　　在研發支撐上面，像傳統的Reivew代碼，特別是作客戶端的同窗幾乎都會作統一的UI庫，你們會設計模板，比較典型的，會有所謂的平常預發、線上染色等等。它的集羣數量跟可以進來的用戶是頗有限的，經過這個環境來確認所開發的代碼發佈到線上可能會有什麼問題。一套代碼通過預發以後再發布到線上去，最後有一個染色環境，好比說用戶打電話反饋遇到的問題，好比說下單下不了或者是搜索無結果，這時會有一個染色集羣，把用戶定位到染色集羣上面，對用戶專門進行一些分析，如今尚未作到直接在用戶機器上作調試，可是用戶到了染色集羣上面，整個調用的鏈路會剝離出來，比較好分析用戶到底發生了什麼事情。

　　2. 測試支撐

　　App的測試很重要，除了比較常規的單元功能測試，還有很重要的像穩定性跟性能，以及自動化這些都是很重要的。像手機淘寶差很少是一個月左右的時間可能會迭代一個版本。好比說新的功能開發會不會影響到老的功能，智能化測試很重要，可能分紅兩部分，一部分是線上全部的API，包括業務邏輯是否是正常。另外一部分是新寫的代碼會不會有問題，由於前面架設了統一的API網關，因此會在網關這個層面作不少自動化的調用迴歸，構造不少正經常使用戶的數據去測試線上API系統的返回值，包括一些異常是否是正常，來保證線上業務邏輯的正常。在客戶端這一側，則會作不少自動腳本的迴歸，保障整個客戶端新作的代碼跟原來相比沒有什麼問題。另外還引入了比較多的靜態代碼掃描，保證不會出現低級問題。

　　3. 運維支撐

　　移動App的運維支撐跟線上不太同樣。除了常見的性能跟穩定性分析，還有針對App的業務監控跟輿情監控。輿情監控這個應該是移動App所特有的環節，你們經過市場去分發，不少用戶會發評論，iOS特別明顯，有人說好，有人說很差，安卓更復雜，特別是國內有大大小小很是多的應用市場，不一而足。因此怎麼對輿情作一個有效的監控，既能經過輿情監控，快速收集問題，也能作一些梳理分析，找到產品或者是性能方面的提高點。

　　4. 發佈支撐

　　發佈支撐，其實也是在大的App上面纔會出現的，針對一我的羣的發佈。傳統的直接是發到市場上，你們都收到了。而手淘如今有不少內部灰度和外部灰度正式發佈，可能有一些內測版本只發給阿里巴巴集團內部員工，這能夠經過本身作的發佈系統來支撐，有比較靈活的發佈策略調整：能夠圈定一批用戶，也能夠選定一個區域，甚至能夠用後臺數據作合理的設置給特定的版本推送特定升級的版本。

　　若是App發到用戶手上，結果發生了致命的問題，怎麼辦呢？其實有兩種方法修復線上的問題，第一個是直接替換，另外就是更小維度的補丁，如今在安卓上作的比較多。

　　李敏還分享了一個案例，在上半年有一次大促的時候發生了一個問題，零點就要促銷了，版本多是前天剛發佈給用戶的，那怎麼辦呢？若是是替換的話也能夠作到，可是下載數據量很是大，剛發佈不久對用戶影響比較大，因此選擇了用補丁修復，主要是相似於替換，用JAVA開發的應該知道，主要是用類替換的方式作的。在iOS上也有一些方案，不過還在嘗試當中。

　　客戶端監控

　　能夠在分鐘級別肯定用戶調用某個操做的成功次數、失敗次數和失敗率，實現對業務可用性的監控。

　　輿情平臺

　　輿情平臺是移動App所獨有的。要獲取信息，會從用戶手機淘寶本身填的反饋，利用市場和微博，實時抓取，而後把內容聚合起來，進行熱門詞歸類，篩選出一些熱門的標籤話題作一些智能分類，分類以後大體知道究竟是支付、詳情、退款出現了什麼問題，肯定問題的重點以後，能夠直接聯繫用戶，甚至去跟蹤用戶，根據這些問題去修復線上的緊急問題或者是改善產品，這就是在線上實際使用的輿情平臺。經過熱門詞的分類排名，就能夠知道某一個版本在某一個階段最重要的問題是什麼，還擴展了用戶集中反饋。

　　好比舉辦一個搶紅包的活動，這個活動出現了什麼問題，大量的用戶重複反饋這個問題，就能夠把熱門的話題彙集起來。另外還能夠經過輿情平臺肯定某個技術的改造是否成功。

　　輿情平臺早期主要用於收集一些信息，後來發現把輿情收集起來作一些大數據分析，能夠得出不少自動化的結論，甚至能夠驗證研發的結果是好是壞。