魅族系统架构师何伟带来了主题为《魅族多机房部署方案》的演讲，多机房容灾是规模互联网企业的必经之路，魅族经过2014-2015年的转型以及销量大爆发后，对互联网业务的可靠性要求有了新的诉求，再加上近期的光纤被挖断事故、某大爆炸对某机房的影响等等，都要求我们尽快实施多机房容灾方案，本次演讲主要介绍魅族在多机房容灾的方案以及实施过程中碰到的问题和对策，以及魅族核心机房的迁移方案和问题的解决方案。

对于魅族多机房部署，何伟表示，我将从为什么做多机房部署、多机房部署面临的挑战、魅族的多机房部署以及踩到的坑、多机房流量调度，希望分享大家的主要就是这些方面。

   为什么要做多机房部署？
   对于阿里投资魅族大家都知道了，魅族也放开了手机从原来的小而美，真正走向大众需求，屏幕也从15:9走向了16:9，这也带来了业务的高速增长，用户量暴增，应用商店日PV达到了2.5亿、在线音乐达到了2.3亿、同步数据量也达到了300亿条记录。
   面对关键业务量的暴增，单机房扩展困难，同时还面临着单机房无法容灾的问题，所谓技术再强，扛不住挖掘机，因此多机房部署迫在眉睫。
   多机房面临的挑战
  想要部署多机房，面临着数据一致性难以保障、跨机房专线昂贵、无保障、流量怎么精准调度、业务依赖关系复杂、跨机房网络延迟等等问题。
  对此何伟表示，我们把大部分业务映射为两大类，一类是读多写少的业务；一类是按用户维度划分的业务，其中魅族的应用商店特点，就是榜单展示、数据变化少、一致性要求并不是很高，就是对于每一个业务进行认真分析。
   机房流量调度
  谈到机房流量调度，何伟表示，我们主要采用了智能DNS和GSLB这两种方式，具体如图所示：

智能DNS

GSLB
 通过这两种方式，基本上实现了在广域网上不同地域的服务器建的流量调配，保证使用最佳的服务器离自己最近的用户，通俗讲就是上海用户访问上海服务，北京用户访问北京服务器，从而确保访问质量。

遇到的哪些“坑”
  在实施过程中存在的问题是两个方面，首先是VPN设备CPU占用率过高，其次是异地机房Slave Mysql跟不上Master，经过认真的观察、抓包分析，最终我们采取的措施，首先针对电信和联通做了两个VPN相互备份；其次核心数据采取QoS保障，最后采用了专门的VPN设备。

魅族多机房方案
我们借鉴以上几种方案，把业务进行一些梳理，映射到下面两种业务：
（1）读多写少
（2）按用户分离
读多写少
这类业务主要是读取，极少写入，所以我们甚至把这类业务归纳为只读业务。
应用商店单机房架构如下图：

接入端分三种业务，API、开发者社区、运营后台。
API提供接口给手机端应用商店使用，主要是读取榜单数据展示给用户看，这部分“读”我们基本是从缓存读取，对数据库的依赖都很小；再就是少量的“写”来自一些统计信息、评论等。
而开发者社区提供给开发者和App厂商上传、维护应用，写数据比较多，读写基本均衡。
后台提供给公司内部运营部门使用，榜单维护、应用上下架等功能，也有较多的“写”。
经过对业务可用性做分级，应用商店(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库。有几个缺点：
DNS劫持, 在我国，DNS劫持时有发生，尤其是二三线城市的运营商，明目张胆。这在智能DNS基本无法解决
本地DNS如果设置成用户自己指定的DNS服务器如8.8.8.8，智能DNS服务器获取到的LocalDNS是美国地址，也无法对应ISP,智能DNS服务只能按设计者喜好提供解析了，这时可能给用户解析到错误的ISP和错误的机房。
无法根据用户信息来调度，有些数据只在特定机房有，由于DNS协议无法携带用户标示，所以也很难做到精准解析。
无法感知服务器宕机。
由此就针对特定业务，我们接入了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服务查找用户数据所在机房，如果用户数据在本机房，则直接返回数据，否则，重定向用户请求到合适的机房重新发起请求。
这种方案可能导致用户浏览器里域名变换，影响用户体验，另外依然无法避免域名劫持。