如何在一天内处理10亿次Web请求而不弄乱发型一项业务——其发展势头帮助品牌从市场上吸引新买家，同时激励现有客户。那么AppLovin是如何在不大幅增加硬件和运维人员的情况下打造出这样一个能够处理百亿级请求的基础设施的呢？在今天的文章中，我们将共同了解公司如何发现并选择采用各种最佳实践，通过技术栈演进实现业务规模化。***具有成本效益的扩展想法让我们从规模开始。对于AppLovin的我们这些人来说，最具成本效益的扩展方式意味着能够大幅增加负载处理能力，同时避免硬件或人员的线性增长。如果我们只能通过购买两倍的服务器设备或者增加一倍的人数来实现请求处理能力的提升，那么这样的方案是完全没有实际意义的。因为我们在构建基础设施时充分考虑了效率扩展的需要，所以我们能够在过去的一年里将服务器处理的请求数量提高到二十倍。还有一点值得注意的是，对于大规模的分布式系统，目前市场上还没有现成的方案可供参考。此类系统必须使用自定义组件构建。无论行业从属关系如何，技术团队在构建分布式系统时都需要仔细评估所选组件。此外，每次工作量爆发式增长时，这些组件也需要及时调整。规划这些调整意味着基础设施本身必须是灵活的。我们从创业之初就充分意识到，移动广告的格局可以说是日新月异，我们需要打造一个灵活的基础设施来匹配和适应。我们希望我们自己的基础设施可以让员工针对各种市场需求进行相应的创新活动。例如，如果我们需要做一些细节上的调整，我们可以直接在现有的基础设施之上简单地实施，而不需要重新设计整个设施。这是我们工作的核心指导思想。该计划实际上得到了回报。最近，我们的月流量翻了一番，这得益于我们极其灵活的基础架构。适应性强、可扩展的实时基础设施考虑到上述建设需求，我们构建了一个基础设施栈，包括Web服务器、实时缓存层、数据库、分布式消息服务和大规模并行计算系统。前端是成百上千个Web服务器。这些服务器设备每天用于响应来自大量用户的数十亿个请求。当每一个请求进来的时候，我们都需要立即做出一系列的决定，包括是否响应、支付多少、用哪个广告作为推广内容——整个决策过程大约需要50毫秒。接下来我们需要做的是缓存用户个人资料信息，整个数据库包含数十亿拥有移动设备的用户。此信息需要在相当长的一段时间内可用，以使网络服务器能够响应并决定是否接受特定的广告请求。简而言之，我们需要的是一个分布式缓存层，旨在实时为所有传入请求提供所需数据。该缓存层使用了Aerospike、Redis和Memchached等多个系统。除此之外，还有大量的分析、报告、数据仓库和数据科学功能集需要与不同类型的数据库进行交互。从宏观上看，这些功能必须具备分布式能力。为了实现这种分布式机制，我们采用分布式消息或者发布/订阅消息服务。分布式消息发送机制给我们带来了以下关键优势：我们可以从任何位置获取我们需要的信息。·我们可以使用日志文件作为事务单元，在一秒钟内处理数十万个请求。·我们可以提供任何服务订阅计划所需的信息。上述消息必须张贴在全球任何地方。目标位置可能是HPVertica数据仓库、MySQL数据库、ApacheHadoop系统或ApacheStorm实时处理系统。分布式消息发送机制可以说是所有实时架构的核心组成部分。最后，我们需要使用分布式计算系统来实现数据处理。拥有分布式计算系统意味着使用Hadoop或ApacheSpark等技术-并行处理系统可以查看所有数据并扩展以处理巨大的数据负载。上面列出的所有组件都是通过分布式日志架构连接起来的。这种基于日志的架构的基本设计思想是可以接受多个数据源，以日志文件为事务单位，从所有数据源获取信息。例如，广告服务器可能会记录“我是否提供了广告？用户是否点击了广告？我是否察觉到了交易？”都会被记录下来，大量的日志信息会汇聚成一个消息系统。这些日志不断地传输、处理，并将最新的聚合数据写入数据库。所有这些数据都可以由日志系统调用，并在订阅的基础上交付给任何需要它的服务。这种类型的架构支持创新，因为我们可以将任何组件插入系统。您可能需要在特定位置插入Aerospike实时数据库，或者您可能想在其他位置使用Vertica。我们必须能够将所有输入信息传递给所有不同类型的处理工具。有了这样一个基于日志的架构，可以帮助我们通过日志把所有的数据源和一个集中的日志系统连接起来，最终成为实现实时订阅系统的基础。评估技术选项我们对这组平台的评估说明了为什么拥有高度灵活的基础架构很重要。其实一开始我们选择使用PHP语言来进行平台搭建。这是一种非常高效的开发方式，很容易找到大量熟悉此类开发任务的程序员。同样的道理也适用于MySQL，考虑到MongoDB在NoSQL数据库领域举足轻重的地位，我们决定将两者并行使用。当然，作为一家初创公司，我们早期将平台的核心主体搭建在AmazonWebServices上。但是***，我们使用RabbitMQ来实现自己的发布/订阅消息机制。随着时间的推移，我们已经开始将数据迁移到Aerospike、Redis、ApacheCassandra、Vertica和Hadoop系统的综合堆栈。我们完成了从PHP到C++的转换，将消息发布任务从RabbiMQ转换为定制的Java系统。与此同时，我们设法减少了我们使用的其他系统的数量，将它们的大小保持在我们相对容易理解并且工程团队知道如何处理的程度。引入新软件无疑是一项昂贵的提议。无论是开源软件还是专有许可软件，如果人们尝试了一些东西但没有按预期工作，那么整个工作就得倒退几个月。这就是为什么我们仔细评估每个产品，希望提前了解它是否物有所值。我们采取的第一步是查看业内其他供应商正在使用的产品，以及这些产品如何改进我们现有的用例。例如，另一家广告技术公司的工作人员向我们讲述了他在评估Aerospike时的经历。然后，我们与四五个其他Aerospike客户进行了交谈，并提出了诸如“您的用例与我们的用例之间有任何相似之处吗？您喜欢Aerospike的实际性能吗？您不喜欢Aerospike的哪些方面？”之类的问题。之后我们也很关心“如果我把这个引入到我的业务系统中，会不会出现什么意想不到的意外情况？”另一个评价要素来自开发者的喜好。这一点在开源项目中尤为突出，但在商业产品的范畴中也具有重要的指导意义。与此相关的问题包括：“开发人员是否已经在编写、使用和记录这个？这个产品是否有我们想要的轨迹？我的朋友中有没有使用这个系统的？如果是开源系统，我是否需要解决自己的问题我自己的问题？”举个例子，我们目前正在对Apa??cheStorm和ApacheSpark做一个全面的对比，这两个项目都可以作为实时计算处理系统的实用解决方案，那么到底哪个更受开发者的青睐呢？这个很重要其他因素势均力敌。接下来是适应度。换句话说：这个解决方案是否能顺利地适应我的系统？例如，如果我们目前使用的是PHP、Python或C++，那么这个新软件是否可以原生集成到相应的系统中？语言？我们能不能在这个组件里面写一个真正和API接口的工具？另外，我们还要深入考虑产品失败的可能性。尤其是在我们的实际案例中，企业的多个数据中心分布在全球各个地方最重要的是在出现故障的时候要及时了解实际情况，有的产品在发生事故的时候并没有发出警报作为提醒，这就很dan了在我们眼中是慷慨的。最后一个需要考虑的问题就是平台的潜在风险——投入大量资源构建的解决方案，可能在后续的使用过程中给企业带来可怕的额外成本。例如，如果一个企业没有构建以.Net为核心的业务系统的经验，选择任何一套与.Net相关的技术平台都是没有意义的。如果这个技术方案是基于Java的，我们是否有必要的资源来妥善维护它？如果我们使用AmazonWebServices或GoogleComputeEngine，我们是否有信心在未来三年内所有业务继续依赖这些云平台的发展趋势？在潜在客户、合作伙伴或投资者眼中，一家公司的技术解决方案通常被视为优势或劣势。总而言之，平台的实施目标是契合业务的运营目标，这也应该成为指导我们选择的根本原则。英文：http://www.infoworld.com/article/2868513/database/how-to-serve-billion-web-requests-per-day.html
