系统架构

爱奇艺效果广告于 2016 年正式上线。起步伊始，业务逻辑简单，广告和订单数量较少，整体架构相对比较简单。为了快速完成系统的搭建和上线应用，复用了品牌广告投放平台的架构，并做了剪裁，系统架构图如下：

爱奇艺广告平台的架构设计与演进之路

接入层 包括 QLB（iQiYi Load Balance）、Nginx 前端机，主要做流量的反向代理和整体的限流与降级功能。

流量分发层：包括策略服务和流量平台服务；策略服务支持公司层面的策略控制和日常的运营需求；流量平台服务主要控制流量在各投放平台上的分配和请求逻辑，投放平台包括品牌广告投放平台，效果广告投放平台和外部 DSP。

投放服务：前文介绍的业务逻辑都包含在这里，由单一的模块来实现。

日志收集：接收曝光点击等日志，主要完成计费、频控和去重等业务逻辑，也是由单一的模块来实现。

计费系统：利用 Redis 主从同步机制把订单的实时消耗数据同步到投放服务。

频次系统：使用 Couchbase 机群来做用户数据存储。

数据同步层：这一层涉及的数据种类很多，其中相对较重要的有两种：业务数据和日志数据，业务数据主要包括广告的定向、排期和预算等内容。

我们利用业务数据做了两方面的优化工作：

通过业务数据分发一些对时效性要求不高的数据给到投放服务，避免了一些网络 IO；

在业务数据中进行空间换时间的优化，包括生成索引及一些投放服务所需要的数据的预计算，譬如提前计算计费系统中的 key 值。

随着业务增长，架构也遇到了一些挑战。

流量增长：系统上线之后很好地满足了广告主对转化效果的要求，这个正向的效果激发了广告主对流量的需求，为此产品和运营团队不断地开辟新的广告位，同时爱奇艺的用户数和流量也在持续增长，这些原因共同为效果广告平台带来了巨大的流量。

广告主数量和订单数量增长：这个增长包括两方面，一方面与流量增长相辅相成，相互促进；爱奇艺的优质流量和良好的转化效果吸引了更多的广告主；另一方面，由于商务政策上的原因，广告主和订单量在季度末会有阶段性的增长。

性能问题：流量和订单量的增长使得系统的负载快速增加，因为订单是全量召回的，当订单量增长到一定数量之后，会使得长尾请求增多，影响整体服务性能，无法通过水平扩容解决。

超投问题：由于曝光和点击的延迟，以及投放计费环路的延迟，不可避免的存在超投问题，这也是广告系统的固有问题；品牌广告是先签订合同，投放量达到即可按照合同收款，超出部分不会对广告主收费，品牌广告预定量都很大，超投比率较小；和品牌广告不同，效果广告实时扣费，如果沿用品牌思路的话，超投部分会造成多余的扣费，而中小广告主对此非常敏感，也会增加技术团队问题分析排查工作，同时因为效果广告的预算少，预算调整变化很快，使得超投比率要比品牌广告大；针对效果广告的超投问题，技术团队要做的事情分成两个层面，一是保证超投的部分不会计费，不给广告主带来损失，二是从根本上减少超投，即减少我们自己的收入损失；分别称为 超投不计费 和 减少超投；