1. 平台定位
平台定义： 到店供应链平台是为服务零售行业提供信息化管理能力的平台
平台用户：
- 面向商家/代理商以及BD人员，提供服务的线上化制作、维护、管理能力。
- 面向审核/运营人员，提供服务内容审核管理能力（通过、驳回）。
上下游依赖：
- 关键性依赖：依赖商品平台，供应链平台在完成服务商品的上单制作后，将数据推送到商品平台，实现服务商品在C端生效。
- 支持性依赖：依赖客户、商家、销售支持、结算等平台，为服务商品的上单制作过程提供必要的支持。
2. 核心概念与领域模型
2.1 概念分析
服务零售 vs 实物零售
服务的定义
- 服务：消费者在某个 空间 内，在某些 人员 的参与下，通过使用/消耗某些 物品，在一定的 时间 内，进行某项 活动。
- 服务要素：完成某项服务活动所必须的空间、人员、物品、时间。
服务要素分析
| 要素 | 物权特征 | 履约能力管理 | 住宿 | 度假 | 到综 | 到餐 |
|---|---|---|---|---|---|---|
| 活动 | 服务的目的（相比实物零售，有更多行业差异性） | 仅内容描述 | 入住 | 玩法、路线等 | 多样化，取决于服务内容 | 就餐 |
| 时间 | 服务的本质（与实物零售的核心差别） | 库存核心维度 | 跨天连住 | 一天内/多天 | 一天内（可跨自然日） | 一天内 |
| 空间 | 到店类服务：交换使用权（一段时间内）上门类服务：无（归属消费者/公共场所） | 容量库存管理可跨服务共享 | 房间 | 景点（开放共享） | 房间、场馆、场地等 | 无（实际会占座，目前无业务场景） |
| 人员 | 协同类服务：交换使用权（一段时间内）自助类服务：无（消费者自己） | 人数库存管理可跨服务共享 | 无 | 无 | 技师 | 无 |
| 物品 | 复用类服务：交换使用权（一段时间内）消耗类服务：交换所有权（交易/履约发生时立即变更归属） | 数量库存管理可跨服务共享 | 无 | 无 | 设备、设施、耗材等 | 菜品 |
相比与实物电商，服务电商在库存及履约能力管理上更加丰富和复杂，尤其是空间、时间、物品这三种服务要素可以在不同的时间维度上，被不同的服务活动共享，可以被独立管理，因此服务电商在商品等核心概念的建模上，与实物电商存在较大不同。
我们把空间、人员、物品这几种决定了服务履约能力的要素抽象为 交易****资源 的概念，进行统一的管理。
交易形态对服务的影响
服务电商的复杂之处还在于，不同交易形态呈现的服务特征是不一样的：
- 预订： 下单时提前锁定资源，时间是强约束，占用了资源一段时间的使用权。
- 点餐/提货： 下单时提前锁定物品，时间是弱约束，物品的所有权发生了变更。
- 团购： 下单时不锁定资源，没有时间约束，相当于购买了服务的兑换资格。
预订->点餐/提货->团购，服务的特征逐步由强转弱。
2.2 商品模型
实物零售对应制造业，制造商在生产商品的同时，也掌握了定义产品规范的话语权，天然具备标准化的特征，加上经过亚马逊、阿里等平台多年的沉淀，业界已经在事实上形成了一套基于 SPU（标品）->Product（商品）->SKU（规格组合）的标准商品模型。
服务零售由于生产和消费过程的一体化，且服务过程中掺杂了人员、空间、工具物品的差异性，天然不具备标准性的特征，加上不同服务细分行业对于服务关键信息的定义和描述存在巨大差异性，因此很难定义出一套标准的服务商品模型适用于所有行业。
到店各业务对商品的定义
为了解决这个问题，我们尝试从交易视角出发寻找服务商品的建模思路。
交易单元： 能明确服务 定价因素 的信息的集合，是下单的最小必要信息集合。但由于服务的定价因素中存在一些与数量、时间、规则等相关的部分，因此交易单元很难具备稳定性，并且容易数量爆炸。
服务定价因素
是否为价格因素，关键要看是否形成了价格差异性
| 价格考虑点 | 特征 | 空间 | 人员 | 物品 | 活动 | |
|---|---|---|---|---|---|---|
| 规格类 | 成本差异/稀缺性 | 静态，可以枚举（固化设定） | 类型、级别、大小 | 级别、年龄 | 类型 | 形式、类型 |
| 数量类 | 乘数/阶梯定价 | 动态，不可枚举（规则计算） | 间数 | 人数 | 个数 | 次数 |
| 时间类 | 稀缺性 | 日期：- 一日：具体日期 |
- 多日：开始日期+结束日期/持续天数时段：- 场次型：可以枚举，有明确的开始时刻+结束时刻，理论上不能中途退场
- 自由型：不可枚举（虽然有明确的范围，但数量过多，且自由度较高） | | | | |
最小交易单元（SKU）： 交易单元中哪些 规格类（可枚举） 定价因素 ****的组合。
- 通过提取可枚举的因素，使得SKU自身具备了可枚举性，让SKU的划分原则变得清晰和稳定。
- 不可枚举的信息作为填单信息，落地在订单上。
商品（Product）： 一组明确了 结算主体、便于用户决策、具备部分共性 ****的SKU的组合。
- 特点：划分原则不够清晰，具有一定灵活性。
- 目标：通过降低信息冗余提升上单效率，通过特征合并降低认知负担。
- 原则：符合业务特征和用户的自然认知。放弃了强制统一标准化，但针对不同细分行业，可以进行局部标准化（待进一步细化梳理）。
商品的分层模型定义
在平台化实践过程中我们发现，模型的抽象度与业务的匹配度是一对矛盾体，不同的层级存在不同的诉求：
- 领域模型是基于业务概念进行的抽象建模，会随着对业务认知的迭代而发生演进。
- 存储模型更偏技术，关注数据结构本身，存储模型变动成本较高，因此更加关注稳定、通用、业务无关性，需要比领域模型更泛化抽象。
- 接口模型最贴近具体场景，过于抽象和复杂会极大增加业务使用负担，特别是库价模式本身大而全，但业务可能只用到了其中很小一部分。我们的思路是提供定制化的SDK来提升业务对接体验。目前在到综预订业务上进行了探索和使用，有效降低了业务接入费力度。
2.3 资源模型
资源实体在定位上和商品处于同等地位，是供应链平台内的两大核心实体。资源模型本身比较简单，只有一些基础字段+KV扩展属性。资源可以绑定库存、价格、规则，对交易环节产生影响。
资源分为两种类型（业务上的概念，技术实现上没有区分）：
交易/履约资源
-
功能：空间、人员、物品等服务要素，本质上体现的是商家的 服务履约能力，这种履约能力通常可以用 库存 的概念来承载。
- 注：对于开放共享型的空间（度假景点），当需要在时段上进行可承载人数容量管理时，可以抽象出时空维度叠加后的资源（例如：景点上午场/下午场），从而进行库存的管理。
-
定义：交易资源就是对这些 服务要素的技术抽象，描述了服务要素的最小可被管理单元。商家实际经营时，可以通过资源对这些服务要素进行管理。
交易资源的应用场景：
信息资源
- 功能：对于服务要素中的活动，需要通过文描的方式来向消费者传达内容。当多个Product包含的活动内容具备共性，甚至能形成标准时，这些文描内容就可以被提取出来单独管理。
- 定义：信息资源就是对这些 可复用（标准化）的活动内容描述的技术抽象。
信息资源的应用场景：
2.4 主体库价规模型
1）库存、价格、规则
对于库存价格规则来说，由于服务的本质是时间，因此不同业务在时间上的稀缺性特征会体现到库价规上。
- 到综玩乐：通常是周一到周日每天可以有不同的库价。
- 酒店：不同的日期区间内有不同的库价，节假日和平日就有很大差别。
- 门票：每一天都会有不同的库价并且可以随时调整。
- 团购：因为可以随买随退，通常就是一个固定的价格和库存甚至是无限库存。
我们将时间按跨度和循环两个维度进行拆解，得到可枚举的有限组合，让库价规在时间维度上可以进行标准化。
按时间跨度：
- 普通模式：在所有的时间范围内，设置相同的库价规。
- 区间模式：在一段明确的开始日期+结束日期的范围内，设置相同的库价规，可以有多个区间段。
- 日历模式：为每一个明确的日期设置库价规，精度到天。
- 日历时段模式：为每一个明确日期下的某个精确时间段（开始时间+结束时间），设置库价规，可以有多个时间段，精度到时刻。
按日期循环
- 周循环计划：为每一周的周一到周日设置不同的库价规计划，下一周自动重复。
- 日循环计划：为每一天设置库价规，第二天自动重复。
2）主体（Subject）
由于服务电商以店为中心，在不同门店、不同城市、不同渠道或者其他不同维度都可以有不同的稀缺性，从而产生不同的库价，例如：
- ProductID+SkuID+Platform： 商品的某个SKU在点评APP都售价和库存与美团APP的不同。
- ProductID+SkuID+PoiID： 商品的某个SKU在门店A的售价与库存与门店B的不同。
- ProductID+ChannelID： 商品在渠道A的售价与库存与渠道B的不同。
可以看到，这些复杂因子的组合，本质上是一种库价规的定位器，技术上的实现就是一组具备标识作用的ID的组合。
我们用主体的概念来定义这些不同维度的ID组合后形成的库价定位器。
2.5 过程数据模型
从管理视角看，围绕商品制作过程的生命周期，『商品』的定义在不同的作用域下会发生变化，需要抽象出一些新的概念。
标准上单环节
上单过程数据模型
1）上单流程
一次标准的上单过程可能会经历制作、审核、发布等环节的轮转，且伦轮转过程会发生角色的切换，整个行为是不连续的，因此需要有地方能记录流转过程中产生的相关数据。我们用【流程】来表达并记录一次完整的上单过程。
2）草稿数据
编辑保存过程中，作为暂存态保存的商品数据，可以进行多次重复编辑。草稿会与流程关联，1分草稿数据只会关联1个流程，草稿的生命周期与流程保持一致。
3）提交快照
在提交的时刻创建并固化，用于在后续的审核、发布环节进行数据传递。当进入审核环节时提交快照可以作为审核标的物，当进入发布环节时提交快照作为发布的数据参数。提交快照的生命周期与流程保持一致。
4）正式数据
当前已经生效的最新商品数据，1个商品只有一份正式数据，数据内容与发布给商品平台的C端数据内容保持一致（部分业务有特殊逻辑的情况可以有差异）。
5）发布快照
在发布时刻创建并固化，可作为后续回顾修复操作的数据来源。目前由于发布快照数据的完整性和一致率尚不达标，因此并为实际使用起来。
3 平台能力
3.1 能力概述
3.1.1 场景功能划分
1）上单场景
供给能力的核心场景，包括制作、审核、发布这三个关键环节，收口商品所有数据变更写入的请求来源。
2）检索场景
为上单供给过程提供数据的查询和复杂条件搜索能力。
与商品平台检索的边界： 按环节区分，不是按角色区分（B端C端）。供应链平台仅为上单供给过程提供查询检索能力，一旦进入展示交易环节后，所有的检索场景都使用商品平台的接口（包括后续B端的客服、商家履约等环节）。
3.2.1 业务扩展方式
平台通过对各个业务线上单场景的汇总分析，按照场景的通用性和抽象度，提供一套统一的标准上单接口和能力实现，但各个业务间依旧存在差异性，需要有一套机制来应对业务的个性化定制诉求。
目前供应链平台主要有两种方式提供业务实现个性化：
-
接入BPF框架：BPF相关知识可参考：使用文档--业务篇
- 基于插件包的扩展点机制：在平台定义的标准能力范围内，允许对部分逻辑执行细节进行扩展，但扩展语义不能打破原有平台能力定义的标准范围。
- 基于域服务节点的活动编排机制：通过有平台现有能力的重新组合，在平台接口的标准语义功能外，实现更灵活的功能组合扩展。
-
接入SPI扩展点：老的扩展方式，主要在发布环节和检索场景，后续会足部改造并接入标准的BPF框架。
BPF框架核心概念
基于BPF的上单系统架构
3.2 上单场景
3.2.1 对接模式
1）普通上单
标准的上单模式，供应链会落地自有数据，并将发布结果同步到商品平台。主要面向人工上单、系统自动维护变更、有B端管理诉求的直连等场景。
2）直发上单（建设中）
供应链不落地数据，直接将请求转发到商品平台，仅作为上单变更的请求入口。主要面向无B端管理诉求的直连、极简上单等场景。
3.2.2 上单流程
1）流程模式
- 有流程上单：标准的上单模式，会在制作、审核、发布等环节间进行流转，通过流程记录过程数据，支持同步发布和异步发布。
- 无流程上单：简化的上单模式，不会在环节间进行流转，仅支持同步发布，主要用于上单过程简单且对性能吞吐量有一定要求的场景。
2）场景类型
- 编辑场景：有草稿数据，适合会有二次内容编辑的业务场景，流程状态可逆（重新回到制作中状态）。
- 维护场景：无草稿数据，适合没有二次内容编辑的业务场景，流程状态单向流转。
3）唯一性校验
- 数据唯一性：部分业务商品中某些字段信息构成了商品的唯一标识组合，且不可重复，平台提供针对这些标识组合唯一性校验的能力，业务可个性化定制（目前只能通过代码配置，改造完毕后可在扩展点中进行控制）。
- 流程唯一性：部分业务针对同一个商品的某种操作，在同一个时刻只允许存在一个流程，平台提供针对流程操作的唯一性卡控能力，业务可在扩展点中定义如何确定唯一性的规则。
3.2.3 制作环节
1）场景功能
| 编辑场景 | 草稿相关 | 保存草稿：修改当前草稿内容。废弃草稿：取消本次编辑内容。保存并提交：保存草稿后立刻提交。 |
|---|---|---|
| 流程相关 | 提交：确认本次编辑完成，提交审核，若命中免审则直接进入发布环节。撤回：对于已经提交并进入审核环节且尚未通过的流程，取消审核重新回到编辑状态。 | |
| 维护场景 | 商品状态 | 上架/下架：控制商品上下线。设置可见/不可见：控制商品在C端列表、货架等流量入口的露出状态，但通过详情页链接还是可以访问。 |
| 门店关系 | 绑定/解绑：控制商品与门店的关联关系。 | |
| 资源关系 | 绑定/解绑：控制商品与资源的关联关系。 | |
| 库价规 | 调整库存、价格、规则内容，调整库价规日期模式 | |
| 管理信息 | 修改责任BD | |
| 联动变更 | 门店状态及信息变更联动商品变更、客户及合同变更联动商品变更、资源归档联动商品归档 | |
| …… |
2）上单模式
| 上单流程 | 草稿数据 | 提交快照 | 正式数据 | 发布PP | |
|---|---|---|---|---|---|
| 单品上单 | 1个流程 | 1份草稿 | 1份提交快照 | 1份正式数据 | 1次发布 |
| 组合上单（待建设） | 1个流程+多个同步/异步子任务 | 1份草稿 | 1份提交快照（合并） | 多份正式数据 | 多次发布 |
| 批量变更（迭代中） | 1个流程 + 多个异步子任务 | 无（仅支持维护场景） | 各自审核：多个提交快照聚合审核：1个提交快照（合并） | 多份正式数据 | 多次发布 |
| 联动变更 | 1个流程+多个联动异步流程 | 无（仅支持维护场景） | 多份提交快照（独立） | 多份正式数据 | 多次发布 |
3）写语义模型
供应链平台的核心功能是完成商品等数据的编辑制作，由于商品数据信息字段复杂多样，不同场景下涉及的变更字段不同，如果用不同接口表达差异性，会导致接口数量爆炸。
为了解决这个问题，我们采取的方案是用有限的接口覆盖标准的上单场景，同时提供基于写语义模型的通用接口，支持用写模型表达丰富灵活的个性化上编辑功能。
写模型是对读模型（原始模型对象）中的每一个字段进行包装后生成的对象，支持对读模型对象进行相关操作语义的表达。
- Replace语义：全量覆盖（结合类型），或全量替换（复杂对象）
- Update语义：增量更新（对集合元素来说，若不存在则直接新增）
- Delete语义：删除（仅支持结合元素）
通过将每个字段包装为变更指令+变更数据的方式，可以形成一套稳定的写语义模型，以不变的数据结构来应对不断变化的业务场景。
- 使用写语义模型实现的接口我们称为低阶API，能支持几乎所有数据变更场景，灵活度很高，但丢失了业务语义，并且需要理解写模型，有一定的使用复杂度。
- 而面向通用业务语义提供的标准接口称为高阶API，支持部分通用场景，虽然灵活度有限，但语义清晰，使用简单。
高阶低阶API的搭配很好解决了接口膨胀的问题。
3.2.4 审核环节
1）对接模式
- 统一对接审核平台：对接到综审核平台（诞生与到综业务，但定位是可以服务到店所有行业），模式和标准统一，审核功能比较丰富，具备不错的灵活性，建议新业务场景接入走该模式。
- 统一对接Gravity：平台标准化对接 Gravity 系统实现审核流（目前旅行社已经接入），并打通保时洁文字和图片审核能力。
- 业务自建审核对接：对接业务已有的自建审核系统，用于存量业务迁移接入。
2）审核模式
- 人工审核：需要运营人员人工介入审核，通常是先审后发的模式，审核通过后才能继续发布。
- 机器审核：在对接统一审核平台模式下，内部已经打通了对接公司保时洁的链路，可以直接使用；在业务自建审核对接模式下，需要业务自行实现机器审核模式。
3）审核功能
- 单品审核：单个商品提交并审核。
- 聚合审核：多个商品批量提交后，聚合为一次审核，审核通过则各自发布，审核驳回则所有商品都审核失败不进行发布。
- 先发后审：提交后只发出提审指令但不等待审核结果直接发布，后续审核结果通知后通过
3.2.5 发布环节
发布可选能力
- 中断挂起/恢复：上单流程在进入发布环节时可以有额外的校验逻辑（检查依赖的外部商品、资源、合同等是否已到达预期状态)，若校验不通过则本次发布挂起，待后续依赖的外部实体到达指定状态后重新唤起流程继续发布。
- 发布锁检测：避免并发冲突导致数据污染，可以对本次发布涉及变更的数据模块（目前粒度比较粗，正在做细化改造）进行上锁，锁未释放前，其他修改了相同数据模块的流程无法进行发布。
3.3 检索场景
3.3.1 查询搜索
1）实体类型
支持商品和资源两类实体的检索。
2）数据版本
- 当前制作中的最新数据：以正式数据为基础，如果当前商品有进行中（制作中、审核中）的流程和草稿数据，会将草稿数据与正式数据进行合并后返回最新数据。
- 当前已生效的最新数据：仅使用正式数据作为检索的基础数据。
3）检索模式
- 按ID查询：底层依赖DB，支持单个和批量两种查询方式，并可按需指定返回数据模块字段。
- 按条件搜索：底层依赖ES，支持按一定的 and 和 or 逻辑进行搜索条件组合（组合能力受限，避免出现不合理的搜索条件降低ES性能），支持全文关键字检索。
3.3.2 索引构建
1）索引字段扩展
商品实体上可以包含大量扩展属性字段，但其中只有部分内容会成为搜索条件。而ES索引本质上是一张大宽表，只能承载有限的索引字段。
为了应对不同业务检索条件的差异性，通过在索引上与保留不同类型的若干索引字段（ExtStr1, ExtStr2, ExtInt1, ……），并提供字段映射能力，实现索引条件的个性化。
2）索引数据来源
- 标准数据：将商品上的结构化字段固定映射为索引上的固定字段，通常是商品的基本信息。
- 摘要数据：将商品扩展属性里的字段按一定规则进行提取成为索引上的某个字段。
- 外部数据：业务外部系统通过数据对接的方式将内容落地为索引字段，支持全量Pull+增量Push的方式对接。
4 平台架构
4.1 链路隔离
核心目标：1处故障不影响其他业务线
隔离手段汇总
1）存储隔离
主要按业务线（BizLine：比较稳定，除非组织架构发生较大变化）进行隔离，自建 DataSource 组件将请求路由到对应的 DB 集群。
注：目前由于成本管控要求，为了提高资源利用率，新接入业务基本不再新增存储集群，会采用和已有业务线共用存储集群，但 DB 隔离的方案。
2）服务隔离
主要按业务（BizCode）隔离，分为 Test 链路（验证用）+ 业务链路（BizCode） + 中心链路（Default，兜底用），基于 LightSet 和大禹分流组件实现。
3）消息隔离
- 平台内：同服务部署，按 LightSet 链路隔离。
- 平台外：不同业务配置不同 Topic 进行隔离，平台对外发送消息时会进行 Topic 的转换。原因是 Test 链路会同时有多个业务混用无法实现真正的隔离，只能通过建立不同 Topic 进行区分。
