(魅族多机房部署方案.docVIP

魅族为什么做多机房部署？ 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里面存了，直接过去拿就可以了。这个就是我们多机房部署，这里面会涉及到一个用户流量的调度，后面会单独来说。 跨机房之二，数据同步 读写均衡，数据量大 如上文所言，这部分数据是根据用户的维度可以做切分的，方案有所不同。不妨细化一下这部分数据的内容：联系