当今互联网有几种主流的商业模式：广告、游戏、增值服务等。毫无疑问“广告推送”带给互联网公司的收入绝对是相当可观。今天为大家分享一篇来自 360 手机卫士团队分享的 SSP 广告引擎。
一、概述
当今互联网有几种主流的商业模式：广告、游戏、增值服务等。今天我想谈一谈广告系统中的 SSP 引擎。SSP（全称：Sell-Side Platform）是一个媒体服务平台，该平台通过人群定向技术，智能的管理媒体广告位库存、优化广告的投放，助网络媒体实现其广告资源优化，提高其广告资源价值，达到帮助媒体提高收益的目的（以上摘自 360 百科）。大白话就是： 各种端（app 端）找 SSP 要广告， SSP 选出一批广告， 并告诉这些端，按照某些样式展示。SSP 负责如何去选广告， 以及相应的样式是什么样子。SSP 不断优化选择广告和确定样式的策略，让各个产品能赚到更多的钱。
一个好的 SSP 系统应该具备那些能力？ 我总结了五点，列在下面：
- 灵活扩展能力
- 快速接入各种广告源
- 快速接入各个产品
- 快速验证广告的不同样式
- 快速调整广告页面布局
- 快速调整广告策略
- 高性能、高并发能力
- 高效发布和在线灰度能力
- 快速调试定位错误能力
- 强大的数据处理和分析能力
- 精准的用户画像刻画
- 准确的广告推荐
- 分钟级数据监控
- 支持海量数据细粒度的多维数据查询
二、SSP 系统架构
SSP 作为一个大型的业务系统， 系统结构还是比较复杂的，架构上可以分为以下六层：产品层、接口层、业务中间层、微服务层、数据处理层、数据存储层。分层系统架构图见图 2-1， 详细架构图见图 2-2
三、Flexible and Scaling （灵活扩展性）
在上一章 SSP 系统架构图中所展示的，系统灵活扩展能力主要体现在业务中间层，从大到小我们分了四个层次来为系统提供足够的灵活扩展性， 分别是架构层、业务层、广告控制层、广告展示层。 我们抽象出四个概念用来对应，Micro Service 对应架构层， Topology Organizer 对应的是业务层， Rule Manage System 对应的是广告控制层， Template Manage System 对应的广告展示层。
3.1 Micro Service
micro service 翻译过来是微服务， 与微服务对应的是单体式架构（传统方式），单体式架构特点是所有功能打包在一起，基本没有外部依赖，优点是开发管理简单；而微服务架构整个系统由多个子服务组成，各个服务功能独立，服务之间通过消息传递来耦合，最大优点是系统耦合性低，有非常好的扩展性，架构示意图见 图 3.1-1 和 图 3.1-2。
从第二章的 SSP 系统架构图上可以看到， SSP 是一个非常复杂的系统， 并且 SSP 有个特点就是各个子服务（各个 DSP， 用户画像，红
包等）之间几乎没有什么关系， 如果想要快速的接入一个广告源，快速的上线一个产品，具有非常灵活的 DSP 上下线规则， 那么微服务
架构是我们唯一的选择。
3.2 Topology Organizer （based DAG Algorithm）
系统架构层我们采用了微服务解决了独立子服务接入的灵活性，那么业务逻辑的多变组合如何来高效解决呢？ 在 Topoplogy Organizer 框架中我们给出了比较好的一个解决方案。该框架包含 DAG, topology, stage, context 四个概念，我们把业务拆解成一个功能单元的组合体， 每个功能单元叫做 stage， DAG 代表了 stage 的执行逻辑图，topology 用来控制 stage 的执行先后顺序，context 用来做 stage 之间的数据交换，这个结构只有数据耦合，具备并行操作的基础（这在 migo 架构中会详细说）。不同业务可以共用 stage 模块代码，大大减少了代码的重复开发量，提高了开发效率。示意图如下：
图中左右两个业务的 DAG 表示图，可见初始化规则库、请求解析、用户画像服务、过滤服务、返回广告等 stage 是可以共用的，
业务可以由这些 stage 灵活组合而成。
3.2.1 DAG
DAG（有向无环图）， 如图 3.2-1 所示， 业务可以组织成 DAG，这种图结构保证了功能模块的执行顺序， 定义好一个 DAG 也就
定义好了一个业务的流程。
3.2.2 topology
topology 算法用来实现 DAG 的功能块执行顺序，保证功能块的次序不会被颠倒，如图 3.2-1 的左图， 通过 topology 会被分解成初始化规则库 -> 请求解析 -> 用户画像 -> 点睛 DSP（或自运营 DSP、MAX DSP， 以上可以通过异步技术手段并行化处理）-＞过滤服务 -＞重排服务 -＞返回广告
3.2.3 stage
我们把每个功能模块称为 stage, 负责完成某一特定功能。stage 模块可以逐步沉淀出很多公共模块，为代码共享，加快开发提供了很好的基础。比如各类 DSP stage 可以抽象出公共 DSP stage， 公共 DSP stage 负责完成和下游 DSP 的 RPC 交互操作，派生的 DSP stage 只用改写自己的各种参数即可。
3.2.4 context
context 是一种表示上下文信息的数据结构，在 Topology Organizer 框架中起到 stage 之间传递数据的作用，正式由于这个结构的提出，才使得 stage 之间逻辑解耦，交互完全变成数据依赖，相当于贯穿一个业务的数据总线。
context 结构的定义大致类似如下的结构：
<business name=" 卫士广告 "> <stage name=" 用户画像 "> <attrlist>{年龄：20；收入：3k；爱好：旅游}</attrlist> </stage> <stage name =" 点睛 DSP"> <adlist>｛ad1:com.mobilesafe.apk ;ad2:com.zhushou.apk; ad3:com.browser.apk｝</adlist> </stage> 。。。。。。 </business>
支持 add, delete, get，set 操作。add, delete 用来添加删除 context 的任意路径的节点， get,set 操作用来对 context 某一路径节
点取值或者赋值。
3.3 Rule Manage System
我们用 micro service 和 Topology Organizer 解决了架构和业务的灵活扩展性，但光做到这两点还不足以提供足够的灵活性。不同业务在同一 stage 下的数据处理逻辑可能会有一些不同，比如频次控制服务，卫士广告可能每个广告控制 10 次， 卫士 CPM 可能是每个广告控制 100 次。如果我们把这些限制条件写入到代码中，那么随后带来的将是无休止的策略调整和代码上线。下面我们介绍一下 Rule Manage System，如何优雅的在数据项这么细的粒度提供灵活性。
3.3.1 rule engine
什么是 rule ，我们可以认为 rule 是条件到输出的一个函数映射，形式描述如下：
Output = R（condition,condition,…） ； Output 为输出， R 为 rule 映射关系，condtion_list 是条件， 为输入参数。
我们发现，上节描述的频次控制功能可以描述成一个规则 Output = R（product，ad_control,model），展开成如下两个具体
规则 ：
通过添加上面两个规则，我们不用修改代码即可实现对频次控制策略的运营，如果卫士广告频次想改成 15 次， 运营改这个规则就可以了，而不用去改引擎代码，避免了引擎测试、上线、重启后续一系列麻烦的事情。
rule table ： 许多的 rule 构成一张规则表， 如果我们想查找符合某种条件的输出是什么， 查这个规则表即可， 如果我们想灵活的控制某一数据项， 向这个规则表插入一条 rule 即可。图 3.3-1 展示了一个规则表实例。
rule engine：对 rule table 进行管理，组织成特定数据结构（可以是上图所示的表的结构， 也可以是其他更加复杂的数据结构），提供插入，删除，查找等操作。
3.3.2 quick match rule
上节我们谈到 rule engine 可以不同的组织方式，不同的数据结构带来的查询性能会有很大的区别，SSP 引擎由于请求量非常大，而且每个请求都会对 rule engine 进行规则查询，那么如何快速的进行 rule match 对 SSP 的性能影响会非常的大。
评论