乐趣区

关于前端:Shopee商家数字商品可配置系统设计与实现

本文首发于「Shopee 技术团队」公众号,摸索更多 Shopee 技术实际

 目录

1. 背景
2. 新增商品的演进之路
    2.1 商品的初代上架流程
    2.2 商品上架流程革新
3. 新增商品可配置零碎
    3.1 如何设计配置化零碎
    3.2 流程配置模块
    3.3 信息配置模块
    3.4 利用侧渲染流程
    3.5 可配置化零碎——Flow
4. 总结 

繁冗的商品上架流程占用了研发人员大量的精力,为了解决这一问题,Shopee Merchant Services 团队依据业务流程设计了一套低成本的商品上架的可视化配置计划,并围绕该计划逐步形成了以经营为核心的商品上架流程,极大地晋升了商品上架的效率。

本文心愿通过介绍这一业务侧的优化实际,为产品、研发以及经营等人员带来启发,思考是否能够通过类似的计划来进步产品迭代的效率,从而配合业务的疾速倒退。

1. 背景

2019 年,Shopee 在东南亚某市场公布了一款线下商家服务 App,该利用提供了话费、流量、游戏点卡、水费、电费等一系列数字商品的购买服务。商户可通过该平台帮忙不具备线上领取能力的集体消费者进行各种业务充值或者数字商品的购买。目前,该 App 已上架百款商品,服务于海量商家。

截至 2021 年,该 App 相继上线多个东南亚市场。与此同时,商品的品种也在迅速减少, 如何可能以最快速度、最低老本上架商品,并保护好多种商品的购买流程以及多样的信息(商品信息、订单信息、小票信息等),成为了研发过程中面临的重大挑战。

2. 新增商品的演进之路

2.1 商品的初代上架流程

在业务上线初期,咱们以上架一个新品类商品为例,能够将其流程演绎为如下几步:

  • 通过 Admin 端上传运营商以及商品信息,后端需当时在 DB 中写入品类数据;
  • 前后端进入我的项目开发阶段,开发过程中,后端须要与第三方服务联调商品的购买流程;
  • 在 Admin 端创立一个商品的购买入口,该阶段前端需手动绑定入口跳转页面,后端须要在 DB 中将入口与商品进行关联;
  • 所有准备就绪,前后端进入联调阶段,将商品的购买流程买通,实现商品上架的研发流程。

上述新商品的初代上架流程看似清晰,但在理论利用中,也暴露出一些毛病,并带来了昂扬的沟通老本。经剖析,问题产生的起因次要蕴含以下几点:

  • Admin 端的操作须要各方提供信息来共同完成,职责界线含糊;
  • 各方排期不统一,前置依赖未实现,后续进度就会被阻塞;
  • 前后端开发的过程中,波及到多端、多服务项目繁冗的批改。

2.2 商品上架流程革新

通过一段时间的调研与摸索,咱们最终抉择走配置化的计划。先拆解局部流程进行尝试之后,再逐渐迁徙,最终实现了商品上架流程全面配置化,造成了新增商品可配置零碎。

通过可配置零碎,咱们能够在 Admin 端实现对大多数商品的上架操作,负责商品上架的人员也由研发人员向经营人员过渡。因而研发人员不再郁结于商品上架的流程中,转而有更多的精力去做业务服务的反对与代码的优化。

与可配置零碎搭配的,是咱们制订的一套商品上架标准,该标准笼罩了商品上架的全流程,具体规定了从测试、回归再到线上环境的操作步骤,以及各方所负责的模块。这让职责界线变得简洁清晰,沟通也不再是一个让大家感到头疼的问题。

除此之外,咱们还开发了一套商品下单发货流程的预查看工具。借助该工具,能够间接在 Admin 端触发商品购买流程,以测验商品配置的正确性。

3. 新增商品可配置零碎

3.1 如何设计配置化零碎

当初谈到利用的配置化,就会自然而然地联想到当下风行的低代码概念。与可配置零碎相比,低代码的灵活性高,通用性强。然而,思考到各品类商品购买流程高度对立,细粒度的配置化计划只会徒增配置的复杂度,最终咱们抉择将购买流程形象为业务模板的计划来做利用的配置化搭建。

商品类型可基于流程划分为账单(Bill)类与非账单类两种。这两类的次要差别在于:账单类的商品须要在购买流程中展现账单信息,以便让用户进行领取前的确认。非账单类只需在用户抉择具体的商品后间接进入领取流程。

如果仅基于流程进行划分,只须要实现两套业务模板以供配置即可。然而从研发人员的角度看,购买流程雷同的商品间还是存在一些差别,思考到后续模板的可维护性,所以抉择基于这些差别再次拆分为多套业务模板。

在利用侧,基于业务流程的差别形象多套业务模板后,咱们开始思考可配置零碎在 Admin 端的配置实现。

咱们将可配置零碎分为入口模块、两头模块、账单信息模块、订单信息模块、小票信息模块、短信信息模块等六个独立的配置模块。如下图所示,这六个配置模块各自负责一块阵地,最终串联起了整个 App 中商品的购买流程。

另外,这六个模块又能够归类为流程配置模块、信息配置模块两大模块。从模块的设计中,咱们也能够窥见,业务模板在利用侧的实现并不是齐全独立,尤其是信息配置模块所对应的业务模块在所有的业务模板中是共享的。所以如果须要减少业务模板,利用侧只须要开发流程配置模块所对应的业务模块即可。

比照高低两张图,能够发现短少了 Payment Success 流程对应的配置模块。思考到该流程在不同商品间的个性化差别不大,咱们抉择间接将其固化。

说完可配置零碎模块的整体设计,咱们再从商品与配置模块的关系来看。

以订单信息配置模块为例,商品与配置模块之间是“1:1”或者“n:1”的关系。这样,当咱们上架一款新的商品时,如果存在可复用的订单信息配置,只须要将商品与其进行关联绑定即可。

至此,咱们曾经能够看出可配置零碎的大抵轮廓。上面就进入到流程配置模块与信息配置模块中,来看更具体的设计。

3.2 流程配置模块

咱们将入口模块和两头模块的配置演绎为流程配置模块,是因为这两块配置在利用侧流程中扮演着理论业务模板的角色,起着疏导商品购买的作用。

如下图所示,在创立商品购买入口的时候能够抉择一个入口模块进行关联,抉择后能够进行更具体的配置。

两头模块的配置,只须要抉择适合的模板,而后配置该模板所提供的选项即可。

3.3 信息配置模块

咱们把非流程的配置模块归类为信息配置模块,次要起因是这些模块配置的都是向用户提供的商品信息以及订单等数据。因为信息配置模块都大抵类似,所以就以小票配置模块为例,来看看是如何进行配置的。

首先从构造上看,小票配置模块分为左、中、右三局部:

  • 左侧为字段编辑区,能够对字段做减少、删除、批改、排序等操作;
  • 右侧为字段款式编辑区,能够对小票的整体排布进行批改;
  • 两头为预览区,字段以及款式的批改都能够集中反映在预览区域,这样配置会更加直观,能够实时裸露问题,防止重复更迭。

如果仅仅是这样,只能说看上去很美。设想一下,在理论配置中,一张小票十几个字段,每个字段下是一张简短的表单,这不是一件轻松的工作。

所以,为了让配置变得更加简略,思考到不同商品间的小票字段重叠率较高,咱们减少了字段池的性能。这样,在配置一张新的小票时,能够尽可能复用之前的配置,以节约配置老本。

好了,所有配置结束,咱们就能够在 App 中看到配置的小票了。

最初,由表及里,再来看一下小票在利用侧的渲染逻辑。

如下图所示,申请通过网关先达到 BFF 两头服务后,由两头服务去获取 CDN 上的小票模板,同时通过订单 ID 去获取对应商品的小票数据。待 HTML 模板和小票数据都拿到之后,将数据填充到 HTML 模板中,生成新的 HTML String,返回给 React Native(以下简称 RN)页面,RN 通过 Webview 进行渲染预览,并通过 Bridge 将 HTML String 传递给客户端后,连贯打印机执行打印操作。

3.4 利用侧的渲染流程

理解了可配置零碎,再来看看利用侧如何利用配置信息实现整个商品的购买流程。

3.5 可配置化零碎——Flow

最终,咱们将所有的配置模块集成在一个流程下,并将商品与配置的关联关系转移为商品与流程的关联关系,称其为 Flow。另外,为了实现跨环境的配置迁徙,咱们还实现了疾速导入导出性能,保障通过配置上架的商品能够稳固地测试上线。

至此,新增商品可配置零碎就曾经全副介绍结束了,不晓得各位有没有思考过这样一个问题:“难道就没有什么流程非凡的商品吗?”。的确,是有的。针对非凡流程的商品,还是须要前后端进行开发,然而因为其流程非凡,复用率简直为零,所以并不会思考形象为业务模板。那非凡商品要怎么融入到可配置的流程中呢?

其实,咱们只须要关联一个非凡的自定义入口,这样就能够进入到这个非凡的商品购买流程中。另外,因为可配置零碎以及利用侧业务模板在实现上是模块解耦的,如果该商品须要,咱们仍然能够接入账单、小票等配置模块,应用可配置的能力。

4. 总结

为了扭转凌乱的商品上架流程,咱们开始摸索配置化的上架计划,从商品购买流程拆解,到逐渐实现与流程绝对应的入口配置、两头配置、账单配置、订单配置、小票配置、短信配置几大模块,并最终聚合为全流程的新增商品可配置零碎。至此,在历经了两个版本的迭代之后,可配置零碎已初具雏形。

与此同时,咱们还制订了商品上架标准,使得各方职责清晰;开发了辅助校验工具,进一步晋升了商品的上架效率。

可配置零碎上线之后,前后端根本无需再进行编码,产品经营能够间接在线上编辑以及新增商品,流程的整合也给测试人员带来了更优的测试体验。通过初步统计,研发阶段的商品上线效率整体进步了 75%。

新增商品可配置零碎扭转了初代凌乱的商品上架流程,让商品上架变得简略、灵便。将来,咱们会持续秉持降本增效的理念,优化可配置零碎的体验,健全商品上架的标准机制,更好地服务于业务的倒退。

本文作者

Liqi、Xiaolong、Yulong,前端开发工程师,来自 Shopee Merchant Services 团队。

退出移动版