导读：百度保障为百度外部各产品线的商品、服务提供保障能力。当网民购买有保的商品或应用有保的服务，因为商家产生欺诈或者商家未兑现承诺时，能够通过保障平台发动赔付申述，失去相应的抵偿。同时，百度保障为商家提供保障增值服务，商家退出百度保障打算后，能够申请相应的高级保障标签，晋升下单转化率。百度保障次要服务于两个外围场景：开环场景和闭环场景。百度保障的业务指标在于：围绕百度商家提供的内容和服务，构建良币驱赶劣币的百度信用生态，让用户释怀的在百度获取信息和服务。

全文 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 端的强有力的工具。

举荐浏览 ：

视觉 Transformer 中的输出可视化办法

深刻了解 WKWebView (渲染篇) —— DOM 树的构建

深刻了解 WKWebView（入门篇）—— WebKit 源码调试与剖析

GDP Streaming RPC 设计

百度 APP 视频播放中的解码优