如何在发型不乱的前提下应对单日十亿计Web请求

原文地址：http://developer.51cto.com/art/201502/464640.htm

就在不久以前，AppLovin移动广告平台的单一广告请求数量突破了200亿大关——至关于每一秒钟处理50万项事务——其如火如荼的发展态势帮助众多品牌在激励现有客户的同时、从市场中拉拢到了新的买家。那么AppLovin是如何打造出这样一套有能力应对数百亿请求、但又无需对硬件及运维人员进行显著扩张的基础设施的呢？

在今天的文章中，咱们将共同了解该公司如何发现并选择采用各种最佳实践，从而经过技术堆栈进化实现业务规模拓展。

极具成本效率的扩展思路

让咱们首先从规模谈起。对于咱们这些在AppLovin工做的家伙来讲，极具成本效率的规模扩展方案意味着可以在大幅提高负载处理能力的同时、避免硬件或者人员的线性增加。若是咱们只能经过采购双倍的服务器设备或者将人员数量提升一倍来实现请求处理能力倍增，那么这样的方案根本没什么实际意义。因为咱们在构建基础设施时充分考虑到效率拓展需求，所以才可以在过去一年中将服务器的请求处理数量增长到此前的二十倍。

 

 

另外一项值得注意的重点在于，对于大规模分布式系统而言，市面上并无现成的解决方案可供借鉴。这类系统的构建工做必须使用自定义组件。不管归属于哪一个行业，技术团队在创建分布式系统时都须要对选定的组件进行认真评估。除此以外，每一次出现工做负载爆炸式增加的时候，这些组件也须要及时做出调整。

针对这些调整制定规划意味着基础设施自身必须拥有出色的灵活性。咱们从业务创建之初就充分意识到，移动广告领域能够说瞬息万变，而咱们则须要打造一套可以与之相匹配且相适应的灵活基础设施。咱们但愿本身的这套基础设施可以容许员工针对各种市场需求实现对应的创新活动。举例来讲，若是咱们须要进行细节调整，那么只需在现有基础设施之上直接实施便可、而无需对设施总体进行从新设计。这就是咱们工做的核心指导思想。

这套方案也切实带来了回报。咱们最近刚刚将单月信息流量提高了一倍，而让这一切变成现实的正是咱们这套灵活性出众的基础设施。

适应性强且具有可扩展能力的实时基础设施

考虑到上述构建要求，咱们所打造的基础设施堆栈中包含Web服务器、一套实时缓存层、数据库、分布式消息服务以及大规模并行计算系统。

做为前端的是成百上千台Web服务器。这些服务器设备用于应答天天来自海量用户的数十亿请求。当每一条请求传入时，咱们须要马上做出一系列决定，包括是否对其做出应答、为其支付多少成本以及提供哪条广告做为宣传内容——整个决定过程大约耗时50毫秒。

接下来咱们要作的是将用户配置信息归入缓存，整套数据库包含数十亿拥有手机设备的用户。这些信息须要在很段的时间周期内进入可用状态，从而实现Web服务器的响应并决定是否为特定广告请求提供支持。简而言之，咱们须要的是一套分布式缓存层，旨在以实时方式为所有传入请求提供所需数据。这套缓存层中使用包括Aerospike、Redis以及Memchached在内的多套系统。

除此以外，另有大量分析、报告、数据仓库以及数据科学功能集须要接入到不一样类型的数据库当中。从宏观规模角度看，这些功能必须具有分布式能力。为了实现这种分布式机制，咱们采用分布式消息或者发布/订阅消息服务。分布式消息发送机制为咱们带来了如下几项关键优点：

·咱们可以从任何位置获取须要的信息。

·咱们可以利用日志文件做为事务单元，从而处理在一秒钟内处理数以十万计请求。

·咱们可以为任何服务订阅方案提供其须要的信息。

上述消息必须被发布到全球世界内的任何位置。其目标位置多是一套惠普Vertica数据仓库、MySQL数据库、Apache Hadoop系统或者一套Apache Storm实时处理系统。分布式消息发送机制能够说是全部实时架构的核心组成部分。

最后，咱们须要利用分布式计算体系实现数据处理。拥有分布式计算体系意味着对Hadoop或者Apache Spark等技术方案的运用——这类并行处理系统可以查看所有数据并经过扩展处理规模庞大的数据负载。

以上列出的全部部件都经过一套分布式日志架构实现对接。这类基于日志架构的基本设计思路在于，它可以接纳多种数据源，利用日志文件做为事务单元并获取来自所有数据源的信息。举例来讲，一台广告服务器可能会记录下“我是否提供了广告内容？用户是否点击过广告内容？我是否感知到事务处理？”这一切都将被写入日志当中，而大量日志信息则汇聚成消息系统。这些日志不断传输、接受处理，最后的汇总数据则被写入数据库。所有此类数据都可以为日志记录系统所调用，并以订阅方式交付给任何须要这些数据的服务。

这种架构类型之因此可以实现创新，是由于咱们彻底能够将任何组件插入到系统当中。你们可能须要在特定位置插入Aerospike实时数据库，也可能但愿在其它位置使用Vertica。咱们必须有能力将所有输入信息交付给所有不一样类型的处理工具。拥有这样一套基于日志的架构可以帮助咱们经过日志将全部数据源同集中式日志记录系统对接起来，并最终成为实时订阅系统的实现基础。

评估技术选项

对咱们这套平台的评估工做可以充分展现，为何拥有具有高度灵活性的基础设施是如此重要。

咱们最初其实选择了利用PHP语言进行平台构建。这是一种效率极高的开发方式，并且也很容易找到大量熟悉此类开发任务的编程人员。一样的道理也适用于MySQL，而考虑到MongoDB做为NoSQL数据库领域重要成员的崇高地位，咱们决定将两者并行使用。固然，做为一家初创企业，咱们在起步阶段在Amazon Web Services上构建起平台的核心主体。但最后，咱们利用RabbitMQ来实现本身的发布/订阅消息机制。

随着时间的推移，咱们已经开始将数据迁移到由Aerospike、Redis、Apache Cassandra、Vertica以及Hadoop系统所共同构成的综合体系当中。咱们完成了由PHP向C++的转换，并且将消息发布任务由RabbiMQ转换到一套定制化Java系统当中。与此同时，咱们还成功削减了其它系统的使用数量，将其规模严格控制在咱们相对易于理解、而工程技术团队又明白该如何处理的程度上。

新软件的引进无疑是个成本昂贵的命题。不管是开源软件仍是专有许可软件，若是你们做出了尝试但却没能收到预期中的效果，那么整个工做就又得退回几个月以前。所以咱们认真对每款产品进行了评估，但愿能预先了解其是否物有所值。

咱们采起的第一项举措是审视行业中的其它厂商在使用哪些产品，这些产品又能给咱们的现有用例带来哪些改进。举例来讲，当评估Aerospike时，来自另外一家广告技术企业的工做人员就向咱们介绍了他的经验。咱们以后又与4、五家其它Aerospike客户进行了沟通，并提出“大家的用例跟咱们的是否存在类似之处？大家喜欢Aerospike的实际表现吗？大家对Aerospike还有哪些不满？”等问题。在此以后，咱们还很是关心“若是我将其引入本身的业务体系，是否会还出现什么意想不到的计划外情况？”

另外一项评估元素则源自开发人员的偏好倾向。这一点在开源项目当中表现得尤其突出，不过在商业产品范畴内也极具指导意义。与此相关的问题包括：“是否已经有开发人员编写、使用以及为其建立文档？这款产品是否拥有咱们想要的发展轨迹？我身边的朋友中是否有人正在使用这套系统？若是这是一套开源系统，那我是否须要独力解决本身面临的问题？”

举例来讲，咱们目前正在对Apache Storm与Apache Spark进行全面比较。这两个项目都可以做为实时计算处理系统的实用性解决手段，那么哪种更受开发人员的青睐呢？在其它因素旗鼓至关的状况下，这一点就显得很是重要了。

接下来是适应性水平。换句话来讲：这套方案可否顺畅融入个人系统？举例而言，若是咱们目前所使用的是PHP、Python或者C++，那么这款新软件可否以原生方式集成到对应语言当中？咱们又是否可以编写出切实与该组件内API相对接的工具？

除此以外，咱们还要深刻考量产品出现故障的可能性。特别是在咱们的实际案例当中，企业的多座数据中心分布在全球各个位置，最重要的就是在故障出现时及时了解实际状况。某些产品在遭遇意外时不会发出警报做为提醒，这在咱们眼中就显得很是危险。

最后一个须要考虑的问题在于平台的潜在风险——投入大量资源构建起的方案有可能在后续使用过程当中给企业带来恐怖的额外成本。举例来讲，若是一家企业并无以.Net为核心构建业务体系的经验，那么选择任何一套与.Net相关的技术平台都将毫无心义。若是这套技术方案基于Java所打造，那么咱们是否拥有对其加以妥善维护的必要资源？若是咱们采用的是Amazon Web Services或者Google Compute Engine，那么是否有信心在将来三年内继续将所有业务依赖于这些云平台的发展趋势？

一家企业所采用的技术方案在潜在客户、合做伙伴或者投资者眼中每每会被视为优点或者劣势因素。总而言之，平台的实施目标在于贴合业务的运营目标，这也应该成为指导咱们选择的根本性原则。

英文：http://www.infoworld.com/article/2868513/database/how-to-serve-billion-web-requests-per-day.html