文章轉載自 infoq
從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發到用戶手上，結果發生了致命的問題，怎麼辦呢？其實有兩種方法修復線上的問題，第一個是直接替換Bundle，另外就是更小維度的補丁——熱補丁，現在在安卓上做的比較多。
李敏還分享了一個案例，在上半年有一次大促的時候發生了一個問題，零點就要促銷了，版本可能是前天剛發佈給用戶的，那怎麼辦呢？替換Bundle也可以做到，但是數據下載量非常大，而且剛發佈不久，這樣對用戶影響比較大，所以選擇了用熱補丁修復，主要是類似於ClassLoader替換，用JAVA開發的應該知道，主要是用類替換的方式做的。在iOS上也有一些方案，不過還在嘗試當中。
客戶端監控
可以在分鐘級別確定用戶調用某個操作的成功次數、失敗次數和失敗率，實現對業務可用性的監控。
輿情平臺
輿情平臺是移動App所獨有的。要獲取信息，會從用戶手機淘寶自己填的反饋，利用市場和微博，實時抓取，然後把內容聚合起來，進行熱門詞歸類，篩選出一些熱門的標籤話題做一些智能分類，分類之後大致知道到底是支付、詳情、退款出現了什麼問題，確定問題的重點之後，可以直接聯繫用戶，甚至去跟蹤用戶，根據這些問題去修復線上的緊急問題或者是改善產品，這就是在線上實際使用的輿情平臺。通過熱門詞的分類排名，就可以知道某一個版本在某一個階段最重要的問題是什麼，還擴展了用戶集中反饋。
比如舉辦一個搶紅包的活動，這個活動出現了什麼問題，大量的用戶重複反饋這個問題，就可以把熱門的話題聚集起來。另外還可以通過輿情平臺確定某個技術的改造是否成功。
輿情平臺早期主要用於收集一些信息，後來發現把輿情收集起來做一些大數據分析，可以得出很多自動化的結論，甚至可以驗證研發的結果是好是壞。
