导读：从2020年开始，百度开始构建本身的商品推广系统，目前系统应用在百家号和直播场景中，为B端商家以及C端做者、主播提供了便捷带货流程，为广大用户提供了直接简单的购物体验。本文按照业务概念、用户界面、系统架构、核心实现的顺序介绍商品推广系统，旨在抛砖引玉，但愿能给读者带来思考和帮助。前端

全文5874字，预计阅读时间12分钟。算法

1、推广流程概述

上次谈到的《百度交易中台之订单系统架构浅析》，讲述了订单系统的实现方式以及迭代流程，本期基于订单系统，继续介绍推广系统的设计与实现。数据库

商品推广系统，是目前电商平台带货场景业务下较为常见的系统。*宝联盟、*东联盟、多*进宝等都是相似的商品推广系统。在当今社会中，随着知识付费、短视频、直播业务的繁荣，大众表达自个人门槛开始下降，愈来愈多的内容创造者（短视频时代，大部分的内容创做者是做者或者主播）具备了强大的影响力。因而面向商家、做者（主播）的商品推广系统就显得十分重要，这个商品推广系统链接了BC两端，极大的解放了生产力。小程序

商品推广系统围绕着做者（主播）、商家、用户为核心，提供一个能够同时服务三者的平台。在推广流程中，不一样的角色有特殊的称呼，做者（主播）称为流量主，商家称为广告主。后端

（1）流量主

商品推广流程的目标是最大限度的促成交易。推广商品的通常手段是提升商品曝光量、增长商品点击量，越多的人看到商品，促成交易的可能性就越高。商品推广系统则是经过联合有影响力的主播或者做者，一块儿进行推广，借此来扩大影响面，就是一般人们口中说的 “带货”。这个方案，主旨是经过影响有影响力的人，经过品牌效应、名人效应去达到宣传商品的目标。参与推广流程的做者或者主播，因为能够帮助订单系统吸引流量，所以称为【流量主】，下文统称参与商品推广流程的主播和做者为流量主。安全

（2）广告主

在常见的商品推广流程中，为了吸引更多的流量主加盟参与推广，会根据商品的类别，酌情为每一笔订单设计一个佣金比例，若是消费者经过流量主提供的入口进行商品购买，则流量主会得到必定比例的分佣返现。分佣返现的金额，由商家或者平台提供，根据不一样的场景会有不一样的策略。网络

对于须要推广商品的商家来讲，一个推广流程，至关于进行了一次对商品的广而告之，只不过这个广告不必定来自某个广告公司，也可能来自某个名不见经传的普通人。这些商家角色，在推广流程中，被形象的称为【广告主】。架构

（3）CPS

随着科技的发展，3G和4G网络让移动支付成为了互联网革命的“蒸汽机”，5G和大数据则让信息立体化。商品推广流程在两者的基础上，提供了让更多人参与到交易当中的机会。常见的电商平台基本都支持分佣推广，在电商场景中，通常经过CPS方式实现分佣动做。负载均衡

CPS是Cost Per Sales的简称，是在商品推广中常见的计费手段，经过实际的销售量进行收费的，更适合购物类APP进行推广，可是须要精确的流量进行数据统计转换。框架

2、百度商品推广流程业务特色

CPS推广带货，一共须要面向3个不一样维度的用户提供服务，分别对应上文中的流量主（主播+做者）、广告主（商家）、用户（消费者），同时，整个CPS推广系统的建设，也是从这三个点入手进行功能拆解。能够将其拆分为3个用户界面服务以及5个内部核心服务。

（图1：百度总体带货体系构建）

（1）三个用户界面

从图1中能够看到，商品推广系统，主要有三个用户界面，分别是针对广告主的小程序B端，针对流量主的商品选品界面，针对用户的订单购买界面。下面分别对三个界面进行说明。

广告主界面部分，小程序B端服务做为商家端，为广告主提供商品注册服务，即，广告主能够在小程序后台的界面，开通商品分佣带货，从而让本身的商品获得推广。

（图2：小程序B端带货开通界面）

（图3：小程序B端用户收益界面）

在实际带货流程中，开发者能够本身做为广告主开通带货，这样的方式带有必定的开发成本（好比当当、亚马逊等）；百度也提供了一套完整的开店服务，能够经过很是低的成本参与到商品推广流程之中（好比度小店）。

流量主界面部分，百家号、直播生态做为选品服务做为入口，为主播以及做者提供方便快捷的商品引入，而且在这部分中，还能够引入百度自有的体系商品。

（图4：百家号编辑选品界面）

上图是百家号的编辑界面，流量主经过编辑按键的添加商品，能够从商品库中选择商品，而且将商品橱窗嵌入文章之中。嵌入文章之中的商品连接，若是被普通用户点击而且成功下单，则会按照必定规则，将该笔订单算做流量主的一次推广。在百家号直播的界面，也能够进行选品以及添加商品连接，这里就再也不赘述。

（图5：选品平台选择界面）

图二，这是百家号的选品界面，能够看到，在选品中，不只包括淘宝、京东、拼多多的分佣商品，还包括一些具备百度特点的选品库，包括度小店、当当网、亚马逊、电影票友等。

用户界面部分，则和广告主相似，商品、订单的界面依赖于百度小程序进行展现，这样的设计方便于在百度APP产品矩阵内进行共享，在技术实现上，广告主的商品界面，只须要开发一次，便可在全部的百度生态内APP上进行展现以及推广。

（图6：用户界面）

用户界面主要就是面向广大消费者，消费者在观看直播，或者观看做者的文章时候，若是这个直播或者文章中包含商品推广的话，就能够按照图6中展现的流程进行商品购买。此时购买的商品就是来自于商品推广系统。

（2）五个核心服务

经过梳理用户界面，能够将商品推广系统按照功能点进行拆分，在本期的实现中，拆分为5个核心服务。服务见下表：

在5个核心服务中，挂载服务、推广服务是针对商品推广场景从新设计以及开发的，交易系统、结算系统、资产系统是交易中台已经有的能力。

（3）建设具备百度特点的推广流程

2020年开始，百度着手创建集团内部的商品推广系统，系统的构建过程当中，面临不少技术挑战，主要有如下几个方面：

百度的业务多个APP造成的产品矩阵，如何提供统一的技术实现方案，让流量主和广告主双方能享受最优质的产品服务
如何在缤纷多变的页面中，有效的采集用户的推广行为
如何整合现有的订单和结算系统、输出一套支付和结算的标准模型

上面只是列举的一些大的问题点，放到细节之上，还有许多前台看不到的，可是很影响体验的问题，好比流量主命中有效推广以后，是须要分配佣金的，这部分佣金的计算如何实现，分配后的佣金又如何能实实在在的变成流量主的收入？又好比做为广告主来讲，如何定型定量的看到本身的推广记录？老是涉及到资金变更，任何人都想看的仔仔细细。

可是，抛开挑战不说，从交易中台开始构建CPS推广体系，起步就是站在巨人的肩膀上的。依托于底层的交易能力，能够快速创建一套CPS推广实现，业务上充分复用已有的能力，包括下单、资金池、资产记帐、提现等均可以快速实现；技术上则能够依托于交易的底层框架，快速的实现功能。

3、商品推广服务实现

（图7：挂载服务&&推广服务架构图）

挂载服务以及推广服务虽然在复杂的商品推广的体系中占据了很是重要的做用，可是从设计角度，进行单独拆分以后，其实各自的功能是比较单一的，这也符合系统之间高内聚低耦合的标准。

上图将服务按照分层设计的方式，拆分红为4个层面，从上到下，分别以下：

业务层：这一层指代抽象的业务，是能够扩展的多个服务方，不一样的服务方站在不一样的角度进行接入，包括广告主、流量主、用户多个角度的不一样服务。

接入层：这一层主要指对业务层提供服务的服务网关层，主要的功能是流量转发、服务鉴权、负载均衡等。除了常规网关的功能以外，接入层还针对BC两侧(B表明商家、C表明用户)的不一样流量进行了分离。其中交易统一网关主要承担来自消费者的流量，该网关的特色是用户请求量大，可是相对简单，所以对于网关的设计，非功能需求方面，性能、安全是主要的考量点。其中电商开放平台(trade.baidu.com)则做为商家端的网关入口，这部分网关访问量没有那么高，所以主要侧重于业务的处理以及关联。

服务层：这一层是核心的服务提供者，包括前台后台多个服务。

动态库：商品推广的核心前端组件，主要负责推广数据的上报，而且须要保障安全性以及数据合法性；

注册服务：这是一个后台服务，提供广告主流量主的注册开通，而且联携下层的商品系统、结算系统提供商品导入、分佣比例设置的功能，是承上启下，数据的注册中心；

挂载服务：挂载服务提供在商品注册以后，进行商品橱窗连接生成、数据真实性校验

推广服务：商品推广的核心后端组件，对外承接来自动态库的推广记录上报，对内承接来自交易系统的订单命推广断定。

组件层：这一层依赖于度长内部的各类中间件快速实现功能。

对于推广记录以及挂载服务来讲，设计难点在于和总体系统的联系，自己业务较为单一，在此值得介绍的包括两部分，一部分是基于动态库的推广记录上报，另外一部分是则是基于数据库批写的写入优化。

（1）基于动态库的推广记录上报

【动态库】是百度小程序提供的框架组件，能够旁路式的为小程序提供底层的基础能力，好比ECharts图表、editor富文本编辑器等。商品动态库则利用这种旁路的设计方式，嵌入到开发者的商品详情页面，而且能够完整的获取到商品页面的扩展参数。（复制此处连接查看小程序动态库官方文档：https://smartprogram.baidu.com/docs/develop/framework/editor/）

（图8：小程序动态库示意图）

小程序动态库如上图，最上层的是订单的购买页面，底层是小程序的运行容器，中间层的就是动态库。动态库是按需动态加载的基础库，由一些特定的小程序业务平台方发布（如大搜、凤巢等），能够提供该业务平台的一些业务功能或约束，动态库具有以下特征：

动态库会静默更新，由动态库发布方决定更新，小程序开发者不能决定什么时候更新。
动态库能提供自定义组件或者JS 模块给小程序使用。
动态库发布方如今只能是百度。
动态库的使用，须要开发者明确的在页面标识才能引用。

因为动态库自己由交易中台进行开发和维护，推广数据上报则经过动态库进行上传。基于动态库的数据上报实现，具备明显的优势：

一、遵循开闭原则：避免下单页面中硬编码实现数据上报。彻底和订单页面解耦，不论开发者升级，或者上报逻辑更新，都不互相影响。

二、一处改多处用：小程序动态库能够无缝的应用在各个矩阵APP上，后续还能够开源应用到外部的宿主APP之上，扩展性和兼容性很是好。

三、可维护性优秀：因为推广上报彻底脱离了订单页面，开发方面不用考虑业务实现以及问题，具有良好的可扩展性。

可是因为动态库是比较底层的实现，俗话说能力越大责任越大，动态库在实际的开发中，对于性能和安全性具备很是高的要求，不能由于动态库的加载，而拖慢开发的提单页面。

对于数据协议方面，动态库虽然能够独立于订单页面运行，可是如何为动态库设计一套普遍通用的数据协议，而且让其具有良好的可扩展性，这是一个问题。在实践中，咱们经过对挂载连接功能进行改造，实现了服务端生成连接+动态库解析链接的闭环。

参见下图中；

（图9：带货连接动态库闭环）

挂载服务为选品界面提供连接生成的能力，对于不一样的商品，会生成该专属流量主的特定连接，而且携带一些扩展参数。这些参数会随着商品页面一块儿加载。这些参数虽然对商品页面不构成影响，但倒是动态库加载的必须参数。这些参数包含自验证机制，若是被随便修改的话，上报验证就会发现。对于不一样的商家和商品，经过在挂载连接中设置不一样的参数实现个性化的推广数据上报能力，好比针对不一样类型的服务，命中推广连接，在商品详情页面的停留时长能够有必定区别。

统一格式的数据协议，对于后续判断推广是否命中也有好处，好比能够统一的使用时间窗口策略断定用户针对流量主的推广是否命中，对于某些商家，还能够跳出商品的范畴，直接断定此时用户是否命中商家的其余有效推广。

（2）基于数据库批写的写入优化

推广数据上报具备请求量大，业务比较简单的特色，再加上推广数据实时查询的需求没有那么强烈，在实际的开发中，咱们针对推广服务采用了数据库异步批量写入的机制来提升性能。

（图10：批量写写入优化）

如今配合上图说明一下优化流程，改进前的单次写入，其实就是直截了当的单次写入，每次数据上报，走一次流程，数据通过控制层、服务层、数据持久层进行写入。这样的好处是逻辑简单，写入实时性好，适合通常的OLTP服务。可是对于数据上报服务（相似的服务还有打点服务、日志上报等）来讲，并无实时查询的需求，因此在服务资源有限的前提之下，能够采用批量写入的方式来充分利用资源，提升服务的吞吐量。

图中右边的部分就是优化后的批量写入，批量写入本质上是一个生产者消费者的模型，目标是下降数据库的TPS。图中的每次收到上报记录，就会加入到内存的阻塞队列中，将同步写入变动为异步写入。队列每一个必定时间执行一次写入，这样一来，数据库的写入QPS实际上是大大下降了。

交易中台中，通常采用横向分表的db设计，推广记录的设计也是同样，数据表根据分表字段路由存储到不一样的数据表中，而且对于不一样的表，还能够分离到不一样的数据库实例当中，进一步进行水平扩容。下图是《百度交易中台之订单系统架构浅析》中的数据分表规则。推广记录的分表方式大同小异。

（图11：分表规则）

对于这种数据库结果，在数据库批量写入中，还能够再进行一次优化，即将同一个实例、分表记录进行聚合，而后统一执行。这样能够进一步提升数据库的写入效率。

4、总结

商品推广系统的构建，难点在于业务复杂，构建路径长，须要跨团队以及跨部门合做。

业务梳理清晰以后，对于技术侧的实现，除了动态库以外，其余的部分实现复杂度都不是过高。关键在于对边界条件的控制，对细节的把控是否周全。推广系统以及交易中台，有幸站在巨人的肩膀上，踏浪潮头，天然事半功倍。

从古到今，软件开发工程多半按照工做领域，划分为系统工程师、算法工程师和业务工程师。不管是哪一类工程师，要想不负使命，都须要在广度和细节之上进行积累，厚积方能薄发。

招聘信息

百度移动生态事业部MEG，用户中心招聘研发岗位（PHP/GO/C++），咱们主要负责公司Passport、用户资产、属性、百度APP会员等核心业务方向，致力于打造高效、便捷、安全的用户体系。若是你对Passport、百万级QPS服务、分布式设计&治理感兴趣欢迎加入咱们。

关注同名公众号百度Geek说，点击菜单栏“内推”便可加入搜索架构部，咱们期待你的加入！

百度交易中台之商品推广流程构建以及实现