魅族多機房部署方案

魅族多機房部署方案

我們為什麼要做多機房部署

魅族經過2014-2015年的轉型以及銷量大爆發後，隨之而來的互聯網服務業務越來越多，用戶基數越來越大，之前單機房的擴展架構已經滿足不了魅族的發展，此外加上國內復雜網絡環境下，單機房無法滿足我們的可靠性需求。近年經常出現的光纜被挖、機房掉電。如支付寶光纖被挖斷，導致業務中斷；去年微信也出現大面積故障，同樣是光纖被挖斷。除了單機房故障風險外，用戶就近接入的需求也很強烈。

技術挑戰

1. 機房之間的網絡延遲和帶寬限制, 租用運營商的專線非常昂貴，可靠性也得不到保障；
2. 業務依賴關系復雜；
3. 機房之間流量的精確調度；
4. 業務改動不能太大。

多機房方案最大的挑戰是機房之間網絡延遲所帶來的一系列問題如一致性，當然業界也有一些成熟的方案，例如阿裡的單元化方案，按用戶把業務封閉在一個單元裡；騰訊的set方案，還有微博的跨機房方案，主要是集中寫，提供了快速切換的方案。

業界方案

魅族多機房方案

我們借鑒以上幾種方案，把業務進行一些梳理，映射到下面兩種業務：

• 讀多寫少
• 按用戶分離

讀多寫少

這類業務主要是讀取，極少寫入，所以我們甚至把這類業務歸納為只讀業務。

接入端分三種業務，API、開發者社區、運營後台。

1. API提供接口給手機端應用商店使用，主要是讀取榜單數據展示給用戶看，這部分“讀”我們基本是從緩存讀取，對數據庫的依賴都很小；再就是少量的“寫”來自一些統計信息、評論等。
2. 而開發者社區提供給開發者和App廠商上傳、維護應用，寫數據比較多，讀寫基本均衡。
3. 後台提供給公司內部運營部門使用，榜單維護、應用上下架等功能，也有較多的“寫”。

經過對業務可用性做分級，應用商店(API接口)的可用性要求最高，運營後台和開發者社區的可用性需求稍低。

基於以上分析，我們只需要對應用商店(API接口)提供多機房方案。

核心機房的部署基本不需要改動，我們華東機房的數據通過MySQL的同步功能復制，榜單類數據的讀取與核心機房一致，從Redis緩存讀取。Redis緩存的數據實用定時任務從DB裡獲取定時刷到Redis裡。

為了保證數據一致性，"寫"依然是單點寫，是跨機房直接寫入核心機房。分兩種，一種是通過消息隊列，寫入遠程機房，即使機房間網絡出現問題，我們的"寫"可以堆積在MQ裡，基本不影響用戶體驗，堆積的數據待網絡通順後再拉去。另一種"寫"要求馬上知道是否"寫"成功，所以是跨機房直接寫入數據庫，這部分如果網絡出問題，將導致失敗，我們可以做降級處理。

另外機房間流量調度我們實用GSLB來調度，後面有詳細闡述。

讀寫均衡業務

我們這裡的讀寫均衡業務有一個重要特性，就是所有數據可以按照用戶維度來切分。相互關聯度不大。例如我們的同步業務，同步業務把手機端的所有數據（聯系人、短信、設置、wifi、輸入法偏好 ...）同步到雲端，遇到手機丟失、刷機需要清數據時，可以隨時把數據拉下來，做到數據永不丟失。

下面是同步業務單機房架構：

我們的用戶訪問接口也分兩部分，一部分供手機端實用的API,另外一部分在Web端用戶可以直接操作（對聯系人做修改）。Web接口獲取到的請求轉發到後端的服務，如聯系人同步、消息同步、設置項同步等服務。後端服務再根據用戶路由信息，存儲到不同DB分片。

這裡做跨機房方案比較方便，直接按照用戶做全局路由，路由到不同機房即可。

跨機房架構圖如下：

我們把業務數據和服務打包到單個Unit，一個Unit服務一定數量的用戶。每個Unit包含了完整的數據和服務，可以單獨部署。每個機房有多個Unit,每個用戶的數據在本地有一份備份、在遠程同樣也有一份備份。當機房故障時，可以把備份數據拉起來服務用戶。

用戶通過API訪問我們的服務時，使用GSLB來做調度，用戶訪問業務服務時，先從GSLB獲取用戶數據所在位置（用戶數據同時僅在某一個機房提供服務），然後把客戶端請求調度到合適的機房。

Web請求是一個挑戰，因為Web服務無法使用GSLB，所以不能精准的調度用戶請求。這塊的方案在後續的流量調度裡講到。

機房流量的精確調度

說到多機房，就牽涉到流量調度。流量調度最簡單的就是使用智能DNS服務。如下圖：

只能DNS根據LocalDNS來的請求裡的IP來判定您是哪個那個ISP，哪個區域的用戶，從而調度到對應ISP,對應區域的機房，核心在智能DNS的IP庫。有幾個缺點：

1. DNS劫持, 在我國，DNS劫持時有發生，尤其是二三線城市的運營商，明目張膽。這在智能DNS基本無法解決
2. 本地DNS如果設置成用戶自己指定的DNS服務器如8.8.8.8，智能DNS服務器獲取到的LocalDNS是美國地址，也無法對應ISP,智能DNS服務只能按設計者喜好提供解析了，這時可能給用戶解析到錯誤的ISP和錯誤的機房。
3. 無法根據用戶信息來調度，有些數據只在特定機房有，由於DNS協議無法攜帶用戶標示，所以也很難做到精准解析。
4. 無法感知服務器宕機。

由此就針對特定業務，我們接入了GSLB服務:

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

帶來幾個明顯好處：

* 可以根據IP或者UID等等信息精確調度。* 避免DNS劫持。* 用戶手工設置DNS也不會調度錯誤。

目前我們所有客戶端的訪問，都接入GSLB，例如上面提到的應用中心、用戶同步的API訪問等。

但是也存在問題，這種方案僅適應於有客戶端的Http、Https請求，不適合浏覽器訪問，浏覽器不清楚你的GSLB是什麼東西。用戶同步的API訪問可以用GSLB來做，但是Web訪問的時候，是不能用GSLB來做流量調度的，因為浏覽器不認GSLB, 如果使用智能DNS也無法根據用戶ID精准調度流量。

基於以上考慮，我們提出了第三種方案，GSLB+智能DNS：

用戶請求服務前，找到DNS解析到的一個服務器，去獲取數據，後端服務會先找GSLB服務查找用戶數據所在機房，如果用戶數據在本機房，則直接返回數據，否則，重定向用戶請求到合適的機房重新發起請求。

這種方案可能導致用戶浏覽器裡域名變換，影響用戶體驗，另外依然無法避免域名劫持。

總結：

本篇文章主要介紹魅族在多機房容災的方案以及實施過程中碰到的問題和對策，以及魅族核心機房的遷移方案和問題的解決方案。

您在多機房部署方面擁有哪些心得及經驗？歡迎在評論中分享。