👇👇关注后回复 “进群” ，拉你进程序员交流群👇👇
作者丨百度交易团队
来源丨百度Geek说（ID：baidugeektalk）
导读：从2020年开始，百度开始构建自己的商品推广系统，目前系统应用在百家号和直播场景中，为B端商家以及C端作者、主播提供了便捷带货流程，为广大用户提供了直接简单的购物体验。本文按照业务概念、用户界面、系统架构、核心实现的顺序介绍商品推广系统，旨在抛砖引玉，希望能给读者带来思考和帮助。
全文5874字，预计阅读时间12分钟。
上次谈到的《百度交易中台之订单系统架构浅析》，讲述了订单系统的实现方式以及迭代流程，本期基于订单系统，继续介绍推广系统的设计与实现。
商品推广系统，是目前电商平台带货场景业务下较为常见的系统。*宝联盟、*东联盟、多*进宝等都是类似的商品推广系统。在当今社会中，随着知识付费、短视频、直播业务的繁荣，大众表达自我的门槛开始降低，越来越多的内容创造者（短视频时代，大部分的内容创作者是作者或者主播）具有了强大的影响力。于是面向商家、作者（主播）的商品推广系统就显得十分重要，这个商品推广系统连接了BC两端，极大的解放了生产力。
商品推广系统围绕着作者（主播）、商家、用户为核心，提供一个可以同时服务三者的平台。在推广流程中，不同的角色有特殊的称呼，作者（主播）称为流量主，商家称为广告主。
商品推广流程的目标是最大限度的促成交易。推广商品的一般手段是提高商品曝光量、增加商品点击量，越多的人看到商品，促成交易的可能性就越高。商品推广系统则是通过联合有影响力的主播或者作者，一起进行推广，借此来扩大影响面，就是通常人们口中说的 “带货”。这个方案，主旨是通过影响有影响力的人，通过品牌效应、名人效应去达到宣传商品的目标。参与推广流程的作者或者主播，由于可以帮助订单系统吸引流量，因此称为【流量主】，下文统称参与商品推广流程的主播和作者为流量主。
在常见的商品推广流程中，为了吸引更多的流量主加盟参与推广，会根据商品的类别， 酌情为每一笔订单设计一个佣金比例，如果消费者通过流量主提供的入口进行商品购买，则流量主会获得一定比例的分佣返现。分佣返现的金额，由商家或者平台提供，根据不同的场景会有不同的策略。
对于需要推广商品的商家来说，一个推广流程，相当于进行了一次对商品的广而告之，只不过这个广告不一定来自某个广告公司，也可能来自某个名不见经传的普通人。这些商家角色，在推广流程中，被形象的称为【广告主】。
随着科技的发展，3G和4G网络让移动支付成为了互联网革命的“蒸汽机”，5G和大数据则让信息立体化。商品推广流程在二者的基础上，提供了让更多人参与到交易当中的机会。常见的电商平台基本都支持分佣推广，在电商场景中，一般通过CPS方式实现分佣动作。
CPS是Cost Per Sales的简称，是在商品推广中常见的计费手段，通过实际的销售量进行收费的，更适合购物类APP进行推广，但是需要精确的流量进行数据统计转换。
CPS推广带货，一共需要面向3个不同维度的用户提供服务，分别对应上文中的流量主（主播+作者）、广告主（商家）、用户（消费者），同时，整个CPS推广系统的建设，也是从这三个点入手进行功能拆解。可以将其拆分为3个用户界面服务以及5个内部核心服务。
（图1：百度整体带货体系构建）
从图1中可以看到，商品推广系统，主要有三个用户界面，分别是针对广告主的小程序B端，针对流量主的商品选品界面，针对用户的订单购买界面。下面分别对三个界面进行说明。
广告主界面部分，小程序B端服务作为商家端，为广告主提供商品注册服务，即，广告主可以在小程序后台的界面，开通商品分佣带货，从而让自己的商品得到推广。
（图2：小程序B端带货开通界面）
（图3：小程序B端用户收益界面）
在实际带货流程中，开发者可以自己作为广告主开通带货，这样的方式带有一定的开发成本（比如当当、亚马逊等）；百度也提供了一套完整的开店服务，可以通过非常低的成本参与到商品推广流程之中（比如度小店）。
流量主界面部分，百家号、直播生态作为选品服务作为入口，为主播以及作者提供方便快捷的商品引入，并且在这部分中，还可以引入百度自有的体系商品。
（图4：百家号编辑选品界面）
上图是百家号的编辑界面，流量主通过编辑按键的添加商品，可以从商品库中选择商品，并且将商品橱窗嵌入文章之中。嵌入文章之中的商品链接，如果被普通用户点击并且成功下单，则会按照一定规则，将该笔订单算作流量主的一次推广。在百家号直播的界面，也可以进行选品以及添加商品链接，这里就不再赘述。
（图5：选品平台选择界面）
图二，这是百家号的选品界面，可以看到，在选品中，不仅包括淘宝、京东、拼多多的分佣商品，还包括一些具有百度特色的选品库，包括度小店、当当网、亚马逊、电影票友等。
用户界面部分，则和广告主类似，商品、订单的界面依赖于百度小程序进行展示，这样的设计方便于在百度APP产品矩阵内进行共享，在技术实现上，广告主的商品界面，只需要开发一次，即可在所有的百度生态内APP上进行展示以及推广。
（图6：用户界面）
用户界面主要就是面向广大消费者，消费者在观看直播，或者观看作者的文章时候，如果这个直播或者文章中包含商品推广的话，就可以按照图6中展示的流程进行商品购买。此时购买的商品就是来自于商品推广系统。
通过梳理用户界面，可以将商品推广系统按照功能点进行拆分，在本期的实现中，拆分为5个核心服务。服务见下表：
在5个核心服务中，挂载服务、推广服务是针对商品推广场景重新设计以及开发的，交易系统、结算系统、资产系统是交易中台已经有的能力。
2020年开始，百度着手建立集团内部的商品推广系统，系统的构建过程中，面临很多技术挑战，主要有以下几个方面：
百度的业务多个APP形成的产品矩阵，如何提供统一的技术实现方案，让流量主和广告主双方能享受最优质的产品服务
如何在缤纷多变的页面中，有效的采集用户的推广行为
如何整合现有的订单和结算系统、输出一套支付和结算的标准模型
上面只是列举的一些大的问题点，放到细节之上，还有许多前台看不到的，但是很影响体验的问题，比如流量主命中有效推广之后，是需要分配佣金的，这部分佣金的计算如何实现，分配后的佣金又如何能实实在在的变成流量主的收入？又比如作为广告主来说，如何定型定量的看到自己的推广记录？总是涉及到资金变动，任何人都想看的仔仔细细。
但是，抛开挑战不说，从交易中台开始构建CPS推广体系，起步就是站在巨人的肩膀上的。依托于底层的交易能力，可以快速建立一套CPS推广实现，业务上充分复用已有的能力，包括下单、资金池、资产记账、提现等都可以快速实现；技术上则可以依托于交易的底层框架，快速的实现功能。
（图7：挂载服务&&推广服务架构图）
挂载服务以及推广服务虽然在复杂的商品推广的体系中占据了非常重要的作用，但是从设计角度，进行单独拆分之后，其实各自的功能是比较单一的，这也符合系统之间高内聚低耦合的标准。
上图将服务按照分层设计的方式，拆分成为4个层面，从上到下，分别如下：
业务层：这一层指代抽象的业务，是可以扩展的多个服务方，不同的服务方站在不同的角度进行接入，包括广告主、流量主、用户多个角度的不同服务。
接入层：这一层主要指对业务层提供服务的服务网关层，主要的功能是流量转发、服务鉴权、负载均衡等。除了常规网关的功能之外，接入层还针对BC两侧(B代表商家、C代表用户)的不同流量进行了分离。其中交易统一网关主要承担来自消费者的流量，该网关的特点是用户请求量大，但是相对简单，因此对于网关的设计，非功能需求方面，性能、安全是主要的考量点。其中电商开放平台(trade.baidu.com)则作为商家端的网关入口，这部分网关访问量没有那么高，因此主要侧重于业务的处理以及关联。
服务层：这一层是核心的服务提供者，包括前台后台多个服务。
动态库：商品推广的核心前端组件，主要负责推广数据的上报，并且需要保障安全性以及数据合法性；
注册服务：这是一个后台服务，提供广告主流量主的注册开通，并且联携下层的商品系统、结算系统提供商品导入、分佣比例设置的功能，是承上启下，数据的注册中心；
挂载服务：挂载服务提供在商品注册之后，进行商品橱窗链接生成、数据真实性校验
推广服务：商品推广的核心后端组件，对外承接来自动态库的推广记录上报，对内承接来自交易系统的订单命推广判定。
组件层：这一层依赖于度长内部的各种中间件快速实现功能。
对于推广记录以及挂载服务来说，设计难点在于和整体系统的联系，本身业务较为单一，在此值得介绍的包括两部分，一部分是基于动态库的推广记录上报，另一部分是则是基于数据库批写的写入优化。
【动态库】是百度小程序提供的框架组件，可以旁路式的为小程序提供底层的基础能力，比如ECharts图表、editor富文本编辑器等。商品动态库则利用这种旁路的设计方式，嵌入到开发者的商品详情页面，并且可以完整的获取到商品页面的扩展参数。（复制此处链接查看小程序动态库官方文档：https://smartprogram.baidu.com/docs/develop/framework/editor/）
（图8：小程序动态库示意图）
小程序动态库如上图，最上层的是订单的购买页面，底层是小程序的运行容器，中间层的就是动态库。动态库是按需动态加载的基础库，由一些特定的小程序业务平台方发布（如大搜、凤巢等），可以提供该业务平台的一些业务功能或约束，动态库具备如下特征：
动态库会静默更新，由动态库发布方决定更新，小程序开发者不能决定何时更新。
动态库能提供自定义组件或者JS 模块给小程序使用。
动态库发布方现在只能是百度。
动态库的使用，需要开发者明确的在页面标识才能引用。
由于动态库本身由交易中台进行开发和维护，推广数据上报则通过动态库进行上传。基于动态库的数据上报实现，具有明显的优点：
1、遵循开闭原则：避免下单页面中硬编码实现数据上报。完全和订单页面解耦，不论开发者升级，或者上报逻辑更新，都不互相影响。
2、一处改多处用：小程序动态库可以无缝的应用在各个矩阵APP上，后续还可以开源应用到外部的宿主APP之上，扩展性和兼容性非常好。
3、可维护性优秀：由于推广上报完全脱离了订单页面，开发方面不用考虑业务实现以及问题，具备良好的可扩展性。
但是由于动态库是比较底层的实现，俗话说能力越大责任越大，动态库在实际的开发中，对于性能和安全性具有非常高的要求，不能因为动态库的加载，而拖慢开发的提单页面。
对于数据协议方面，动态库虽然可以独立于订单页面运行，但是如何为动态库设计一套广泛通用的数据协议，并且让其具备良好的可扩展性，这是一个问题。在实践中，我们通过对挂载链接功能进行改造，实现了服务端生成链接+动态库解析连接的闭环。
参见下图中；
（图9：带货链接动态库闭环）
挂载服务为选品界面提供链接生成的能力，对于不同的商品，会生成该专属流量主的特定链接，并且携带一些扩展参数。这些参数会随着商品页面一起加载。这些参数虽然对商品页面不构成影响，但却是动态库加载的必须参数。这些参数包含自验证机制，如果被随便修改的话，上报验证就会发现。对于不同的商家和商品，通过在挂载链接中设置不同的参数实现个性化的推广数据上报能力，比如针对不同类型的服务，命中推广链接，在商品详情页面的停留时长可以有一定区别。
统一格式的数据协议，对于后续判断推广是否命中也有好处，比如可以统一的使用时间窗口策略判定用户针对流量主的推广是否命中，对于某些商家，还可以跳出商品的范畴，直接判定此时用户是否命中商家的其他有效推广。
推广数据上报具有请求量大，业务比较简单的特点，再加上推广数据实时查询的需求没有那么强烈，在实际的开发中，我们针对推广服务采用了数据库异步批量写入的机制来提高性能。
（图10：批量写写入优化）
现在配合上图说明一下优化流程，改进前的单次写入，其实就是直截了当的单次写入，每次数据上报，走一次流程，数据经过控制层、服务层、数据持久层进行写入。这样的好处是逻辑简单，写入实时性好，适合一般的OLTP服务。但是对于数据上报服务（类似的服务还有打点服务、日志上报等）来说，并没有实时查询的需求，所以在服务资源有限的前提之下，可以采用批量写入的方式来充分利用资源，提高服务的吞吐量。
图中右边的部分就是优化后的批量写入，批量写入本质上是一个生产者消费者的模型，目标是降低数据库的TPS。图中的每次收到上报记录，就会加入到内存的阻塞队列中，将同步写入变更为异步写入。队列每个一定时间执行一次写入，这样一来，数据库的写入QPS其实是大大降低了。
交易中台中，一般采用横向分表的db设计，推广记录的设计也是一样，数据表根据分表字段路由存储到不同的数据表中，并且对于不同的表，还可以分离到不同的数据库实例当中，进一步进行水平扩容。下图是《百度交易中台之订单系统架构浅析》中的数据分表规则。推广记录的分表方式大同小异。
（图11：分表规则）
对于这种数据库结果，在数据库批量写入中，还可以再进行一次优化，即将同一个实例、分表记录进行聚合，然后统一执行。这样可以进一步提高数据库的写入效率。
商品推广系统的构建，难点在于业务复杂，构建路径长，需要跨团队以及跨部门合作。
业务梳理清晰之后，对于技术侧的实现，除了动态库之外，其他的部分实现复杂度都不是太高。关键在于对边界条件的控制，对细节的把控是否周全。推广系统以及交易中台，有幸站在巨人的肩膀上，踏浪潮头，自然事半功倍。
古往今来，软件开发工程多半按照工作领域，划分为系统工程师、算法工程师和业务工程师。不论是哪一类工程师，要想不负使命，都需要在广度和细节之上进行积累，厚积方能薄发。
-End-
最近有一些小伙伴，让我帮忙找一些 面试题 资料，于是我翻遍了收藏的 5T 资料后，汇总整理出来，可以说是程序员面试必备！所有资料都整理到网盘了，欢迎下载！
