魅族多机房部署方案

最新推荐文章于 2024-08-19 07:51:02 发布

cxzhq2002

最新推荐文章于 2024-08-19 07:51:02 发布

阅读量1k

点赞数

魅族为什么做多机房部署？

2014年魅族转型，转型之后放弃小而美的发展模式，这个时候用户量达到2500万，这个是比较早的数量，还不包括双11的数量，达到2000万之后，机房扩展出现了一个瓶颈，单机房已经很难满足需求了。

魅族不就是做手机的

图片描述

魅族的应用商店，日PV2.5亿；在线引用，日PV2.3亿；用户数据同步，即包括联系人、短信、设置项目在内的用户手机上的数据，全部传到云端，日PV也有3.6亿，数据量可达300亿条记录，规模较大。

单机房的问题

1.扩展存在困难

之前的机房选址广州亚泰，质量可观，机位紧俏。相应的，扩容就很困难，绝不是需要就可以马上得到。我们要提前预约好机柜的数量，但业务量爆发的时候，数量可能会超出预计，因而单机房扩容，极为困难。

2.价格很难谈妥

因为只有一个机房，在与机房IDC谈商务条款时屡遭困难，对方云淡风轻“要不你就拆迁呗”，我们无可奈何，并没地方迁，价格因而很难谈下来。

3.无法做到容灾

挖掘机挖段光纤的事情屡见不鲜，支付宝也曾不幸中招业务中断。当然他们基于更为复杂的业务也有相应的多机房容灾机制。此外也有云服务商的机房遭受闪电攻击，进而电力出现问题。单机房若遭闪电必停止服务无疑。

实际经营中，各种意想不到的情况都有可能发生。因此：魅族在2014年初时即着手准备做多机房部署。

多机房部署面临的挑战

首先是数据一致性难以保障，这是最大的一个问题，当数据在一个地方有变动，在另外一个地方怎么样体现出来，这很困难。如果机房和机房之间通过网络传输数据，先不论可怕的网络延时，跨机房专线的昂贵和无保障也足以让人望而却步。运营商不可能说专线给你做到3个9或者是4个9，一般99.5就不错了，你怎么样做到3个9，4个9，这个问题只有自己解决。
我们的流量该怎样调度？用户怎样决定去A机房还是B机房，用什么方式决定？
业务层面，多机房的架构，必须考虑业务部门的感受，不能天马行空。我说我哪里那里需要重写，业务部门很难接受。所以方案必须要让业务部门改动尽可能小。
最后，因为各个业务之间的依赖关系很复杂，之前也要做若干解偶和业务的切分。

魅族的两大跨机房部署方案

图片描述

大大小小五六十个业务，映射到两种类型，第一个是读多写少的业务，另外一个是按用户维度划分的业务，是两种不同的方案。

图片描述

应用商店想必已经周所周知。而魅族的应用商店有一个特点，数据是一个榜单，主要是展示它给大家看，不管是竞选、排行、分类，各种都是榜单，数据变化很小、很少，对数据的一致性要求并不高，A和B用户看到的数据可能不一致，并不会影响大局，只要可以下载应用就可以。

跨机房之一，应用商店

单机房架构下业务分为三类：

图片描述

API客户端接入使用，客户端就是应用商店的APP要想下载，就在这里拉数据、列表。
开发者社区，提供给开发者维护应用的数据。API数据的一个特征主要是读取数据，写很少，只是拉榜单出来。一部分像评论，下载的话有一个下载的机数，数量较少。而开发者社区的读和写差不多，量也是差不多。
运营后台，主要是后台运营成员来维护数据，读和写也类似，数量上差不多。我们前端划分了许多业务，后端则会有一些服务化的按照业务做了切分，做不同的服务，应用排行、购买服务、运营服务等等，数据如API等，要使用应用排行，需要通过Task到Recis集群读取。

应用商店怎样做到多机房

图片描述

A机房主要是读取数据，在我们业务部门里面叫做读业务，因为只有读而很少有写，所以多机房主要是处理这一类，即API的读取。这块数据对用户来说很重要，开发者社区和运营社区挂掉无所谓，大不了开发者、运营人员看不到，可用性可以稍微低一点，但是对普通用户来讲，可用性要求会高一些。况且数据又是只读的，所以魅族将这部分拿出来做多机房服务。
数据是怎么走的？魅族的核心机房还在广州，华东另外部署了一个机房，数据是通过macical同步服务，这边同步了一个数据，刷到了Recis的集群，如上文所言两边的数据一致性并不高，所以两边的Recis集群数据可以不一致，用户看到不一致没有任何关系。分为两种写，一种写是立即生效的，是跨机房直接写到我们的CB，这块写如果失败的话，会有一个服务，这个服务会做降级。另外一个写，是用户不一定马上要落地这个数据的，这个时候通过MQ写到本地机房，异地机房拉这个数据，拉到这个数据之后，就会落地。这里主要是应用商店多机房的部署。还有一点值得补充：就我们的写而言，网络挂掉对我们并没有什么影响，因为数据已经CB里面存了，直接过去拿就可以了。这个就是我们多机房部署，这里面会涉及到一个用户流量的调度，后面会单独来说。

跨机房之二，数据同步

读写均衡，数据量大

图片描述

如上文所言，这部分数据是根据用户的维度可以做切分的，方案有所不同。不妨细化一下这部分数据的内容：联系人、便签、数据、信息等等。这些数据都可以存储到云端，是送存储上去的，好处很明显——假设手机丢了，数据还在云端，重新买一个魅族手机，拉下来就可以了，当然仅限魅族手机。而如果用户需要清系统、清数据，也不用考虑任何东西，可直接清理。清完数据之后，登录帐号，数据就会自动被拉下来。

以上是这一部分服务的介绍。它的特点是读和写差不多，甚至是写比读还大，不同于应用市场主要是读，读多写少的只读业务，这个是读和写是均衡的，另外数据量非常大，也超过应用市场，一个应用商店就几十万的应用，其实数据量并不大，而这个数据量是会增大的，PV达到3亿左右。

同步业务的单机房部署

图片描述

我们有访问两种方式，一种是API，是我们的手机端，手机端访问数据。另外一个是WEB，在WEB上维护自己的数据，比如说WEB端添加联系人也是可以的，通过API在你手机同步下去。业务模块划分很多，像联系人同步、短信同步、输入法偏好/设置项同步。数据一部分存在DB里面，另一部分存在集群里面，用户和用户之间的数据没有必然的联系，所以可以很简单的切开，根据用户ID来切分。访问数据的时候，先从这个路由的DB去取数据，取出来说这个用户的数据是在哪个DB的，还有文件是存在哪个文件系统的，取出来之后，就知道用哪个DB了，这个缓冲用的并不太高，而缓冲主要是用在路由DB这部分。

同步业务的多机房部署解决方案

图片描述

这里有三个机房，看一个机房即可，每一个机房会把业务打包成一个一个的单元，一个单元包含了接入的服务，包含了后端的业务逻辑，包含数据，这个单元单独拿出来可以单独做服务，和其他的公共服务没有关系，像认证、用户流量的调度、用户路由有关系，用户来请求，会先找到GSLB服务，这里有用户的调度，拿到请求之后，会找GSLB服务，看数据在哪个机房，找到对应机房之后，找到对应的是哪个单元，找到数据之后，直接拿数据就可以了，而这部分的数据，会有一个备份，在本地的话，数据会有组成的备份，一个组挂了，会马上自动的起来，一个数据会自动的备份到另一个机房，假设这个机房实在起不来了，挂了，则人工把这部分的用户导到这边来，再在这边拉起服务为用户服务，按用户维度切分的。

多机房下的流量调度

智能DNS和GSLB

刚才所涉及的众多业务，因数据不是在每一个机房都有，所以调度很重要。流量调度分为两种，一种是智能DNS，另一个是GSLB。

图片描述

智能DNS，顾名思义，用户拿了一个域名解析，会找到你的用户应提供给你的服务，拿这个去做解析，当然可能也缓存，如果没有的话，就会找到我们的DNS服务器，去问我的IP是什么，这时候所谓的智能，是根据LacalDNS来解析你的地址出来，例如你这个IP是电信的，或者是联通的，这里就能够知道，那好，我要给你一个电信的IP，最后就返回一个IP地址给你。有两个问题存在，一个是DNS延时，在中国二线、三线城市经常出现，一线城市一般没有，好象没有见过有一线城市有DNS流失，二三线城市，基于运营商利益的考虑，例如流量，还可以做缓存，运营商和运营商之间的流量解析计算费用是非常之高的，所以为了节省这部分的费用，会把你一部分的数据、一部分的内容，缓存到他的服务器，这时候DNS解析的话，是会到虚拟的服务器，而不是到你的服务器，避免网间结算的费用。另外还有一些插广告那些东西。假设LocalDNS是我自己定义的，像有人愿意填谷歌提供的服务，我的DNS，看到的是你的LocalDNS是来自美国的，不知道这个时候分配你什么样的IP了，可能给你一个电信或者是联通的，如果这时候IP不对，用户的体验会出问题的。另外是无法根据用户数据来做调度，只根据你的IP来做调度，如果像最后说的那种业务的话，我们的是根据用户的数据来切分的，而这个数据只存在一个机房，这时候一个业务过来了，很可能找不到我要的数据，如果只用智能DNS的话。下面就出现了一个GSLB，很多公司都会用它，它是什么？是全球服务负载均衡。它是怎么做的呢？我们提供了GSLB的服务，你请求真正的服务之前，先找到GSLB服务去问，说我这个数据应当是在哪个地方，你给我一个IP，这个时候可以根据用户的来源IP来决定，比如说用户是南方的，就给一个南方的IP，如果用户是电信的，就给一个电信的IP，拿到数据之后访问相应的服务。这里有一个问题，浏览器并不认GSLB，而只认DNS，不知道GSLB是什么，所以说并不适合浏览器的访问。当然它的好处是像DNS延时的话，就被避免了，因为不走用户的DNS解析了。用户自己设所谓的DNS解析，这个也不会有问题，还有一个好处，可以根据用户ID做解析， ID从用户端可以传到GSLB，可以判断用户数据归属地，例如是北方的，就是北方的一个IP，这个是GSLB，有它的问题，刚才说了浏览器没有办法使用。刚才的同步业务，有两种访问方式，一种是API的访问方式，还有一种是通过WEB的访问方式，但是并不是所有的机房都有，如果是通过API访问的话，用GSLB可以解决这个问题，但是通过浏览器的话，就没有办法解决这个问题了，因为我们的用户数据只在一个机房，用户ID没有办法传给用户去做调度，这个时候有另外一个方案，一个请求过来的时候，会先去找DNS解析，拿到这个IP，会去访问他的同步服务，访问同步服务的时候，已经把用户ID带过来了，用户ID拿到之后，会找GSLB的服务，看数据是不是在这个机房，如果我说数据在这个机房的话，就直接返回用户的数据就可以了，如果说不在这个机房，就会告诉这个服务，说我的数据会在哪个机房，这个时候会返回一个302，给一个正确的机房，比如说是北京的机房，这个时候也有一些问题，例如说域名可能会变掉，浏览器中发现域名不一致，和之前访问的不太一样，这是WEB访问时候的调度方案。

实施过程

多机房的问题与对策

图片描述

机房和机房之间的连接，不是用的专线，而不像BRTR，用起来很爽，像同一个机房一样，我们用的是VPN。两个机房之间，会做两条VPN，一条是走电信的，一条是走联通的，两个VPN可以做相互的备份，一个VPN挂了，另一个VPN会把数据连接起来。问题主要是处在VPN中，VPN之前并不是用在承载用户，所以这个VPN的CPU不是很强，会导致我们的数据很薄，搞得很头大，当然后来我们就换了专用的VPN防火墙解决这个问题。
另外一个是Slave，异地的Slave是跟不上Master，如果数据写到异地机房了，马上需要读到的话，这个时候会直接到异地读，而不是去本地读，因为本地数据还没有跟上。VPN还有一个问题上文没有涉及，VPN网络会很多业务一起用，这个时候有一些是核心数据，一些不是核心数据，这个时候我们就用QoS对用户做保障，来解决这个问题。

未来多机房方案展望

多机房的问题与对策

图片描述

一是数据库需要统一的管理平台，这个管理也很复杂，跨机房，这个平台可能要做一些事，是复制、备份、迁移、扩容等等，二是用户的数据，如上文所言，同步数据是在不同机房的，如果这个用户本来是在深圳的，但是后来找了工作之后在北京，这个时候的数据可能一直是异地访问的，这个时候因为用户体验并不是特别好，后面会根据常用地变化做一个迁移。写入还是当地写，可能后面会考虑多地写，这个当然很难了。