有赞零售· 跨平台订单优惠计算

1.2 业务场景

在线下开单收银场景，零售提供了多种客户端供商家选择，买家使用的端：门店小程序、自助收银大屏版。商家收银的端：PC 收银(浏览器/桌面)，Phone/Pad 收银端等。

总结下零售线下场景优惠计算的 难点和痛点 ：

属于 交易核心逻辑 ，涉及到资产，如果计算出问题，容易对商家或买家造成资损

营销活动较多，迭代速度快，业务逻辑复杂 耳熟能详的有：限时折扣、优惠券、满减送、买一送一、打包一口价、积分抵现等。为了促进消费，营销玩法会不断地更新，同时原有的活动也一直在往细致化发展，贴合商家使用需求

开发量冗余 业务场景对应的客户端多，使用的技术栈也是不同的。部分端实现了本地计算，部分端暂时依赖后端优惠计算

各端实现细节可能不一致 ，维护起来费时费力

如果发生计算错误，很难及时修复问题

1.3 前世

零售移动端团队在每次营销项目迭代中，Android、iOS两端小组都需要投入开发资源，影响团队整体的项目迭代效率。

于是，移动端团队基于 JavaScript 开发了 第一版跨平台订单优惠计算 ，它统一了 Android/iOS 订单本地优惠计算和优惠详情展示的逻辑，还有动态热更的能力。

在后续迭代中，后端也希望能够接入这套能力，并共建这套系统，但是发现了有一些问题急需解决。

计算过程中依赖了 共享全局变量，有并发问题 ，无法同时计算多笔订单，对后端使用场景来说，虽然可以通过多个执行引擎实例来实现并发安全的计算，但此方案实属下策

没有领域模型 ，营销活动模型各不相同，实现的计算逻辑差异较大，导致代码重用度不高

没有设计活动互斥 ，互斥逻辑是硬编码在活动处理类中的

订单的数据结构冗余 ，商品和活动模型应该是独立的，但实际上商品模型下挂载了可以使用的活动，这样即增加理解成本，又增加了数据序列化的开销

没有类型约束，开发起来，代码提示全凭记忆 ，对于初次接触该系统的人，代码理解成本较高，开发新功能也束手束脚

处理逻辑繁琐，在商品特别多的情况下， 性能不太理想

2.0 设计目标

新的方案需要满足以下几种需求:

能够提供给现有场景的多个端使用，已有的活动都需要支持。

统一的模型设计。商品和活动要有对应的模型，一个活动一个模型是不能接受的，这样代码复用率太低。

对后续的需求迭代,能够很轻松的扩展原有功能或新增营销活动
多个端的使用差异需要满足

性能优化。就算在商品特别多的场景，也不能出现耗时长的问题。

其实，最重要的还是提升研发效率，相同的营销计算逻辑不需要在多端都开发一遍。

2.1 重构还是重写？

方案 1: 重构活动模型成本巨大，改动贯穿所有文件，加上动态语言一时爽。

方案 2: 从长远看，用 TypeScript 重写对后期开发效率提升会很大，同时也会大大降低代码理解成本。 ✅

简单介绍下 TypeScript 特点:

提供了静态类型，编译时静态类型检查可以避免不少低级错误

对代码重构和补全提示友好

多人协作起来，降低了沟通成本

可以编译成


    JavaScript

运行在各端

2.2 静态类型玩得更好

在 Native 这边的泛型，经过序列化之后，在 JS Runtime 反序列化得到的是普通对象，没有了 自身行为和类型约束 。

当然这不是语言层面的问题，但我们仍然可以设计得更完善。

我们可以通过 合并对象 的方式，让对象实例既有数据，又有行为和类型检查。

2.3 业务模型分析

2.3.1 营销活动模型

“满 300 减 30、2 件 8折，3 件 7折、全场 100 元任选 3 件……”

其实营销活动本身最核心的三个部分是：

门槛如需要满足多少金额或商品数量，是否原价使用等

优惠如直接打多少折，减多少钱，或者 3 件 100 元这种指定金额的玩法

基本信息 包含了活动唯一标识、活动类型、活动名称

仔细想想，对这个门槛和优惠扩展一下，然后组合起来，就是一个新的营销活动玩法。

除此之外，营销活动优惠计算处理逻辑还有：

计算优先级 多个活动计算优惠时，需要有优先级定义，然后按照顺序计算使用

使用策略 多个活动都可以使用时，要考虑它们之间的关联关系，互斥，可叠加，选最优

作用维度 单个、多个商品使用，或者整单立减

无侵入的活动互斥

为了避免活动互斥的逻辑硬编码在活动处理类中，在执行营销活动计算的处理方法时，排除掉了已经参与互斥活动的商品，这样活动处理器不用感知活动互斥，只需要关心自己的处理逻辑。

大致代码如下：

// 活动互斥容器
class PromotionMutex {  
  test(a: PromotionType, b: PromotionType): boolean;
const promotionMutex = new PromotionMutex();
// 活动优惠计算处理
abstract class Processor<T> {  
  process({ skuWrappers }) {
    // 获取处理器关心的活动类型
    const type = this.getType()
    // 迭代SKU列表， 筛选出可用的商品(没有参与互斥活动)
    const availableSkuList = skuWrappers.filter(
      sku =>
        !sku.allAvailablePlan.some(plan =>
          promotionMutex.test(plan.type, type)
    // 交给处理器
    this._process({ availableSkuList });
2.4 整体设计
2.4.1 分层设计
主要把外部传入的数据做整理转换。 这部分是可选的，可以在Native层就做好适配，不同的端可以通过扩展 Entry来实现自己的处理。
核心计算层
构建领域模型，实际是为输入层的数据增加了自身能力的处理逻辑。如商品应有的能力：使用改价价格、计算总价、拆分一部分数量出来、应用优惠等  
将合适的商品和活动交给处理器，计算出优惠结果
结果导出层
Native端不再需要做多余的模型转换，减少了很多工作量。JS 这边针对不同场景，数据直出。 JS 做起来简单且合适（拥有所有数据）
例如：移动端需要的不仅仅是订单优惠详情，还有移动端两端之间约定的渲染模板（什么地方用啥颜色,字体大小等）
通过扩展输入层和结果导出层，共享核心计算层的方式，满足不同端的业务场景需求。
2.4.2 核心类图
2.5 细节设计
2.5.0 写在前面
总结下几个设计原则
领域模型应该拥有自身的能力，而不是交给XXXManager处理
内聚的模型，代码复用率很高
增加中间层，解耦活动模型变化和计算逻辑，提升扩展性
多用组合。compose(A,B) => Foo, compose(A, C) => Bar
避免使用扩展字段（字典），看起来大而全，实则并不能节省开发量，还浪费了类型检查，能明确的字段就直接定义出来
通过包装原有数据对象的方式，为其添加能力，始终不会修改源数据。
2.5.1 内聚的模型
将核心逻辑放在对应的模型上，模型聚焦自身能力，隐藏实现细节，简化外部的使用。
这里举几个栗子：
商品模型：除开商品自身的数据，应提供
计算商品总价的能力、隐藏改价、商品单位、附加属性的计算逻辑
应用SKU级别优惠的能力、隐藏使用优惠之后，价格变动的处理
门槛模型：
SKU 级别门槛提供：商品能否使用优惠、隐藏全选、部分选中、反选和无码商品的逻辑
组合级别门槛提供：生成商品统计概要之后，是否满足了要求，凑单还需什么或者已经超过门槛了多少倍
优惠模型: 提供 计算应该优惠多少金额的能力, 隐藏打折,减钱, 指定价格, 抹零这些优惠方式
// SKU的包装类
class SkuWrapper {  
  // 应用SKU级别的优惠方案
  applySkuPlan(skuPlan: SkuPlan);
  // 计算SKU的总价
  reCalcTotalPrice();
// 对一组商品参与活动的统计
interface ItemStats {  
  // 数量
  totalCount: number;
  // 价格
  totalPrice: number;
  // 使用原价？
  useOriginPrice: boolean;
  // 可以参与商品的列表
  suitableSkuList: SkuWrapper[];
  // 源数据
  sourceSkuLit: SkuWrapper[];
// 活动门槛
class Condition {  
  // 包含 SKU
 isContains(sku:Sku);
// 组合级活动的门槛
class CombineCondition extends Condition {  
  // 是否满足门槛
  hasMeet(itemStats: ItemStats);
  // 超过门槛多少倍
  overTimes(itemStats:ItemStats);
  // 还缺多少满足门槛
  calcRemainValue(itemStats: ItemStats);
// 活动优惠
class Preferential {  
  // 计算优惠价格
  calcPreferentialPrice(originPrice: number);
通过这些核心模型的设计，处理一个 SKU 级别活动将变得非常简单，核心代码不会超过20行, 大致如下:
_process({ skuList, promotions }) {  
  // 迭代活动
  promotions.forEach(p => {
    // 取出活动门槛和优惠
    const {
      conditionPreferentialPairs: [{ condition, preferential }]
    } = p;
    // 迭代SKU列表
    skuList.forEach(sku => {
      // 如果门槛包含SKU
      if (condition.isContains(sku)) {
        // 计算优惠后的价格
        const preferentialPrice = preferential.calcPreferentialPrice(
          sku.salePrice
        // 生成优惠方案
        const plan = {
          preferentialPrice
          // other properties
        // 应用SKU级别优惠方案
        sku.applySkuPlan(plan);
2.5.2 处理器抽象模板类
对于不同的活动，需要实现活动处理模板类中的抽象方法：
关心的活动类型  
处理活动数据（基础信息 + 门槛 + 优惠）到活动泛型的映射  
处理自身活动泛型和商品，生成和应用优惠方案
abstract class Processor<T> {  
  abstract types(): PromotionType[];
  abstract ownModelMappings(promotion: Promotion): T;
  abstract _process(ctx: ProcessorContext<T>): void;
活动模型的扩展性：各个活动总是有差异的，不需要全部按照一个固定的模型去设计。把通用的部分定义出来，允许出现特性，同时不会对外部传入的数据做限制。
这里主要通过增加中间层来实现活动模型的扩展性。ownModelMappings()会将数据封装为自身所需的泛型，即使外部活动的门槛或优惠有变化，之前的计算逻辑也不用修改。
例如有这么一个场景：有门槛和优惠关系是 1:1的活动 Foo，定义如下：
// 门槛和优惠比例 1:1
  condition: {type, value},
  preferential: {type, value}
// 优惠计算处理
class FooProcessor extends Processor<Foo> {  
  // 将数据转换为活动对应的泛型
  ownModelMappings(p: Promotion): Foo {
    return new Foo(p);
  _process({foo}){
    // do sth
// 门槛模型
class Condition {  
  constructor(c) {
    // 合并数据和行为
     Object.assign(this, c);
  isContains(sku:Sku);
class Foo {  
  constructor(p: Promotion) {
        this.condition = new Condition(p.cs.condition)
需求变更为：多个门槛满足一个即可享受优惠。那么，其实只需要扩展原有condition的封装方式，实际对原来的计算逻辑没有任何影响。
// 门槛和优惠变更为 n:1
  conditions: [{type, value}, ...],
  preferential: {type, value}
// 一个门槛满足即可
const anyCondition = conditions => ({  
  isContains: s => conditions.some(c => new Condition(c).isContains(s))
class Foo {  
  constructor(p: Promotion) {
    // 活动门槛的匹配方式修改为 anyCondition 即可
    this.condition = anyCondition(p.cs.conditions)
2.5.3 商品活动匹配
一个商品能不能使用活动的优惠，主要有以下几种匹配方式：
SPU 级别（商品 ID）
SKU 级别（商品 ID + SkuID）
原价才能使用
原价SPU 级别（商品 ID）
原价SKU 级别（商品 ID + SkuID）
非称重商品才能使用
通过以上的几种情况可以看出，如果纯粹按照需求来开发这块功能，会有很大的冗余。为了减少重复开发量，使用组合的方式来实现
// 定义匹配函数
type Matcher = (condition: Condition, sku: Sku) => boolean;  
// 原价才能使用
const originPriceMatcher = (condition: Condition, sku: Sku) => true  
// SKU维度标识匹配
const skuIdentityMatcher = (condition: Condition, { goodsId, skuId }: Sku) => false  
// 组合匹配
const composeMatcher = (a: Matcher, b: Matcher): Matcher => (  
  condition: Condition,
  sku: Sku
) => a(condition, sku) && b(condition, sku);
// SKU维度标识匹配且使用原价
const originPriceWithSkuIdentityMatcher = composeMatcher(originPriceMatcher, skuIdentityMatcher)  
2.5.4 性能优化
对于系统的性能优化，做了几点微小的事：
简化输入输出数据结构，减少边界开销
尽量避免深度复制，尤其是结构层次深的对象
选择合适的算法，通过剪枝的方式，缩小计算量。在商品特别多的情况下，时间复杂度依然能保持常数阶
以下是iOS客户端生产环境采集新老计算耗时的数据统计。为了避免影响观感，去除了极端场景下老版本计算超时的记录
2.5.5 测试覆盖
开发一个项目，测试代码是必须要有的，更何况是涉及到资产，一定要稳。
除了在开发功能阶段编写的单元测试，测试同学还提供了一系列核心用例，加上线上真实订单计算场景的数据，都补充到了集成测试当中。
项目的测试率覆盖如下图：
3.后端计算场景
3.1 JavaScript 运行环境选型
J2V8  Google V8 高性能 JavaScript 引擎的 Java 封装
Nashorn JDK 内置轻量级高性能 JavaScript 运行环境       ✅
3.2 热更新
后端服务感知到有新版本的 JS 发布，需要创建新的ScriptEngine，并加载 JS 文件，然后通过静态的订单数据预热，预热结束后替换掉老的版本，对外提供服务.
值得注意的是:  假如服务正在使用 ScriptEngine 处理计算，同时又有新版本发布，创建了新的ScriptEngine，此时直接暴露出去使用，会导致脚本未加载完成的错误。所以需要 ScriptEngine 所有准备过程(创建, 加载脚本和预热)封闭在工厂方法内，准备阶段完成，得到的就是完全可用的 ScriptEngine。
3.3 版本发布
各端的版本发布流程大致相同：
将工程通过 webpack 以区分 Entry 的方式进行打包，并上传至内部文件服务器  
在发布管理页面操作，创建一个新的版本，绑定文件下载地址  
将新的版本信息发布到配置中心  
当前环境的服务端感知到配置变化，去文件服务器拉取脚本  
加载新版本到计算服务中，预热，替换老版本，开始对外提供服务  
当前环境确认服务稳定，同步至下个环境。跳转至 4  
当前环境服务不稳定，通过配置中心历史记录回滚。跳转至 4
方案 1：最新版本兼容所有老版本，需要很多feature-flag。历史包袱会越来越重，维护成本太高了。靠人脑去维护版本的兼容是不可靠的
方案 2：服务端按需加载相应版本在内存中，使用请求对应的版本计算。 无历史包袱，内存占用会越来越大         ✅
3.3.3 内存压力
先看看目前的 JS 文件大小和内存占用情况，JS 编译到 ES5 之后，文件大了一倍多。文件大小约187K
创建了 2 个计算引擎，加载完脚本占用内存 22.2M。经过粗略的计算，JVM ScriptEngine本身占用约 3M，加载一个 JS 计算脚本需要 7M 左右的内存成本
可以通过 作用域隔离 的方式，分离不同的版本。 第三方依赖的包，是所有版本共享的。前提是后面依赖不会有变化，以订单优惠计算的业务来讲，不会需要新的依赖了。
优化之后，加载了 11 个版本。 内存占用 13M，除去JVM ScriptEngine占用的 3M, 加载一个 JS 计算脚只需不到 1M 内存成本。
结合目前的各端发版周期和版本覆盖率的情况来看，后端按需加载对应版本，不会有太大的内存压力。
4.已经遇到的问题
4.1 版本管理
一个代码库，多个平台发布。一般开发新功能，先拉特性分支，开发结束后合并到master，然后用 master来发布版本。但是当两端的开发需求同时进行，想要发布的内容，时间节点也不一样。那么代码如何合并、发布就是个问题。目前采用的方式是，代码仍然合并到master，各端拉发布分支的方式去发布。有新的特性或者修复，可以摘取过来，然后定期和master同步。缺点就是端的负责人需要关注新代码的合并，需不需要合并到发布分支，有没有冲突问题。这种方式只能算折中之举，后续还需要继续思考和探索如何处理会更好、更省事。
4.2 风险
收益与风险总是并存的。各客户端统一的核心逻辑是：开发一次，到处运行。这样可以很大程度上提升迭代速度和一致性。但是，如果有新功能开发，通常需要评估对不同场景的影响，回归核心用例确保稳定性。虽然系统本身有单测/集成测试覆盖，但依然增加了测试同学的工作量。庆幸的是，随着客户端自动化测试和后端沙盒录制回放的用例覆盖率增长，风险和工作量会逐渐减小。
5.总结与展望
截止目前，移动端和后端都已经稳定上线，投入使用。也就是说，有赞零售所有的线下收银场景都使用了这套计算框架。后面需要做的是，将自身平台有能力，但目前依赖后端计算的场景（PC 收银、自助收银大屏版)，集成这套计算框架。实现本地计算，优化用户体验。
对于上线后近期的产品迭代，目前的模型设计和扩展性能够优雅的实现需求，如在「营销叠加互斥项目」中，对业务来讲属于大改的，其实对订单优惠计算的影响很小，很容易就实现了，得益于设计之初就将使用策略与计算逻辑分离。
在今后的迭代中，希望能保持项目的代码质量和良好设计  (附上邮箱 [email protected] 可内推、聊技术和代码整洁)
                    欢迎关注我们的公众号