汽车之家移动主App服务端架构变迁
聲明：本文為《程序員》原創文章，未經允許不得轉載，更多精彩文章請訂閱2016年程序員：http://dingyue.programmer.com.cn/
導語：汽車之家移動主App服務端架構經歷了從外包的無架構概念，到流量激增后的架構調整、重構等。本文主要介紹了其主App服務端架構演進歷程中面臨的主要挑戰、解決思路和實施過程。
隨著移動互聯網時代的到來，移動技術也隨之飛速發展。如今，App已然成為絕大多數互聯網企業用來獲取用戶的核心渠道。以往以PC為主要承載平臺的各業務線，源源不斷集成加入到移動項目中來，原本以產品為中心快速迭代的單一開發模式，已經無法應對這洶涌爆炸式的業務接入和高速增長。同時伴隨著用戶量的增長，流量的持續暴增，系統架構面臨的一系列挑戰和轉型。怎么構建出高可靠、高擴展、低成本、多快好省系統體系架構已成為業界樂而不厭的長談話題。
發展
2010年-2012年
2010年移動端剛剛興起，公司組建了移動團隊（剛開始就幾個人）帶領著一家外包公司做了第一版。當時業務十分簡單，即把PC端的論壇文章等直接搬App端進行展示，服務端也是ALL IN ONE的結構，也沒有架構的概念（如圖1），雖然系統耦合嚴重、但流量低也不見明顯的問題。
2013年-2014年
2013年公司上市，業務擴展，移動端流量開始增長，特別是2014年。
2014年末流量較年初增長了2.5倍。而原來的這種ALL-IN-ONE體系結構的弊端日益凸顯，服務端經常由于高峰期的訪問壓力宕機。這種高耦合的結構常常由于某一個接口的超限流量導致其他接口也不能正常訪問。
而隨著業務的不斷擴張，應用的不斷迭代導致應用的體積不斷增大，項目越來越臃腫，冗余增加，維護成本水漲船高……老架構力不從心。
面對日益嚴重的服務壓力，公司開始組建自己的移動研發團隊（C#+SQL Sever），服務端程序進行了第一次重構。
服務端程序進行對應用分層（接口層API、業務邏輯層Service、數據訪問層DAO）、分割（根據App端的各個模塊把原來的ALL-IN-ONE的結構分割成不同服務）、做動靜分離CDN加速、讀寫分離、集群負載。同時公司運維部根據我們的業務特點研發自己的CDN服務、二級緩存SCS服務對應用做進一步加速，經過這次改造，暫時緩解了服務端的壓力。
2014年-至今
我2015年初加入汽車之家，當時移動端面臨的問題如下：
請求量更大，應該說是流量暴增的時代：2015年9月，汽車之家移動端日均獨立用戶總訪問量較2014年9月同比增加約73.0%。2016年初移動端PV實現億級。
依賴資源多： 依賴Redis、DB、RPC、HTTP、MongDB、MQ、數十個業務。
垂直業務耦合嚴重：如帖子、文章最終頁和評論系統這種垂直耦合業務常常出現評論系統掛掉導致帖子或文章最終不能訪問的情況。
運營推廣活動多：為了增加用戶粘度，提高用戶活躍度，各個業務方和我們自己的運營推廣活動大量增加。
發版快：每月固定兩次發版，多版本并存。
微軟技術體系：微軟收費服務都需要大把白花花的銀子，且高質量的.NET工程師越來越難招，生態圈不太景氣。
為了應對流量的暴漲，服務的高可用性和團隊變大，所有開發人員集中針對同一個系統的嚴重沖突，App端進行插件化改造。服務端2015年初也開始了二次重構計劃，進行了一次脫胎換骨的轉型，全面擁抱Java，主要的技術改變有：
Windows→Linux、SQL Server→MySQL、IIS→Tomcat、C#→Java。
重構
需求方面主要有這幾點：文章、帖子的評論這種垂直業務不能掛掉；業務爆發能夠快速實現；依賴（多業務方、多資源）解耦，故障時絕對不允許相互影響。
解決方案分為以下幾步：
分解。首先是團隊：根據App插件化的劃分，對服務端團隊研發人員進行分組，各小組只負責自己的模塊，每月固定的兩次迭代，各小組服務獨立上線互不影響。其次是服務結構，包括水平擴展：多集群、多機房部署提高并發能力和容災能力；垂直拆分：垂直業務進一步拆分，依賴解耦；業務分片：按功能特點分開部署，如活動、秒殺、推送等物理隔離；水平拆分：服務分層，功能和非功能分開，基礎核心服務非核心服務分開。
業務服務化，相互獨立，如咨詢、論壇、廣告等。
無狀態設計。調用鏈路無單點、無狀態服務，可線性擴容（盡可能不要把狀態數據保存到本機、接口調用做到冪等性）。
可復用。復用的粒度是業務邏輯的抽象服務，不是服務實現的細節、服務引用只依賴服務抽象。
資源分層。Redis、DB、MQ 主從設計，多機房部署、保障高可用。
松耦合、自保護、防雪崩。跨業務調用盡可能異步解耦，必須同步調用時設置超時、隊列大小、線程池大小、相對穩定的基礎服務與易變流程的服務分層；線程池保護，超出服務器最大線程時DROP請求（Nginx、Tomcat）。Redis、DB、MQ、Turbo（RPC）、HttpClient等在后端資源出問題時可以自動降級請求調用、發送異常報警。
服務隔離可自理。服務可降級、可限流、可開關、可監控、白名單機制。
各個服務獨立部署互不影響，服務異常自動熔斷，根據各個服務特點走相應的降級策略。基礎服務下沉可復用基礎服務自治、相互獨立、基礎服務要求盡量精簡可水平擴展、物理隔離保證穩定（如用戶中心、產品庫）。
分清核心業務。核心業務服務盡量精簡，利于穩定（運行時優先保證主流程順利完成、輔助流程采用異步：如日志上報）。
實現
- 單服務的體系結構
App端請求經過接入層（CDN、LVS、NG/SCS），通過接口控制層的設置校驗（CDN配置、反劫持配置、日志服務配置、安全校驗……）調用API層發布的REST接口，通過參數校驗后調用業務邏輯層的業務實現。同時業務邏輯層通過數據接口層（SourceInterface源接口服務、DbUtils數據庫分開分表組件、AIS4J異步請求組件、Trubo RPC服務）調用資源層的資源服務來完成本次業務的數據組裝，完成本次業務的調用。
配置方面，一個基于zookeeper的配置服務（配置服務用于系統的各種開關的實時配置如：源接口的限流熔斷閾值等）；Monitor：監控服務實時查看系統異常、流量；Trace：系統跟蹤服務；Log：（日志服務）。
- RPC-Trubo體系結構
為了應對服務化作服務自理，2015年底我們全面啟用公司的RPC服務Trubo
框架特點主要有：多語言服務端發布，支持C#和Java；高效透明的RPC調用，多協議支持；基于ZooKeeper的注冊中心，用于服務發現；客戶端軟負載和容錯機制；使用Spark進行服務監控與跟蹤Trace分析；整合Locker（Docker調度平臺），實現服務部署自動化。
服務發現與RPC穩定性和容錯方面，主要是雙機房部署ZooKeeper集群，主力機房5個節點（Leader/Follower集群），其他機房2個節點（Observer節點），保證性能和穩定性；Trubo客戶端服務端添加守護線程，定時校驗本地緩存和ZooKeeper的數據一致性；Trubo客戶端會將緩存的服務信息持久化到本地，即使ZooKeeper掛掉或者重啟也不影響正常調用；嵌入Trace客戶端上報收集分布式跟蹤日志。
- 異步請求組件AIS4J
為了解決接口和資源依賴問題（源站或Redis、DB等資源層掛掉導致我們服務不可用的高風險），同時也為了請求響應時間受到源站依賴問題，我們封裝了異步請求組件AIS4J。同時嵌入我們的熔斷限流組件來對源站進行解耦。
引入AIS4J后大大緩解了對外部資源的依賴，提高了服務的可用性，但同時也帶來了一些問題。公司要求對緩存內容時間限定在10分鐘以內，原來的時間被平均分配到了CDN和我們的二級緩存SCS上，現在加入這個組件為了滿足10分鐘的要求必須把原來的10分鐘拆分到AIS4J上，這就需要增大系統接口的回源率（10%左右）。這個時間就要對請求時間和系統壓力上做一個權衡。
服務監測
就目前階段來說，服務分解封裝應對一段時間的流量增長已沒太大問題。但為了保證服務的高可用、系統的擴容預估、故障的實時定位……就必須有一套完善的監測報警系統。
圖7是系統調用追蹤服務，通過對程序Java的Instrumentation和配置系統對系統程序進行埋點跟蹤，再通過Spark對跟蹤日志進行實時分析展現。
Trace實現
Trace ID標識唯一調用樹，Transaction ID標識唯一次調用，一次Trace調用會產生四條日志，Trace調用樹可以由Turbo、本地調用、HTTP或其他調用方式組成，Trace客戶端是獨立的，Turbo單向依賴Trace。
同時我們在APP端的請求頭中埋入Req ID，通過Req ID和Trace ID的對接記錄一次請求過程（CDN、SCS、后端服務、RPC/HttpClient調用）每一步的時間消耗。
為了更快的定位穩定，我們在程序中預設了Debug模式，在內網環境中只要拿到請求的URL開啟Debug模式就可以快速的調出系統調用資源鏈和每一步的程序調用消耗時間。
報警實現
通過Spark對日志記錄的分析結果，會實時對接到我們的報警系統上，實現對程序異常的實時報警。報警系統通過短信、郵件方式發生，內容中包含請求的Trace ID超鏈到報表系統實現對異常問題的實時查看定位。
作者簡介：湯泉，2015年加入汽車之家，參與到移動主軟件服務端的架構設計與開發。
責編：錢曙光（qianshg@csdn.net）
本文為《程序員》原創文章，未經允許不得轉載，更多精彩文章請訂閱2016年程序員：http://dingyue.programmer.com.cn/
2016年4月22日-23日，由CSDN重磅打造的SDCC 2016數據庫&架構技術峰會將在深圳舉行，目前18位講師和議題已全部確認。兩場峰會大牛講師來自百度、騰訊、阿里、京東、小米、唯品會、滴滴出行、攜程等知名互聯網公司，共同探討高可用/高并發/高穩定/高流量的系統架構設計、秒殺系統架構、搜索架構、中小企業架構之道、數據平臺系統演進歷程和技術剖析、傳統數據庫與分布式數據庫選型/備份/恢復原理及優化實踐、大數據應用實戰等領域的熱點話題與技術。【目前限時6折，點擊這里搶票】
總結
以上是生活随笔為你收集整理的汽车之家移动主App服务端架构变迁的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 路由器和三层交换机的基本实验操作
- 下一篇： iphone避坑指南