互联网广告是流量变现的主要手段之一， Google、 Facebook 等公司都以广告收入作为其主要的营收来源。随着移动互联网时代的兴起，信息流广告得到长足发展。信息流广告对比传统的展示广告或者搜索广告有如下特点：

• 库存的可增长性强，信息流广告的库存与用户刷新信息流的次数和时长正相关，用户粘度越高，带来的广告库存就越多；
• 原生性，系统可以从用户信息流的内容和关系维度出发，匹配相关性一致的广告，这样既提高了广告效果也降低了对用户体验的伤害。

广告系统以收入增长为目标，需要不断的提升流量变现效率。可以从三个方面来衡量流量变现效率：流量接入量，广告召回率，广告 eCPM 值，也就是接入更多的流量来商业化，同时提高已商业化流量的广告召回率和 eCPM 值。对于广告系统来讲就是请求量、曝光量、曝光效率的持续增长，这就需要系统架构保持良好的稳定性和可靠性。

比如对于一个日请求 10 亿，召回率 60%， eCPM 值 20 元的广告系统来说，系统的超时率做到 99% 和 99.9% 时对收入的影响会达到：

10 亿 * 0.9% * 60% * 20 / 1000 = 108,000 元


下面以微博广告系统架构演进过程中遇到的一些问题及解决方案为例，说明如何构建稳定可靠的广告系统。涉及到系统性能提升、稳定性保障、流量高峰应对措施、业务优化、实时监控等几个方面。

1、匹配服务架构选型

匹配服务是是广告系统架构的控制中心，需要从 DMP 获取用户画像、从索引获取广告候选集、调用竞价服务完成竞价排序等功能。同时是整个系统的流量入口，保持稳定性显的尤为重要。匹配服务在系统中的位置如下图所示 :




图 1：系统服务结构

从匹配服务在系统中的位置和功能描述可以看出如下特点：

• 属于整个系统的流量接入层，需要高并发的处理能力；
• 依赖的外部服务多，必须要进行并行化处理；
• 业务变动会比较频繁。

根据以上特点，匹配服务选用基于 Nginx 和 Lua 的高性能 Web 平台 OpenResty，有如下好处： 

• Nginx 框架轻量高效稳定，适合应对高并发问题；
• 使用 Lua 协程和 Nginx 的 epoll 事件处理机制实现并行化处理，能够降低并行获取数据的开发成本；
• 脚本语言 Lua 开发能够保持对业务迭代的高效支持。

微博广告系统的匹配服务日承接请求数十亿次，实现了广告的定向、匹配、初选等业务功能，上游服务对匹配服务的系统耗时也有着严格的要求，基于 OpenResty 的系统架构对这些约束进行了完美的支持同时保持了高效的业务迭代速度。

2、索引服务分片

索引服务存储在投的广告计划，并根据流量属性匹配上相应的计划。针对不同的定向要求，索引服务一般采用位图索引、倒排索引、关系索引等方案。如果索引匹配的计划达到一定的数量级，把这些计划都返回给上层服务进行竞价和排序。

由于特征获取、排序运算等带来的系统开销会比较大，索引服务会进行广告计划的初选，根据广告出价、创意、用户属性等维度筛选出进入到匹配服务的计划，筛选过程如下图所示：



图 2：索引筛选漏斗

因为索引服务的耗时会随着计划数量的增加而线性增长，为了提高性能，给优化策略留出充足的性能空间。我们对索引进行分片处理，按照一定的规则把计划存储在不同的索引节点，上层服务并行化调用索引节点然后对结果进行 merge。这种分片方法能够有效降低单个索引节点处理计划的规模，提升整体效率。

分片部署情况如下图所示：



图 3：索引分片

3、业务逻辑优化

广告系统与业务需求结合紧密，策略优化等工作需要大量的数据支持。如果能够对系统的服务依赖关系、存储类型、数据传输进行全局的设计和优化，带来的性能提升往往会事半功倍。下面通过资源的统一管理和下发来说明下这个问题。这里的资源是指业务策略需要的用户画像、社交关系、点击行为等数据。

我们使用 DMP（数据管理平台）来统一的进行资源的存储和更新，集中化管理资源。由于匹配服务是广告系统的控制中心，会和各个子系统进行交互，因此适合在匹配服务进行资源的获取和下发。

对于系统内部各个模块共同用到的数据，比如用户关注关系，索引服务在检索广告时要使用，同时关系服务在生成推荐理由时也要使用，就可以由匹配服务预先从 DMP 获取，然后再下发到各个子系统，从而降低了系统的整体开销。



图 4：数据统一下发

4、动态扩容

在微博这类社交网站上，由于热点新闻事件的影响，广告系统经常会遇到突发的流量高峰。为了最大化流量利用效率，系统需要能够承载这些流量并转化为收入，因此不能够进行流控或者降级。



图 5：世预赛中韩大战流量高峰

上图是世预赛中韩大战当晚广告系统的流量请求监控图，我们可以看到系统 TPS 在某一时刻有一个突然上涨，对于这种流量特点如果直接进行服务器扩容来承载流量高峰，那么在热点事情的影响消除之后服务器的使用率又会下降。因此我们采用云主机动态扩容的方案，具体操作流程如下：

广告系统的匹配服务、索引服务、竞价服务都是无状态的服务，可以把这些服务封装成一个 Docker 镜像，根据请求量和系统承载能力之间的变化情况，利用云主机进行动态扩容缩容，能够有序地平衡系统承载能力的增长和硬件资源的使用效率之间的关系。动态扩容系统拓扑如下图所示：



图 6：动态扩容拓扑

5、实时监控平台

广告系统的稳定运行离不开实时监控系统，监控系统的挑战在于要对大数据量的日志进行实时传输和分析处理。我们使用 flume 来收集日志到 Kafka 上，采用 ELK 方案搭建实时日志分析平台，因为业务日志格式的异构性，监控系统日志解析工具要求具有通用性，否则无法适应业务日志种类的增加，使用 Logstash 可以通过配置项适配不同的日志格式，解析出元数据入到 ES 中存储和索引。另外 Kibana 被换成了界面更友好的 Grafana。
下图为实时监控平台搭建流程：



图 7：实时监控平台

实时监控平台实时分析广告系统各个服务产生的业务日志，生成请求量、曝光量、超时率、召回率等业务指标监控曲线。通过与报警系统的结合，可以对流量高峰、系统故障等进行预判和响应。

上面分别从系统性能提升、业务逻辑优化、基础设施建设等方面阐述了如何构建稳定可靠的广告系统。系统架构的优劣评判一方面是性能、并发量等技术指标，同时能否保持对业务迭代的快速支持也尤为重要，架构设计要求对业务发展保持前瞻性，才能做到有的放矢。随着这几年微博商业化进程的顺利开展，挑战与机遇并存，广告系统架构也随着业务发展不断地进行迭代和升级，有效支撑着业务快速发展。

崔建兴，微博商业产品部广告技术专家。2013 加入微博后先后负责内容相关推荐、社交关系推荐、粉丝头条广告、微博广告交易平台（WAX）等项目。对于推荐系统、在线广告投放系统有着一定的架构设计经验。对如何构建高性能 Web 服务、离线数据挖掘、策略算法工程化等领域感兴趣。目前致力于高可用高性能的微博广告平台的建设。

本文来源：高可用架构公众号

长按二维码 关注「高可用架构」公众号