魅族系統(tǒng)架構(gòu)師何偉帶來了主題為《魅族多機(jī)房部署方案》的演講，多機(jī)房容災(zāi)是規(guī)?；ヂ?lián)網(wǎng)企業(yè)的必經(jīng)之路，魅族經(jīng)過2014-2015年的轉(zhuǎn)型以及銷量大爆發(fā)后，對(duì)互聯(lián)網(wǎng)業(yè)務(wù)的可靠性要求有了新的訴求，再加上近期的光纖被挖斷事故、某大爆炸對(duì)某機(jī)房的影響等等，都要求我們盡快實(shí)施多機(jī)房容災(zāi)方案，本次演講主要介紹魅族在多機(jī)房容災(zāi)的方案以及實(shí)施過程中碰到的問題和對(duì)策，以及魅族核心機(jī)房的遷移方案和問題的解決方案。

對(duì)于魅族多機(jī)房部署，何偉表示，我將從為什么做多機(jī)房部署、多機(jī)房部署面臨的挑戰(zhàn)、魅族的多機(jī)房部署以及踩到的坑、多機(jī)房流量調(diào)度，希望分享大家的主要就是這些方面。

   為什么要做多機(jī)房部署？
   對(duì)于阿里投資魅族大家都知道了，魅族也放開了手機(jī)從原來的小而美，真正走向大眾需求，屏幕也從15:9走向了16:9，這也帶來了業(yè)務(wù)的高速增長，用戶量暴增，應(yīng)用商店日PV達(dá)到了2.5億、在線音樂達(dá)到了2.3億、同步數(shù)據(jù)量也達(dá)到了300億條記錄。
   面對(duì)關(guān)鍵業(yè)務(wù)量的暴增，單機(jī)房擴(kuò)展困難，同時(shí)還面臨著單機(jī)房無法容災(zāi)的問題，所謂技術(shù)再強(qiáng)，扛不住挖掘機(jī)，因此多機(jī)房部署迫在眉睫。
   多機(jī)房面臨的挑戰(zhàn)
  想要部署多機(jī)房，面臨著數(shù)據(jù)一致性難以保障、跨機(jī)房專線昂貴、無保障、流量怎么精準(zhǔn)調(diào)度、業(yè)務(wù)依賴關(guān)系復(fù)雜、跨機(jī)房網(wǎng)絡(luò)延遲等等問題。
  對(duì)此何偉表示，我們把大部分業(yè)務(wù)映射為兩大類，一類是讀多寫少的業(yè)務(wù)；一類是按用戶維度劃分的業(yè)務(wù)，其中魅族的應(yīng)用商店特點(diǎn)，就是榜單展示、數(shù)據(jù)變化少、一致性要求并不是很高，就是對(duì)于每一個(gè)業(yè)務(wù)進(jìn)行認(rèn)真分析。
   機(jī)房流量調(diào)度
  談到機(jī)房流量調(diào)度，何偉表示，我們主要采用了智能DNS和GSLB這兩種方式，具體如圖所示：

智能DNS

GSLB
 通過這兩種方式，基本上實(shí)現(xiàn)了在廣域網(wǎng)上不同地域的服務(wù)器建的流量調(diào)配，保證使用最佳的服務(wù)器離自己最近的用戶，通俗講就是上海用戶訪問上海服務(wù)，北京用戶訪問北京服務(wù)器，從而確保訪問質(zhì)量。

遇到的哪些“坑”
  在實(shí)施過程中存在的問題是兩個(gè)方面，首先是VPN設(shè)備CPU占用率過高，其次是異地機(jī)房Slave Mysql跟不上Master，經(jīng)過認(rèn)真的觀察、抓包分析，最終我們采取的措施，首先針對(duì)電信和聯(lián)通做了兩個(gè)VPN相互備份；其次核心數(shù)據(jù)采取QoS保障，最后采用了專門的VPN設(shè)備。

魅族多機(jī)房方案
我們借鑒以上幾種方案，把業(yè)務(wù)進(jìn)行一些梳理，映射到下面兩種業(yè)務(wù)：
（1）讀多寫少
（2）按用戶分離
讀多寫少
這類業(yè)務(wù)主要是讀取，極少寫入，所以我們甚至把這類業(yè)務(wù)歸納為只讀業(yè)務(wù)。
應(yīng)用商店單機(jī)房架構(gòu)如下圖：

接入端分三種業(yè)務(wù)，API、開發(fā)者社區(qū)、運(yùn)營后臺(tái)。
API提供接口給手機(jī)端應(yīng)用商店使用，主要是讀取榜單數(shù)據(jù)展示給用戶看，這部分“讀”我們基本是從緩存讀取，對(duì)數(shù)據(jù)庫的依賴都很??；再就是少量的“寫”來自一些統(tǒng)計(jì)信息、評(píng)論等。
而開發(fā)者社區(qū)提供給開發(fā)者和App廠商上傳、維護(hù)應(yīng)用，寫數(shù)據(jù)比較多，讀寫基本均衡。
后臺(tái)提供給公司內(nèi)部運(yùn)營部門使用，榜單維護(hù)、應(yīng)用上下架等功能，也有較多的“寫”。
經(jīng)過對(duì)業(yè)務(wù)可用性做分級(jí)，應(yīng)用商店(API接口)的可用性要求最高，運(yùn)營后臺(tái)和開發(fā)者社區(qū)的可用性需求稍低。
基于以上分析，我們只需要對(duì)應(yīng)用商店(API接口)提供多機(jī)房方案。
應(yīng)用商店多機(jī)房架構(gòu)如下圖：

核心機(jī)房的部署基本不需要改動(dòng)，我們?nèi)A東機(jī)房的數(shù)據(jù)通過MySQL的同步功能復(fù)制，榜單類數(shù)據(jù)的讀取與核心機(jī)房一致，從Redis緩存讀取。Redis緩存的數(shù)據(jù)實(shí)用定時(shí)任務(wù)從DB里獲取定時(shí)刷到Redis里。
為了保證數(shù)據(jù)一致性，"寫"依然是單點(diǎn)寫，是跨機(jī)房直接寫入核心機(jī)房。分兩種，一種是通過消息隊(duì)列，寫入遠(yuǎn)程機(jī)房，即使機(jī)房間網(wǎng)絡(luò)出現(xiàn)問題，我們 的"寫"可以堆積在MQ里，基本不影響用戶體驗(yàn)，堆積的數(shù)據(jù)待網(wǎng)絡(luò)通順后再拉去。另一種"寫"要求馬上知道是否"寫"成功，所以是跨機(jī)房直接寫入數(shù)據(jù)庫， 這部分如果網(wǎng)絡(luò)出問題，將導(dǎo)致失敗，我們可以做降級(jí)處理。
另外機(jī)房間流量調(diào)度我們實(shí)用GSLB來調(diào)度，后面有詳細(xì)闡述。
讀寫均衡業(yè)務(wù)
我們這里的讀寫均衡業(yè)務(wù)有一個(gè)重要特性，就是所有數(shù)據(jù)可以按照用戶維度來切分。相互關(guān)聯(lián)度不大。例如我們的同步業(yè)務(wù)，同步業(yè)務(wù)把手機(jī)端的所有數(shù)據(jù) （聯(lián)系人、短信、設(shè)置、wifi、輸入法偏好 ...）同步到云端，遇到手機(jī)丟失、刷機(jī)需要清數(shù)據(jù)時(shí)，可以隨時(shí)把數(shù)據(jù)拉下來，做到數(shù)據(jù)永不丟失。
下面是同步業(yè)務(wù)單機(jī)房架構(gòu)：

我們的用戶訪問接口也分兩部分，一部分供手機(jī)端實(shí)用的API,另外一部分在Web端用戶可以直接操作（對(duì)聯(lián)系人做修改）。Web接口獲取到的請(qǐng)求轉(zhuǎn)發(fā)到后端的服務(wù)，如聯(lián)系人同步、消息同步、設(shè)置項(xiàng)同步等服務(wù)。后端服務(wù)再根據(jù)用戶路由信息，存儲(chǔ)到不同DB分片。
這里做跨機(jī)房方案比較方便，直接按照用戶做全局路由，路由到不同機(jī)房即可。
跨機(jī)房架構(gòu)圖如下：

我們把業(yè)務(wù)數(shù)據(jù)和服務(wù)打包到單個(gè)Unit，一個(gè)Unit服務(wù)一定數(shù)量的用戶。每個(gè)Unit包含了完整的數(shù)據(jù)和服務(wù)，可以單獨(dú)部署。每個(gè)機(jī)房有多個(gè)Unit,每個(gè)用戶的數(shù)據(jù)在本地有一份備份、在遠(yuǎn)程同樣也有一份備份。當(dāng)機(jī)房故障時(shí)，可以把備份數(shù)據(jù)拉起來服務(wù)用戶。
用戶通過API訪問我們的服務(wù)時(shí)，使用GSLB來做調(diào)度，用戶訪問業(yè)務(wù)服務(wù)時(shí)，先從GSLB獲取用戶數(shù)據(jù)所在位置（用戶數(shù)據(jù)同時(shí)僅在某一個(gè)機(jī)房提供服務(wù)），然后把客戶端請(qǐng)求調(diào)度到合適的機(jī)房。
Web請(qǐng)求是一個(gè)挑戰(zhàn)，因?yàn)閃eb服務(wù)無法使用GSLB，所以不能精準(zhǔn)的調(diào)度用戶請(qǐng)求。這塊的方案在后續(xù)的流量調(diào)度里講到。
機(jī)房流量的精確調(diào)度
說到多機(jī)房，就牽涉到流量調(diào)度。流量調(diào)度最簡單的就是使用智能DNS服務(wù)。如下圖：

只能DNS根據(jù)LocalDNS來的請(qǐng)求里的IP來判定您是哪個(gè)那個(gè)ISP，哪個(gè)區(qū)域的用戶，從而調(diào)度到對(duì)應(yīng)ISP,對(duì)應(yīng)區(qū)域的機(jī)房，核心在智能DNS的IP庫。有幾個(gè)缺點(diǎn)：
DNS劫持, 在我國，DNS劫持時(shí)有發(fā)生，尤其是二三線城市的運(yùn)營商，明目張膽。這在智能DNS基本無法解決
本地DNS如果設(shè)置成用戶自己指定的DNS服務(wù)器如8.8.8.8，智能DNS服務(wù)器獲取到的LocalDNS是美國地址，也無法對(duì)應(yīng)ISP,智能DNS服務(wù)只能按設(shè)計(jì)者喜好提供解析了，這時(shí)可能給用戶解析到錯(cuò)誤的ISP和錯(cuò)誤的機(jī)房。
無法根據(jù)用戶信息來調(diào)度，有些數(shù)據(jù)只在特定機(jī)房有，由于DNS協(xié)議無法攜帶用戶標(biāo)示，所以也很難做到精準(zhǔn)解析。
無法感知服務(wù)器宕機(jī)。
由此就針對(duì)特定業(yè)務(wù)，我們接入了GSLB服務(wù):

這個(gè)服務(wù)避開DNS請(qǐng)求，發(fā)起請(qǐng)求前，訪問我們自己的GSLB服務(wù)(或者 HttpDNS),業(yè)務(wù)可以帶上用戶標(biāo)識(shí)，來定位自己的數(shù)據(jù)在哪個(gè)機(jī)房，使用IP來訪問業(yè)務(wù)服務(wù)。
帶來幾個(gè)明顯好處：
* 可以根據(jù)IP或者UID等等信息精確調(diào)度。
* 避免DNS劫持。
* 用戶手工設(shè)置DNS也不會(huì)調(diào)度錯(cuò)誤。
目前我們所有客戶端的訪問，都接入GSLB，例如上面提到的應(yīng)用中心、用戶同步的API訪問等。
但是也存在問題，這種方案僅適應(yīng)于有客戶端的Http、Https請(qǐng)求，不適合瀏覽器訪問，瀏覽器不清楚你的GSLB是什么東西。用戶同步的API 訪問可以用GSLB來做，但是Web訪問的時(shí)候，是不能用GSLB來做流量調(diào)度的，因?yàn)闉g覽器不認(rèn)GSLB, 如果使用智能DNS也無法根據(jù)用戶ID精準(zhǔn)調(diào)度流量。
基于以上考慮，我們提出了第三種方案，GSLB+智能DNS：

用戶請(qǐng)求服務(wù)前，找到DNS解析到的一個(gè)服務(wù)器，去獲取數(shù)據(jù)，后端服務(wù)會(huì)先找GSLB服務(wù)查找用戶數(shù)據(jù)所在機(jī)房，如果用戶數(shù)據(jù)在本機(jī)房，則直接返回?cái)?shù)據(jù)，否則，重定向用戶請(qǐng)求到合適的機(jī)房重新發(fā)起請(qǐng)求。
這種方案可能導(dǎo)致用戶瀏覽器里域名變換，影響用戶體驗(yàn)，另外依然無法避免域名劫持。