当今互联网有几种主流的商业模式：广告、游戏、增值服务等。毫无疑问“广告推送”带给互联网公司的收入绝对是相当可观。今天为大家分享一篇来自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的性能影响会非常的大。

创作场景

如何打造高质量的 SSP 广告引擎（上）