該文章來自阿裡巴巴技術協會（ata）精選集
2014年12月19日~20日，archsummit北京2014大會上“移動網際網路，随時随地”專題火爆非凡。阿裡無線事業部技術負責人莊卓然（花名南天）任移動專題出品人。
阿裡無線事業部的進階專家李敏（花名心石，微網誌：@allblue_華麗地低調 ）分享了《手機淘寶架構演化實踐》，演講深受好評，榮獲明星講師。
手淘技術研發團隊派出的交流學習小分隊也在archsummit大會現場和行業裡的工程師們愉快的交流學習和玩耍 。
archsummit全球架構師大會是由infoq舉辦的archsummit北京2014大會，重點關注目前最熱門的領域：移動網際網路、網際網路金融、知名企業架構、智能硬體、雲計算案例、大資料處理等，彙聚了業界最資深的架構師和研發總監，力圖為參會者營造一個友好互動的交流平台，講師除了分享自己的架構經驗和心得，也将和參會者進行面對面的直接交流。
下文為infoq對李敏/心石的演講的整理和報道。原文點這裡。
李敏主要負責淘寶無線用戶端和無線網站基礎服務、購物主鍊路的架構、研發方面的工作。從09年開始參與手機淘寶研發團隊的組建和線上産品研發，先後負責過無線部門的社群、會員、營銷、交易等多條産品線的技術工作，建構和發展了阿裡無線技術體系中包括交易鍊路、百億級别高性能api網關、webapp平台等多個重要技術産品，經曆和見證了阿裡巴巴無線從開始之初到成為日活上億級别電商應用技術變遷和積累。
從2009年開始，dau從100萬增長到超過1億，面臨的問題、包括研發支撐所需要解決的事情各不相同。在使用者量和業務複雜度的線性遞增下，架構也進行了相應的演進。如下圖所示，具體可以分為四個階段：
第一階段，手淘的前身wap網站，業務初立、變化快，需要快速釋出，采取html模闆和單一應用，最大程度滿足快速釋出和修改的需要；甚至不需要改動後端的業務代碼，在前面的模闆上做一些修改就可以了。
第二階段，dau的快速增長，wap/android/ios多個平台的業務起來了，需要在多個平台上進行快速的業務複制和業務管控，統一api網關出現。
第三階段，dau進一步增長，線上系統越來越多，業務的多樣性需求更多的展現出來，基于html5的一整套解決方案上線，更多的html5和native混合的業務形态，api網關進行進一步優化和擴充，更友善的接入方式。
第四階段，當dau達到100m的時候，全集團的業務都需要在手淘透出，api網關被部署到更多的idc機房，如何更有體系化的進行有效的研發、接入更多業務、并進行更有效的業務監控，需要更加體系化的架構治理。
做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網關發送。
去年下半年，開發團隊對整個手機淘寶的架構做了比較大的調整，如下圖所示，左側是運作時的架構分布，右側是工程代碼級别的分布。在運作的時候，其他的業務團隊提供的都是一個個的業務bundle，這是可部署的單元，包括ui、服務和标準中間件的調用代碼，下面有一個總線程，負責管理和開發好統一的ui服務，包括消息服務的總線。再下面是運作容器，上面跑的的是所有的bundle的東西，對應運作時的東西，右側是真正在開發時候的結構。比如說聚劃算，它要開發它的業務，就做一個單獨的工程，然後去開發；它隻用開發自己的，開發到差不多的時候，就将其代碼打成一個bundle提供過來，然後一起打包發出去。
下圖是現在手機淘寶上關于html5的整體架構圖。手機淘寶上的方案大緻分為兩部分，中間那一部分是手機淘寶自己開發的html5的運作容器，它負責在上面跑各種各樣的webapp，線上上有一個統一釋出管理系統，它可能對性能進行檢測，包括cdn是否符合規格，html本身有沒有異常等情況，經過這些必要的檢測，包括審查之後，它統一發到cdn上。容器本身其實也會接受運作時的資訊，容器接收到這兩邊的指令之後，它自己會做一些更新配置，也可能會裝載運作，從線上系統下發新的webapp。此外，還可以運作webapp或者是做url的導航攔截，甚至做一些互動。
這是今年新的建設，整個系統是基于前面整個體系來做的，稱之為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所獨有的。要擷取資訊，會從使用者手機淘寶自己填的回報，利用市場和微網誌，實時抓取，然後把内容聚合起來，進行熱門詞歸類，篩選出一些熱門的标簽話題做一些智能分類，分類之後大緻知道到底是支付、詳情、退款出現了什麼問題，确定問題的重點之後，可以直接聯系使用者，甚至去跟蹤使用者，根據這些問題去修複線上的緊急問題或者是改善産品，這就是線上上實際使用的輿情平台。通過熱門詞的分類排名，就可以知道某一個版本在某一個階段最重要的問題是什麼，還擴充了使用者集中回報。
比如舉辦一個搶紅包的活動，這個活動出現了什麼問題，大量的使用者重複回報這個問題，就可以把熱門的話題聚集起來。另外還可以通過輿情平台确定某個技術的改造是否成功。
輿情平台早期主要用于收集一些資訊，後來發現把輿情收集起來做一些大資料分析，可以得出很多自動化的結論，甚至可以驗證研發的結果是好是壞。
mtt是手機淘寶技術團隊（mobile taobao tech team）的英文縮寫，歡迎關注手機淘寶技術團隊，一起交流分享無線技術，共創移動開發無限未來！掃描微信二維碼關注我們！我們将分享更多的技術幹貨！