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

当今互联网有几种主流的商业模式：广告、游戏、增值服务等。毫无疑问“广告推送”带给互联网公司的收入绝对是相当可观。今天为大家分享一篇来自 360 手机卫士团队分享的 SSP 广告引擎。

3.4 Template Manage System

SSP 系统有一项很重要的功能就是管理广告样式以及管理广告展示布局，例子（见图 3.4-1 和 图 3.4-2）可以形象的展示不同的广告样式和广告布局。 我们的产品往往不断调整广告的样式，如三图变长图；或者增加新的广告样式如视频广告，轮播广告；又或者针对不同产品的不同功能页面会尝试不同的广告组合来布局。 如何支持广告的灵活性运营， 对 SSP 系统提出非常高的要求。我们使用两个机制来很好的解决了这个问题，base template 机制，polymorphism and combination 机制 。下面我们来具体的介绍这两个机制，以及这两种机制如何结合起来支持广告运营的灵活性。

3.4.1 base template

base template 我们叫做基础模版，用来解决广告样式的多样性。在处理广告展示的过程中，如果每一个广告都写代码去针对性处理，广告千变万化，这个工作量将是非常复杂的。如果仔细的研究一下，会发现虽然广告千变万化（广告素材、广告标题等）但是广告的样式种类确可以归成很少的几十类，最多几百类。 我们把广告剥离成静态和动态两部分， 静态的是广告样式， 种类只有数十种，这样管理起来就非常的简单， 只需要运营这几十个静态模版类即可；动态的是广告的素材啊，标题啊，跳转连接啊，点击动作啊， 这些可以通过下一节的 polymorphism 机制进行实例化， 从而实现动态部分的灵活运营化。

3.4.2 polymorphism and combination

polymorphism 叫做多态实例化机制， combination 叫做组合机制， 这两个机制结合起来用来解决页面广告布局的灵活性。

base template 可以决定广告的样式，从基本模版库中选中样式模版后，通过 polymorphism 可以对该模版进行实例化，比如两个同样的长图模版，填入不同的素材链接地址，标题，点击动作可以形成两个广告实例。polymorphism 的灵活性如何实现？通过 3.3 节的规则管理系统可以动态的配置基础样式模版所需要的属性信息， 这样就可以完成 polymorphism 的实例化，并且可以交付运营来配置管理（实例化形象例子可以参考图 3.4-2）。

有了实例化的模版，我们的工作完成了一半， 产品所需要的不是单一的一个广告，产品端的页面是一系列广告的展示， 但是产品的广告页面布局会不断调整的，不能每个页面写死由那些固定模版组成。 我们通过 combination 机制（组合机制）很好的解决页面布局的灵活性， 也就是通过 3.3 节的规则管理系统由运营来动态组合样式实例来形成页面布局（布局形象化例子可以参考图 3.4-2）。base template，polymorphism, combination 机制结合起来形成页面布局见图 3.4-3。

四、高性能、高并发引擎架构

SSP 每天请求量超过 30 亿，支持这么大的流量需要一个非常出色的高性能 http 引擎。http 引擎框架大多归为两类，一类是多进程框架，一类是多线程框架， SSP 的演进过程中也分别使用过这两类框架，一个是 360 大流程云引擎部门开发的 cloudUcs， 一个是核心安全部门开发的 trident，下面我们来详细介绍一下，最后我们来谈谈基于 go 协程机制的新的 http 引擎框架。

4.1 多进程框架（cloudUcs）

cloudUcs 是大流程云引擎部门开发的， 是一个比较优秀的高性能 http 引擎，目前搜索一级引擎还是采用这个框架，框架图见图 4.1-1。

Ucs 的优点有如下几点：

1.master-slave 多进程模型，可以保障引擎的可靠性

2.worker 进程支持多线程异步化处理各种 IO 事件

3.网络通讯细节封装良好，业务逻辑不需要关心网络底层细节

4.进程间请求流量均衡

Ucs 当时存在如下一些缺点，我们后来改用了 trident 框架，列一下当时遇到的问题：

1.ucs 的多进程模型在加载了短信的预测模型后，导致内存占用特别大，系统负载高；

2.在当时 ucs 的情况下，配置加载必须要进行进程 reload，会有丢包现象，不适合 ssp 这种强运营性的系统；

3.ucs 的进程模型相比于 trident，事件分发速度慢，而且多进程间负载均衡做的不好，work 进程负载不均匀；

4.ucs 编程模型不够友好和搜索业务绑定的比较严重，新人上手门槛高；

4.2 多线程框架（trident）

trident 是大流程云查杀组开发的，现属于核心安全部门， 也是一个比较优秀的高性能 http 引擎，目前云查杀引擎是采用这个框架，SSP 也是采用这个框架，框架图见 4.2-1。

trident 优点：

1.单进程加载资源，占用系统内存少；

2.支持配置的热加载，尽管存在互斥锁的问题；

3.trient，顾名思义，单一进程内可以支持 tcp、udp、http 三种服务；

4.worker 线程之间的负载，相对于 ucs 来说，负载更均衡，之前 ucs 因为 worker 负载不均衡问题，我们只能把每个 worker 的队列长度都设置为 1 以便强制所有 worker 参与调度，但这也限制了 ucs 的 qps，而 trident 因为负载叫均衡相对较好，qps 要比 ucs 好些，但是

这个是理论上，没有做过极限压力测试；

trident 缺点：

1.配置热加载过程采用互斥锁，影响性能，ssp 已经规避了该问题；

2.当前 trident 采用的单进程多线程方式，已经整个 ssp 系统采用的异步 stored、异步 redis 等，造成单进程内线程数量太多，线

程间同步和竞争关系复杂；

3.trident 的对外 IO 事件和分发事件只有一个线程在处理，业务量大时该线程时瓶颈；

4.大量的异步应用，多线程模型，导致开发的 debug 成本较高，新人入手困难。

5.还存在一个极端状况下会出现的 bug，请求量极速上升，内存占用会急剧上升（接收和处理线程之间的队列无队列长度上

限）。

4.3 go 微服务框架（migo）

4.3.1 migo 简介

migo 是我们团队用 go 语言重新开发的 http 引擎框架， 充分挖掘利用了 go 的协程机制，拥有非常强大的性能。由于多线程模型在发生线程调度的时候代价很高，不能充分利用 cpu 的时间片，所以人们又提出协程概念，相当于在线程的工作时间片上又切成很多小段，分给协程来工作，有统一协程调度器来调度协程，而不会触发线程的调度，得以充分的利用线程的工作时间片。go 语言在语言层面对协程进行了支持，所以简单易上手，目前在高性能、高并发领域是非常火热的编程语言。所以我们采用 go 语言重新打造了一个新的微服务引擎框架 migo。migo 本身我们设计成一个通用的微服务框架，也具备 SSP 的很多特点，也具有 DAG，topology, stage, context，micro service 这些组件（组件介绍见第三章）。与 C++或者 php 语言相比，DAG，topology, stage 反而更好的把 go 的协程机制发挥出来，提供充分的并行性。 migo 的系统框架图见图 4.3-1 和图 4.3-2。

4.3.2 migo 性能评测

我们分别对 migo， php-fpm，trident 进行性能测试，用来对比分析这几个框架的性能差异，migo 和 php -fpm 框架性能对比见图 4.3-3 和图 4.3-4：

简单业务 migo 性能是 php-fpm 的 3-5 倍；

复杂业务 migo 性能可以达到 php-fpm 的 20 倍；

4.3.3 总结以及 migo 未来规划

综上我们总结一下 migo 的特点：

1.性能优越，充分利用 goroutine 机制，最大化的利用 cpu 的分片时间，不但一个请求可以用 goroutine 来实现，请求里面还可以分成小段 stage，这些小段 stage 也可以启用 goroutine 来实现，并行化的粒度变成了一次请求中的小单元而不是线程框架下的一次请

求；

2.新人上手简单，易学易用；

3.有很好的灵活扩展性，模块很好重用，极大提高业务编写效率；

migo 未来的规划：

1.进一步探索框架性能的提升，提出类似 spark RDD 概念的的 gRdd，研究 stage 之间数据共享的可行性；

2.研究 migo 和 docker 部署的结合；

3.研究 migo 如何对不同业务（topology）进行调度，提供更高层次的灵活扩展性；

4.更多公共 stage 模块的开发，提供更强大的能力；

本文转载自公众号 360 云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/q3-cvys7AmQTDaDlR3kQWQ