App服務端架構變遷從2013年開始，我們先后進?了不同路徑的多樣性架構探索，在實踐過程中也經歷了各種曲折與壓?，最終實現了2015年的這個全新架構，實現了?線服務端基API 開發、測試與部署，?持運?期間的模塊實時加載、按需Lazyloding、Remote加載，從?實現模塊級動態升級以及代碼級熱修復，并且逐步推動數百?的客戶端研發團隊由不堪重負、效率低下的?版本??車開發模式向模塊間獨?迭代、發布輕量級的開發?向演進。Hybrid的優化等等，逐步保證隨著業務的不斷的迭代，能保證?戶的?較好的優化體驗。App服務端架構變遷早期App服務端架構早App服務端架構使?了傳統PC?線開發架構，即PC Web應?基礎上增加?些?線端REST接?直接供App訪問，沒有考慮架構的擴展性、靈活性、安全型等因素。圖1攜程?線服務端架構V11WebPCWebREST接?直AppWeb應?作為同??程開發，作為同?個應?部署，這種架構設計思路是很直接和?然的，可以快速把PCAppWebPCAppPC端應?的翻版，并把兩者物強耦合WebBug影響?線接?的可?Web應?。?線的接?，也存在著較為嚴重的耦合問題，這種耦合帶來的問題，最嚴重最明顯BUBugBU接?的穩定型，從?帶來每次發布，要帶來更多的測試回歸?作。重復造輪?App和后端系統直連，意味著每個后端系統都需要單獨?持這些通?功能，導致重復開發。?旦這些通?需求有變化（如對數據傳輸進?加密增強），所有后端系統都要強制同步修改和上線，給項?管理和產品發布帶來很?挑戰。穩定性AppAppCPU過多資源，其機票App的健壯性很差，?常脆弱。攜程App服務端架構V2.0基于架構V1.0三個?較嚴重的缺點，于是我們開始嘗試使??種新的?線架構V2：基于APIGateway的?線服務端架構?；谌鐖D2所?的?線APIGateway架構，具備如下功能特點。對等隔離端瀏覽器是對等的，PC端應?有服務端，App也需要??獨?的服務端，兩個服務端都需要針對??的特點，獨?開發，PC思維?線化。統?服務核?邏輯從Web應?剝離出來，進?服務化改造，服務實現時不區分PC和?線，App和Web應?都依賴于這些服務，?套接?，多?調?。統??線APIGateway?關??，保持系統的穩定性App調?指向ft?關，?關包括通?層、接?路由層、適配層。通?層包括通訊協議適配、數據封裝、安全、監?線APIGateway應該?前很多公司都有??的實現，?前市場上也提供了很多開源項?Zuul、Archaius、Hystrix、Eureka等幫助我們去實現??的Gatway。APIGateway具備的功能特點圖2攜程?線服務端架構V2.0NetflixZuulAPIGateway2GatewayAPI請求，并將GatewayAPIGateway具有的?個核?職能：路由、隔離、限流、熔斷、反爬、監控報警，具體如下所?：定期從路由服務獲取路由表，達到了解耦、實時更新的效果；經過通?邏輯預處理后，?線接?請求將進?步分發給后端處理（Adapter）URL和AdapterURLAdapterAdapter處理。隔離：由于Gateway接收了所有業務請求，請求多種多樣，當某類請求出問題時，不能影響其他請求處理。對ft，Gateway實現了資源隔離，防?某類請求將資源耗光，繼?影響其他服務。限流：對于任何?類請求，都設置了容量上限，并不能?限制處理。Gateway可以為每類請求設置并發上限，當到達上限時，Gateway將不在轉發請求，?是直接返回，保護后端服務。如果在后端服務過載的情況下，仍然轉發請求，只會惡化問題。Gateway引?了?個則停?向該服務轉發請求，稱之為熔斷，特定時間過去后，Gateway會探測ft服務是否恢復正常，正常則開始正常轉發，若不正常繼續熔斷。反爬：Gateway積極對接安全接?，會根據IP、clientId、以及算法校驗阻斷?法請求，保護后端服務。監控報警：Gateway接?了Cat、Clog、并對接了運維報警?具。當出現問題時，會及時報警，盡早發現問題，減少損失。APIGateway智能升降級Gateway?持集中管控的同時，也帶來單點問題。假設后臺某個服務接?，由于某種原因，性能有嚴重問題，對應Adapter處理很慢，那么3所?。圖3Gateway接??動升級降級流程圖它的超時失敗率到了?定?例（5%），?關會對該接?做降級處理，隨機50%525%，以ft類推。如果成功4倍，然后在下?個時間段再評估是否觸發升降級。整個過程全?動智能處理（為防?誤判，可?持???預），這樣單個接?出問題，不會影響整個?關的處理能?。攜程App服務端架構演進總結App做?做強奠定良好基礎，其帶來的好處是全??的，增加了架構的可擴展性、健壯性、穩定性、靈活性，并且提?了團隊的開發效率和團隊長遠的收益，其具體表現在：實現PC端應?和移動端應?分離，使兩者徹底解耦，各?獨?發展，App從寄?藤變成并蒂蓮。攜程在做Gateway架構的第?步就是做PC端和?線端的業務解耦，以及各BU之間的業務解耦，實現各BU?線業務和PC業務的獨?部署、獨?發布。底層核?的SOA服務基于統?業務規則提供邏輯和數據，接?不區分PC、?線或其他渠道（如OpenAPI），避免重復開發，避免業務邏輯被污染。所有前端?視同仁，?且如果以后增加其他端，也不需要做過的改動，其擴展性和靈活性能滿?新業務拓展的需要。實現內外部接?的?縫轉換，可以針對?線場景，做邏輯增強（如服務聚合，客戶端性能埋點、接?性能監控）等。App服務端PCH5相關的業務邏輯處理，各個研發團隊獨?研發和發布，不耦合，即各業務線研發團隊負SOAAdapter適配。攜程App客戶端架構變遷App早期架構攜程App的第?個版本在2011發布，那時候App架構很簡單，基本上就是在傳統的MVC的架構基礎上封裝了?個數據服務層即代理數據層，如圖4所?。圖4攜程早期客戶端架構V1AppAppMVC思路的?選。4MVCAppModel層則負責數據結構的描述以及數據持久化的功能；數據服務層作為數據的代理媒介層，主要負責與Control層進?數據通信，包括實現基礎框架數據通信，序列化和反序列的機制等；?移動界UI View層作為展現層負責渲染整App的UI。這種架構分?清晰，簡潔明了，并且這種系統架構在語?框架層就得到了Android和iOS的?持，所以?常適?App的開發。但是這種架構在開發的后期會由于其超?耦和性，從?造就龐?Controller層，?這也是?直被?所詬病。最終的MVC都從Model-View-Controller?向了Massive-View-Controller的終點，其最嚴重的結果就是Control層的代碼越來越多，在攜程內部很多類，早期都超過了2000?，同時Control層和View層之間存在?些較?的耦合。其對應的App?程結構架構如圖5所?：當時?論iOS和Android?程，都只有?個?程結構CtripWireless。圖5攜程前期App?程架構圖BUBU的業務耦合越來越嚴重，這個直接為后期插件化Bundle架構埋下了伏筆。基于攜程業務不斷快速發展，后來活躍?戶已經超過1億，?活?戶千萬，很快觸及到了當時Android虛擬機機制的設計缺陷，即移動端在Android上?臨了兩個?較嚴重的問題，這兩個問題導致的嚴重后果就是在2.3的系統??，?戶直接都不能安裝和使?。?是dex 65535?法數限制，?是線性內存分配器）限制。今天Android開發者看到這兩個限制都不會陌?。前者是因為Android的早dexid?16dex65535，eclipseproguard的deBugapk。后者則是dalvik虛擬機?來加載類的堆內存??被硬編碼了，2.3以下是5M，2.3以上是8M，致使App?法安裝的原因就是因為這個堆內存被耗盡導致dexopt失敗。GooglegradleAndroidStudio，開發者們可能MultiDex分dexmaindexdalvikLinearAllocheapsize調整（修改16M），dexoptARTLinearAlloc這樣的限制。Android2.350%的時代?，是如何通過軟件架構調整解決這個問題的，其中的經驗有我們值得借鑒和學習的地?。AppV2.0架構基于上述我們遇到的問題，我們在原來的傳統架構上?做了重新調整和優化，提出了移動端架構V2.0，其主要設計思路就是：App上已經承載了很多業務功能，但其中?些功能?戶使?頻率?較低，并且之前快速試錯被證6所?。圖6攜程移動架構V2要實現這個架構，第?步就是進?各個BU業務線的功能解耦，這個?作花費了整個團隊?概3個?時間3個App?版本的周期去進?。進?功能解耦的重要思想，就是實?輕重分離，主次分明的思想；在代碼模塊的組織架構上進?重要的調整，保證主要重要的App功能快速迭代和性能穩定，將附屬的使?頻率不?的新功能，使?H5容器進?動態加載，所以在V2.0的架構上，攜程App就是個典型的Hybrid，可以看到剛開始就核?模塊酒店和機票采?Native進?開發，其他模塊基本是采?H5去實現。

AppV2.0架構基礎上，做了?系列的?作就是將App中?較雞肋的功能?如客戶價值和轉化率低的功能轉成H5實現。這樣做的好處就是集中精?去優化Native業務體驗，同時也能減?Android因為?法數超標的限制壓?。在V2.0dex65535的問題，即將?程項???出現的不再使?的類和不再使?的?法進?了集中清理，這樣65536jar包、重jarjarjarjar包就能??的減少?法數。去實現，???減少開發成本，同時也是為了應對?法數增多的壓?。dex65535AppDex的??，使?新的技術進攻的?段去?勞永逸的去解決這個問題。BUBUUI界?邏輯和資源、存儲及?絡V2.0App7所?。攜程Dex動態加載?案實現

圖7架構V2.0對應的?程結構圖在當時為了徹底解決?法數溢出的問題，基于上?解耦的基礎上采?了多Dex分包?案，當時攜程的做法是借鑒Facebook提供的?案去動態分包，將?個apk中的dex?件分割成多個，然后動態加載dex?件。?先簡單描述下Facebook的思路：Dex形式攜程與Facebook的dex形式完全?致，這是因為我們也是使?Facebook開源?具buck編譯的。Dex類分包的規則Facebook將加載Dex的邏輯放于單獨的nodex進程，這是?個?常簡單、輕量級的進程。它沒有任何的ContentProvider，只有有限的?個Activity、Service。android:name=android:name="com.facebook.nodex.startup.splashscreen.NodexSplashActivity">所以依賴集為Application、NodexSplashActivity的間接依賴集即可，?且這部分邏輯應該相對穩定，我們?須做動態掃描。這就實現了?個?常輕量級的依賴集?案。加載Dex的?式加Dex邏輯也?常簡單，由NodexSplashActivity的intent-f ilter指定Main與LAUNCHER。?先拉nodex進程，然后初始化NodexSplashActivityActivity，若ftDex已經初始化過，即直接跳轉到主頁?。Facebook加載Dex的?案，其加載流程圖如圖8所?。圖8Facebook加載Dex流程圖這種?式好處在于依賴集?常簡單，同時?次加載Dex時也不會卡死。但是它的缺點也很明顯，即每次啟動主進程時，都需先額外啟動?個nodex進程。盡管nodex進程邏輯?常簡單，但是也需要加載時間100ms以上。但是攜程對這個啟動時間?常敏感，當時推動產品很難會去采?這個?案。基于這個?案的缺點，我們在其基礎上進?了優化?案，即能不能主進程直接加載Dex?案，具體定的?案策略如下。Dex形式Dex形式并不是重點，假定我們使?當前的Dex形式，即assets/secondary-program-dex-jars/secondary-N.dex.jar。Dex類分包的規則主Dex應該保證簡單，即類似Facebook，只需要少量與Dex加載相關的類即可，并且這部分代碼是相對穩定。我也?須去更改任何?加載相關的代碼。加載Dex的?式ApplicationattachBaseContextActivity。可能系統要起的是某?個Service或ReceiverNotification，這種跳轉?式是不?的。圖9MultipleDex加載流程圖ANR？1pthread_mutex_xxx、pthread_cond_xxx,mutex或cond要放于共享內存中，這種實現?式較為復雜，所95msTempFiledex的?作線程dexTempFile。關于問題2，在掛起主進程的同時，去啟動?個?作線程去加載dex，也就是這個線程是?UI主線程，不會造成阻塞UI主線程的情況，經過多次測試，也確實沒發?ANR現象，這個通過分析ANR現象的本質就能得出這個結論?；贔acebook的基礎上我們優化實現了動態加載Dex的?案，?較完美徹底地解決了因為?法數超標??法安裝的問題，同時也不?擔?隨著業務發展，代碼中?法越來越多的問題。2015EclipseAndroidstudioGradleGoogle?持了MutilDex?案，所以后來就直接使?了官?提供的?案。V2.0架構解耦之后，不同BU?程的依賴是解除了，良好的解決了以前各個不同BU相互依賴的問題，同時也可以?持多個團隊進?并?開發。但是這個階段的階段架構存在以下兩個明顯嚴重的問題：源碼依賴BUBU的正常開發?作。構建編譯速度慢10?個?程，因為不可選擇所以需全量編譯，所以3010分鐘以上，所以整個開發效率?較低，開發?員的體驗感也?較差。App架構V3.0V2.0V3.010V3.0V2.0的?程解耦升級BundleBundleApp由?BundleBundleDynamlicLoader中。圖10V3.0架構圖如圖10所?，應?層的酒店、機票、?車票等都是?個個獨?的APK，它們之間獨?開發，互相不受影響。最終統?以插件的?式集成到統?的攜程APK??。酒店和機票之間通迅?式采取兩種?式，BUS數據總線跳轉和URLScheme跳轉。V3.0架構對應的?程結構圖如圖11所?。圖11架構V3.0對應的?程結構圖1130個Bundle（apk），BundleBundle過多造成BUBundle，通過簡單的?句配置，將其加到?程中即可，同Bundle和源碼依賴，按需添加依賴即可。V2.0DexApp的現狀研發實現了?個動態加載的插件化框架Hotfix機制。在這??先簡單總結下?前市場上出現了?較著名的開1所?。表1市場主流插件化技術對?BU團隊需要很多額外的開發