EMAS，一部淘寶十年移動互聯網技術的演進史

導讀

本文根據2018雲棲大會深圳峯會·EMAS專場—移動互聯的進化論，阿里巴巴高級技術專家泠茗《 EMAS全景介紹》的演講整理而成，文中就EMAS的起源史及EMAS的五大移動研發場景解決方案進行了分享。

淘寶的移動互聯網演進史

各位好，今天我想從阿里巴巴具備表明性的APP - 手機淘寶的互聯網演進史看一下阿里巴巴移動團隊在近10年的過程當中咱們所作的一些技術上的選擇，咱們作的一些技術上的沉澱。手機淘寶近10年的移動互聯網演進史，也是EMAS這個產品的起源史。

上面這兩幅圖畫是阿里集團移動APP的產品矩陣，從這兩幅圖中你們也能夠看到，阿里集團孵化了數十款千萬級、億級的APP，你們熟悉的有手機淘寶、天貓、支付寶、高德、釘釘、優酷、UC瀏覽器等等。阿里在移動互聯網行業的技術積累從全球範圍內看也是處於比較前沿的狀態。

接下來咱們看看手機淘寶在近10年的發展歷程中經歷了哪幾個階段。咱們從2008年開始發佈了手機淘寶的第一個版本，在最初的階段咱們對手機淘寶的定位是一個工具型的APP，在這個階段咱們主要是爲了完成對商品的完整生命閉環的支持，從商品的搜索、瀏覽、下訂單、支付、售後運維以及物流等等。在這個階段咱們更關注這個APP基本功能的保障，以及這個APP基本性能的保障。

隨着咱們整個手機淘寶業務不斷地發展，咱們的整個體量也在不斷地壯大，到了2.0階段，淘寶逐漸成長爲阿里集團內部的一個平臺型的APP，咱們叫作航母級的APP，在這個階段大量的阿里集團的其它的業務，比方說飛豬、天貓、聚划算等等都把相應的業務入口搬到了手機淘寶這個平臺上來。因此手機淘寶每個大版本的迭代，它背後實際上是有大量的業務團隊進行相應的協同來完成這樣一次工做的，因此在這個階段，咱們主要是關注手機淘寶這樣一個航母級的平臺總體的迭代的效率以及它的穩定性上的保障。

而後進入到第三個階段，也就是咱們如今所處的階段，咱們把本身定位爲一個生態型的超級APP。怎麼理解這個生態型的超級APP？你們知道去年雙11整個阿里集團電商當天的GMV達到1670億，在這樣一個大型的商業活動當中，手機淘寶實際上是扮演了阿里集團業務運營中軸的角色，經過手機淘寶咱們來串聯阿里集團內部，不只僅是咱們的電商體系，還包括大文娛、金融體系，你們一塊兒協同共振來產生了這樣一個很是了不得的成績。因此在這個階段，咱們更關注的是如何經過這些技術框架、技術能力去支撐上層的阿里集團的業務創新，以及在整個生態下各個板塊之間的協同。

在手機淘寶的演進過程當中，咱們也遇到了大量的技術上的挑戰，還有效率上、質量上以及性能上的挑戰。首先是整個協同效率方面，手機淘寶早期的技術架構仍是一個單一工程的研發模式，這樣一個研發模式隨着客戶端承載的業務愈來愈多，它的總體業務間的依賴關係也愈來愈複雜，系統的耦合程度愈來愈嚴重，比方說咱們每次開啓一次迭代，多是不一樣的業務方從他的主幹分支拉一個分支代碼進行獨立的研發，到最後要進行分支結合的時候，由於業務耦合很是嚴重，每一個業務作的變動，相互之間匹配的時候都會有大量的衝突，這樣的衝突就要求咱們協同大量的業務團隊一塊兒來進行衝突的解決，這樣一種方式實際上是帶來大量的協同上的問題。

第二方面，隨着咱們整個業務之間耦合不斷地提高，系統的複雜度不斷地提高，後續整個系統的擴展、業務的擴展，咱們須要新增一些業務到APP體系當中的時候，你會發現你的歷史包袱愈來愈重，也爲後續APP的迭代帶來大量的成本，這是協同方面帶來的一個問題。

另一方面就是手機APP的發版模式，跟咱們傳統的B/S架構的應用有很是大的不一樣。B/S架構的應用，你在後端隨時能夠控制它的系統的升級，應用可控性是很是強的，可是像APP這樣一個C/S架構，一方面你的APP的發版是須要經過應用市場進行審覈發佈的，另外一方面客戶端的更新也是由客戶進行控制的，這樣的發版方式也限制了咱們業務應對市場的變化的響應速度和相應的業務創新的靈活性。

剛纔提到的是效率上的問題，咱們面對不一樣業務之間的協同上而帶來的牽一髮而動全身，整個業務的迭代不夠敏捷，成本很是高昂。

除了效率上的問題，第二個就是質量上的問題。由於手機淘寶移動APP，做爲整個集團業務運營中軸的角色，要求咱們在應對市場變化的時候有很快的響應的速度，而且移動業務自己也是一個迭代頻度很是高的場景。在這樣的場景下怎麼保證APP的質量，也是咱們當前遇到的一個很大的挑戰。由於一旦一個事物變化的頻度加快的時候，它的容錯率就下降了，因此怎麼樣在業務快速迭代過程當中保障這樣體量的一個APP的高可用，也是咱們在演進過程當中遇到的一個很大的問題。

第三個就是網絡層面的問題，由於移動業務是一個在線屬性的業務，所謂的在線就是對網絡的依賴。移動網絡對比有線網絡是有很是多不一樣的，它多出了一個移動鏈路的環節，總體的穩定性、連通率對比有線網絡都有必定的不足，怎麼解決網絡層面通訊效率的問題，怎麼解決網絡安全的問題，這些也是咱們在業務演進的過程當中所面臨的挑戰。

面對這些挑戰咱們作了什麼事情，首先是關於整個協同效率方面，爲了解決協同上的問題，爲了解決整個APP架構的優雅設計的問題，咱們也是開發了一個應用容器，這個應用容器本質的原理就是指望能把一個APP內部全部的業務模塊拆分爲一個一個獨立的業務板塊，這些業務板塊之間咱們經過標準的協議進行通信的，這樣的方式能夠確保每一個業務模塊獨立並行往前走，每一個業務模塊最後對應的是一個獨立的工程，工程和工程之間拆分出來了，不一樣的業務模塊之間就不存在任何的耦合關係，經過這樣的方式咱們能夠大幅提高不一樣業務團隊之間的協同效率。

另一方面經過這個應用容器，咱們會負責託管整個業務組件的完整生命週期，經過這樣的方式好處在於當你的業務組件出現問題的時候，咱們能夠經過容器在內部消化這個問題，避免這個問題會影響到全局APP的質量。另一點，由於咱們的容器託管了業務模塊的一個完整的生命週期，因此咱們能夠實現每一個業務模塊動態部署的能力。這一點咱們有一些在APP上使用上的業務模塊，我在一開始打包的過程當中就能夠把這些業務模塊，不須要加在最終的二進制的包裏面，能夠減小APP的包大小，當這個APP處於運行時的時候，我再經過這個容器去進行一個動態的加載，經過這種方式進行動態部署。另一個，這種動態部署能力也意味着當線上出現一些問題的時候，能夠經過動態部署的能力盡快完成線上問題的即時修復。

圍繞剛纔說的質量的問題，咱們也是沉澱了一套泛質量管理的體系個，一個是基礎設施層面，一個是流程層面，基礎設施層面咱們有很是好的實驗室，針對解決如何提高移動應用線下測試的效率，如何提高它的自動化的程度，自動化的UI的測試，自動化的性能測試等等，去提高總體的Bug檢出率，替換原先人工的黑盒測試的模式。進一步咱們也沉澱了大量終端的能力，如何解決遠程調試，當端上出現問題的時候，是否是能經過一些遠程調試設備幫你解決問題，如何進行端上移動日誌的管理，如何實現端上熱修復的能力等等。

再往下咱們有面向移動大數據處理的平臺，如何採集來自不一樣數據源的數據，如何去作交叉分析、聚合分析，如何去發現潛在的一些風險，如何去智能地感知線上的一些問題。在流程方法論方面，手機淘寶也沉澱了一套高保障的機制，咱們大概劃分爲三個階段：

第一是研發測試階段，咱們經過靜態掃描、真機服務，保障在研發測試階段的代碼質量，在阿里集團內部咱們有一整套統一的移動應用質量質量基線的定義，當第一個階段你的整個靜態掃描也好，你的真機測試也好，評測下來的結果符合咱們的質量標準基線的時候，咱們進入到第二個階段。

第二個階段是幾輪的灰度發佈的階段。由於線下的真機測試，畢竟它能覆蓋的樣本數，可以覆蓋的場景仍是相對比較侷限的，因此是須要線上必定量的灰度量，可以把一些邊角的案例可以覆蓋住。

灰度發佈階段，咱們也能基於大量的設備畫像進行很是細粒度的定向的灰度發佈，通過灰度發佈，經過咱們的整個質量基線的評測以後，咱們會進入到正式發佈的階段，在正式發佈階段，咱們也會經過咱們的APM的能力，輿情管理的能力，進行實時線上的質量大盤的監控。當發現問題的時候，咱們會經過遠程調試的能力，經過終端日誌的能力去快速地進行問題的發現，而後快速完成線上問題即時修復。

經過這樣一整套的流程機制，確保像手機淘寶這樣一個超級APP，這樣一個生態型的APP，在運行時可以始終保持一個高可用的狀態。

第三部分是關於性能網絡方面。性能網絡方面其實咱們主要解決的問題是兩個，第一是移動業務場景下，有大量的業務場景對網絡是強依賴的，比方說咱們的移動API服務，比方說消息推送、即時通信、數據同步、遠程配置等等，對網絡都是一個強依賴，假如說每一個業務團隊都本身來負責網絡層面的研發，這個成本實際上是很是高昂的，咱們知道網絡自己實際上是一個相對比較窄，具有必定門檻的基礎領域，若是每一個團隊都去維護這樣一個網絡專家團隊的話，一方面你的技術研究週期比較長，和你的業務快速迭代是有必定衝突的，因此整個網絡層面的研發成本仍是很是高昂的，怎麼樣去解決這方面的問題，在阿里內部咱們是把全部的無線端的網絡都統一到一個團隊來解決，而後也提供了統一的無線網絡接入的體系。

面向終端，咱們是提供統一的SDK，承載不一樣業務場景的網絡接入。在後端咱們有一個接入網關，解決流量調度、APP管理、網絡優化等等，和上層解偶的網絡基礎設施的建設。而且咱們有專門的團隊作底層協議的持續優化以及和移動網絡適配，經過這樣的方式能夠去解決在移動網絡場景下，網絡劫持、安全加密，以及網絡通信效率等等方面的一系列的問題。

企業級移動中臺EMAS

剛纔說到的圍繞效率、質量、性能，其實沉澱的仍是比較典型的幾個案例，但在近10年的發展歷程中，咱們也沉澱了大量的基礎設施，今天這些基礎設施在阿里內部咱們是由EMAS移動中臺來統一承載的，而且經過EMAS這個移動中臺來支撐整個阿里巴巴上層大量的移動業務的快速創新。今天咱們也指望經過阿里雲這個口子可以把咱們的移動中臺對外輸出，幫助客戶快速地完成數字化、移動化的轉型。

這幅圖是EMAS的產品全景。EMAS包含三部分，第一是基礎架構層，咱們叫EMAS Infrastructure，這是提供面向APP開發域的，咱們會提供大量的功能組件、服務組件、移動端的中間件、推送、移動網關、APM、輿情分析等等相關的中間件。而後是下面的架構層，咱們有跨平臺的開發框架和移動端的應用容器，幫助你們構建一個更加優雅、科學的APP底層架構。

第二層是研發支撐層，EMAS DevOps，這主要是圍繞一個APP完整的生命週期，從你的代碼管理到你的靜態掃描、編譯、構建、灰度發佈、正式發佈、運營這樣一個完整的生命週期，提供阿里巴巴的工做體系，來進行閉環的管控。

第三層是工程理念層，EMAS Philosophy，也一層咱們但願EMAS不只輸出阿里巴巴沉澱的一些硬的基礎設施，咱們還但願把阿里巴巴沉澱的一些軟實力，咱們的Android、IOS的研發規範、火車式的版本發佈機制、APP性能指標基線、質量指標基線，甚至是說不一樣的開發者可能處於不一樣的階段，在不一樣的階段你的整個移動互聯網研發團隊的組織架構如何去構建等等這方面的經驗，咱們也指望可以把這些軟的東西、軟實力的沉澱經過EMAS的平臺開放出來。

這張圖是整個移動中臺EMAS在阿里巴巴的技術棧全景當中所處的位置。咱們一直在說阿里巴巴是一個很典型的大中太、小平臺的業務體系，上層的業務很是多，要支撐這些上層業務的快速變化，須要有大中臺支撐。在大中臺中咱們有業務中臺、數據中臺、互聯網中間件、基礎設施、IaaS層的資源等等，移動中臺也是其中很重要的一部分，如何去支撐上層的業務在移動層快速的業務創新。

5大移動研發場景解決方案

接下來咱們就一塊兒看一下基於EMAS的產品能力，咱們面向移動研發的幾個比較典型的痛點場景，咱們所沉澱出來的解決方案，包括持續交付、組件化、跨平臺、泛質量管理以及網關統一接入。

首先是EMAS的持續交付解決方案。在EMAS平臺上咱們也支持三種研發模式，包括傳統的Native方式，以及跨平臺方式，基於WEEX的跨平臺開發框架，第三是混合開發，所謂混合是Native加上WEEX的方式。咱們也指望經過EMAS輸出三項IT效能指標的參考體系，包括圍繞效率咱們怎麼樣定義一個研發團隊的研發效率，包括咱們怎麼定義一個應用的質量基線，包括咱們怎麼定義一個應用的性能體驗的基線等等，咱們會把阿里巴巴內部的這一整套的基線體系輸出出來。

持續交付也會覆蓋咱們所謂的五大職能域，從研發、測試到發佈、運維、運營。在這五大職能域，咱們也沉澱了大量的基礎設施和工具服務，比方說構件階段，咱們會藉助依賴管理、編譯緩存、構建集羣等等，大幅提高Android、IOS打包的效率，而後在測試階段，咱們會提供大量的私有API的檢測、包大小的檢測，基本的安全屬性的檢測，包括咱們會把Android、IOS研發規約最終實體化爲一個靜態代碼檢測的腳本，經過這樣的方式把規範提到平常實踐當中。在發佈階段，咱們有很是細粒度的灰度發佈的能力，在運維階段咱們有基於端上的全景監控體系，能夠全盤監控整個端上的性能質量狀態。再到運營階段，咱們有相應的輿情管理，以及相應的消息推送能力，可以實現更快速、更實時的用戶的處理。EMAS的持續交付就是經過EMAS DevOps進行五大職能域的工做串聯，幫助開發者真正實現一個一站式、一體化的應用迭代的管理。

EMAS持續交付解決方案帶來的價值，能夠從手機淘寶的版本發佈頻度去看它的效果。最先以前手淘的版本多是一個月才發版一次，如今咱們平均天天發版次數是1.7次，這樣一個頻度可能你們會有疑惑，爲何你的版本發佈這麼頻繁，這也跟我接下來介紹的組件化解決方案有關係。

組件化解決方案本質上是經過咱們的應用容器來實現APP架構的優化，實現APP架構內全部不一樣業務模塊之間的解耦，經過這樣的方式，咱們能確保咱們的每一個業務模塊相互之間是徹底獨立的，是單一工程能夠並行研發的，另外咱們也能夠實現這樣一個基於容器動態部署的能力。每個業務模塊，它單獨的動態部署都意味着咱們這個APP發生了變化，因此爲何咱們剛纔提到手機淘寶天天大概有1.7次的發佈，這是由於每一個業務模塊發生一次動態部署，我都認爲是一次APP的發佈，這就是爲何咱們發佈頻度這麼高的緣由。

這幅圖是手機淘寶的一個組件化的案例，在手機淘寶體系內，像你的首頁、搜索、評價、支付等等，背後其實都是一個個獨立的業務模塊，經過咱們這樣一個容器框架能夠實現不一樣模塊的解耦，上下會用統一的基礎設施的中間件，經過這樣的方式，咱們可以完全的從一個單一工程開發的模式轉化爲一個多功能運行開發、協同開發的模式。

組件化解決方案帶來的一個優點是說，原先的這種單一工程、強耦合的架構其實類比於兩人三足的協同模式，一旦某個模塊出現問題，就會致使整個隊列被那我的阻塞住，須要整個隊列協同起來才能往前走，這樣協同的成本是很是高昂的。經過咱們的組件化的方案，總體的架構能獲得有效的優化。在手機淘寶內部咱們的版本發佈是遵循一個班車制發佈的原則，咱們在一年作規劃的過程當中，咱們就會確立接下來一年每月大版本發佈的時間點是何時，而且這個時間點是不會發生變化的，假定某個模塊須要跟隨這個大版本的發佈，通過個人買票上車的環節，就是經過個人靜態檢測、真機測試，知足了個人應用質量基線標準以後，跟隨我這一次的大版本的發佈。
假如沒有知足，沒有關係，由於咱們具有動態部署的能力，因此當你達到了這樣一個發佈的狀態的時候，你能夠基於咱們應用容器的動態部署能力，去完成本身的應用迭代，從這樣一個方式，咱們能夠完全地從原先的多方捆綁的方式，轉化到業務發佈按需發佈、想發就發的狀態，整個業務的效率獲得大幅提高。

還有一塊就是咱們的跨平臺解決方案，它主要想解決的問題就是但願可以同時繼承各類研發模式各自的優勢，經過這樣的方式，一方面能夠實現快速研發，研發團隊維護成本低，同時它的性能體驗是基於原生的渲染引擎進行渲染的，因此它的體驗都會比較優異。

經過跨平臺的解決方案，也推進咱們在組織架構上進行改變，隨着跨平臺解決方案的出現，咱們的平臺慢慢的演化爲一個一個獨立的工做組的模式，跨平臺我只須要有幾個前端的開發人員，就能夠幫助我完成多平臺的業務快速的開發，研發團隊的維護成本會很是低，每一個業務團隊慢慢的演化爲這樣一個獨立的工做組的模式，可以閉環的完成業務的快速迭代。而咱們原先的客戶端團隊就慢慢的下沉，變成咱們一個基礎支撐的團隊，如何去更好地把底層的能力封裝成JS API，向上層去暴露出來，經過這樣的方式咱們也大幅地提高了內部不一樣團隊之間的協同效率，以及支持了這些業務的快速創新和迭代。

跨平臺框架在阿里雙11的大型商業項目中，一些大型的運營項目中，WEEX框架也是發揮了重要的做用，像2017年雙11當天，整個框架承載了16萬+頁面的渲染。除了阿里體系內其它一些大型的APP以外，在整個社區也有大量的社區基於WEEX開發框架作混合開發。

另一部分是泛質量管理解決方案。剛纔提到手機淘寶圍繞質量問題實際上是沉澱了一整套很是體系化的泛質量管理的體系。這一點咱們主要是爲了解決三個問題，第一是傳統的APP很依賴發佈前的人工黑盒模式的測試，而這樣一種測試模式成本很是高，可是由於是須要人工去進行單點測試的，因此它可以覆蓋的環境、場景也是很是有限的，效率很是低，應該說是一種很典型的單點式保障的模式。

另一個問題就是絕大多數的APP都缺少主動的問題感知以及智能的問題感知的能力，每每是被問題推進走，拆西牆補東牆的模式。同時還存在一個問題，當線上出現問題的時候，不少時候仍是靠線下猜想問題的緣由，缺乏一系列的數據和工具來支撐，如何提高定位問題，以及解決問題的效率。咱們是但願經過泛質量管理的解決方案，一方面整個質量管控是從測試域擴展到研發域，擴展到運維域、運營域，如何經過這樣一個全鏈路的鏈式的保障來實現咱們的總體質量管控。另一方面咱們也但願經過咱們的全鏈路的核心指標的監控體系去實現多個數據源的數據聚合、交叉分析，去儘量實現智能的一些問題的感知和一些風險的預判，而後經過咱們的全鏈路的排查工具，終端日誌的能力、遠程調試的能力，如何去提高定位問題的效率，如何經過咱們的熱修復的能力，快速的實現線上問題的即時修復。

這幅圖是手機淘寶高可用保障的流程方法論，在EMAS平臺上咱們經過EMAS DevOps的工做流體系把咱們平臺上的組件服務，像咱們的靜態檢測、移動測試、APM、移動日誌、用戶反饋、灰度發佈、雲構建、熱修復等等，把他們的流程、數據所有貫穿起來，而後提供給開發者一體化的開發體驗。

這裏能夠看到咱們的幾個核心指標，包括線上故障數的指標、線上故障修復的指標，經過這種開發方式都大規模的減小。

最後一部分是網關統一接入的解決方案，這裏咱們但願提供的能力。大量無線端的業務對網絡是強依賴的，咱們但願這裏有一個統一接入的解決方案，去解決API管理、限權限流、安全加密、流量優化等等，這些自己和業務解耦的網絡基礎設施的優化。包括咱們在集團內部有專門的網絡專家團隊來進行深度的面向移動場景的優化研究。

而後包括像移動端的API網關，其實也是一個移動應用很是核心的基礎設施，在咱們這個網絡解決方案裏面，咱們面向API也提供了一鍵編排的能力，從建立一個API到這個API在API網關的實時發佈，再到你的終端API的生存，再到你的API網關和數據的交互，經過這樣一個平臺，可以實現一鍵的部署。同時圍繞這個API的統計分析，限權限流、版本管理等等，都能在這個網絡解決方案裏面完成閉環式的管控。

咱們但願EMAS爲開發者從兩個維度提供真正的業務價值，也就是團隊方面和業務方面。在團隊方面，咱們但願經過EMAS一鍵複製阿里巴巴所沉澱的實踐標準，咱們的流程、方法論，幫助咱們的開發者儘可能少走彎路、錯路。本質上仍是但願經過這樣一整套解決方案，幫助開發者去提高企業內部的人均效能。在業務的視角來看，咱們也但願經過咱們這樣一整套的基礎設施，幫助開發者快速、高效地去構建一個高質量、高性能的移動業務。另一方面就是經過咱們的架構層面的能力輸出，幫助開發者去真正地構建一個優雅的APP底層的架構設計，避免在後續的業務迭代過程當中，這個業務會過於臃腫、龐大，而後會走樣、變形等等。

咱們提倡的理念是：企業互聯網+真正標誌是研發體系互聯網化。如今說的雲計算，你們更多理解爲IaaS層的服務，可是單純經過虛擬機替換原來的物理機，這樣的動做僅僅是資源層面的替換，並無辦法爲企業的研發效能提高帶來質的變革，而只有你真正實現了企業內部研發體系的互聯網+的升級，才能爲你企業內部的研發效能的提高帶來一個質的變革，而EMAS就是整個阿里巴巴近10年移動互聯網研發體系的具像化的載體。

今天在EMAS平臺上，已經有大量的行業客戶，與咱們並肩同行，將來咱們也但願有更多的客戶可以加入到咱們的研發生態當中。今天應該說移動互聯網已經事實上成爲整個社會最核心的基礎設施，因此咱們也但願經過EMAS這樣一個移動中臺，可以真正地賦能客戶，幫助他們去實現企業數字化、移動化的轉型，幫他們去構建這樣一個超級APP、業務運營的中軸，經過EMAS去支撐上層業務的快速創新。