魅族應用商店伺服器端架構實踐

導讀ID:TOP100case

導語：魅族應用商店是魅族官方應用市場，提供海量最新最潮的魅族手機應用、遊戲下載；從最初上線十萬PV到日PV超過3億，迎接新的挑戰，不斷推進網站的架構演進，為用戶提供高性能、高可用的服務。本次案例分享魅族應用商店架構實踐，包括分布式緩存，資料庫分庫分表，服務化框架，自動化監控，日誌分析系統，服務降級，GSLB，多機房建設和部署等。

（全文共3089字 預計閱讀時長：3分鐘）

應用商店的簡介

魅族應用商店是國內較大的Android應用分發平台，在國內最早提供內付費購買功能。應用商店為開發者提供了管理、發布的功能。我們有專業的運營和開發團隊提供專業技術支持；對上線的應用可以在Flyme全平台及其其他平台進行推廣，藉助Flyme品牌優勢進行傳播。

魅族商店的應用，通過雲測掃描保證App的安全。同時提供支付寶、微信，銀行卡等多種支付方式，提供指紋支付，Https等加密方式，支付安全可靠；同時會對上架應用進行安全掃描。用戶可以在海量的應用庫中查看、搜索、下載自己感興趣的應用，然後進行評論和分享。用戶、開發者、魅族構成了應用商店互惠互利的生態圈。

我們通過運營精心推薦的應用，同時提供排行，分類，搜索，增量升級等功能，為用戶推薦有用，感興趣，匹配度高的App商品，讓用戶下載安裝，同時還可以實現跨平台的分享，例如微信分享。到2015年魅族商店的下載量超過80億次，每天的用戶訪問次數超過3億次，這裡面不含文件下載，每日分發量超過2800萬次，伺服器虛擬機台數目前超過100台。應用商店是一個千萬級用戶規模的大型系統。

第一代架構

開始，魅族商店的架構是用戶少，手機用戶只有10萬級。團隊規模非常小，只有2～3位開發工程師；而項目初期，我們希望能快速迭代、快速上線，有問題再快速調整，改變，再次發布，對於技術，我們優先使用成熟、被廣泛應用的開源技術。

2.1 伺服器集群

用戶請求到LVS，為了避免單點故障，有一個備用的LVS伺服器，自動切換，實現高可，用LVS把請求轉發到Nginx和Jetty的伺服器集群，可以靈活的增加伺服器，滿足用戶流量的增長需要。

2.2使用緩存

把榜單，應用詳情等熱點數據和訪問頻率高的介面使用Memcache緩存。

2.3讀寫分離

由於業務讀多寫少，採用了讀寫分離策略，分攤資料庫訪問壓力。寫的請求在主庫。

2.4CDN

文件和圖片等靜態文件使用CDN訪問，減少伺服器的請求壓力，也能為用戶提供更快地訪問速度。

這是一個典型的系統架構設計，在項目初期，足以支撐用戶的快速訪問。

微服務架構

到了2012年，隨著用戶註冊量及訪問量的增加，我們的架構暴露出了一些問題；我們迅速做出架構調整，我們採用了微服務，多級緩存，資料庫分庫分表、同時加強標準化。

隨著用戶的增加和用戶數據量的增長，如果用戶安裝歷史等數據表超過1000萬戶或上億戶，主DB寫入出現性能瓶頸，資料庫的數據量很大，有時出現一個慢SQL導致發布故障，同時魅族互聯網項目不斷增加，應用商店的功能不斷完善，跨系統的耦合嚴重，相互影響，有時會發布到深夜。

隨著開發人員的增加，以前的架構是一個單體架構，所有的應用商店打包成一個，這樣不便於開發人員之間的合作，同時由於規範和標準很少，執行不到位，伺服器的版本，Linux版本導致不一致，隨著開發人員的增加，開發效率出現了降低。容易造成人為失誤，重啟Web伺服器，本機緩存過期導致DB壓力很大。

當時我們工程師的現狀是，在珠海魅族辦公大樓，經常看到很多位開發工程師晚上12點在椅子上睡覺，但是這不是工作累的，而是等著不能離開。因為大的項目發布，項目相互依賴，需要排隊發布，然後測試，沒有排到位的工程師就在公司睡著了。

就在這個時候，我們花了一個月的時間，把業務需求基本停下來，對架構迅速做了調整，升級，滿足用戶的需要，我們期待美好的明天即將到來。

微服務架構包含接入層、服務層、資源層。接入層有介面規範，業務監控，流量切換，手機端，H5等介面。服務層我們提出了榜單、搜索、推薦等。資源層我們對訪問方式做了一些改變。如圖1所示。

圖1 架構全貌

3.1採用的開源產品類型

FastDFS 是一個輕量級的分布式文件系統，主要解決了大數據量存儲和高並發訪問的問題。

ZooKeeper是開源的分布式應用程序協調服務，主要用於服務的發現和調度。

MetaQ是淘寶開源的一個Java消息中間件。

RPC框架採用自研的Kiev框架通信，Kiev底層通信基於Netty網路框架，串列化協議支持Hessian、Protobuffer。

分片：DB，redis（基於Twemproxy的Redis集群方案，jedis做封裝，監控，大Key限制保護）做了分片和集群。

3.2微服務的改變途徑

業務梳理，減少不必要的跨系統調用；

業務解耦，功能模塊化，服務獨立部署；

開發人員增加，微服務有助於提升開發效率；

使用zookeeper實現服務配置中心，實時感知後端伺服器的狀態變化（上線，下線，宕機）；

接入層、介面層、存儲層，不允許跨層調用。

3.3多級緩存到主動緩存

業務熱點數據比較集中，讀多寫少，更新不頻繁；

通過Task把應用排行和詳情數據刷到redis；

訪問量大的查詢類介面只訪問redis，不訪問Mysql；

緩存策略從被動緩存到主動緩存；

Mysql掛掉不影響用戶瀏覽和下載應用等主業務功能；

添加JVM本地緩存，通過日誌統計發現，緩存命中率達到90%，大大減少了對redis的訪問；

動態頁面靜態化為文件，放到CDN供用戶就近訪問；

引入Android客戶端本地緩存，首頁等介面伺服器添加版本號，如果版本未改變，不返回伺服器端數據。

3.4資料庫分庫分表

按照當前用戶10倍的規模估算用戶數據；

為了增加伺服器的工作簡單化，主要採用分庫而非分表，建議成倍的增加資料庫伺服器；

按用戶Hash分庫或新的用戶增加新的DB，考慮數據總量可控；

一台Mysql實例可同時安裝100+個資料庫；

資料庫連接到Mysql實例而不是具體的分庫，因此每次SQL執行前進行use db的操作；

每台伺服器採用雙Master模式，實現故障自動切換，避免單點故障；

由於按用戶分庫，用戶相應記錄都在同一個DB，減少跨庫訪問。

3.5標準化

環境標準化：標準化公用組件，運行環境，配置文件，文件目錄；有差異的部分提取配置平台；

伺服器數量眾多，人工查詢日誌困難：日誌包含時間，唯一標識，線程名稱，日誌級別；

跨系統的日誌遵從統一的規範；

提供集中的日誌查詢平台；

執行：單元測試代碼覆蓋率達到80%以上才允許提交測試。

多機房架構

到了2014年的下半年，我們開始嘗試做多機房的部署（如圖2），我們為什麼要這麼做？

4.1不做多機房，風險很大

單機房擴展困難:用戶增長迅猛，電力或者機櫃資源有限，單機房擴展困難，難以滿足業務發展需要。

單機房無法容災:由於光纜被挖、機房掉電等導致的故障時有耳聞，如2015年出現幾次網路故障，官方回應光纖被挖。

用戶需要就近接入:國內網路環境複雜，用戶就近接入能提供更快的響應速度。

圖2 多機房架構的架構圖

4.2多機房架構建立中的兩個問題

用戶流量調度

流量調度最簡單的就是使用智能DNS；

發起請求前，訪問我們自己的GSLB服務(or HttpDNS)，業務可以帶上用戶標識來定位自己的數據在哪個機房，使用IP來訪問業務服務。

多機房數據雙向同步

Mysq BinLog日誌進行主從資料庫同步，通過task刷定時刷到緩存，機房之間提供聯通和電信雙VPN線路；

只從主DB寫入，容錯和重試；

跨機房通過MQ進行數據傳遞，比較實時的更新緩存；

Redis持久化到Mysql。

4.3建立多機房時我們踩過的坑

VPN設備CPU過高，達到90%以上，網路之間的速度相對比較慢，對於用戶有很大的影響。我們的解決方案：最初買的設備很低端，CPU軟加解密設備，然後，升級為高性能（30倍）晶元加解密的VPN設備。

異地機房Mysql Slave 跟不上Master，有一定的延時。我們的做法是採用雙VPN，通過部署電信和聯通兩個VPN相互備份，將網路的風險降到最低。

未來的展望

5.1異地多活、多點寫入

我們現在的架構，只有主機房寫入，未來我們希望每個機房都能夠寫入，一個機房失效，另外一個機房迅速接入寫入的請求。

5.2大數據時代

利用大數據對用戶做畫像，對用戶刷榜識別，甄別惡性刷榜，同名應用圖片識別，為用戶做更好地推薦，篩選以及內容甄別。

5.3個性化推薦

個性化推薦現在只做到按群體（男女，飛行射擊）進行推薦，以後按個人用戶畫像進行精準推薦。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！