我们为什么要做多机房部署

魅族经过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服务查找用户数据所在机房，如果用户数据在本机房，则直接返回数据，否则，重定向用户请求到合适的机房重新发起请求。

这种方案可能导致用户浏览器里域名变换，影响用户体验，另外依然无法避免域名劫持。

总结

本篇文章主要介绍魅族在多机房容灾的方案以及实施过程中碰到的问题和对策，以及魅族核心机房的迁移方案和问题的解决方案。

您在多机房部署方面拥有哪些心得及经验？欢迎在评论中分享。