1.业界方案-魅族多机房部署方案（2）

概要：技术挑战、业界方案（读多写少 &读写均衡 按用户分离）、机房流量的精确调度

一、技术挑战

1、机房间网络延迟和带宽限制, 租用运营商的专线非常昂贵，可靠性不保障；

2、业务依赖关系复杂；改动不能太大

3、机房之间流量的精确调度；

最大挑战是网络延迟一系列问题如一致性，成熟方案如阿里单元化，按用户把业务封闭在一个单元里；腾讯set方案，微博，主要是集中写，快速切换。

二、业界方案（读多写少 & 按用户分离）

2.1读多写少

应用商店单机房架构

接入端分三种业务，API、开发者社区、运营后台。

(1)API（只需对API提供多机房方案）：应用商店读取榜单数据给用户，“读”从缓存读取，少量“写”来自评论等。

(2)开发者社区：App厂商上传、维护应用，读写均衡

(3)后台：榜单维护、应用上下架，较多“写”

应用商店多机房架构图

华东机房通过MySQL同步功能复制，榜单类数据与核心机房一致从Redis缓存读取。定时任务从DB里获取定时刷到Redis里。

单点写，跨机房写入核心机房。分两种，(1)消息队列写入远程机房，即网络出现问题，"写"在MQ里不影响。(2)实时性高，跨机房直接写入db， 如网络问题失败，可以做降级

另外机房间流量调度我们实用GSLB来调度，后面有详细阐述。

2.2读写均衡业务

读写均衡业务有重要特性，按照用户维度切分，相互关联不大。把（联系人、短信、 ...）同步云端，永不丢失。

同步业务单机房架构

跨机房方案：(1)直接按照用户做全局路由，路由到不同机房即可，存储到不同DB分片

(2)业务数据和服务打包到单个Unit(可单独部署)，一个Unit服务一定数量的用户。每个机房有多个Unit,本地远程备份

(3)API访问时，GSLB把客户端请求调度到就近机房，获取用户数据所在位置（用户数据同时仅在某一个机房提供服务）。

ps；Web服务无法使用GSLB不能精准调度

三、机房流量的精确调度

3.1最简单的流量调度：智能DNS服务

只能DNS根据LocalDNS请求IP来判定是哪个ISP，哪个区域用户，调度到对应ISP,区域的机房，核心在智能DNS的IP库。

缺点：

DNS劫持, 在我国时有发生，尤其二三线城市运营商，明目张胆无法解决

设置指定DNS无法对应ISP，随机解析到错误的ISP和机房。如8.8.8.8，智能DNS获取到的LocalDNS是美国地址，

无法根据用户信息来调度，有些数据只在特定机房有，DNS协议无法携带用户标示，不能精准解析。

无法感知服务器宕机

3.2 接入GSLB服务:

避开DNS请求，请求前，访问GSLB服务(或HttpDNS),带上用户标识，定位数据所在机房，用IP访问。所有客户端的访问，都接入GSLB

好处：

1* 根据IP或UID等精确调度。

2* 避免DNS劫持。

3* 设置DNS也不会调度错误。

问题：仅用客户端Http、Https请求，不适合浏览器访问，浏览器不清楚GSLB是什么。所以：

3.3 GSLB+智能DNS（最终路由策略）：

请求前找到DNS解析的服务器，获取数据，后端先找GSLB服务查数据所在机房，如在本机房直接返回，否则重定向发起请求。

缺点：可能导致用户浏览器里域名变换，无法避免域名劫持

问题：最终是上面两种组合？

http://www.ttlsa.com/linux/meizu-mutil-loaction-soul/