對話架構師：魅族應用商店雲端架構實踐

本文系魅族Flyme架構師胡成元，在Boss直聘主辦的直聘學院「對話架構師」活動上的分享整理，介紹魅族應用商店雲端架構實踐的總結。

胡成元，Boss直聘「直聘學院」特邀分享嘉賓。2011年加入魅族，一直致力於移動應用架構研發，提高產品體驗和研發效率。 目前主要負責魅族應用商店的研發工做，關注服務化、分佈式、NoSQL、大數據等領域。

如下是分享實錄整理：《 魅族應用商店雲端架構實踐 》

魅族應用商店做爲國內最先的應用分發平臺，積極探索，獨創了許多新業務模式，比較典型的：應用內付費。受限於早期的封閉生態，其發展速度緩慢，這並不影響魅族人對技術架構的追尋與創新。

水平分層、垂直拓展
應用商店首先定位於應用管理平臺，其次更是應用分發平臺，其典型業務場景包括：
幫助Flyme用戶找應用；
幫助Flyme開發者推廣、分發應用；
營造維護應用分發生態圈。

根據業務場景，不難推導出業務架構特色：
讀多寫少；
請求量大、併發高；
系統要求延時低；
數據規模可控；
用戶關聯弱。

隨着用戶規模的增加，不斷的重構、線上運行、探索與沉澱，逐步造成了當前平臺的架構。以下圖所示。橫向、典型的三層架構；縱向、以業務爲驅動，積累沉澱了衆多技術規範、基礎組件，豐富完善全棧業務監控。依託完善的監控體系，衍生出相應的服務治理機制。

服務化框架
平臺早期，規模小、結構簡單。伴隨公司互聯網轉型，用戶規模高速增加、業務增多，平臺關係複雜、擴展難、開發效率低，原有架構徹底沒法服務大規模的Flyme用戶。

爲了減小業務依賴、提高集羣效率、提升開發部署效率，咱們基於業務典型場景，把業務邏輯模塊化，單元化。拆分出了應用管理、應用展現（榜單）、應用推薦（個性化推薦）、應用搜索等多個服務。

服務分爲兩類，一類是基礎服務，該類不依賴其餘服務，業務邏輯簡單，僅提供基礎業務邏輯，例如應用管理服務。另外一類是聚合服務，該類聚合多個基礎服務，造成相對複雜的業務邏輯，例如應用搜索服務。

成型服務化框架能知足大衆化的需求，如遠程調用、動態發現、負載均衡、監控等，同時勢必會引入一些無關的功能，影響性能。外加此類產品沒法知足咱們的定製化需求，咱們重複造輪子。

與以往同類產品不一樣，咱們作了以下改進：
精細化度量指標
實時度量計算
系統依賴、調用鏈
無縫IT系統集成

服務間採用自研的Kiev框架通信。Kiev底層通信基於Netty網絡框架，序列化支持協議支持Hessian、Protobuffer等，支持跨語言（C/Java）調用，通信協議支持TCP、UDP等。框架基於ZK(ZooKeeper)實現了High Availability與Load Balance策略。服務調用時會採樣，生成詳細的調用鏈，收集，產生豐富的服務狀態數據（Response Time,QPS），爲服務治理提供了詳實有力的數據支撐。

消息隊列（MetaQ）
消息隊列是分佈式應用間交換信息的一種技術。爲了解核心業務及輔助業務，咱們引入消息隊列，將搜索團隊、大數據團隊須要的業務數據按期全量同步，實時增量更新。既隔離了業務間的強耦合，又保障了數據的及時性。

接口規範
接口衆多、形式多樣，管理維護成本高，爲了規範開發流程、便於問題跟蹤定位，咱們制定了統一的接口規範。例如接口採用RESTful風格，統一接口返回形式，約定每一個業務層的錯誤編碼，每一個錯誤編碼還會攜帶可選的錯誤提示，方便問題跟蹤。

安全性也是平臺不可忽略的一個關鍵點，基於通用型的原則，咱們採用了業界通用OAuth協議來保障接口安全。爲了應對異常流量對系統形成的衝擊，咱們給接口層添加了流量控制功能。

分佈式緩存
平臺早期，分發接口採用DB+本地緩存的方式提供數據，這種模式DB壓力大、接口吞吐量小、本地緩存更新不及時。爲了解決這些問題，咱們引入分佈式緩存Redis。業務接口數據所有被緩存到Redis集羣，緩存數據由定時任務主動刷新，零穿透，緩存即存儲、存儲即緩存。依託Redis的高性能極大的提升了系統吞吐量。Redis集羣先按業務場景作垂直切分、再根據數據量作水平分片。業務經過代理（Twemproxy）鏈接全部分片。 Redis集羣基於ZK實現HA（High Availability），基於定製化腳本實現線上自動擴容，這樣既保障了緩存集羣的高可用性，又知足了集羣容量自動擴充的需求。

MySQL水平分片

隨着用戶規模增加，單庫單表已沒法知足業務需求，爲此咱們將數據量大的用戶數據庫橫向拆分出多個數據庫。爲了下降運維成本，咱們採用了單實例多數據庫的部署模式。業務層經過分庫路由組件透明的訪問數據庫。當單實例多數據庫的模式沒法支撐當前業務需求時，經過更新路由規則就能夠平滑的完成DB擴容。

GSLB(Global Server Load Balance)

使用域名提供服務的互聯網企業，都沒法避免在有中國特點的互聯網環境中遭遇到各類域名被緩存、用戶跨網訪問緩慢等問題。Flyme互聯網基礎架構團隊推出了一種全新的域名解析調度系統：GSLB。GSLB是爲移動客戶端量身定作的基於Http(s)協議的流量調度解決方案，解決LocalDNS解析異常以及流量調度不許。

GSLB的原理很是簡單，主要有兩步：
A.客戶端直接訪問GSLB服務接口，獲取業務在GSLB服務中配置的訪問最優的IP。基於容災考慮，咱們保留了運營商LocalDNS域名解析的方式。
B.客戶端獲取到的業務服務IP後，直接向此IP發送業務協議請求。

GSLB將域名解析的協議由DNS協議換成了Http(s)協議，並不複雜。可是這一轉換，卻帶來了許多收益：

A.解決域名解析異常：用戶使用Http(s)協議向魅族GSLB服務發起域名解析請求，繞過了運營商的LocalDNS，用戶在客戶端的域名解析請求將不會遭受到域名解析異常的困擾，有效預防DNS劫持。
B.用戶就近訪問：GSLB能直接獲取到用戶IP，結合魅族自有IP地址庫以及測速機制，能夠爲用戶搜索最優的IDC服務節點。
C.實現精準流量調度：流量異常（週年慶推廣活動）或機房故障時，方便快捷的將流量平滑的調度到附近的機房，保障服務的高可用性。

下載防劫持

運營商HTTP劫持推送廣告的狀況相信你們並不陌生，近來國內各大應用分發平臺都有不一樣的程度的應用下載被劫持現象，咱們也難置身事外，爲此，咱們上線文件下載防劫持方案。

以下圖所示。應用商店在分發應用時，會同時分發應用文件的摘要等相關信息，客戶端下載獲取到應用文件(Apk)後，會計算並比對文件的摘要，以此來判別文件是否被修改或替換。若是文件比對失敗，則更換爲HTTPS通道繼續下載應用。爲防止CDN與源站的網絡被劫持，CDN回源先後也會校驗文件信息。

除了比對應用文件的摘要，咱們還會比對文件的大小、包名（Android應用的惟一標識）、版本號等信息。針對APK下載場景，生產環境咱們主要使用文件大小和包名來作校驗。

有些遊戲應用文件比較大，如熱門遊戲《植物大戰殭屍》大小在100M左右、熱門網絡遊戲《夢幻西遊》大小在300M左右。若是全量計算文件摘要這樣會比較耗時、耗資源，對硬件資源有限的手機來講是一筆很大的開銷，勢必會影響到用戶的操做體驗。爲此，針對大文件，咱們採用了部分比對文件摘要的方式。

應用商店應用數量大、渠道不單一，爲了預防分發信息異常形成大面積應用下載失敗事故，雲端新增了動態關閉、調整客戶端判別邏輯的機制。

不管劫持動做是否成功修復，客戶端均會上報操做日誌，藉助大數據的優點，咱們能夠分析改進防劫持效果。

[對話架構師] 是Boss直聘「直聘學院」旗下對話系列沙龍。聯合業內明星創業公司&合做夥伴聯合發起，爲架構師、運維、程序員、開發者等舉辦的技術沙龍，旨在經過大咖乾貨分享，構建純業內、純技術交流圈，共同推進技術進步。這次活動參與對象主要是CTO，架構師，運維和技術經理等。主辦：Boss直聘（互聯網招聘第一APP）特別支持社區：SegmentFault