魅族多机房部署支撑网站运维的方案

魅族多机房部署支撑网站运维的方案

魅族的系统架构师刘雯做了主题为“魅族多机房部署方案”的演讲。多机房容灾备份是大型互联网公司运营的必经之路。魅族手机在2014-2015年转型发展，销量爆发后，对互联网科技业务的公信力有了新的要求，再加上最近光缆被切断的安全事故，以及一次爆炸对一个机房的危害。要求大家尽快实施多机房容灾备份方案。本次演讲详细介绍了魅族手机多机房容灾备份方案，整个实施过程中遇到的问题及防范措施，以及魅族手机重点机房转移方案及问题的解决方案。

针对魅族手机多机房部署，刘雯表示我会从开放多机房部署的原因、多机房部署遇到的挑战、魅族手机遇到的坑、多机房总流量调度等方面期待分享这一关。

为什么要开多个机房进行部署？
众所周知，魅族手机投资阿里巴巴的项目，也将手机从原来的小而精放宽了，显示屏从15:9移到了16:9。这也导致了业务的快速增长和用户数量的激增。应用商城日PV已经达到2.5亿，线上歌曲达到2.3亿。
应对重要业务量激增，单间扩容困难。另外还遇到单间无法灾后恢复的问题。说白了，再强的技术也支撑不了挖掘机。因此，迫切需要部署多个房间。
多个机房遇到的挑战
如果要部署多个机房，会遇到无法保证数据一致性、跨机房专线运输价格高且无保障、总流量如何精确调度、业务相互依赖复杂、跨机房网络延迟等问题。
对于这件事，刘雯表明，大部分业务投射成两类，一类是读得多写得少的业务；一种是按照用户级别划分的业务。其中，魅族手机的应用商城的特点是显示总列表，数据变化很少，一致性要求不是很高，也就是针对每一个业务进行仔细分析。
机房总流量调度
谈到机房总流量调度，刘雯表示两个关键的方法是智能DNS和GSLB，实际如下图所示:

智能DNS

GSLB
根据这两种方法，大部分都完成了局域网上不同区域网络服务器总流量的配置，以保证拥有最好网络服务器的用户离自己最近。一般来说，上海的用户浏览上海的服务项目，北京的用户浏览北京的网络服务器，这样就保证了浏览质量。

你遇到了什么“坑”
在整个实施过程中有两个缺点。一是VPN机器CPU太高，二是国外机房的从Mysql，跟不上主。经过对数据包捕获软件的仔细观察和分析，最后，我们采取了对策。首先我们做了电信网和联通的两个VPN，互相备份数据。其次关键数据有QoS保证，最后选择专业的VPN机器设备。

魅族手机多机房计划
大家按照上面的计划，把业务组织起来，投射到下面两个业务上:
(1)多读少写
(2)按用户分开
。
应用商城单间框架如下:

连接分为三个服务，API，开发者平台，运营后台。
API将socket呈现给移动应用商城应用，主要是加载通用列表数据展现给用户。这些“读取”都是基于缓存文件的，对数据库的依赖不大；然后就是少量的从一些统计数据、评价等“写”出来的。
但开发者平台呈现给开发者和App厂商的是提交、维护和应用，文字数据更多，读写能力均衡。
后台管理是提交给企业内部业务单元进行应用，以及维护总列表、使用左右框架等功能。，也有更多的“写作”。
对业务的可用性进行分类后，应用商城(APIsocket)的可用性最大，而运营后台和开发者平台的可用性要求略低。
根据上面的分析，你只需要把多机房方案展示给应用商城(APIsocket)就可以了。
应用商城的多房间架构如下:

不需要修改关键机房的部署基础。华东地区机房的数据是按照MySQL的相同功能复制的。总表数据加载与关键机房一致，从Redis缓存文件加载。Redis缓存文件的数据可以通过调度任务从DB中获取，定时执行，在Redis中刷出。
为了更好的保证数据的一致性，“写”还是点写，跨机房立即加载到关键机房。有两种，一种是根据消息队列加载到远程控制机房。即使机房上网出现问题，每个人的“文字”都可以存入MQ。基础不伤害用户感情，沉淀的数据会在上网后拉出来。另一个“写”规则是，立即知道“写”是否成功，因此它立即被加载到整个机房的数据库中。如果互联网出现问题，就会导致失败，我们可以做降级解决方案。
另外，GSLB用于调度机房的总流量，后面会详细讨论。
读写能力平衡业务
这里读写能力平衡业务的一个关键特点是所有数据都可以按照用户级别进行划分。相关系数并不大。比如人人的点对点服务，点对点服务，连接了手机上所有的数据(手机联系人、短信、设置、wifi、电脑输入法偏好...)到云空。当手机被盗，需要一键刷机清除数据时，可以随时随地将数据拉出来，保证数据永不丢失。
以下是同一商家的单间结构:

人人的用户浏览socket也分为两部分，一部分是移动端易于使用的API，另一部分是Web端用户可以立即 *** 作(对手机联系人进行更改)。Websocket获取的需求与后端服务项共享，如手机联系人、信息、设置等服务项。后端开发服务项根据用户路由器信息内容存储在不同的DB块中。
在这里做跨机房规划更方便。你可以马上根据用户做一个全局路由器，路由器可以去不同的机房。
跨机房框架图如下:

每个人都把业务数据和服务项目打包成一个单元，一定数量的用户拥有一个单元服务项目。每个单元包括详细的数据和服务项目，可以独立部署。每个机房都有几个单元，每个用户的数据都有一个本地备份数据，以及一个远程控制备份数据。机房出现常见故障时，可以拉起备份数据为项目用户服务。
当用户根据API浏览每个人的服务项目时，应该使用GSLB进行调度。用户在浏览业务服务项目时，首先要从GSLB获取用户数据的地理位置(用户数据只显示某个机房的服务项目)，然后将手机客户端需求调度到相应的机房。
Web需求是一项挑战。因为web服务不能应用GSLB，所以不可能准确地调度用户需求。这方面的计划在后面的总流程调度中有所提及。
机房总流量的精确调度
[/s2/]当涉及到多个机房时，就涉及到总流量调度。总流量调度很简单，就是智能DNS服务的应用。如下图:

只有DNS可以根据来自LocalDNS的请求中的IP判断你是哪个ISP，哪个区域的用户，然后调度到匹配的ISP和匹配区域的机房。关键在于智能DNS的IP库。几个缺陷:
DNS被劫持。在中国，DNS劫持经常发生，尤其是二三线城市，更是肆无忌惮。这在智能DNS的基础上是无法处理的
。如果将LocalDNS设置为用户自己的特定DNS网络服务器，比如8.8.8.8，那么智能DNS网络服务器获取的本地DNS就是美国地址，无法匹配ISP。智能DNS服务项目只能根据设计者的爱好来分析，而此时很有可能用户会发现不正确的ISP和不正确的机房。
无法根据用户信息内容进行调度。有些数据只有在专门的机房才有，因为DNS协议不能携带用户身份，所以很难保证分析准确。
我无法识别停机时间。
因此，针对特殊业务，每个人都连接了GSLB服务项目:

此服务绕过DNS要求。在提出请求之前，请浏览我们自己的GSLB服务(或HttpDNS)。服务可以携带用户logo精准定位自身数据所在的机房，使用IP浏览服务项目。
有很多显著的好处:
*它可以根据IP或UID精确调度信息内容。
*防止DNS被劫持。
*如果用户手动设置DNS，他们不会安排错误。
在这个阶段，所有的手机客户端都是连接GSLB的，比如上面提到的应用商店，用户的API浏览等。
但是，有一些问题。这种方案只满足手机客户端Http和Https的要求，不适合电脑浏览器浏览，电脑浏览器不知道你的GSLB是什么。用户的API浏览可以用GSLB来完成，但是在网页浏览的情况下，不能用GSLB来调度总流量。因为电脑浏览器不识别GSLB，如果应用智能DNS，就不能根据用户ID准确调度总流量。
基于以上考虑，我们明确提出了第三个方案，GSLB智能DNS:

在请求用户服务之前，查找由DNS分析的网络服务器以获取数据。后端开发服务将首先寻找GSLB服务来搜索用户数据所属的机房。如果用户数据在这个机房，它会立即返回数据。否则，跳转到相应的计算机房再次请求。
这种方案很可能造成用户电脑浏览器中的网站域名转换，危及用户体验，仍然无法防止流量劫持。