背景：2014年9月4日，魅族科技今日與戴爾簽署合作備忘錄，雙方將建立長期戰(zhàn)略合作伙伴關系，致力于加速魅族移動互聯網基礎建設，同時協(xié)助魅族搭建內部私有云。這一舉動，也體現了戴爾對中國高端手機制造業(yè)的支持。 魅族云服務的優(yōu)勢在于系統(tǒng)級別整合、權限智能分配、一站式帳號管理，這也對互聯網整體解決方案提出了更高的要求，并面臨更多難點。此次合作的建立標志著魅族又一次與國際頂尖信息技術供應商的接軌，業(yè)界更佳期待戴爾發(fā)揮其解決方案優(yōu)勢，全力幫助魅族加速其云架構建設，實現更大的成功。
應用商店可以說是移動設備上最特殊的一個應用，它用于分發(fā)和管理其它應用，是移動操作系統(tǒng)的核心之一，但和操作系統(tǒng)其它組件不同，它需要一個龐大的云端作為支持。
魅族應用商店是國內最早的應用分發(fā)平臺，在國內首創(chuàng)了許多業(yè)務模式，本次魅族工程師將分享魅族應用商店云端的整體架構。
水平分層、垂直拓展
應用商店首先定位于應用管理平臺，其次更是應用分發(fā)平臺，其典型業(yè)務場景包括：
幫助Flyme用戶找應用；
幫助Flyme開發(fā)者推廣、分發(fā)應用；
營造維護應用分發(fā)生態(tài)圈。
根據業(yè)務場景，不難推導出業(yè)務架構特點：
讀多寫少；
請求量大、并發(fā)高；
系統(tǒng)要求延時低；
數據規(guī)模可控；
用戶關聯弱。
隨著用戶規(guī)模的增長，不斷的重構、線上運行、探索與沉淀，逐步形成了當前平臺的架構。如下圖所示。橫向、典型的三層架構；縱向、以業(yè)務為驅動，積累沉淀了眾多技術規(guī)范、基礎組件，豐富完善全棧業(yè)務監(jiān)控。依托完善的監(jiān)控體系，衍生出相應的服務治理機制。
服務化框架
平臺早期，規(guī)模小、結構簡單。伴隨公司互聯網轉型，用戶規(guī)模高速增長、業(yè)務增多，平臺關系復雜、擴展難、開發(fā)效率低，原有架構完全無法服務大規(guī)模的Flyme用戶。
為了減少業(yè)務依賴、提升集群效率、提高開發(fā)部署效率，我們基于業(yè)務典型場景，把業(yè)務邏輯模塊化，單元化。拆分出了應用管理、應用展示（榜單）、應用推薦（個性化推薦）、應用搜索等多個服務。
服務分為兩類，一類是基礎服務，該類不依賴其他服務，業(yè)務邏輯簡單，僅提供基礎業(yè)務邏輯，例如應用管理服務。另一類是聚合服務，該類聚合多個基礎服務，形成相對復雜的業(yè)務邏輯，例如應用搜索服務。
成型服務化框架能滿足大眾化的需求，如遠程調用、動態(tài)發(fā)現、負載均衡、監(jiān)控等，同時勢必會引入一些無關的功能，影響性能。外加此類產品無法滿足我們的定制化需求，我們重復造輪子。與以往同類產品不同，我們做了如下改進：
精細化度量指標
實時度量計算
系統(tǒng)依賴、調用鏈
無縫IT系統(tǒng)集成
服務間采用自研的Kiev框架通訊。Kiev底層通訊基于Netty網絡框架，序列化支持協(xié)議支持Hessian、Protobuffer等，支持跨語言（C/Java）調用，通訊協(xié)議支持TCP、UDP等。框架基于ZK(ZooKeeper)實現了High Availability與Load Balance策略。服務調用時會采樣，生成詳細的調用鏈，收集，產生豐富的服務狀態(tài)數據（Response Time,QPS），為服務治理提供了詳實有力的數據支撐。
消息隊列（MetaQ）
消息隊列是分布式應用間交換信息的一種技術。為了解核心業(yè)務及輔助業(yè)務，我們引入消息隊列，將搜索團隊、大數據團隊需要的業(yè)務數據定期全量同步，實時增量更新。既隔離了業(yè)務間的強耦合，又保障了數據的及時性。
接口規(guī)范
接口眾多、形式多樣，管理維護成本高，為了規(guī)范開發(fā)流程、便于問題跟蹤定位，我們制定了統(tǒng)一的接口規(guī)范。例如接口采用RESTful風格，統(tǒng)一接口返回形式，約定每個業(yè)務層的錯誤編碼，每個錯誤編碼還會攜帶可選的錯誤提示，方便問題跟蹤。
安全性也是平臺不可忽略的一個關鍵點，基于通用型的原則，我們采用了業(yè)界通用OAuth協(xié)議來保障接口安全。為了應對異常流量對系統(tǒng)造成的沖擊，我們給接口層添加了流量控制功能。
分布式緩存
平臺早期，分發(fā)接口采用DB+本地緩存的方式提供數據，這種模式DB壓力大、接口吞吐量小、本地緩存更新不及時。為了解決這些問題，我們引入分布式緩存Redis。業(yè)務接口數據全部被緩存到Redis集群，緩存數據由定時任務主動刷新，零穿透，緩存即存儲、存儲即緩存。依托Redis的高性能極大的提高了系統(tǒng)吞吐量。Redis集群先按業(yè)務場景做垂直切分、再根據數據量做水平分片。業(yè)務通過代理（Twemproxy）連接所有分片。Redis集群基于ZK實現HA（High Availability），基于定制化腳本實現線上自動擴容，這樣既保障了緩存集群的高可用性，又滿足了集群容量自動擴充的需求。
MySQL水平分片
隨著用戶規(guī)模增長，單庫單表已無法滿足業(yè)務需求，為此我們將數據量大的用戶數據庫橫向拆分出多個數據庫。為了降低運維成本，我們采用了單實例多數據庫的部署模式。業(yè)務層通過分庫路由組件透明的訪問數據庫。當單實例多數據庫的模式無法支撐當前業(yè)務需求時，通過更新路由規(guī)則就可以平滑的完成DB擴容。
GSLB(Global Server Load Balance)
使用域名提供服務的互聯網企業(yè)，都無法避免在有中國特色的互聯網環(huán)境中遭遇到各種域名被緩存、用戶跨網訪問緩慢等問題。Flyme互聯網基礎架構團隊推出了一種全新的域名解析調度系統(tǒng)：GSLB。GSLB是為移動客戶端量身定做的基于Http(s)協(xié)議的流量調度解決方案，解決LocalDNS解析異常以及流量調度不準。
GSLB的原理非常簡單，主要有兩步：
A、客戶端直接訪問GSLB服務接口，獲取業(yè)務在GSLB服務中配置的訪問最優(yōu)的IP。基于容災考慮，我們保留了運營商LocalDNS域名解析的方式。
B、客戶端獲取到的業(yè)務服務IP后，直接向此IP發(fā)送業(yè)務協(xié)議請求。
GSLB將域名解析的協(xié)議由DNS協(xié)議換成了Http(s)協(xié)議，并不復雜。但是這一轉換，卻帶來了許多收益：
A、解決域名解析異常：用戶使用Http(s)協(xié)議向魅族GSLB服務發(fā)起域名解析請求，繞過了運營商的LocalDNS，用戶在客戶端的域名解析請求將不會遭受到域名解析異常的困擾，有效預防DNS劫持。
B、用戶就近訪問：GSLB能直接獲取到用戶IP，結合魅族自有IP地址庫以及測速機制，可以為用戶搜索最優(yōu)的IDC服務節(jié)點。
C、實現精準流量調度：流量異常（周年慶推廣活動）或機房故障時，方便快捷的將流量平滑的調度到附近的機房，保障服務的高可用性。
下載防劫持
運營商HTTP劫持推送廣告的情況相信大家并不陌生，近來國內各大應用分發(fā)平臺都有不同的程度的應用下載被劫持現象，我們也難置身事外，為此，我們上線文件下載防劫持方案。
如下圖所示。應用商店在分發(fā)應用時，會同時分發(fā)應用文件的摘要等相關信息，客戶端下載獲取到應用文件(Apk)后，會計算并比對文件的摘要，以此來判別文件是否被修改或替換。如果文件比對失敗，則更換為HTTPS通道繼續(xù)下載應用。為防止CDN與源站的網絡被劫持，CDN回源前后也會校驗文件信息。
除了比對應用文件的摘要，我們還會比對文件的大小、包名（Android應用的唯一標識）、版本號等信息。針對APK下載場景，生產環(huán)境我們主要使用文件大小和包名來做校驗。
有些游戲應用文件比較大，如熱門游戲《植物大戰(zhàn)僵尸》大小在100M左右、熱門網絡游戲《夢幻西游》大小在300M左右。如果全量計算文件摘要這樣會比較耗時、耗資源，對硬件資源有限的手機來說是一筆很大的開銷，勢必會影響到用戶的操作體驗。為此，針對大文件，我們采用了部分比對文件摘要的方式。
應用商店應用數量大、渠道不單一，為了預防分發(fā)信息異常造成大面積應用下載失敗事故，云端新增了動態(tài)關閉、調整客戶端判別邏輯的機制。
無論劫持動作是否成功修復，客戶端均會上報操作日志，借助大數據的優(yōu)勢，我們可以分析改進防劫持效果。
