【广告架构day2】新浪广告系统架构的演进之路：服务化改造

按：广告系统是互联网商业化过程中核心系统之一，像今日头条、百度等，大头利润都靠卖广告。广告系统有何独特的特性？可从中多学习。本文来自新浪徐挺的分享。

 

摘要

其实新浪很早就开始研究广告系统了，根据UserID + CookieID + 用户行为日志等多重要素进行用户区分，进而针对个体用户做控频投放。同时为了更好的监控广告服务平台的性能和准确性，新浪广告技术团队在此基础上进行了众多改善措施。 

 

技术架构和痛点

sinaX 服务化之前的架构

可能有些朋友对互联网广告的技术架构不太了解，这里先介绍下大概的构造。基本上所有的公司的技术方案中都有一个adexchange——负责广告流量接入以及流量优化的模块（图中的中间模块）。

从上端过来的广告流量都会进行流量优化，优化完成后将向下方的各个投放DSP询价。

整个过程类似拍卖，一个流量进来后，如果被判断为优质流量，就会向一些DSP发起竞价请求，DSP根据内部的算法优化以及用户行为优化给出价格，adexchange接收到这些报价后会决策出胜出者，最后广告请求被给到胜出者。这里面adexchange主要在做两件事，一是决策出竞价胜出者，二是生态层面的调整，adexchange对下方所有投放引擎并不是一致均等对待的，而是根据阶段性广告生态的要求做出调整。

早期我们的adexchange是基于Nginx服务器，在服务器内部有Lua写的业务逻辑，也就是前面提到的竞价规则和流量最优化调度。

 

SinaX 旧架构的痛点

由于adexchange对投放引擎并非是一视同仁，所以整个流量呈现的是一个漏斗模型。

 

在adexchange的开发过程中，为了能够更好的实现漏斗模型以及业务提升，我们在内部进行了二次开发，开发过程中发现了很多问题。

用Lua做功能开发并不方便，因为需求的频繁变化导致需要即时响应，而即时响应的过程中有些功能使用Lua嵌入非常麻烦。Lua代码可维护性差，一旦出现人员变动，新人阅读之前代码的成本很高。

第三是业务内的监控很难做，如果采用Nginx加Lua的方式，严格来说唯一的解决方案就是使用某种方式将日志输出，很难在Nginx内部提取状态量发送到关键业务检测点上。最后是测试问题，基于Nginx加Lua的环境做完全量测试或者全量灰度测试很麻烦，一般只能通过直接嵌代码的方式解决，无法采用一些传输的技术方案。

<