一文縱覽EMAS 到底內含多少阿里核心技術能力
申請阿里雲EMAS,體驗一站式移動研發平臺,更多精彩盡在開發者會場
EMAS的整體定位是阿里巴巴移動技術對外輸出的主視窗,沉澱了阿里巴巴近10年在移動網際網路技術架構上的積累以及在一系列垂直場景中所實踐的核心技術能力。一方面,EMAS希望為廣大開發者提供安全、穩定、快速、彈性的移動應用基礎設施,另一方面也希望幫助廣大中小企業、初創團隊以及處於“網際網路+”轉型階段的傳統企業構建工程化、系統化、智慧化的企業級移動網際網路研發體系,並將近十年來阿里巴巴在移動網際網路總結和沉澱的一系列方法論分享給業界。
從2015年第一個產品公測開始,到目前為止EMAS總共服務了近14億移動終端裝置、20萬App以及10萬移動開發者,在一定程度上也影響了整個國內移動開發生態的發展。
隨著技術形態的不斷演進,移動網際網路已經成為全球商務生態系統當中不可或缺的一部分。用一句話形容EMAS的願景就是“30天和你一起再造一個手機淘寶”。這背後的含義就是無論規模多小的創業團隊都可以基於EMAS的服務快速便捷地擁有像手機淘寶、支付寶一樣完善的基礎設施,可以低成本地擁抱移動互聯時代。當前EMAS處在快速向前迭代發展的階段,未來也會有越來越多的阿里巴巴集團內部優秀的移動基礎服務通過EMAS平臺對外開放。目前EMAS開放了一個研發支撐平臺、九大公共雲產品服務、五種場景解決方案以及兩種專有云產品服務。
EMAS將整個移動應用開發劃分成了5個職能域:專案域、工程域、構建域、運維域和運營域,並且面向這5個職能域形成了移動中介軟體基礎解決方案。
在解決方案環節,阿里巴巴已經開源了面向Android的應用容器Altlas以及跨平臺的UI開發框架Weex,圍繞這些開發框架也會提供相應的商業化版本解決方案,幫助開發者更便捷地完成App的建立和管理。通過端+雲的緊密配合為移動開發者提供全鏈路端到端的移動研發解決方案。在專有云環節提供了面向傳統企業開發企業級應用研發服務EMAS,希望打包整個阿里巴巴集團近10年移動網際網路研發體系的積累,並以SaaS化的服務形態一鍵複製我們的能力、經驗,我們的流程、機制和方法論,希望幫助更多的傳統企業快速地完成業務移動化的轉型升級目標。
基於上述提到的這一套端到端的全鏈路移動應用研發體系,阿里巴巴也提出了一種新的移動App研發正規化——Cloud Native App。
傳統的Cloud Native概念主要是面向後端應用的,利用容器、微服務、持續整合、持續構建以及DevOps這一套雲化的架構來構建應用,其本質則是一套應用構建的方法論,怎樣充分地利用雲端計算服務模型的優勢來低成本、快速地構建彈性的應用,這樣一套方法論在移動App場景中同樣適用。比如基於面向移動端Serverless的架構實現App執行環境的透明化和按需擴充套件,基於雲上開放的移動App DevOps實現研發流程流水化,支撐應用的高效交付,基於雲上的移動中介軟體體系實現所有的基礎設施服務化,按量付費,基於Weex/Atlas賦能應用,真正實現大型App元件化和跨平臺的能力。這樣一套Cloud Native App研發正規化能夠真正幫助開發者去降低業務本身的技術風險,把自己有限的資源投入在和本身業務快速增長的工作上。
接下來分享阿里巴巴在移動App的研發關鍵路徑上所開放出來的一系列的核心能力,主要分為了幾個關鍵環節:網路、訊息與資料、應用質量和高可用以及企業級移動應用研發服務EMAS。
(一)網路
網路是所有移動App非常關鍵的基礎模組。Google之前對搜尋系統有做過相應的統計評測,搜尋系統延遲每上升400毫秒,搜尋量業務量就會降低0.59%,雖然這一相對值看似比較低,但是在Google搜尋體量背後也是非常大的損耗。雅虎整體Web系統的延遲每上升400毫秒,流量就會下降5%到9%;Bing延遲每上升2秒,整體收入下降4.3%;而對於Mozilla,延遲每降低2.2秒,下載量就會提升15.4%。所以說網路這個環節不僅僅和移動端體驗息息相關,同時也直接決定著產品的核心商業指標情況。
在網路環節,阿里巴巴也有非常深厚的沉澱。首先從網路最開始的階段、最前置的環節來看就是流量排程和域名解析。傳統DNS解析體系存在很多問題,比如域名劫持的問題,以及由於本身的排程精準性帶來的網路訪問質量降低的問題,還有在移動場景本身域名解析的延遲有200毫秒左右,而這樣的延遲對於本身使用者網路訪問也會帶來一定的體驗上的損耗。傳統基於B/S架構瀏覽器的Web應用,對於開發者而言都是黑盒,很難針對網路環節進行優化,到了移動網際網路時代,移動App基本上以C/S架構形態構建的,這樣一個形態和架構特性意味著有更多的針對客戶端的定製和優化的空間。在這樣的背景下,HTTPDNS應運而生,它替代了傳統DNS解析路徑的服務質量最不可控的LocalDNS環節。
HTTPDNS有以下幾個特性:
• 防劫持,因為LocalDNS環節往往沒有商業化的SLA保障,而通過這樣的方式可以徹底地規避域名劫持問題。同時基於全網的BGP Anycast的部署可以實現全網客戶端就近接入的能力,同時通過遍及全網的多機房的容災可以保障商業化的服務SLA。另外一方面,HTTPDNS和權威DNS之間也是通過EDNS進行直連的,這意味著可以基於客戶端IP進行精準排程。在傳統的DNS體系中,一般權威DNS進行排程的時候是基於LocalDNS代理節點進行排程的,一旦LocalDNS的分佈不是很均勻,就會降低CDN域名解析等的精準性。
• 0延遲解析,因為移動App是C/S架構的,所以在端上會提供SDK,可以通過像預解析、智慧快取、懶載入等特性把每一次DNS解析延遲從使用者網路請求當中抽離出來非同步地在後臺進行實現,這樣可以在真正意義實現零延遲解析,進而降低每次網路請求的延遲開銷。
• 解析變更秒級生效,由於HTTPDNS和權威DNS之間是存在相應的互動的,解析域名的實時變更可以同步到HTTPDNS這邊,這樣全網變更秒級生效在傳統DNS體系下是無法實現的,這是因為LocalDNS本身會進行IP快取,很多時候對於IP快取並不遵循標準TTL協議,所以會導致了變革在全網生效有很大的延遲。
• 軟體定義解析能力,通過這個能力使用者可以基於自己業務訴求來進行自定義的流量排程,這樣的能力在A/B Test、版本灰度以及安全流量排程等場景下都有很大的利用空間。
• 基於現在對於網路流量資料的評測,HTTPDNS已經成為整個移動網際網路中非常重要的域名解析和流量排程的基礎設施。
域名解析之後就是網路請求的主體環節。對比有線網路,行動網路一個很重要的特點就是多了一個移動鏈路環節,其整體丟包率、穩定性以及延遲對於有線網路都有所不足。通常稱這個鏈路為Lastmile,如何解決Lastmile通訊效率的問題也是行動網路優化最為核心的課題。對於普通的開發者而言,整個網路鏈路是以黑盒形態存在的,所以開發者針對網路形態所能做的網路優化的空間是非常有限的,如果需要專門針對行動網路進行優化則需要聘請相應的專家針對協議層面進行相應的優化,所以整體資源的投入和維繫的成本以及門檻也是比較高的。基於此,阿里巴巴也會開放內部的網路優化體系——移動加速服務,希望能夠從端、管、雲三個層面幫助開發者完成App網路整體立體式優化。
傳統的App網路訪問鏈路從客戶端發出請求是通過公網路由進行原站訪問的,而通過移動加速,App發出網路請求首先會就近接入遍及全網的加速節點,通過加速網路進行快速的路由選擇再回原站訪問。這樣的整體收益就來自以下三個方面:
• 在“端”方面,移動雲會提供網路託管SDK,通過託管SDK和加速節點配合,真正意義上構建雙端加速模型。傳統CDN是典型的單端加速模型,而雙端加速模型的一個很重要的優勢就是從客戶端到加速節點之間的鏈路由於雙端都有控制,可以進行傳輸協議的協商和實現。在這樣一個雙端加速模型上可以針對傳統四層的TCB協議的一些缺陷進行深度優化定製。
• 在“管”方面,移動雲擁有遍佈全網的海量就近接入節點,在頻寬以及鏈路等方面質量都是非常優異的。同時,傳統CDN是短連線的形態,每次發起的業務請求在結束之後可能就被釋放掉了。而在移動加速場景下,從客戶端到加速節點到原站之間實現了全鏈路的長連線,可以大幅度削減在網路通訊過程中的三次握手以及安全握手等冗餘的開銷。另外在動態路由方面,全網會有海量的加速節點,通過這些加速節點可以實時地、智慧地去計算從就近加速節點到使用者原站之間應該通過怎樣的路由使得整體的延時更優化,進而降低每次網路訪問的延遲。
• 在“雲”方面,傳統CDN實現的功能是靜態資源的快取、分發能力,同樣的移動加速會繼承傳統CDN靜態資源快取分發能力,同時對於像HTML、JS、CSS等面向Web化的資源也會進行動態的資源優化,進一步壓縮鏈路上網路頻寬的訴求,提升網路訪問的效率。
對比於傳統的CDN,移動加速就是CDN面向移動場景的解決方案。在雙端加速模型,的背景下,可以針對訪問鏈路進行協議定製優化,同時在連線層面可以實現真正意義上的全鏈路的長連線,大幅削減安全握手、三次握手等冗餘開銷。加速網路內部在端上引入機器學習的元素,可以通過智慧判斷分析對於當前的客戶所處的當前環境到底應該選擇使用加速鏈路還是公網路由。基於雙端加速模型,可以進行優化定製,對於HTTPS的加密協議也可以進行深度定製,可以實現效率上的提升。
除了域名解析和網路優化之外,行動網路還有非常多的場景訴求,比如說網路撥測、網路體系監控、資源上傳、遠端呼叫、網路診斷等,行動網路本身是內聚性非常強的閉環場景。App對網路訴求可以用四個關鍵詞概括:高速、穩定、可控,可視。
(二)訊息與資料
移動網際網路進入到下半場,人口流量紅利也在慢慢退去,如何實現更精準的客戶觸達和留存成為每一個產品最核心的運營指標。如果說大家之前有關注過手淘的“雙11”會場頁面會發現手淘已經實現了“千人千面”能力,同時基於資料智慧訊息推送系統在線上運轉多年並且取得了非常好的成績。現在阿里巴巴也會把這些產品能力背後的核心技術開放出來,幫助大家實現對於客戶的拉新、促活、留存和轉化。
面向運營域,阿里巴巴會開放經歷多年“雙11”歷練的訊息推送系統。在送達方面開放整個阿里系共享的訊息推送通道,結合廠商合作伙伴提供的基於多訊息推送通道的通送解決方案保障整體送達效果。延遲方面,會針對行動網路場景進行深度優化和定製,同時面向IOS推送場景提供相應的中美高速通道專線,保障每一次任務的及時下發和網路秒級應答。在流量方面,每秒百萬級別訊息裝置的吞吐率意味著在面對類似“雙11”這樣的強脈衝計算的場景下,也能夠及時地對於推送業務進行應答。
除了傳統PaaS層推送通道之外還會進一步開放複合推送的能力,基於移動推送+簡訊推送組合面向客戶提供更彈性的觸達終端使用者的解決方案。在複合推送的模型下,優先通過應用鏈的訊息推送進行客戶觸達,在訊息推送沒有辦法觸達客戶的情況下就通過簡訊推送進行補償。一方面可以利用簡訊推送的高觸達率保障營銷任務的觸達效果,另外一方面也可以利用訊息推送本身的低成本進一步地降低營銷任務背後的成本開銷。
阿里巴巴也會進一步開放集團內部的基於大資料的智慧推送的能力,基於個性化推薦引擎可以構建企業完整的使用者畫像,基於使用者畫像標籤、終端使用者地理位置資訊、終端狀態資訊以及每一次推送具體的內容等多個輸入源進行智慧的裝置圈選,有效地提升推送的精準度,能夠幫助客戶實現真正意義上基於大資料的精準定向營銷。
(三)應用質量和高可用
移動網際網路發展到今天已經累積了幾萬款移動終端裝置,海量的機型和作業系統以及解析度構成的配置組合給移動應用本身的質量保障帶來非常大的挑戰。
傳統測試模式基於人工,不管在測試覆蓋度、測試效率,還是Bug檢出率方面已經無法完全應對測試本身複雜度的指數級增長。基於這樣背景阿里巴巴開放了內部的真機測試服務平臺——移動測試服務,其包括了真機適配、功能自動化、雲端除錯、線上錄製、效能測試以及H5測試等方面的能力,希望能夠從公共雲和專有云兩個渠道幫助不同訴求的客戶一起保障移動App高質量的交付。
移動雲面向移動App還推出了線上問題一鍵熱修復的解決方案Sophix,針對Native App發版節奏慢,更新週期長的問題提供端到端一體化的熱修復解決方案,Sophix可以面向程式碼、資源、SO檔案三個維度進行修復,接入成本非常低廉,對應用沒有侵入,幾行程式碼可以完成整體接入,補丁包採用差量技術進行更新,從Patch生成、灰度、線上釋出和統計能夠幫助開發者實現一站式線上故障應急處理的解決方案。
移動應用質量管理高可用這個體系類似於上述的行動網路體系,也是內聚性非常強的閉環場景,在這樣的場景內阿里巴巴沉澱了非常多的能力,比如資料探勘、分析梳理、面向終端日誌採集分析處理等等。
(四)企業業務移動化
除了上述提到的公有云開放的幾個場景能力之外,面向專有云、傳統企業、面向企業移動化浪潮,阿里巴巴也會開放相應的解決方案。
傳統企業進行業務移動化過程中會面對各種各樣的研發協同挑戰,存在著很多面和點的問題,為了應對這些問題,阿里巴巴開放了企業級移動應用研發服務EMAS。對於傳統企業而言企業“網際網路+”的標誌是研發體系的網際網路化,單純在資源層面通過雲上虛擬機器替換傳統的物理機並不能帶來本質的變革,只有真正實現了傳統體系內部研發體系的“網際網路+”的升級,才能夠真正為傳統企業內部研發效能的提升帶來質的變化。EMAS希望打包整合阿里巴巴近十年研發體系以及能力、經驗的積累,希望幫助更多的傳統企業快速構建工程化的移動應用研發體系,完成企業業務移動化的轉型升級目標。
EMAS研發支撐平臺覆蓋從研發管理到持續整合、自動化測試、版本管理、灰度釋出、監控大盤、系統運維、使用者運營等完整的全流程生命週期管理,是移動網際網路沉澱的這套流程、機制、方法論很重要的載體。同時配合在雲上提供的移動中介軟體基礎服務體系,可以從真正意義上面向開發者提供移動應用研發全棧解決方案。
上圖所示的就是完整版的EMAS能力交付的全景圖,除了剛才介紹的傳統從端+雲+資料這樣一套能力棧中軸之外,也會開放阿里巴巴沉澱的軟能力,幫助研發者構建軟硬一體化完善的研發體系。
原文連結
更多技術乾貨 請關注阿里云云棲社群微