隨著智慧裝置普及和移動網際網路發展，移動端應用逐漸成為使用者新入口，重要性越來越突出。但企業一般是先有PC端應用，再推APP，APP 1.0版的功能大多從現有PC應用平移過來，沒有針對移動自身特點考慮APP的架構。隨著APP越來越複雜，功能和非功能要求越來越高，架構的先天不足逐漸成為大型APP升級的瓶頸。

本文作者結合大型移動應用的落地實踐，從服務端架構設計角度，闡述如何進行升級優化，為後續APP做大做強奠定架構基礎，供大家參考。

本文主要內容包括：

• V1架構
• 問題分析
• V2架構
• 智慧升降級
• 總結

V1架構

APP分手機端和服務端，手機端負責UI，相對簡單，服務端負責提供資料和業務邏輯，相對更為關鍵。APP1.0版的服務端架構比較簡單，一般在原有PC端Web應用的基礎上增加無線介面，供APP呼叫，如圖一所示。

服務端系統一方面以Web應用的方式提供給PC端瀏覽器訪問，另一方面為支援移動，在Web應用基礎上增加一些REST介面直接供APP訪問，相應地，無線介面和Web應用作為同一工程開發，作為同一個應用部署，這種設計思路是很直接和自然的，可以快速把PC端功能複製到APP。

問題分析

上述設計是在現有Web應用上打補丁，體現的是PC思維無線化，把APP簡單作為PC端應用的翻版，並把兩者物理上捆綁在一起，帶來一系列的問題：

緊密耦合

無線介面和Web應用緊耦合，Web端的修改會影響無線介面，Web端的釋出導致無線介面被動連帶釋出，Web端的bug影響無線介面的可用性，反過來也一樣，無線介面的任何變化會影響Web應用。

重複開發

無線介面除了給APP提供業務資料，還需要考慮一系列非功能性因素，如通訊協議和資料格式封裝、安全控制、日誌記錄，效能監控等，這些對每個無線介面都適用。如果APP和後端系統直連，意味著每個後端系統都需要支援這些通用功能，導致重複開發。一旦這些通用需求有變化（如對資料傳輸進行加密增強），所有後端系統都要強制同步修改和上線，給專案管理帶來很大挑戰。

穩定性

APP和多個後端系統直連，只要一個系統出問題，就會影響APP的可用性，缺乏故障隔離機制，導致APP非常脆弱。

這些問題本質上是因為沒有把Web應用和APP做清晰隔離，導致相互影響，一損俱損。

那麼如何實現有效隔離呢？首先兩者共享核心的業務邏輯，所以核心業務邏輯要獨立出來，以一致的方式供APP和Web呼叫；同時，無線介面服務於APP，和Web前端沒有任何關係，需要進一步對它們進行剝離，單獨維護和部署，經過拆分後架構如圖二所示。

圖二 系統拆分示意

V2 架構

除了APP和Web應用拆分，架構改造還必須考慮APP自身的特點。APP一方面需要從服務端各個系統獲取資料，這個是個性的，面向業務；另一方面所有呼叫需要非功能性的通用處理，這個是共性的，並且和業務無關。架構上需要做到統分結合，共性統一處理，個性分散處理。

最後，結合APP/Web拆分需求和APP自身特點，新的APP架構方案如圖三所示。

圖三 APP 2.0 架構

對等隔離

APP實際上和PC端瀏覽器是對等的，PC端應用有服務端，APP也需要自己獨立的服務端，兩個服務端都需要針對自身的特點，獨立開發，獨立部署，同時實現邏輯和物理層面的解耦，從架構層面徹底擺脫PC思維無線化。

統一服務

核心邏輯從Web應用剝離出來，進行服務化改造，服務實現時不區分PC和無線，APP和Web應用都依賴於這些服務，一套介面，多方呼叫。

統一閘道器入口

提供統一的無線閘道器，所有APP呼叫指向此閘道器，閘道器包括通用層、介面路由層、適配層。

• 通用層
  通訊協議適配、資料封裝、安全、監控、日誌這些系統級功能，每個介面呼叫都需要同樣邏輯，這些功能統一由閘道器前置處理，避免重複開發。具體實現時，每個通用處理邏輯封裝成攔截器，遵循統一的過濾介面，並且做到可配置，閘道器依次呼叫這些攔截器，這樣可以支援通用邏輯的靈活擴充套件。
  攔截器介面定義如下：

Object filter(Object input) throws Exception

• 介面路由
  經過通用邏輯預處理後，無線介面請求將進一步分發給後端處理（各個Adapter）。URL和Adapter在配置檔案裡做對映，分發邏輯根據請求中的URL資訊，找到對應的Adapter，然後把請求交給Adapter處理。
  配置例子如下：

www.Website.com/search SearchAdapter
www.Website.com/detail1 DetailAdapter

• 服務適配
  外部無線介面和內部SOA介面的輸入輸出格式以及通訊協議很可能不一樣，比如前者經常是HTTP+JSON格式，後者可能是Hessian+二進位制格式，Adapter首先用於無線介面和內部SOA介面的適配，除此之外，Adapter還可能對多個SOA服務做聚合，對APP提供粗粒度的資料，以減少遠端網路呼叫次數。實現上一般每個業務系統有一個Adapter，負責本系統無線介面的呼叫適配。
  Adapter介面定義如下：

Object adapter(Object input) throws Exception

Adapter物理上是jar包，由各個業務線研發團隊提供，作為相應SOA服務的前置，最終所有Adapter集中部署在閘道器，閘道器本身支援水平擴充套件。

智慧升降級

閘道器支援集中管控的同時，也帶來單點問題。假設後臺某個服務介面，由於某種原因，效能有嚴重問題，對應Adapter處理很慢，那麼閘道器所在伺服器的執行緒很快被耗盡，導致單個介面拖垮整個系統。這種問題，單純通過加機器，水平擴充套件閘道器數量是解決不了的，實踐中，我們引入智慧升降級機制快速隔離單個介面的影響，如圖四所示：

圖四 智慧升降級

針對特定一個介面，如果在一定時間間隔內（比如5秒鐘），它的超時失敗率到了一定比例（比如2%），閘道器會對該介面做降級處理，隨機拋棄部分流量，比如只允許50%流量通過。下一個5秒再評估，如果失敗率還沒有改善，允許通過的流量降到25%，以此類推。

如果成功率好轉，閘道器對該介面做升級處理，提升通過的流量比例，為了快速恢復，一般提升到原流量4倍，然後在下一個時間段再評估是否觸發升降級。

整個過程全自動智慧處理（為防止誤判，可支援人工干預），這樣單個接口出問題，不會影響整個閘道器的處理能力。

總結

APP服務端架構通過一系列的拆分和整合，既優化了公司整體應用架構，又為APP做大做強奠定良好基礎，其帶來的好處是全方面的：

1. 實現PC端應用和移動端應用分離，使兩者徹底解耦，各自獨立發展，APP從寄生藤變成並蒂蓮。

2. 底層核心的SOA服務基於統一業務規則提供邏輯和資料，介面不區分PC、無線或其他渠道（如Open API），避免重複開發，避免業務邏輯被汙染。所有前端一母同胞，本是同根生。

3. 根據無線本身的特點，支援系統層面的集中處理和業務層面的分散處理。通用邏輯支援外掛化擴充套件，可以根據需要逐步補充；Adapter實現內外部介面的無縫轉換，可以針對無線場景，做邏輯增強（如服務聚合）。前面師傅領進門，後面修行靠各媽。

4. 移動研發團隊和各業務線研發團隊各司其職，每個團隊專注於自己擅長部分，移動團隊負責APP客戶端和閘道器通用邏輯處理，各業務線研發團隊負責底層SOA服務及前端Adapter適配。上帝的歸上帝，凱撒的歸凱撒。

如果用一個字描述APP架構，V1是“爪”，年幼依託各家；V2是“丫”，長大獨立成家。

新架構，大型APP的成年禮，你“Y”準備好了嗎？