交易履约之产品中心实践

Posted 2023-03-20

作者：京东科技晏银喜、邹成兵、叶浩、张锐、杨贺麟、梁玉、程龙

一、我们是谁？科技产品中心是什么？

1、科技产品中心

1.1、定位

打造科技统一的内外部产品供应链管理系统，支持业务发展及对外输出；核心职责包括建立产品管理标准、统一产品管理和提升产品管理效率。

1.2、发展路线图

科技产品中心系统从2019年开始建设产品库，主要接收金融类产品，逐渐收口科技8套分散的产品管理系统，统一对接各业务线、财务、经分等，现阶段融合了科技各业务线的产品管理能力，

除金融类产品外，还包括京东云产品、保险产品、实物商品等，承接了科技产品委员会对TOB、TOC产品标准建设的全生命周期管理流程。

1.3、功能概览

科技产品中心服务于科技、物流、健康等多个京东集团BGBU，包括产品类目和产品主数据管理、TOB产品定价管理、产品渠道分发以及库存管理，可由内外部系统录入或导入，实现集团视角的产品信息统一。

1.4、优势及特点

我们的优势：拥有5级类目，灵活支持各类产品在类目上的配置及产品在类目上的迁移，同时支持将各级类目作为集团或BGBU进行收入达成、损益经营分析；通过产品模板管理各业务线的产品数据，

产品录入与变更灵活，支持各业务线产品差异化存储和动态扩展，产品字段变更，无需投入研发资源，业务自配置即可完成。

我们的特点：我们针对TOB、TOC不同产品设置不同产品模版，分别管理不同类型产品的字段配置，同一类产品使用同一模版，灵活且不耦合；针对TOB产品可配置计费项和计费规则，

支持产品预付费、后付费、先付费多种付费模式配置；支持渠道、门店、产品多维度的产品库管理和交易，提供丰富的各维度的统计报表。

1.5、我们服务于谁

我们主要服务于科技集团各业务线，为科技各业务线的产品分级制定标准，统一为各业务线产品在各销售端和平台渠道方进行售卖提供产品相关数据支撑，助力业务线展业创收，同时我们也服务于科技财务、经分、风控等

各职能部门，为产品收益结算，成本核算等提供线上化数据。除此之外，我们还和京东零售、京东保险、京东物流等其他BGBU正在陆续建立合作，为集团TOB产品的统一管理提供技术服务与支持。

1.6、应用案例

我们提供统一的产品信息服务，既支持业务开展，又可通过渠道分发的功能将产品信息分发至不同的渠道或者商家运营平台，本案例通过渠道分发功能分发到电销的京音平台，再由京音平台不同的销售场景引导用户转化。

具体实现流程如下图。

二、我们的核心能力有哪些？

1、一张图看懂我们的核心能力

我们通过山海运营平台、大麦运营平台统一维护金融App、云官网、科技星海CRM等多渠道销售的产品数据，其核心服务能力包括统一产品类目、差异化产品管理、多维度库存管理、定价管理和渠道分发管理。

下图为产品中心产品核心能力输出图谱。

2、类目管理

我们持续在实现科技、物流、零售、工业、健康等多个BGBU存量百余款技术产品全量入驻产品中心，建立后续增量技术产品入驻流程及标准，实现集团视角技术产品和目录统一。

为建设统一CRM、统一经营分析打下产品基础。我们为各BGBU提供5级产品类目管理，可覆盖集团各业务线的类目主数据需求。

3、产品管理

3.1、产品创建流程

我们管理的各业务线产品数据源，有来自各业务线推送，也有来自我们山海产品运营平台的产品创建，在我们运营平台可编辑配置产品信息，同时分发到相应销售渠道进行产品售卖。在山海运营平台进行产品创建的流程，

主要包括以下6个步骤，1、创建类目，2、开通权限，3、新增产品，4、维护定价（tob产品），5、审核上架，6、渠道分发。其中创建类目和开通权限，需要由各业务线产品接口人向战略部申请新增或者调整，

战略部和财务部确认后，由山海产品运营平台产研配置，并且开通类目权限。之后各业务线可登录山海运营管理平台，创建产品（TOB产品可维护定价信息），产品上架提交审批，指定分发的渠道可进行售卖。

总体产品创建流程如下图。

3.2、产品创建

登录山海系统，选择产品中心，进入产品运营平台，选择产品管理菜单，点击“新增产品”，选择特定类目录入产品，点击保存即可完成产品创建。

3.3、产品定价创建（TOB）

登录山海系统，搜索需要维护定价的产品（只支持TOB产品设置定价），选择操作按钮中的设置定价，选择定价计费项，录入定价信息，点击保存按钮即可完成产品定价的创建。

3.4、审核上架

产品已完成基本信息、定价信息的录入后，点击产品操作按钮，选择提交审核，系统会发起线上审核流程，审核通过后，可点击产品操作按钮，选择上架，确认后即可上架成功。

3.5、渠道分发

在山海产品运营平台，选择渠道管理菜单，选择渠道分发模块，查询要分发的产品，点击渠道分发按钮，在弹出的窗口中选择要分发的渠道，点击确定按钮即可分发成功，产品分发成功后，在指定的渠道端即可对产品进行销售管理。

4、库存管理

我们支持金融虚拟库存、实物商品库存管理，支持总库存、日库存、预约日库存和预约余量售卖多种库存模式，支持金额、人数和个数多种库存类型，支持渠道、门店、产品和活动多维度进行库存交易与统计。

登录山海产品运营平台，选择库存管理模块，根据实际需要选择不同维度的库存管理，可查询产品在渠道、门店等不同维度的产品总库存、预占、可售、货损、调拨中的库存量，同时可支持修改库存信息。

三、我们的系统架构与技术亮点？

1、系统架构

我们的系统基于DDD领域思想指导，划分系统业务边界，定义业务身份和扩展点，进行微服务设计。系统领域包括产品核心域、分类渠道支撑域以及任务和审批通用域。科技产品中心领域划分如下图所示。

基于各业务线产品逻辑差异化，定义去重校验、产品名称校验、字段初始化等扩展点，定义业务扩展包，脱离主流程，解耦系统的同时提高系统扩展性。提供索引服务，可支持不同字段的复杂检索，

通过alias能力支持在线更新mapping，实时构建索引。系统还提供库存服务，可维护不同渠道、不同场景(或门店)的产品库存，为产品交易过程中库存冻结、解冻、扣减提供能力。

系统整体技术架构如下图。

我们各业务线产品定义，管理流程差异化越来越大，为解决代码腐化，提高迭代效率，降低迭代成本，梳理出通用的的产品管理模型，沉淀平台核心能力，差异化功能抽象定义为各种扩展点，

采用业务包的形式通过SPI方式定制化实现，平台能力与业务功能解耦，做到业务隔离，降低相互影响的风险。

2、技术亮点

2.1、基于元数据可管理的产品数据

我们构建产品属性库，提供产品基础字段管理，保证业务字段标准化，可复用，同时通过JSON Schema来验证指定产品模版JSON字段的必填或重复等基础校验、关联校验及复杂的业务校验。

通过可拖拽的可视化画布编辑产品模版，保存模版的同时，解析模版字段写入元数据表，打通产品搜索、产品列表、产品导入等功能，让系统数据变得可配置，可管理。产品元数据整体架构如下图所示。

2.2、基于可拖拽的模版扩展产品表单

通过山海产品运营平台，进入产品模版管理页面，可通过产品属性构建产品模块，或者产品模版，绑定产品分类和渠道，生成模版版本，将模版版本绑定测试环境，预环境发或生产环境，

即可在指定环境发布产品模版，产品字段变更无需硬编码，通过可拖拽的模版画布，动态扩展产品表单。实现流程如下图所示。

前端产品模版布局，采用JoyPage可视化搭建平台来实现可拖拽的页面配置，可以拖拽式轻松配置业务表单，像玩“乐高”一样自由搭建产品信息模板。

JoyPage是京东科技业务中台团队自研的一款前端低代码框架，支持丰富的组件类型，包含文本、日期、下拉菜单、单选、多选、富文本、表格、业务模块组件、布局组件等数十种字段类型按需搭配，

支持事件配置、动态数据源api接口配置，灵活的进行前后端交互。在搭建过程中，从左侧组件列表拖拽到中间画布区域，点击且选中画布中已有的组件，在右侧组件属性面板进行组件的属性配置。

搭建界面如下图所示。

2.3、基于保型加密可配置长度的ID发号器

JidGenerator是京东科技产品中心自研的ID发号器，主要应用于以科技产品中心系统为主的京东科技内部中台系统用来生成唯一的系统ID。JidGenerator是基于保型加密算法原理实现的分布式ID生成器，

该生成器基于每天生成唯一的二维矩阵模型来实现保型加密，ID生成的数据来自于二维矩阵的数值，可根据系统的业务量级自定义加密后ID值的位数（可配置生成的矩阵行数）。

下图定义为加密后的值为5位示例，即每天生成的唯一二维矩阵行数定义为5，列数配置为10，共5组slat，每组都是0～9随机生成的数字。

一个系统中如果要生成多种类型的ID，如（渠道ID、分类ID、产品ID等），可使用JidGenerator生成ID时配置的类型别名来区分，即同一个系统可生成不同类型的ID。同时计算当前日期距离1970-1-1相隔的天数，

使用生成ID的类型别名+相隔1970-1-1的天数作为缓存key（如某天生成产品ID序号的缓存key为：item19080），缓存需要生成的ID序号，ID序号初始数值和步长可配置，如初始数值配置20即提前生成20个序号，

缓存中序号使用完成后继续按照配置的步长累加后再写入缓存。ID的生成根据从缓存中获取序号左位补零的方式获取新数，新数的每位数字作为二维矩阵的下标从二维矩阵中获取加密后的数字生成ID。

例如：根据缓存key（如item19080）从缓存中获取的序号为10，左位补零的方式扩展为5位后为00010，则加密后的数字为21956。

2.4、支持复杂查询的产品检索能力

我们提供索引微服务，监听产品核心服务的数据变更事件，同步更新ES存储，各业务线复杂的查询通过索引服务批量查询返回产品ID列表，根据产品ID列表读取R2M缓存数据给各业务方，实现原理如下图。

同时我们提供动态mapping，支持在线重建索引，同步数据，变更别名，通过新索引别名动态改变索引，支持原索引作为备份索引，异常时切换，实现索引的无缝切换。

2..5、产品主数据标准化治理

科技产品中心实现产品域科技集团的产品和类目覆盖及统一管理，解决产品交易及输出过程中渠道端、业务系统、财务整个交易链条的主数据一致性问题，

我们对接集团EBS系统，打通财务收入、损益核算线上化，实现产品数字化，支持财务进行公司产品损益分析，针对科技集团产品和产品类目提供标准化输出。

四、未来规划

当前科技产品中心经过了超4年的迭代，为了适配各业务线产品不同字段的问题，系统也经过了多次升级改造，目前已提供了非常成熟的产品管理能力，能兼容不同业务的产品差异化，同时提供全流程产品管理，包括统一类目，产品创建，产品分发，产品库存交易等，已覆盖了科技集团内部大多数的业务线及京东保险的产品主数据管理。

2023年及未来产品中心计划将推广到京东零售、京东物流、京东健康、京东工业等其他BGBU，实现产品和类目的统一，助力集团各BGBU财务、风控等职能部门进行技术类产品的线上化收入和损益结算。

合阔智云核心生产系统切换到服务网格 ASM 的落地实践

背景

合阔智云(http://www.hexcloud.cn) 是专注于为大中型零售连锁行业，提供全渠道业务中/前台产品和解决方案，并建立以消费者为中心的全渠道交易和敏捷供应链的新一代零售运营协同平台。

合阔智云提供了从全渠道交易管理到订单履约再到门店供应链完整的餐饮零售连锁解决方案，整个方案采取微服务设计，并深度使用了 Kubernetes 作为生产调度平台。

技术现状

整个业务系统采用微服务架构，但不同业务场景在不同阶段选择了不同的技术语言来开发，如 Python、Golang 和 Java，甚至有部分应用使用了 Nodejs，因为技术栈的缘故，Spring Cloud 或者 Dubbo 这样的全家桶并不适合我们，为了能够适应业务需要，我们选择了下面的策略：

• 不依赖于单一语言和单一技术框架，允许使用更加合适业务的开发语言，如快速业务迭代使用 Python，基础服务和云原生部分使用 Golang，核心的业务系统使用 Java
• 服务内部使用 gRPC 通信，服务接口定义依赖于 Protobuf
• 原则上跨服务通信不依赖于消息队列，消息队列只用于服务自身的调度与补偿，这样子降低了消息系统本身的复杂性
• 所有系统不直接暴露 HTTP，需要提供 HTTP 服务的，使用团队开发的 grpc-proxy 来实现 HTTP to gRPC 的转码代理工作

原则上应用只处理业务本身的问题，所有基础架构部分的能力都转由 K8s 来负责，包括：

• 网关
• 服务发现
• 负载均衡
• 指标与监控
• 健康检查
• 故障恢复

当前挑战

早期所有技术人员只需要专注业务的编写，其他所有的工作全部交给 K8s，在流量比较小业务相对简单的情况下，这个运行非常流畅。然而，随着应用数量的增加，业务变得越加复杂，外部流量也在不断增长，由此带来了应用链路调用更加复杂等新的运维难题：

• 内部调用用的是 gRPC 协议，应用端没有做特别处理，导致基于 HTTP2 的长连接协议无法实现负载均衡，尤其是单一客户端调用变大的情况下，服务端无法有效负载；
• 因为应用本身比较薄，应用调用链路无法透明化，每次新的发布部署容易出问题。

在 2022 年之前，我们使用 Linkerd，初步解决了服务在负载均衡和调用链路上的治理难题，但我们大部分的基础架构都是依赖于阿里云，比如：

• 日志使用 SLS
• 应用监控使用 ARMS
• 链路追踪使用 XTrace
• 仪表盘使用 Grafana
• 容器监控使用 Prometheus

为了简化基础架构的复杂性，我们在基础服务上的基本原则是使用云厂商而非自建，而 Linkerd 在实际的使用过程中遇到了一些问题：

• 需要使用自建的基础设施，无法和阿里云提供的基础设施很好的融合
• 应用可观测性比较简单
• Sidecar 使用默认配置，控制能力相对较少，在应对一些复杂一点的场景，无法做到灵活配置

而可观测性是服务网格的基石，在一套自建的基础架构上，我们会偶发的出现链路被熔断、某个端口无法访问的场景，最终的解决方案就是取消注入或者重新注入来解决。

基于服务网格 ASM 的探索

集群现状

我们目前有两个生产集群，合计 150 台 ECS，2500 个 Pod，不同开发语言应用的特点如下：

• Golang 用于用户基础架构以及计算密集型性的应用系统，总体内存占用不会超过 500M，部分服务会随着临时性的内存而增长，如文件的导入导出服务；
• Python 用于早期业务敏捷迭代构建的业务系统，都是单进程多线程工作模式，单一 Pod 内存占用不高，但一个 Deploy 需要更多的 ReplicaSet 数量；
• Java 用于全渠道在线交易业务构建的系统，单一 Pod 需要耗费的资源比较多，但同等情况下单一 Pod 的处理能力比较强。

两个集群包括了不同的应用场景：

• ACK-PROD：早期针对大型客户专有部署的应用集群，每个客户的规模体量比较大，应用资源的隔离通过namespace和调度绑定来隔离；
• ACK-SAAS：针对 SME/KA 全新开发的 SaaS 平台，所有客户都使用统一的计算资源。

调研阿里云服务网格 ASM

我们知道， 服务网格作为一种用来管理应用服务通信的基础核心技术, 为应用服务间的调用带来了安全、可靠、快速、应用无感知的流量路由、安全、可观测能力。我们针对开源社区 Istio 和阿里云服务网格 ASM 产品分别进行了调研， 通过试用了解到作为云厂商的产品， ASM 具备了若干生产使用的功能和实战经验，具体来说， ASM 增强了多协议支持以及动态扩展能力，提供精细化服务治理，完善零信任安全体系，并持续提升性能及大规模集群支持能力，降低在生产环境落地服务网格的门槛。商业版适用于有多语言互通，服务精细治理需求，在生产环境大规模使用服务网格的场景。

详细的介绍可以参见：https://help.aliyun.com/document_detail/176082.html

通过调研， 我们了解到作为业内首个全托管 Istio 兼容的服务网格产品 ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区开源的 Istio 定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。

托管式服务网格 ASM 在成为多种异构类型计算服务统一管理的基础设施中, 提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及实现统一的代理可扩展能力, 以此构筑企业级能力。可以通过点击"阅读原文"查看具体的内容介绍。

基于上述的调研， 我们决定开始使用阿里云服务网格 ASM 产品进行迁移。

迁移到阿里云 ASM

第一轮

• 第一次注入：ACK-PROD

我们首先将一个足够规模体量的单一客户生产环境（门店供应链）（每天 50 万笔订单，1500 万库存流水）注入 Istio，因为这个环境的使用场景不是全天候的，出现问题会有半个小时的缓冲时间来解决问题，并且应用系统做了完善的自动补偿，确保在出现问题我们取消 Istio 以后业务也能够正常恢复，第一次注入非常成功。

• 第二次注入：ACK-PROD

然后我们将另外一个门店供应链的生产环境也做了 Istio 注入，相对于第一个环境，规模体量小一点，但业务环境更加复杂，有更多的应用服务在运行，第二次注入非常成功。

• 第三次注入：ACK-SAAS

随着前面两次的成功实践，我们在一个更加重要的实时生产系统（门店全渠道交易）的基础服务部分引入了 Istio，因为这些服务只使用 Golang 编写，都是一些实时处理要求比较高，但业务相对简单的，第三次注入成功。

• 第四次注入：ACK-SAAS

我们在生产环境开始注入部分交易链路，注入以后系统生产可用，在第二天高峰期发现了会有部分服务出现 istio-proxy crash 导致应用不可用，从而影响了部分应用的正常运行。鉴于对生产环境的谨慎，我们重新复盘了出现问题的场景，最终得到的结论是：

• Java 应用的启动对于资源的要求比较苛刻，我们没有提前配置好更加合理的启动参数，将会导致 Java 应用启动缓慢；
• 检查机制不完善，将会导致流量打给还没有完全准备就绪的服务，此时 K8s 的健康检查机制会在多次没有响应时会再次重启服务；
• Istio Sidecar 默认的设置也会推慢整个 Pod 的启动时间，之前应用的假设是 15s 内完成启动，随着 Sidecar 代理的注入，有时候会遇到更长的时间；
• Java 应用提供 gPRC 服务的时候，istio-proxy 会出现某种特殊情况的 Crash，这也是导致生产服务不可用的直接原因。

简单而言，在 istio-proxy 存在部分 bug 的情况下，我们的应用的快速启动策略和健康检查机制的不合理，直接导致了注入 Sidecar 代理的部分服务生产不可用。
针对这个问题，我们在阿里云工程师的支持之下，在另外一个环境复现并做了改进，主要的改进如下：

• 针对 istio-proxyCRASH 问题，社区已经有了解决方案，在阿里云工程师的支持下，我们升级了 Sidecar，并做了 A/B 测试，确定复现了这个 Crash 的场景；
• 针对 Java 应用一开始分配更多的CPU资源来加快 Java 应用启动，在测试过程中，如果默认分配 0.2 调整到 1.5，启动时间最长的会从 6 分钟减少到 40 秒；
• 调整 Sidecar 配置，根据应用优化 istio-proxy 的启动速度；

第二轮

在方案得到确认以后，我们开始了第二轮的 Istio 升级。

• 第一次注入：ACK-SAAS

我们将 SaaS 的供应链业务注入 Istio，除了升级过程中遇到部分服务资源不足的问题，其他都非常顺利；

• 第二次注入：ACK-SAAS-QA

我们在测试环境复现了启动速度慢的问题，并通过更加合理的启动参数配置验证了在 CPU 初始化申请对于 Java 应用的影响；

• 第三次注入：ACK-SAAS-QA

A/B 测试 Istio crash 场景，确认新的 Sidecar 已经修复这个问题；

• 第四次注入：ACK-SAAS

正式完成全渠道交易的 Istio 生产注入；

• 第五次注入：ACK-SAAS

将剩余的应用全部完成注入。

此外，服务网格 ASM 相比社区 Istio 能够实现更加丰富的能力，如流量标签、配置推送优化等能力。在实际的应用场景中，我们充分利用配置推送优化能力。在默认情况下，由于无法确定数据平面内所有工作负载与服务之间的关系，服务网格数据平面内的所有 Sidecar 都必须保存数据平面集群内所有服务信息的全量配置。同时，一次针对控制平面或数据平面的修改（例如在控制平面新建一条虚拟服务规则），都会导致控制平面向数据平面的所有 Sidecar 推送新的配置。

而在我们的数据平面 Kubernetes 集群中的工作负载数量比较多， 默认情况下会增加 Sidecar 对数据平面集群的资源消耗，同时控制平面会面临较大的配置推送负担，降低控制平面的效率与可用性。ASM 提供了选择性服务发现和 Sidecar 资源推荐功能，帮助优化配置推送效率。

服务网格 ASM 可以通过分析数据平面 Sidecar 产生的访问日志获取数据平面服务之间的调用依赖关系，为数据平面中的每个工作负载自动推荐 Sidecar 资源。为工作负载推荐 Sidecar 资源后：

• Sidecar 配置内将仅保留该 Sidecar 对应工作负载所依赖的服务信息。
• 当该 Sidecar 资源对应的工作负载无依赖关系的服务发生改变，或与该服务相关的资源发生改变（例如虚拟服务等），都不会引起控制平面向该 Sidecar 的配置推送。

服务网格ASM 通过访问日志分析自动推荐 Sidecar CR

经过优化后， Sidecar 配置大小从原来的 40 多M减少为 5M, 控制面配置推送时间也随之大大减少。

总之， 经过一个多月的反复测试和确认，我们终于完成了基于服务网格 ASM 的核心生产系统切换，相对于之前的服务网格方案，给我们带来了很多益处。

方案优势及进展规划

完备的可观测性以及应用监控

通过服务网格对应的控制面盘，我们发现了很多之前应用本身的问题，比如：

• 不合理的应用补偿策略
• 不合理的应用部署（比如把大数据查询和应用处理放在同一个服务）
• 不合理的应用报错
• ...

而这些问题随着服务网格的上线，我们变得一清二楚，进而非常方便的推动应用架构的改造。

流量与资源的均衡

这是我们上线服务网格的初衷，随着我们将所有应用放到服务网格，我们真正做到了在 CPU、内存、网络利用率的均衡，通过通过应用调用的监控来看，所有请求数量和错误也非常均衡的分配在不同的 Pod 上，不用再去担心随着流量的增长因为负载不均衡而导致横向扩展失效。

更加强大的流量治理能力

在没有 Istio 之前，我们基于自身业务需要做了一些“手工”的流量治理工作，比如：

• 东西流量：基于基于租户与门店的流量隔离，允许我们可以允许需要针对某一个租户某一个门店发布指定服务
• 南北流量：针对业务场景进行灰度测试，比如某一个租户的美团订单处理使用新的接单服务
• 为某个租户提供自定义域名
• ...

这些工作都是基于 K8s CRD 构建的，随着服务网格的上线，我们发现 Istio 可以帮助我们实现更多，比如灰度发布、熔断、限流、流量标签等。这些能力将在未来持续不断提升我们线上业务的稳定性。

作者：刘如鸿

原文链接

本文为阿里云原创内容，未经允许不得转载。