背景
闲鱼目前已经是国内最大的闲置物品交易平台。随着闲鱼体量的增长和用户规模不断扩大，闲鱼 App 上的一个普通 banner 抑或是 feeds 中的一张普通的卡片，每天都可能被数以千万计的人看到。
为了更好地服务好广大的用户群体，更加个性化的内容推荐和更加精细化的素材投放就显得尤为必要了。今天我们来聊一聊如何设计一个可以精准触达用户、运营快速试错、解放开发生产力的投放系统。
思路分析
投放是什么？举例来说，往城市广场的一块广告牌上在不同时段不同场景下更换广告画就是一种投放，当然互联网技术带来了人的维度，不同用户看到的广告画可能也是不一样的。我们来看下这样一个系统应该包含哪些功能。
1、我们把“城市广场上的那块广告牌”叫资源位，那么需要一个服务端接口来获取需要透出的素材。
2、不同资源位需要透出的素材格式可能是不一样的，可能是 banner，可能是 feeds，可能是运营自定义的手填数据，可能是任何合理的数据结构。
3、同一个资源位，不同时段，针对不同平台、不同人群，透出的素材可能是不一样的，那么就需要有一个服务来在一堆素材中筛选出适合资源位的内容。在资源位命中了多个素材的时候，还需要有一些机制来裁决出最终透出的那一个。
详细设计
我们设计的投放系统扮演的是前端实体资源位和后端多种数据源之间的桥梁的角色。它负责从各个业务数据源中根据一定规则筛选出在特定资源位上需要透出的数据，基本的数据流如下图所示：
资源位
所谓资源位，在我们这个体系内，是指前端页面上的实体坑位。是技术同学在产品开发中创建的。理所当然，资源位需要消费的数据结构是在开发阶段就确定了，比如 banner、feeds 或者结构非常灵活的手填数据等。
在我们这个体系里，我们用一个 schema 描述资源位需要消费的数据结构。
这个 schema 是用 json 描述的。技术同学在前端页面上开发实体资源位后，需要在我们的系统中创建对应的虚拟资源位，并通过一个图形化的 json schema 编辑器来定义这个资源位需要消费的数据结构
投放物料
上述 schema 定义了一个资源位所需要消费的数据的格式。但是光有 schema 是不够的，因为资源位要消费的数据，而不是数据结构本身。在我们的系统中，我们用一个动态表单模块根据 schema 生成动态的表单，产品运营同学通过动态表单生产的数据，我们称之为投放物料。资源位消费的就是投放物料。
对于一些手填数据，表单直接产生的数据就是资源位可用的了。但是对于 Feeds 之类的，表单往往只能定义 Feeds 的一些诸如选品等特征字段。对于这类特殊类型的数据源，服务端就不能简单的直接返回数据了，需要根据这些特征字段，做一些数据查询和数据解析工作，再返回给前端一个完整规范的数据。
投放单元
前述文章说到，同一个 banner，可能对新用户投放的是红包，对年轻男孩子投放的是手机数码内容，对年轻女孩子投放的是美妆服饰。我们把这个连接了资源位、投放物料与多个投放因子的桥梁叫做投放单元。
那么投放单元需要有多少个投放因子呢？其实是视业务而定的，我们认为基础的投放因为应该包含 投放时段、投放人群、投放平台、投放 AB 配置等。
当资源位向投放系统发起请求拉取数据时，投放系统在这个资源位上挂载的所有投放单元中根据投放因子筛选出命中的投放单元，最后将命中的投放单元上挂载的投放物料返回给前端的投放资源位。当命中了多个投放单元时，需要有些方法来裁决出最终胜出的那一个。这个方法简单点做，可以在投放单元中配一个权重，筛选时最后选择权重高的那个，也可以引入算法决策，根据投放的 ctr 数据做排序。
投放计划
投放计划是产品运营对多个资源位管理形式。简单来说，一个投放计划下，可以挂载多个关联的资源位。试想一下，一次大促活动可能涉及到几十个资源位的投放，将这些资源位组织到同一个投放计划中进行管理，可以更加方便操作以及查看投放效果。
端侧接入
对于前端来说，我们希望通过提供一个封装的 npm 包，通过简单调用，传入 resourceId(资源位 ID) 即可获取数据。
这种调用方式对业务调用方来说是比较优雅的，但是对页面性能来说却是不省心的。因为一个页面往往由很多个资源位组成，每个资源位单独发起请求就会形成大量的并发请求，不仅页面性能会降低，还会对服务器产生比较大的 qps 压力。
针对这种情况，我们做了一个小优化。服务端提供一个批量查询的接口，前端 SDK 内部，每 10ms 对模块的请求调用做一次聚合，将单个资源位的数据获取转化成批量的查询。负面影响是对部分资源位的数据加载造成最大 10ms 的延时，优点是提升了页面整体的性能，有效减小了服务端 QPS 压力。
效果
上述投放系统在我们的拉新业务实践中 run 得非常好，已为闲鱼应用内的数百个资源位提供投放能力支持，每天服务数以千万记的闲鱼用户。既实现了资源位的精细化投放，提高了单个资源位的利用率，又赋能运营更自由地进行各种拉新投放实验，减小试错成本，还减少了技术同学频繁参与运营实验改造的开发工作量，解放了技术同学的生产力。
总结
上述文章介绍了一个简易的投放系统的设计思路，本质上是一个连接前端实体资源位和服务端多种数据源的桥梁的设计。
其中有很多能力是依赖了团队内部其它同学努力的成果，比如：
1、描述资源位数据结构的 json schema 如何设计
2、根据 json schema 动态生成的表单怎么实现
3、人群校验的服务和能力
4、AB 测试的能力
5、feeds 的选品服务
4、个性化动态 banner 能力
还有很多可以优化的点，比如数据回流如何做得更好，怎样引入算法能力对策略筛选进行优化。。。持续优化、持续为业务创造价值是我们一直坚持努力的方向。
本文作者：闲鱼技术 - 长玖
阅读原文
本文为云栖社区原创内容，未经允许不得转载。