前几天无意中刷到了2021 Q2互联网公司广告收入排行榜。我对广告业务的增长速度和进化能力感到惊讶，我对其背后的技术产生了兴趣。用了什么技术来支撑如此庞大的业务量和数据？如何建立稳定的广告系统架构支持？中间走过哪些坑，解决过哪些问题？带着一系列问题，我们采访了美团资深技术专家ArchSummit全球建筑师峰会讲师林乐斌，来回答这些问题。此外，他还将在ArchSummit深圳2021上分享“美团外卖广告系统平台架构”的演讲。感兴趣的同学不要错过。
美团广告系统架构探索与实践InfoQ:能简单介绍一下广告系统平台架构的设计思路和搭建流程吗？
林乐斌:架构是为业务服务的，设计思路是如何通过合理的架构设计保证业务的快速发展。也就是说，与业务相比，架构具有适度的前瞻性，但不能设计得太过短暂。因此，我们的架构建设流程将根据业务发展的阶段特征来制定。
我们的广告体系是2016年开始搭建的。在业务测试前期，我们通过MVP方案帮助业务快速获得盈利；后来随着业务量的增加，主要体现在C端流量和B端供给的大幅增加。主要工作是提高架构的可扩展性，解决可能出现的系统瓶颈。后来，随着新老业务的不断发展，对产品的需求越来越大，而R&D的人力是有限的。此时，我们已经开展了旨在提高R&D效率的平台工作。稳定、性能优化、资源利用率提升的不断构建贯穿整个过程。
InfoQ:构建如此庞大的广告架构体系，我们经历了哪些坑，解决了哪些技术痛点？
林乐斌:需要解决的技术痛点很多，主要有以下几个:
1.前期的数据同步系统比较简单。对于广告的更新数据和增量更新，B端直接向下游服务发送数据，而全量更新使用增量更新来更新数据。后来随着业务量的增加，在扩展性和稳定性方面出现了一些问题，比如更新的素材比较多，积压比较明显。另外，每次发布服务，切换过程比较繁琐，很容易出错。后来我们借鉴了ESB 的总线思想，开发了一套集流和批为一体的数据通路平台。
2.为了提高迭代效率，我们推出了一个平台项目。在实现中，我们会用DAG 的调度框架代替原程序自身的调度逻辑。新的框架带来了便利。同时，由于线程池调度的引入，性能会受到一定的损失。通过无锁调度和线程模型调优等方案，基本保证性能与原生相当。另外，对于某些业务，由于业务逻辑非常复杂，很难手动给出最佳的调度关系，因此无法达到最佳性能。基于数据驱动的思想，我们实现了逻辑调用的自动化方案，从而大大提高了业务性能。
3.在算法架构方向，算法迭代会经历“训练样本构建、模型训练、评估、特征在线、模型推送、在线推理”一系列过程。由于各个环节的碎片化，人工参与度高，中间大量重复开发，算法迭代的实验周期会很长。我们通过一站式算法平台解决了算法迭代的痛点。另外，在线推理中，随着模型复杂度和体积的增加，性能遇到很大挑战，导致无法正常迭代。通过建立工作流和异构计算的预测框架，保证算法不断迭代，提高了算法的性能。
InfoQ:目前我们的广告架构体系面临的主要挑战是什么？
林乐斌:说到目前的大挑战，首先我们支持的业务线很多，包括feed流形式的列表广告、泛ka的展示广告、游戏场景的搜索广告、创新广告等主要产品线，以及对应的20+细分业务场景，都是我们团队封闭的。
这些业务场景在逻辑上互不相同。由于发展阶段不同，业务需求也会有很大不同。如何通过技术能力帮助各自业务快速发展，如何通过技术为不同业务线相互赋能，都是很大的挑战。
其次，算法的日益复杂和产品需求的多样化导致耗时越来越多。但是，在上行超时一定的情况下，如何通过合理的架构设计和极致的性能优化，更好地服务于业务，也是重中之重。
InfoQ:在架构搭建的过程中，我们在一些技术方向上做了哪些取舍，原因是什么？能否从技术角度简单解释一下？
林乐斌:快速支撑业务的思路还是技术平台的思路。这是我们整体做的一个大的取舍。对于这个问题，我的思路是根据业务的发展阶段来决定，这也是我们架构搭建的过程。在业务初期，规模还比较小，业务希望快速获利。这个时候我们会把有限的人力投入到快速支持业务上。当业务发展到一定规模，业务条线逐渐增多的时候，就开始技术平台的思路建设。一方面可以通过技术能力的深化解决规模带来的问题，同时通过平台化的能力提高多个业务线的功能复用，从而帮助更多业务线提高迭代效率。
另外，我们在一些技术细节上做了一些取舍。这里举一个外卖特性的例子:在广告检索方面，外卖广告有典型的LBS 分发范围限制，所以对于商家的召回场景，因为数量不会特别多，所以在框架设计上，根据商家的特点，在召回阶段，我们没有采用传统的前向和后向召回模式，而是使用上游服务对商家的LBS范围进行筛选。
InfoQ:在高可靠性和可扩展性的框架下，我们如何处理系统可靠性和可扩展性的问题？
林乐斌:可靠性在以下两个层面做了一些工作。
1.在运行机制层面，我们建立了一套系统的日常、事前(事故发生前)、事中(事故发生时)、事后(事故发生后)的维稳建设方案。“日常”主要是一些基础能力的建设，包括流程规范、性能优化、日常演练等等。提前做好各种力度的监控，确保第一时间发现错误；在事件中，做好各种应急预案，比如降级、回滚等。事后做好事后总结，这样可以举一反三。
2.在具体的落地动作中，映射到架构层面也做了很多。这里我简单说一下我们接下来要做的事情，智能降级的方案。【/s2/】将我们之前在智能算力方面的能力(参考我们之前在美团微信官方账号的文章——美团外卖广告智能算力的探索与实践)运用到稳定性上，即如果出现流量突增的情况，我们可以根据流量的价值和不同的流量选择不同的降级方案，使降级过程中的收益损失最小化。
扩展性对于广告系统来说，常见的场景有两种，一种是广告请求，一种是广告更新。前者是读场景，后者是写场景。我们对广告请求场景的可扩展性设计主要在两个层面，一个是服务层面，一个是逻辑功能层面。前者主要是通过服务拆分的方式，即流量、功能、存储的拆分。后者的逻辑功能部分主要通过平台化中框架和组件的思想实现解耦，提高可扩展性。对于广告更新，我们主要通过消息总线将双方解耦，达到可扩展的效果。
不同业务场景带来的架构调整挑战InfoQ:随着业务的发展，每天对广告的需求非常大，流量分布周期不均匀，要求低延迟响应。怎么才能应对这种峰值爆炸的情况呢？林乐斌:外卖业务具有典型的潮汐效应，每天的流量高峰主要集中在下午高峰和晚高峰期间。其实上线的机器数量也是按照高峰期的峰值来估算的，正常情况下是没有问题的。但如果出现活动流量突然增加的情况，我们的处理原则是减少损失和影响范围，尽快恢复。具体来说，降损就是减少单个流量的损失。我们的主要思路是把这个流量降级，我们会从服务、功能、数据、流程多个维度降级。缩小影响范围是指减少不同流量的相互影响。主要思想是限流和隔离。对于限流，主要看公司限流元件的能力，可以实现机器、集群、自定义功能等多维限流能力。隔离主要通过业务线之间的部署隔离来解决，防止不同业务线之间的流量相互影响。此外，公司的集装箱动态扩容将用于快速扩容和恢复。
InfoQ:如何在尽可能不影响用户体验的情况下，提高广告的点击率和营收，减少用户流失？我们用什么样的技术来平衡商家、用户、平台之间的利益，来维持广告业务的健康持续发展？
InfoQ:说到深度学习，深度学习技术在美团外卖广告系统架构中有哪些应用场景，具体做法是怎样的？
林乐斌:深度学习在美团外卖广告中的应用可以分为两个方面。一个是偏推荐部分，从召回、粗排名、搜索广告中的相关性优化，到精细排名中CTR、CVR、客单价估算模型的迭代；第二部分是偏广告机制，比如智能竞价、智能创意、深度拍卖模型等等。
国内外广告系统架构的发展InfoQ:几年前DSP在国内非常流行，很多人对DSP的期望很高。现在还没有达到人们的预期。你认为主要问题是什么？
林乐斌:我觉得主要有以下几个原因:
1.由于隐私、利益等原因，数据不够开放，导致媒体、客户、平台之间的数据碎片化，限制了各方的策略优化空；
2.媒体更倾向于优先考虑自己的优质流量客户，所以DSP和自己的广告主竞争并不是绝对公平的；
3.DSP的出现降低了商家投放的门槛。因为App的应用是集中的，流量主要集中在头部的一些媒体，会导致优质流量的激烈争夺，从而抬高流量成本。
InfoQ:最后说点别的。我们知道，微软、谷歌等外国公司在广告领域进行了大量创新。我们国内的厂商有没有可以借鉴的地方，我们现在的优势或者劣势是什么？
林乐斌:在广告领域，国外几家头部公司做了很多有影响力的工作。比如 DSSM (深度结构化语义模型)和YouTubeDNN经典双塔+谷歌的精细化排名Wide & Deep模型推动了深度学习在推荐广告中的大规模落地，GSP 和VCG 也成为标配抛开具体的技术细节，最值得我们关注的是，有几家国外公司敢于从商业实践出发，将先进的技术与0到1的开拓精神结合起来。
相比较而言，国内互联网起步较晚，长期以来都是跟随者。但近年来，随着国内互联网业务的快速发展和产品技术的不断创新，在很多技术上出现了很大的赶超趋势。综上所述，国内产品模式的创新，大量的互联网用户，科技人才的涌现，成为国内互联网产品技术进一步发展的最大优势。
采访嘉宾介绍林乐斌[/s2/]，美团高级技术专家，2016年加入美团。目前是美团外卖广告引擎架构负责人。前后在腾讯和百度工作，有10多年互联网广告经验。
