无堆栈保护的elf构建_我们如何构建12层堆栈而又不疯狂

无堆栈保护的elf构建

自2018年6月起，Appodeal拥有约100人的团队，他们在旧金山，莫斯科，基洛夫，巴尔瑙尔，巴塞罗那以及现在的明斯克工作。 我们通过向用户展示广告来通过移动应用获利。 我们从广告中介开始，但是由于技术堆栈的不断增长，增加了新的广告技术产品。

对于那些不熟悉广告技术的人，这是技术公司从事广告的领域。 当您告诉人们您在移动广告行业中工作时，他们往往会持怀疑态度，可能会看到令人讨厌的“播放此视频”广告。 但是，这种过时的广告观与以多样性和快速增长为特征的实际广告业务无关。 我们从事的移动细分市场已经远远超出了网络广告。

为什么要整合广告？

发布者努力创建一个引人入胜的应用程序，当他们准备将其提交给应用程序商店时，他们需要考虑如何利用其获利。 为了成功获利，发布商应考虑许多因素。 他们可以利用各种模式（从应用内购买到展示广告）来确保自己的应用繁荣发展。 展示广告是让人们免费使用应用程序并确保覆盖面更广的最好方法之一。

毫无疑问，太多的广告会惹恼人们并影响用户保留率，这是每个人都希望避免的事情。 这就是为什么发布商始终寻求巧妙地集成广告，以便从他们的应用中获得最大的收益，同时又为用户减轻了不希望的费用。

这是如何运作的？

一旦您决定通过广告获利，请务必注意应用开发的这一部分，并采用可帮助您最大限度地提高收入的解决方案。

如果您注册Appodeal会怎样？ 在我们的网站上注册后，我们将一个应用程序集成到我们的服务中。 这是通过将应用程序连接到服务器并通过API与服务器交互的客户端SDK来完成的。

为了使它简短有趣，将交互作用简化为：

一个。 确定当前要显示的广告

b。 发送有关所显示广告的信息并将其记录在统计信息中

如今，Appodeal为数千个活动应用提供服务，每天显示400到4.5亿个广告，并向直接提供广告的广告网络发出多达10亿个请求。 为了确保一切正常运行，我们的服务器每秒处理约125K个请求（即每天约10.8B个请求）。

核心是什么？

我们使用各种技术来提供速度和可靠性，以及敏捷的开发和支持。 目前，我们使用以下语言进行编码：

• / Ruby / Ruby on Rails + React.JS（前端）/：我们的用户和员工可以看到的大多数API和整个Web部件
• / GoLang /：处理各种统计数据和其他数据
• / Scala /：通过RTB协议实时处理与流量交易板进行交互的请求（有关详细信息，请参见本文的最后一部分）
• / Elixir / Phoenix /：更多是实验部分。 构建多个微服务以处理一些统计信息和API。

为什么从一开始就使用Ruby和Ruby on Rails？

在移动广告领域，Appodeal与行业巨头竞争，因此我们知道我们需要时刻保持警觉并Swift适应市场变化。 通常，感觉就像在以100 km / h的速度行驶时改变车轮。 Ruby on Rails使我们能够参与竞争并在市场上稳固地确立领先地位。 我们看到Rails的以下优点：

• 大量高素质的开发商
• 伟大的社区
• 许多现成的解决方案和库
• 快速实施新功能并更改/删除旧功能

明显的缺点：

• 通常，效率尚待提高。 我还应该提到（目前）缺少JIT和并行代码的能力（除了JRuby）。 可以容忍到一定程度，因为从NewRelic屏幕截图可以看出，通常数据库和缓存会使速度变慢：

• 很难将Rail块划分为微服务，业务逻辑与数据访问逻辑（ActiveRecord）紧密相关

您存储什么数据？

我们有很多数据。 我们处理数十亿/几百亿/几千亿的记录。 但是，由于这些数据非常不同，因此我们以多种方式存储它。 架构永远不应局限于一个通用的解决方案。 首先，如实践所示，几乎没有通用的高负载解决方案。 实现通用性的代价是访问速度/读取速度/存储空间处于中级甚至更低。 其次，您始终需要尝试新事物，进行实验并为手头的任务寻找非常规的解决方案。 总结一下：

• / PostgreSQL /：我们非常喜欢Postgre，并认为它是当前存储数据的最佳OLTP解决方案。 我们在那里存储用户，应用程序，广告活动和其他数据。 我们使用主/从复制，但是仅在圣诞节期间进行备份，因为这是一个cookie-pushers游戏（游戏）。
• / VerticaDB /：我们用于存储数十亿条统计记录的面向列的数据库。 简而言之，在过去，我们认为Vertica是存储分析的最佳OLAP解决方案。 它的主要缺点-昂贵的（个人）许可价格。
• / ClickHouse /：我们正在逐步从VerticaDB迁移到的面向列的数据库。 我们认为OLAP是目前最好的解决方案。 它不花任何钱，因为它是完全免费的。 它也非常快速和可靠。 它的主要缺点是您无法擦除或更新数据（如果有兴趣的话，我们可以写一篇单独的文章）。
• / Aerospike /：它似乎是最快的NoSQL键值存储解决方案之一。 它有一些缺点，但总的来说，我们对此感到满意。 在Aerospike的网站上，您可以查看将其性能与其他解决方案的性能进行比较的表格：[何时使用Aerospike NoSQL数据库vs.Redis]（https://www.aerospike.com/when-to-use-aerospike- vs-redis /）
• / Redis /：奇怪的是，它的主要优点是易于使用和单线程体系结构，该体系结构避免了竞争情况，例如在使用标准计数器时。
• / CouchBase /：在某些时候，memcache变得与手头的任务不相等，因此我们切换到了ouchbase，仅在某些本地节点上保留了memcache。 我们将所有的全局缓存存储在couchbase中。
• / Druid /：我们将其用于与RTB板一起使用的大数据阵列。 实际上，它与ClickHouse有很多共同点，但是，到目前为止，我们还没有切换到单个工具。

您可能会认为我们使所有事情复杂化，但事实并非如此。 首先，Appodeal有多个开发团队和一个项目中的许多子项目。 其次，我们并不孤单：广告技术中的许多公司都在一家公司中使用各种技术的堆栈。

是吗 您如何监控呢？

不，那不是全部。 我们还有很多有趣的事情正在进行。 例如，由于数据流很大，因此必须将它们排队。 我们为此目的使用Kafka。 我们认为它是用Scala编写的出色的可靠解决方案，迄今为止从未令我们失望。

在这种情况下，对使用者的唯一要求是处理队列的速度快于其增长的速度。 这是一个简单明了的规则，我们主要为此目的使用GoLang。 但是，您必须记住，该服务器必须具有足够多的RAM。

为了跟踪所有这些东西，有必要对所有内容进行监视和委派。 为了帮助我们做到这一点，我们使用以下解决方案：

• / NewRelic /：这是一个经过时间检验的解决方案，与Ruby on Rails和GoLang微服务很好地集成在一起。 因为NewRelic的唯一缺点是价格，所以我们不会全盘使用它。 我们主要努力将其替换为手动收集的指标，并将其放入Grafana。
• / Zabbix /：一个很好的实时监视工具，可以处理我们服务器上发生的所有事情。
• / Statsd + Grafana /：一个收集内部指标的好工具，除了我们必须自己设置一切并“复制” NewRelic的即用型功能。
• / Fluentd + ElasticSearch + Kibana /：我们将几乎所有内容都放入了日志中，从缓慢的PostgreSQL请求到某些Rails的系统消息。 实际上，像Kibana这样的基于ElasticSearch的解决方案可以将所有日志收集到一个地方，然后在其中搜索消息。
• / Airbrake /：此过程不可或缺的一部分是收集错误以及消息的堆栈跟踪。 我们目前正在从Airbrake迁移到免费解决方案，以节省资金。

重要的是要了解完善的监控是您的眼睛和耳朵。 做猜测是浪费时间。 您需要能够随时查看服务器上发生的情况。 因此，产品的稳定性和可靠性在很大程度上取决于您构建度量标准收集和视觉显示系统的能力。

顺便说一句，说到可靠性，我们有几台登台服务器，在其中执行试验推出和测试发布，通过向它们发送实际流量的部分副本来稳定地保持负载。 每周我们都会在生产和登台之间同步数据库。 这为我们提供了一种可以测试无法在本地验证的事物的镜像，并可以在负载测试级别查明问题。

真的那么复杂吗？

是。 埃隆·马斯克（Elon Musk）在他的书《 特斯拉（Tesla），SpaceX和《追求梦幻般的未来》（Quest for a Fantastic Future）中提到，Facebook的早期工程师杰夫·汉默巴赫尔（Jeff Hammerbacher）告诉他：“我们这一代最聪明的人正在思考如何使人们点击广告……这太糟了”。

这是Appodeal的简短描述：

• 我们已与60多个广告网络和DSP集成在一起。 我们会自动在这些网络中注册应用程序并设置各种参数，以使这些网络发挥最佳性能。 并非每个网络都具有所需的API，因此这里出现了漫游器。
• 每个网络都向用户支付显示费用。 必须收取这些费用，根据各种参数进行划分并进行处理。 这是循环执行的。 再一次，这里和那里的机器人都被用于此目的。
• 为了最大化用户的收入，我们通过在广告优惠中放置所谓的“瀑布”来引起网络之间的竞争。 根据我们以各种方式预测的各种标准（例如eCPM，1000台显示器的平ASP格）构建瀑布。 瀑布上的广告报价越高，其预计价格就越高。 瀑布根据需要经常转发到设备。 您可能已经猜到了，没有人打开的烦人的广告对任何人都没有兴趣。 也许例外，来自可口可乐，百事可乐和其他公司的“品牌”横幅广告以其图像迷恋倾向而闻名。
• 这种互动的一部分是通过RTB协议完成的：实时出价。

在这里，所谓的竞标者在右边在线讨价还价，以在所选设备上展示其广告。 这是一个有趣的话题，值得在单独的文章中介绍。 许多交易所市场（例如Google AdExchange）对服务器的响应时间（例如50毫秒）设置了严格的约束，这会引发性能问题。 不遵守通常会导致数千美元的罚款。 这正是用Scala编写的核心与Druid共同完成的工作。

• 每个人都想知道绳子，因此我们的客户（以及我们）都希望了解谁看过广告，何时以及为什么看到广告。 因此，我们必须将所有数据与Kafka排队，然后逐步对其进行处理，并将其放入OLAP数据库（ClickHouse）中。 许多人认为PostgreSQL可以像处理各种“臀部”解决方案一样处理此任务，但这值得商bat。 PostgreSQL很好，但是当用于过滤和排序的字段数超过10并且存储的数据记录数接近10亿时，用于建立索引以进行快速数据访问的规范解决方案将失效。 您将只需要很短的内存来存储所有这些索引，否则会遇到更新它们的问题。 无论如何，对于分析请求，您都无法达到相同的性能水平，如面向列解决方案所证明的那样。

摘要

在本文中，我试图简要描述我们做什么以及我们如何存储和处理数据。 如果您希望在评论中说明您正在使用的堆栈，并随时提出问题，我们很乐意与您分享我们的经验。

翻译自: https://hackernoon.com/how-we-managed-to-build-a-12-story-stack-and-not-go-crazy-4fd90ed301b9

无堆栈保护的elf构建