2015.12.30 丨 壹佰案例

案例分享| 魅族多机房部署方案

2015.12.30 丨 壹佰案例

本文是根据魅族系统架构师何伟11月28日在麦思博(msup)有限公司和魅族科技联合主办的魅族技术开放日第一期演讲中的分享内容整理而成,转发请注明出处。


作者简介

何伟,2009年加入魅族
现负责魅族科技互联网•技术平台


活动:魅族技术开放日第一期

演讲主题:魅族多机房部署方案

时间:2015年11月28日 下午

地点:深圳弈投咖啡


正文

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

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


魅族不就是做手机的
还有什么业务?

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

1
扩展存在困难
之前的机房选址广州亚泰,质量可观,机位紧俏。相应的,扩容就很困难,绝不是需要就可以马上得到。我们要提前预约好机柜的数量,但业务量爆发的时候,数量可能会超出预计,因而单机房扩容,极为困难。
2
价格很难谈妥
因为只有一个机房,在与机房IDC谈商务条款时屡遭困难,对方云淡风轻“要不你就拆迁呗”,我们无可奈何,并没地方迁,价格因而很难谈下来。
3
无法做到容灾
挖掘机挖段光纤的事情屡见不鲜,支付宝也曾不幸中招业务中断。当然他们基于更为复杂的业务也有相应的多机房容灾机制。此外也有云服务商的机房遭受闪电攻击,进而电力出现问题。单机房若遭闪电必停止服务无疑。

实际经营中,各种意想不到的情况都有可能发生。

因此:魅族在2014年初时即着手准备做多机房部署。


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

最后,因为各个业务之间的依赖关系很复杂,之前也要做若干解偶和业务的切分。


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


大大小小五六十个业务,映射到两种类型,第一个是读多写少的业务,另外一个是按用户维度划分的业务,是两种不同的方案。
应用商店想必已经周所周知。而魅族的应用商店有一个特点,数据是一个榜单,主要是展示它给大家看,不管是竞选、排行、分类,各种都是榜单,数据变化很小、很少,对数据的一致性要求并不高,A和B用户看到的数据可能不一致,并不会影响大局,只要可以下载应用就可以。
跨机房之一,应用商店
单机房架构下业务分为三类
1
API客户端接入使用,客户端就是应用商店的APP要想下载,就在这里拉数据、列表。
2
开发者社区,提供给开发者维护应用的数据。API数据的一个特征主要是读取数据,写很少,只是拉榜单出来。一部分像评论,下载的话有一个下载的机数,数量较少。而开发者社区的读和写差不多,量也是差不多。
3
运营后台,主要是后台运营成员来维护数据,读和写也类似,数量上差不多。我们前端划分了许多业务,后端则会有一些服务化的按照业务做了切分,做不同的服务,应用排行、购买服务、运营服务等等,数据如API等,要使用应用排行,需要通过Task到Recis集群读取。
应用商店怎样做到多机房
1
A机房主要是读取数据,在我们业务部门里面叫做读业务,因为只有读而很少有写,所以多机房主要是处理这一类,即API的读取。这块数据对用户来说很重要,开发者社区和运营社区挂掉无所谓,大不了开发者、运营人员看不到,可用性可以稍微低一点,但是对普通用户来讲,可用性要求会高一些。况且数据又是只读的,所以魅族将这部分拿出来做多机房服务。
2
数据是怎么走的?
魅族的核心机房还在广州,华东另外部署了一个机房,数据是通过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访问时候的调度方案。
实施过程
多机房的问题与对策
1
机房和机房之间的连接,不是用的专线,而不像BRTR,用起来很爽,像同一个机房一样,我们用的是VPN。两个机房之间,会做两条VPN,一条是走电信的,一条是走联通的,两个VPN可以做相互的备份,一个VPN挂了,另一个VPN会把数据连接起来。问题主要是处在VPN中,VPN之前并不是用在承载用户,所以这个VPN的CPU不是很强,会导致我们的数据很薄,搞得很头大,当然后来我们就换了专用的VPN防火墙解决这个问题。

2
另外一个是Slave,异地的Slave是跟不上Master,如果数据写到异地机房了,马上需要读到的话,这个时候会直接到异地读,而不是去本地读,因为本地数据还没有跟上。VPN还有一个问题上文没有涉及,VPN网络会很多业务一起用,这个时候有一些是核心数据,一些不是核心数据,这个时候我们就用QoS对用户做保障,来解决这个问题。
未来多机房方案展望
多机房的问题与对策

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


结语:以上是魅族系统架构师何伟在msup和魅族联合举办的#魅族技术开放日#的演讲内容,多机房部署方案还将进一步完善,我们拭目以待。


▼关注「TOP100summit」微信公众号获取into100沙龙最新动态 。


媒体联系

票务咨询:赵丹丹 15802217295

赞助咨询:郭艳慧 13043218801

媒体支持:景    怡 13920859305

提交需求