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

本文链接：https://blog.csdn.net/Ture010Love/article/details/104356076

本文介绍了新浪广告系统从早期基于Nginx+Lua的架构到服务化改造的过程，分析了服务化改造的原因，如Lua开发不便、监控困难等问题，并详细阐述了服务化改造的技术选型、监控方案以及广告检索、高可靠性和可扩展性的实现策略。通过对业务痛点的解决，实现了广告系统的优化和升级。

摘要由CSDN通过智能技术生成

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

摘要

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

技术架构和痛点

sinaX 服务化之前的架构

史上最详细的新浪广告系统技术架构优化历程

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

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

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

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

SinaX 旧架构的痛点

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

史上最详细的新浪广告系统技术架构优化历程

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

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

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