百度信誉保障服务架构全解析
全文6610字，预计阅读时间17分钟
一、**背景**
百度保障是商家与网民之间发生投诉纠纷时，百度处理投诉的兜底方案，目标在于围绕百度商家提供的内容和服务，构建良币驱逐劣币的百度信誉生态，让用户放心的在百度获取信息和服务。目前百度保障覆盖百度的各主要核心业务场景。搜索场景，无论是pc还是wise，端内还是端外，几乎所有交易场景都覆盖了；电商场景，无论toB，还是toC，爱采购、度小店精选、招财猫等；feed场景，feed广告、小程序保障；重点垂类，柠檬爱美、生活服务、医疗、教育等。
网民在百度进行交易或者使用百度服务时，只要认准"保障"标记，由于商家发生欺诈或者商家商家承诺没有兑现时，可以通过保障平台发起赔付申诉，得到相应的赔偿。
图（1）为百度在搜索场景和电商场景两个核心场景的主要入口和保障服务标签披露。
图（1）保障核心场景入口
百度保障产品介绍
百度各业务线商家可以通过百度保障统一入驻服务，采取缴纳保证金等形式加入百度保障计划，同时百度保障提供高阶保障标签服务，赋能各B端商家。商家加入保障计划后，百度保障标签和高阶保障标签会展示在C端商家对应的商品和服务上，从而提升网民对百度商品和服务的信任感，提高下单转化率。
当网民购买带有"保障"的商品或服务，存在商家欺诈或违背承诺等情况，网民可以来百度保障提供相应的证据，经过营运判定处理后，得到相应的赔偿。针对百度的特点，目前保障赔付系统支持两种主要形式的赔付，分别是：基于网民行为记录（如点击记录、小程序调起记录）的开环场景赔付申请和基于订单（电商订单、支付订单）的闭环场景赔付申请。
图（2）百度保障产品介绍
二、**业务架构全景**
如图（3）为保障业务全景图。最下层为保障核心业务数据，主要分三类，分别是商户数据、网民数据、赔付数据。其中商户数据包括：商户的基本信息（商户ID、商户名称、营业执照等）、保证金信息、高阶保障信息等。网民数据包括网民基本信息（网民ID、名称、姓名）、实名信息等。赔付数据主要包括赔付的申请记录、举证信息、百度的付款记录等。数据层之上为基础服务层，主要包括基础能力、计算融合服务、三方服务等。中间层为保障服务的核心系统，主要包括统一的入驻系统、披露系统、接入系统和赔付系统。核心系统直接对接业务的B端和C端，为各业务方提供服务。
图（3）保障业务全景
（1）入驻系统主要服务于各业务方B端系统，为客户提供保障的入驻服务，客户可以在此进行保证金和高阶保障管理。业务方接入保障时，需要与保障一起确认不同行业类目的保证金门槛，保障测进行相应的配置，然后，业务方B端只要通过iframe的形式内嵌保证的页面即可。
（2）披露系统主要为各业务方C端或其他展现端提供高性能的保障数据查询服务，包括保标和保障浮层。主要的数据维度包括：账号userid、网站url、小程序的appkey、店铺ID维度。
（3）保障接入系统，主要服务于开环场景网民行为数据的接入，由于开环场景，网民申请赔付时，线上唯一可以获取的凭证就是网民在系统的点击行为等数据，所以针对开环场景，需要接入不同业务方的点击行为数据，以便作为网民申请赔付的依据。
（4）保障赔付系统主要包括两种场景的赔付，针对开环场景基于点击记录的赔付，以及针对闭环场景订单的赔付。两种场景赔付的主要区别在于赔付的依据不一样，以及运营判断赔付的标准不一样。在申请赔付过程中，需要对网民进行真实性身份验证，主要是采用人脸活体技术。在申保的过程中为网民提送联系商家，联系平台等服务，提升网民的申报体验。最终运营统一判定赔付。
三保障服务核心能力介绍
3.1 统一入驻
统一入驻主要面向各业务方的B端系统设计，方便业务方商户快速加入保障。商家加入保障的门槛条件为缴纳足够的保证金。保障将保证金充值、退款、扣款、罚款、财务对账等复杂繁琐的财务交互逻辑沉淀为底层能力，业务方只要嵌入保障统一入驻页面即可。
由于历史原因百度存在多套账号系统，业务方账号体系和权限控制系统也不一致，导致业务方的账号权限控制多种多样。那么对于这种情况，百度保障应该怎么做呢？首先百度保障作为通用服务，没必要感知业务方的个性权限逻辑，因此统一入驻采用token鉴权进行权限控制，具体的权限控制交由业务方控制。业务方通过保障接口api，将页面参数给保障token服务，获取到token信息，再将token信息作为参数拼装到保障入驻管理页面，通过iframe的形式嵌入保障入驻页面。保障测控制token的有效期和保障同一个token只能在一个浏览器被正常访问。这样有效的将保障统一入驻服务与业务方账号系统和权限控制服务解耦。
客户带入服务主要解决不同的业务方入驻保障维度不一致问题，如小店优选以店铺维度加入百度保障计划，生活服务商家通过账号ID加入保障计划。客户带入服务将业务方不同的维度统一转化为保障商户（deposituserid）维度，保障的所有数据都挂在该deposituserid上。
从风险角度考虑，保证金收取的额度都是和商家的行业类目绑定的，业务方、保障、法务共同制定不同行业类目保证金限额。同时保障提供通用和个性话的保证金计算服务，不同的业务方根据自己不同的业务特点选择保证金计算策略，如小店优选以保证金要求最高的类目的保证金作为保证金的最低额度，爱采购可能以商户所有类目的保证金和作为保证金最低额度，商户缴纳的保证金必须大于等于保证金最低额度，方可加入百度保证计划。商家加入保障基础后，才可进行高阶保障的申请。
图（4）保障统一入驻
接着一下看看业务方与保障统一入驻的核心交互。
1、业务通过页面iframe的形式嵌入保障的统一入驻管理页面，商户可以在该页面进行保证金的管理（包括保证金的充值、退款等）和高阶保障的管理，商家加入某个高阶保障项（如7天无理由、48小时发货，假一赔三等）之后，即可将对应的高阶保障项标签展现在对应的商品详情页上，从而提升网民对商品的信任感，提高转化率。
2、业务方商户的行业类目发生变更时，会以api的形式通知保障，完成相应的保证金和高阶保障项的重算逻辑。
3、最终保障的状态和保障项的结果会以api的形式下发给个业务方，同时入驻信誉披露系统，用户C端各页面的展示。
业务方接入保障统一入驻的步骤。
1、初始化类目与保障金、类目与高阶保障项关系。
2、是否需要定制化保证金计算策略，需要则升级，不需要则直接介入。
3、配置化上线，主要配置业务方都需要哪些功能和相应的下发接口地址等。这样一个新的业务方入驻可在一天内完成。
3.2 信誉披露
随着百度保障业务场景的不断扩大，保障标签和信息在各场景、各业务方的披露越来越多。同时保障期望建立百度保障统一品牌，这就需要在不同场景对保障标签和信息的数据和披露样式信息进行统一，所以最好的方式是将保障披露的数据和样式统一收敛到保障测，所以保障需要提供一个面向C端用户的统一保障数据服务和前端统一样式。当前保障信息每天展现两几十亿的数据量级，峰值qps达15Wqps，那么信誉披露如何在保障高性能的同时，支持这么高的qps呢？下图（5）是信誉披露的核心实现。
图（5）信誉披露核心实现
首先，无论保障信息披露的场景多么复杂，披露的数据维度还是相对稳定的，主要包括通用维度userid、url、小程序appkey（主要是根据百度业务特点来的，百度的核心内容主要来源：百度商户userid，百度自然结果url，第三方小程序appkey）和业务方个性化维度sappid+objectid。标准化各维度的数据结构。为了提高检索的性能，减少检索的逻辑，信誉披露采用读写分离、离线计算的形式，即在信誉信息入库的时候根据检索需求，先将结果检索需要的数据数据结构，检索只要取出相应的数据，做简单微调即可。
信誉披露采用多地域部署，根据信誉披露数据源入库特点，采用一主多从的模式，数据在华北地区写入，并同步到华北、华东、华东各从库，减少由于地域差异给不同地域地域带来的影响。同时采用mysql作为数据的备份，再通过binlog将数据以异步消息队列BP 和 文件udw形式输出，满足不同业务方的个性化需求。
在语言选型方面，信誉披露服务采用golang实现，并行处理各种检索请求，最大限度提高服务的性能。当前信誉披露实时检索服务平均响应时长稳定在2ms内，支持20w+qps。
3.3 点击记录接入
上文提到，当网民在百度购买使用带有保障标记的商品或服务被骗时，可以来百度保障提供证据申请赔付，从而得到相应的补偿。而百度的赔付系统主要支持两种场景的赔付开环场景和闭环场景。
开环场景是指用户从百度获取商家相关信息，再线下完成交易，百度对整个交易过程基本无感知，典型的开环场景是：网民在百度搜索某广告，从凤巢广告点击跳转商家落地页了解商家相关信息，并最终在线下完成整个交易过程。对于开环场景，有个很重要的信息就是网民在百度的行为记录，这是网民申请赔付的凭证，否则无法证明是从百度了解的信息。如果百度保障的不同业务方都实现一套网民信息记录的存储是不可取的，为减小业务方的接入成本，同时最大限度与业务方逻辑解耦，因此保障收敛点击接入接入服务，将各业务方的点击记录统一维护在保障测。当网民在浏览商品或者服务时，业务方只要将相应的点击记录接入保障，后续网民基于当时的点击发起赔付申请，运营赔付处理，财务打款对于业务方都是透明的。
图（6）保障点击记录接入架构
点击记录接入系统主要处理点击的分发、字面还原、合并入库与存储。
首先需要规范点击记录结构（主要包括，搜索相关的query、物料title、点击时间、点击ip、跳转链接、网民passportid、商户userid等）。
点击接入支持文件、异步消息队列、api等多种样式。点击记录系统两个主要的服务bzWorker、bzMerge 组成。bzWorker主要用户对不同业务方的点击记录进行自适应处理，包括点击日志物料的还原、无效日志过滤等，新日志源接入时，只要自适应封装物料还原等服务即可。bzMerge为点击日志通用入库逻辑。其中bzWorker和bzMerge取采用master-worker模式形式，master负责消息的分发，worker负责消息的处理，可以最大限度的提高点击日志的介入速率和资源利用率。
图（7）bzWorker实现
在bzWorker和bzMerge之间加入redis缓冲区，可以启动很好的削峰作用，同时可以提高系统的整体稳定性，下游bzMerge挂掉时，点击记录会暂存于缓存区，不会造成消息的丢失。点击记录数据存储分为两部分，点击映射数据采用gaia-x存储，gaia-x是一种newsql 分布式数据库（SQL on Distribute KV），是一种列式存储数据库相对与ddbs主要优势在于，节约存储资源和可扩展性好。同时采用sndb存储重复度高的物料基础信息，最大限度的节约存储空间。
保障点击记录接入系统，满足业务方点击记录秒级延时介入，支持20000+写吞吐。
3.4 赔付申请
百度保障的赔付有两种核心场景，分别是开环场景和闭环场景。对于开环场景的赔付，主要网民提交相应的证据信息，主要靠运营把控，整个申保过程相对简单，所以这部分主要介绍闭环场景基于订单的赔付。
闭环场景基于订单的赔付相对点击记录的赔付要复杂得多。首先开环场景的赔付凭证点击记录都已经收敛到了保障，而闭环场景的订单分散于各业务方。订单属于交易场景的基础服务，各业务方要么已经自建、要么使用了通用的订单服务，保障如何在减小对业务方侵入的的情况下，将订单接入赔付系统？同时保证同一个订单在交易的整个过程中都可能产生过程中订单？如何用户在小店精选购买某个商品下单，首先在小店的订单中心会有一条订单记录，同时为了方便用户更方便的查找订单，业务方的订单数据会接入手百订单中心，当用户完成支付时，还会产生一条支付记录，如果用户在其他app（如百度地图）发生交易，订单还会进入百度地图订单中心，那么保障如何保证用户无论在那处申请赔付，数据都同步更新，避免出现刷单等情况呢？
从上面的过程中，可以找到保障赔付的三个主要角色：保障业务方、保障平台、手百订单中心（订单聚合平台，保障的合作方）。保障平台和手百订单中心是两个独立服务提供方，不同的业务方接入维度存在差异。加入手百订单中心的业务方不一定加入保障平台，同样加入保障平台的业务方不一定加入手百订单中心。在整个订单赔付过程中，如何让手百订单中心尽量不感知保障业务，从而做到新业务通过手百订单中心加入保障赔付时，手百订单中心可以透明无感知？
网民在业务方下单那一刻，只有业务方能感知当前当前对应的商品或者商家是否已经加入保障计划，所以只要业务方将下单是否订单对应的保障快照信息baoinfo（主要包括：保障为业务方分配的原始sappid，业务方加入保障的维度 objectid，业务方原始订单ID sorderid、当前保障状态等），接下来会在整个订单流转过程中保证保证原始信息baoinfo的透传即可。保障的赔付信息只要挂在原始保障信息上，这样无论网民在什么地方发起赔付，只要订单快照中原始保障信息不变，对应就是同一个赔付。并且只要百度保障和手百订单中心建立合作后，后续加入保障的业务方，只要按照约定将原始保障信息baoinfo给手百订单中心即可完成订单赔付接入保障，整个过程中，手百订单中心都是透明的。
图（9）订单赔付实现
同时，在闭环订单赔付场景，网民对应赔付体验的要求也是不一样的。因此相对开环场景，订单赔付引入了系统自动判断逻辑，如48小时发货，只要网民申请，系统判定商家确实晚发了，直接给网民赔付，不需要人工审核。对于赔付成立，财务打款，开环场景，采用财务统一打款，需要网民提供相应的银行卡信息、经过财务审核、财务审批打款，打款周期长，在订单赔付场景中，百度保障引入了快捷打款能力，直接通过提现小程序实时给用户打款。
四、电商场景实践
电商场景的典型代表就是小店优选。
小店优选商家通过缴纳保证金加入百度保障基础保障计划，商家根据自己的行业类目选择相应的高阶保障项，并在商品详情页进行保障项露出，提升买家对商品的信任感，从而促进下单转化，当商品质量出现问题、或者商家没有遵守承诺（如没在承诺的48小时内发货），可以直接在手百订单中心或者小店订单中心发起赔付。从实验数据可以看出，商品加入保障计划后，可以在很大程度上提高商品详情页的提单转化率。
图（10）小店优选保障实践
五、发展与思考
未来，在业务上，我们将持续深耕电商类、服务类、医疗等垂类行业保障，让用户在百度获取的内容和服务更加可信。在技术上，信誉保障研发团队会通过引入更多的系统自动判定手段来提升保障的处理效率，进一步减少运营成本，同时提升网民的申保体验；在数据方面，重点建设保障B端数据能力，让百度保障成为赋能B端的强有力的工具。