本文根據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去支撐上層業務的快速創新。
原文釋出時間為：2018-04-19
本文作者：泠茗
本文來自雲栖社群合作夥伴“
淘寶技術”，了解相關資訊可以關注“
”。