Mobvista汇量科技 首席技术官 王平

以下为演讲实录：

我给大家带来的分享是：作为一家数字营销公司，如何在AWS架构平台下实现系统整体的落地。

整体分四部分，首先是业务背景及场景介绍，运维面临的问题，架构及应用解决方案，以及最后总结为什么选择AWS。

简单延伸一下为什么从运维角度分享，其实我们也是一家创业公司，很多时候作为创业型的公司运维上会投入比较大，但在AWS下落地可以减少运维成本，让我们的系统更加稳健。

首先说一下我们的生意，我们是一家全球化的公司，帮助开发者推广他的产品，并实现技术变现。我们大约有13个办公室，公司有500+的员工， 40%是研发人员，我们是产品驱动技术型的公司。

由于2016年的财报数据暂未披露，所以11亿的营收是2015年的数据。另外去年8月我们公布了2016年上半年财报，报告期内公司实现营业收入7.89亿元，仅用半年时间就超过了2015年年报的全年数字。这一业绩在新三板挂牌同业公司中位列第一。

左边是整体系统的抽象化概念图，我们有两块业务，一块是推广，一块是变现，推广就是帮助APP开发者、移动开发者，把他的APP推广到全球，让全球用户去下载、安装。第二是变现，帮助开发者通过集成我们的SDK实现他们的流量变现。

整体上来说，我们的广告用户流量应该覆盖240个国家和地区，日展示量100亿，全球用户数据大概20亿左右，现在变现的SDK月活跃数据超过3亿。基于这样的数据，我们整体架构解决方案都是由这两种业务驱动的。

我们的移动广告的推广模式，就是在各个媒体展示我们的广告，当用户看到广告点击之后就会有各种跳转，在GP、iOS上去下载，完成之后就是安装，整个业务的生意模式就完成了，看着比较简单。

在这样一个体量下面临哪几个问题，核心是五个：

1、我们的流量在全球，而各地的网络也是极其复杂的，如何在这样复杂的网络情况下，如何让所有的用户能够得到一个比较理想的广告展示和点击下载的环境，这是第一个需要解决的问题。

2、海量用户下载访问，会导致高并发，高并发带来的进一步问题是流量的不可控性，会导致爆量，代表服务器可能出现异常，企业就会受到影响。

3、海量数据下如何实现高速查询

4、利用云计算平台如何做数据分析、挖掘以及相关的模型训练。

5、全球的异地容灾和故障转移。

整体系统架构

几乎所有的模块都是在AWS的平台上，都是AWS相对成熟以及稳健运作的模块。首先当用户过来，我们会通过DNS做相关的路由。当用户点击跳转展示的时候，进入到整体真正的后台服务模块。我们整体在全球部署了11个地区的服务框架，首先通过ELB做一个负载均衡，然后又通过 Auto Scaling的方式，动态启停相关的服务，确保容错性。

随后是DynamoDB，大数据部分用了EMR。所有的数据通过S3存储，通过EMR或者S3的平台再把相关数据直接推送到业务平台，让我们的业务正常运作起来。

关于全球用户的访问，以及如何解决相关的访问体验问题，主要是三个方面。第一我们会部署11个全球地区，然后在通过Route 53，寻找链条最短的一条地区，在地区里通过负载均衡落实到相关的实例上，这是我们基本的对于网络优化的思路。

我们取了8月份一周的数据，可以看到一天流量存在波动，与此同时每天流量存在自然上涨的过程。最可怕的是我们时不时遇到浏量突增，曾经遇到突增流量服务器宕机的情况。

对于系统的稳定性是我们需要去解决的问题。这一块我们采取了几个措施，第一个措施，从整体对我们的系统架构进行重构，对各个服务进行一定的解耦，然后部署在不同的服务器上，这样确保一个事情，不同业务之间的影响尽可能降到最低，尤其需要避免的问题是： 次要的业务影响主体的业务，冲击主体业务的收入。同时我们会通过AutoScaling的方式，自动扩容，在面临流量突增的情况下，让服务器直接起来，这套方案，通过运维人员的技术平台和调用AWS的接口实现这一功能。

前端的扩容相对容易，后端对于接收到请求之后有一系列的复杂算法计算，这个消耗是存在的，后端的系统相对会更加困难。那我们会做异步化，在一些核心环节，让请求过来后进行必要的响应，同时把请求扔到相关的文件或队列里面，通过异步的方式去消耗。这样前端的整体性就会得到一个比较好的提升，业务不会因为突然波动而增加，让后台数据计算发生崩坏的连锁反应。

解决海量数据高速查询

海量数据高速查询，简单介绍一下，2013年成立的一家公司到现在经历的阶段，每秒处理5-10K的写入，如何完成毫秒级的查询这样一个课题。

最早我们的数据量几十万，采取的是一个简单的MongoDB单点，优势比较明显，快速简单，缺点是单点问题，读写压力非常大。

等到数据量长到百万级，这样的模式就不太适用了。我们在MongoDB的基础上加上了一个Replica Set。带来的好处一是读写分离，第二个是单点问题被取消了，但有了一个隐患，因为是全量数据，随着业务的增长后续横向扩增就会是约束。

随后到千万量级，在这个基础上又做了一次Sharding，本质上分表分库。这实现了真正的分布式，整体硬件和后期维护的成本非常高，或者说一旦重新调整分片，整个时间会非常长。这是到千万量级面临的问题。

最后到亿级的时候，最终选择的是用DynamoDB来解决快速查询的问题，他把上面出现的问题几乎很好的解决了，也是我们现在使用比较广泛的查询服务。优势是几乎不需要人为干扰，不需要再考虑人为介入。

在使用DynamoDB之后，最上面这条线是我们预留的资源，下面一条线是实际跑的资源，整体贴合比较近。从这个角度来说，当时在用MongoDB预留的比较多，浪费比较多，现在下来几乎比较好的贴合这条线然后很好的控制成本。

大数据的分析统计

大数据分析这一块的技术运维部署，整体是变现的框架，举例来说。最前端是一些SDK和API，中间有一些广告展示，当用户看到广告点击的时候，自然而然进入全球化部署的各个地区，相关的日志数据都会集中到新加坡节点，所有数据都是在新加坡节点集中处理。整个分析平台搭建亚马逊EMR上，底层是hadoop。里边的数据挖掘、机器学习都是在这个平台上完成。随后输出的模型就涉及到在线服务，其中到了全球各个节点，这是一个基本的系统部署。

这里边的核心又到了两个模块，一个是EMR，一个是Redshift。Redshift适合报表查询，通过Redshift快速的查询相关数据，进行各种维度分析。EMR是Hadoop平台。所有的数据都是按照这一条数据流进行，全球数据都存储在S3上，然后整体汇总在新加坡节点中心，S3是全球透明的文件系统，对我们来说是一个整体，使用比较便利。这个过程中进入了Reshift平台最后进入业务集群。Reshift在快速查询上做的还是非常不错的，具备优点是对表格有自动的分区，中间拓展也无需停机，也支持相关的备份，兼容性比较好。

原先我们尝试过自己搭建分布式平台，过程中所有的问题都能解决，但发现我们投入了过多的资源在维护上，后边我们就迁移到EMR上，这样带来的好处是：整个EMR平台是非常便捷的，当你需要的时候大约10分钟之内就能把整个服务器跑完，跑完之后就可以退出。

现在我们已经有几十万的任务一直在Hadoop平台上面跑，这样的情况下不会频繁的开关机，我们有一个集群一直24小时在跑相关的任务。对于初创的公司，这样一个快速的切入是非常便捷，整体使用也非常方便，大概是四步就能把一个运行的任务跑完。中间整个集群又有AWS支持团队，大大减少了维护的成本。

全球异地容灾及故障转移

最后简单说一下，一个机房如何进行容量切分，第一DNS会检查各个地区之间的健康状况，会找一个效果最好的地区，在每个地区内部又通过负载均衡模块，检查各个状态，选择一个最佳的。这是一个大的机房或一个大的片区出现问题的时候可以解决问题。

为什么选择AWS

我之前所在的公司基本很多模块都是自建的。最早我也有一种想法，有一些东西还是有必要自建，但真正进入一家创业公司来看业务、产出效率的时候，我更看重投入产出比、效率、成本这些因素，这些角度我更愿意倾向选择AWS。

这是我们选择时候的一些考量，整体上来说一是方便，第二是成本比较好的可控，第三是作为从2013年走到现在的公司，从小到大，每个阶段都会发现AWS都有对应配套的工具能够支撑好我们的业务，至少现在还没有发现有脱节的时候。

与此同时，我们现在整个公司500多人，技术团队150多人，线上服务器，整体每个月的费用会非常高，但这个情况下，我们运维团队大概只有6个人，6个人的运维团队支撑起了百亿的展示，将近超过千台服务器的维护。一定程度上一定是AWS这边有一个第二运维团队在支持我们相关工作。这也是我们为什么选择AWS的一个原因。

谢谢大家！