撮合前端平台在低代码平台的落地实践 | 京东云技术团队

在京东技术的发展当下，不同的业务线，不同的区域，甚至于很多触达消费者的端，正在被中台架构能力所支撑。大家都很清楚，中台建设能够带来技术的规模化效应，具有提高业务协同、加速创新和交付速度、提高系统稳定性和可靠性、降低成本和支持业务快速发展等优势。

中台架构往往和领域产品有密切的关系，领域产品是在京东体系中，处于前台和共享业务域之间，基于标准理论标准，为实现某个特定商业场景、而提供的一组业务活动能力，接入团队可以通过复用领域产品的能力，达到快速实现业务需求的目的。

基于传统认知，前端产品直接触达消费者，往往具有高度的定制化、需求变更频繁等特点，要求具有很好的动态性, 能够满足不同客户的需求。那么能否建设类似的前端中台产品，我们姑且称之为“前端领域产品”，实现接入团队端到端能力复用呢？我们在撮合业务线中进行了一系列思考和探索。

架构设计

左图展示了实现前端领域产品之前业务线的接入模式：各个业务线独立对接撮合中台，需要各自搭建前端平台（端）。右图展示了在撮合中台和端之间，嵌入了前端领域产品（后文中统一称为撮合前端平台），以一套MVP标准版驱动多种业务形态接入，对各个业务线提供前端支撑能力，提供接入撮合的基础能力和业务能力供业务方使用，业务接入后不再需要自己搭建前端平台，而是作为撮合前端平台的一部分直接使用，这样就大大减少了开发成本。

作为一套标准领域产品，撮合前端平台应当具有如下特征：

能力隔离：实现不同业务接入的数据隔离、业务形态隔离
标准化：对撮合业务进行模型抽象，对流程不同环节中的业务提供标准组件
兼容性：不同业务线之间能够实现技术通用和复用
易扩展：新业务快速接入，不同业务域具有一定的定制化能力

技术方案

撮合业务可以抽象为多租户接入模型，在数据隔离方面主要参考交易中台的四要素模型，四要素包含租户（Tenant）、流量场（BU）、子渠道（Channel）、用户终端（UA），主要应用于多租户、多流量场、多销售渠道、多端的业务场景。

	租户（Tenant）	流量场（BU）	子渠道（Channel）
控制方	领域产品	领域产品	接入方
载体	应用/页面	页面	组件

撮合前端平台总体采用平台和接入方共享共建的方式使用：

针对租户级别的差异性，我们考虑使用应用或页面的方式进行承载，例如撮合前端平台划分为3个基础应用，分别为买家端、商家端和运营端，分别承担撮合询价、报价和管理的角色。在新业务接入时，若与基础应用能力差异很大，则可基于基础应用快速搭建子应用接入的方式；否则可采用基础应用内新建页面的形式。
针对场差异性，使用页面的方式进行隔离承载，由领域产品提供抽象的业务闭环能力，例如询价能力、报价能力，由接入方进行使用。
最后针对场内的细微差异，接入方可通过页面/组件暴露的配置化接口进行配置的方式实现。
若撮合前端平台能力不足，则接入方也可通过平台提供的能力自建组件进行能力补充。

低代码平台与产品形态契合度高、设计风格统一，能够支持业务快速运维部署，我们认为这套业务模型在低代码平台上进行落地更为高效，因此在技术选型的过程中选择了水滴低代码平台进行撮合前端平台的可视化搭建，充分利用低代码平台的内置能力，例如表单表格、权限管控、微前端等。基于低代码平台能力和底层撮合中台的能力，我们针对撮合业务形态搭建了完整的业务链路。

技术加速

在2022/12我们着手开始搭建撮合前端平台MVP版本，2023/2完成专项视觉优化改造，并在2023/3规划新业务接入。在大促前后，将技术架构进一步改良，驱动这种创新能力在新业务接入中进行赋能，有利于推动撮合交易业务增长。在新业务的接入中，识别到业务的较大差异，对原有基于SKU进行撮合的MVP能力进行了较大改造，实现了基于SKU和SPU进行撮合的两套业务体系。

在项目搭建的过程中充分利用低代码的页面搭建能力，实现了33个页面的标准页面开发，并完成如下通用化改造：

场参数和环境参数：采用url传参的方式，实现四要素参数和环境参数的注入，实现数据和环境自由切换。
统一拦截器：将分散在各个表单和表格的接口进行识别和整合，通过统一拦截器进行处理，封装公共逻辑如接口异常处理、公共参数拼接等，对接口调用方式进行了精简。
能力复用：对功能进行更细粒度的拆分和重组，如将询价单和商品信息剥离开，询价单操作和询价单展示剥离等，新增页面表头操作组件、spu查询组件、spu卡片等组件，并兼容跨场能力。引入描述性列表组件和通用描述协议，实现跨场动态表单配置和渲染。业务组件采用npm包插件的方式引入，可以在低代码页面引入后使用。
微前端改造：支持业务线进行旧工程微前端改造，实现低代码页面以微前端方式嵌入。