译者的话

我是酥酥，目前在Tubi用Akka和Scala搭建AdServer，此前在Twitter做API的开发。我在从经济系毕业生到硅谷程序员一文中提到，在我离开Twitter前，Twitter的平台组刚开始风风火火地对AdServer进行微服务化重构，项目名称Project Tao（道）。如今一年多过去，Twitter完成了平台的重构，并用博文Accelerating ad product development at Twitter记录了这一过程，对从事AdServer工作的我很有启发。我根据自己有限的知识，对全文进行了翻译，并在局部进行了重写。

本文同步在个人博客yiksanchan.com，欢迎订阅。

康威定律指出，”组织的架构决定系统的架构”。Twitter团队也不例外。2010年，团队有约15名工程师和2800万美元的收入，到了2019年，团队增长至数百名工程师，有约34亿美元的收入。期间，Twitter系统的功能和复杂性一直在增加，而团队或服务的运营模式并没有大幅改变。

团队早期的系统架构很适合初创公司，有利于抛下之前的决策包袱，快速迭代。后端大致分为三个团队。平台（Platform）、科学（Science）和产品（Product）。团队的最终目标是：快速构建和迭代产品，帮助Twitter实现盈利。

Twitter的平台由基础设施和核心组件构成，其中核心组件又包括AdServer、计费（billing）、数据基础设施、分析（analytics）等系统。其中，单体AdServer（Monolithic AdServer）是平台的核心服务。它从Twitter客户端获取请求，根据用户信息和主的定向（targeting）条件，对池里的候选进行排名，筛选出最符合条件的，然后进行次价拍卖（second price auction），最后为用户发送最相关的作为响应。

团队分工方面，平台团队负责搭建可靠、高性能的单体AdServer，并承担部署和oncall的责任。产品团队的重点则是根据Twitter前端产品团队提的需求，在AdServer上做改动。本质上，平台团队扮演一个把关的角色，对改动和服务进行全面的控制。产品团队则在平台团队的把关下，在代码库的各处做改动。

基于这种模式，Twitter打造了多款成功的产品，它们的目标各不相同，复杂度越来越高。Promoted Tweets（推广推文）首先推出，它帮助品牌覆盖广大的受众，以提高品牌产品的知名度。Promoted Trend（推广趋势，类似于微博热搜）使得品牌能够占用全部Twitter用户的探索栏全天的时间。Mobile App Promotion（移动app推广）鼓励用户下载主所要推广的手机app。Web Clicks（网页点击）鼓励用户访问品牌网站。Promoted Video（推广视频）让品牌通过视频这种更容易讲故事的媒介来做推广，还支持对覆盖面和效果的衡量。

这种模式在小规模的工程师团队中效果非常好，迭代速度很快。但随着业务和团队的增长，平台团队开始成为功能迭代的瓶颈。为了更好地说明这一点，下面首先概述一个请求的流程。

请求的工作流

为了提供最相关的，我们在请求路径中使用以下两个组件：Ad Mixer和单体AdServer。

Ad Mixer是ad serving管道的网关（gateway）服务。每当收到一个来自客户端的请求，它都会：

单体AdServer负责对于每一个请求，考虑每一个符合条件的，并将最佳的候选返回给AdMixer。考虑到Twitter产品的规模，该服务是分片（sharded）的，这样每个分片只考虑全部候选的一个子集。这种分片方案还使并行计算成为可能，满足对请求延迟的严格要求（要求在200-500毫秒不等）。

译者注：在此需要简单了解的三级结构：组/campaign – 计划/line item – 创意/creative。一个组对应一到多个计划，一个计划对应一到多个创意。组描述一次推广，例如“Nike瑜伽装备2020秋季推广”。计划通常包含对目标群体的描述，如“男性推广”、“女性推广”和“儿童推广”，分别对应于三个目标群体。创意描述具体要展示的内容，可能是一段视频、一张海报、或一段文字。

每个AdServer分片，都根据它的候选子集，执行以下步骤。

从2010年到2018年，AdServer的逻辑日渐复杂。结果是：

此外，AdServer的几个步骤之间没有划定明确的边界，缺乏有效的机制来确保属于”创意的扩展和产品逻辑”的代码不被加入到”候选选择”或”候选排名”中。不清晰的边界还给产品团队的工程师（译者注：以下简称产品工程师）带来了额外的复杂性：单体AdServer本就是一个黑盒子，组件间强耦合，缺了哪一块，AdServer都无法正常工作。产品工程师只了解AdServer的局部，很难测试。有时，一个很简单的改动从开始开发到部署至生产中需要一个月的时间。

产品功能的生命周期

在2018年，基于上述平台团队和产品团队的结构，一个视频产品功能的生命周期如下：

代码考古

由于产品和平台的耦合，业务逻辑和基础架构组件之间缺乏清晰的API边界，AdServer代码的复杂度指数爆炸。产品工程师首先需要理解错综复杂的平台组件和产品组件，并试图弄清楚当前AdServer是怎样工作的。

设计

随后，产品工程师将明确：需要对系统进行哪些改动？这里的挑战包括：产品工程师难以完全理解视频产品的改动对运行在同一单片AdServer中的其他产品的影响。此外，他们也很难估计改动对性能的影响。

咨询平台团队

一旦设计准备就绪，产品团队的下一步将是与平台团队对接，由平台团队负责提供指导和代码审查。然而现实中，由于平台团队负责平台，而产品团队负责产品，两个团队的激励并不总是一致的，这导致产品的很多请求被平台争论甚至驳回，两个团队都感到失望和沮丧。

发布

一旦代码通过审查，被合并，产品团队需要再次依靠平台团队进行部署。新功能的测试往往十分困难，有时一个部署要包括多达200个改动。此外，由于多个产品的逻辑运行在同一个强耦合的单体AdServer中，一个错误的改动可能阻塞整个部署，从而影响到其它产品团队。 最终的测试要到发布后才能完成，且需要不同团队的参与，因此修复突发bug的时间难以预测。

解决方案

引入产品竞价器，加速产品迭代

我们从多个方面解决这些问题。我们首先将服务于不同产品的基础设施组件分离出来（例如选择服务Selection Service，排名服务Ranking Service等，更多信息见我们之前的博文）。此外，提高产品团队迭代速度的关键在于引入产品竞价器（Product Bidder），并确保不同产品的竞价器共用一个框架，以保持乘法效应。（译者注：将拆分后的AdServer命名为bidder，可能因为竞价是AdServer的一个重要环节，不同产品之间的竞价逻辑可能差异较大。）

将单体服务的每个模块都拆分为一个微服务看似会大大提高产品迭代效率，但这也使得跨服务改动经常发生，降低开发效率。因此，在拆分过程中，我们做了适当的取舍：

竞价器框架

如上图所示，每个管道（pipeline）都包含Filter和Enricher等多个步骤。竞价器框架规定了这条流水线的结构和执行机制，而每个产品竞价器可以根据具体产品需求做定制化执行。

这种方法解耦了服务与产品，从而使平台团队只负责竞价器框架，产品团队负责竞价器的具体实现。它最大程度地提高了开发的敏捷性和速度，同时保留了乘数效应。例如，框架升级会同时作用于所有产品竞价器；所有产品竞价器还能共享一套分析数据采集机制。

不同产品竞价器之间的相互独立，使得工程师可以对特定产品（如视频）进行更改，而完全不影响与视频不相关的产品。例如，如果一个新的视频功能需要额外的计算资源，视频产品竞价器可以增大其允许延时，而不改变其它产品的行为。

数据依赖框架

（译者注：本段大量根据自己的理解写成，可能与原文有出入）在AdServer的整条流水线中，每个步骤都涉及对通用数据结构的直接改动，这使得我们很难找出数据具体是在哪一个步骤被修改的。我们开发了一套数据依赖框架，严格规定了每个步骤的输入输出格式，禁止对通用数据结构的直接改动，而需要通过immutable的方式做改动，这样能使每个步骤的职责更为清晰。

分片服务的数据获取与传输

在原有系统中，Ad Mixer在每次请求中，都会一次性获取所需数据（比如用户的个人信息、兴趣、活动等），并将数据传递给各个分片AdServer。在拆分后，每个竞价器需要不同的数据源，然而我们希望避免每个拆分的服务都各自进行数据获取，因为这可能会使数据的获取量增加400倍。我们选择仍然在Ad Mixer处做一次性数据获取，并使用以下方法确保竞价器高效地获取各自所需数据：

挑战与经验

可靠的逐步迁移

在我们进行拆分之前，Twitter的单体AdServer上运行着价值30亿美元的业务。因此，在做拆分的同时，我们必须保持现有业务的运行，以及支持正在进行的产品开发。

在项目过程中，我们进行了广泛的A/B实验，由新系统支持小部分流量，由原有系统支持大部分流量，对产品指标进行详尽分析，确保两个系统在收入和各项指标上都基本符合，希望在不影响正常业务的前提下，及早发现问题。

我们在长达4周的时间内，逐渐地给新系统增加流量比例。此外，我们还为每个产品竞价器部署了约20%额外的容量，并启用了保证30秒内完成回滚的机制。最后，我们在长达一个季度的时间内，将小比例的流量运行在之前的单体AdServer上，用于研究季节性对各项指标的影响。

代码复杂度

拆分无可避免地需要直面非常复杂的远古代码，我们要搞清楚这些好几年没人碰过的代码到底在做什么。我们努力将数据处理逻辑归类到“候选选择”、“候选排名”等核心组件，或是“预算计算”、“频率管理”等小组件中。在技术债的泥潭中，做这些改动并不简单。

揭露潜藏的bug

过去的八年中，团队一直对AdServer做渐进性的改动，这样做的缺点是难以发现大bug。这次拆分对系统做根本性的改变，帮我们发现了软件中潜藏的bug。发现、诊断并修复这些bug花了我们一个季度的时间，但这使我们的系统更为健康。

权衡取舍

任何解决方案都不是万能的，我们的团队充分认识到这个决定的风险和收益，做出以下的“舍”：

失去对候选做全局排名的能力

当我们将单体AdServer垂直拆分为多个产品竞价器时，每个产品竞价器都会分别给候选排名。从而，我们失去了在AdServe内以接近全局的方式对所有候选进行排名的能力。我们清楚利弊，决定通过增加最终拍卖所考虑的候选的数量来弥补局部决策带来的损失，以确保我们不会过滤掉原本有资格的候选。（译者注：假设有两种产品，视频和卡片，二者分别有10个候选。假定全局最优的5个中，有4个视频和1个卡片。那么，如果我们在局部排名中，分别对视频和卡片取前3名，汇总后再进行全局排名，则我们错误地过滤掉了一条视频。Twitter可能通过对二者各取前5名的方式来减少这种情况的发生。）

下游服务的流量增大

考虑到AdServer的规模，我们必选在项目开始时就估计好服务的流量情况，并提前6个月告知基础设施团队。我们使用一些原型（prototype）以及大量的压力测试来确保估计的准确。

从单体AdServer改为多产品竞价器架构后，AdServer对直接下游服务的请求数量增加，进而增加所有下游服务的压力和成本。考虑到这一点，我们谨慎地选择了要分割的产品垂直领域，以使我们获得最大的投资回报。

发布平台改动的发布周期变长

把AdServer按产品切分还意味着每一个平台层面的改动都要在所有产品上完成测试和发布。我们清楚认识到、并且愿意承担这个成本。

哪怕有上述不足，在竞价器架构正式上线后，我们还是看到了产品隔离的好处。一个具体的例子是，我们通过给Promoted Trend竞价器中的选择服务配置一个缓存，实现延迟的降低，而完全不影响其它产品的行为。我们还看到产品功能的迭代不再被平台团队所阻塞，解决了一个主要的痛点。

总结

所有定律都有局限性，康威定律也不例外。它适用于所有的组织，但我们也可以共同努力打破它，确保服务和组织都适合未来的需求，而不是受制于历史。切分并不能解决所有问题，但对团队以及服务确实有积极的影响，其结果是产品工程师在新架构中添加新功能的工作流程得到了简化。当我们开始这个项目的时候，这似乎是一个几乎不可能完成的任务，但回过头来看，它不仅帮助我们搭建了更健康的系统，还加深了对系统工作方式的理解，为实现Twitter部门的下一个宏伟目标奠定了基础。