1.業(yè)界方案-魅族多機房部署方案（2）

概要：技術(shù)挑戰(zhàn)兽叮、業(yè)界方案（讀多寫少 &讀寫均衡按用戶分離）萄喳、機房流量的精確調(diào)度

1、機房間網(wǎng)絡(luò)延遲和帶寬限制, 租用運營商的專線非常昂貴他巨，可靠性不保障充坑；

2、業(yè)務(wù)依賴關(guān)系復(fù)雜染突；改動不能太大

3捻爷、機房之間流量的精確調(diào)度；

最大挑戰(zhàn)是網(wǎng)絡(luò)延遲一系列問題如一致性觉痛，成熟方案如阿里單元化役衡，按用戶把業(yè)務(wù)封閉在一個單元里；騰訊set方案薪棒，微博，主要是集中寫榕莺，快速切換俐芯。

應(yīng)用商店單機房架構(gòu)

接入端分三種業(yè)務(wù)钉鸯，API吧史、開發(fā)者社區(qū)、運營后臺唠雕。

(1)API（只需對API提供多機房方案）：應(yīng)用商店讀取榜單數(shù)據(jù)給用戶贸营，“讀”從緩存讀取，少量“寫”來自評論等岩睁。

(2)開發(fā)者社區(qū)：App廠商上傳钞脂、維護應(yīng)用，讀寫均衡

(3)后臺：榜單維護捕儒、應(yīng)用上下架冰啃，較多“寫”

應(yīng)用商店多機房架構(gòu)圖

華東機房通過MySQL同步功能復(fù)制邓夕，榜單類數(shù)據(jù)與核心機房一致從Redis緩存讀取。定時任務(wù)從DB里獲取定時刷到Redis里阎毅。

單點寫焚刚，跨機房寫入核心機房。分兩種扇调，(1)消息隊列寫入遠(yuǎn)程機房矿咕，即網(wǎng)絡(luò)出現(xiàn)問題，"寫"在MQ里不影響狼钮。(2)實時性高碳柱，跨機房直接寫入db，如網(wǎng)絡(luò)問題失敗燃领，可以做降級

另外機房間流量調(diào)度我們實用GSLB來調(diào)度士聪，后面有詳細(xì)闡述。

讀寫均衡業(yè)務(wù)有重要特性猛蔽，按照用戶維度切分剥悟，相互關(guān)聯(lián)不大。把（聯(lián)系人曼库、短信区岗、 ...）同步云端，永不丟失毁枯。

同步業(yè)務(wù)單機房架構(gòu)

跨機房方案：(1)直接按照用戶做全局路由慈缔，路由到不同機房即可，存儲到不同DB分片

(2)業(yè)務(wù)數(shù)據(jù)和服務(wù)打包到單個Unit(可單獨部署)种玛，一個Unit服務(wù)一定數(shù)量的用戶藐鹤。每個機房有多個Unit,本地遠(yuǎn)程備份

(3)API訪問時，GSLB把客戶端請求調(diào)度到就近機房赂韵，獲取用戶數(shù)據(jù)所在位置（用戶數(shù)據(jù)同時僅在某一個機房提供服務(wù)）娱节。

ps；Web服務(wù)無法使用GSLB不能精準(zhǔn)調(diào)度

只能DNS根據(jù)LocalDNS請求IP來判定是哪個ISP肄满，哪個區(qū)域用戶，調(diào)度到對應(yīng)ISP,區(qū)域的機房质涛，核心在智能DNS的IP庫稠歉。

DNS劫持, 在我國時有發(fā)生，尤其二三線城市運營商汇陆，明目張膽無法解決

設(shè)置指定DNS無法對應(yīng)ISP怒炸，隨機解析到錯誤的ISP和機房。如8.8.8.8瞬测，智能DNS獲取到的LocalDNS是美國地址横媚，

無法根據(jù)用戶信息來調(diào)度纠炮，有些數(shù)據(jù)只在特定機房有，DNS協(xié)議無法攜帶用戶標(biāo)示灯蝴，不能精準(zhǔn)解析恢口。

無法感知服務(wù)器宕機

避開DNS請求，請求前穷躁，訪問GSLB服務(wù)(或HttpDNS),帶上用戶標(biāo)識耕肩，定位數(shù)據(jù)所在機房，用IP訪問问潭。所有客戶端的訪問猿诸，都接入GSLB

1* 根據(jù)IP或UID等精確調(diào)度。

2* 避免DNS劫持狡忙。

3* 設(shè)置DNS也不會調(diào)度錯誤梳虽。

問題：僅用客戶端Http、Https請求灾茁，不適合瀏覽器訪問窜觉，瀏覽器不清楚GSLB是什么。所以：

請求前找到DNS解析的服務(wù)器北专，獲取數(shù)據(jù)禀挫，后端先找GSLB服務(wù)查數(shù)據(jù)所在機房，如在本機房直接返回拓颓，否則重定向發(fā)起請求语婴。

缺點：可能導(dǎo)致用戶瀏覽器里域名變換，無法避免域名劫持

問題：最終是上面兩種組合驶睦？

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者