Javashop企业级电商中台架构

近几年来中台的概念开始被广泛讨论，电商企业要不要采用中台的架构？有从战略角度考量的，也有从业务需求角度考量的。Javashop的客户之中也有搭建中台的需求，总结我们为客户落地电商中台系统的经验，在这里分享给大家。

一、大型企业电商面临的问题点是什么

1．跨领域性

大型企业一般业务覆盖广泛，子业务横跨多领域，导致业务模型的共性和差异化并存。跨领域导致从操作体验到流程变得繁杂，在电商落地中要梳理清楚每个子业务，并进行抽象，落实到软件需求。

2．一个中心

很多集团型企业在面对繁杂子业务的时候，需要一个中心、一套规范来进行整合系统。做到数据中心化、核心业务中心化、接口中心化，规范的统一实现功能的复用，提高效率降低成本。

3．多端多触点

紧随互联网时代的步伐，实现微信H5/小程序/App/Pc多端支持，组合支撑企业业务发展。

4．灵活运维

电商营销运维本身要求灵活多变，且企业落地电商业务可能非原有熟悉领域,运维团队需要不断尝试“新玩法”，这要求系统可以快速响应变化，实现敏捷变更。

二、如何助力企业电商落地

推动企业电商落地我们从以下三点出发：

1．Javashop电商中台抽象出业务中台，涵盖用户中心、商品中心、订单中心、营销中心、售后中心、支付中心。业务中台对企业内部暴漏统一的标准服务接口，通过消息总线子业务实现各自的订单业务流转。

2．Javashop电商中台的前后端分离式架构，允许前端灵活点接入业务中台，统一的用户中心使得前端复用业务中台能力，达到灵活响应、快速实现的目的。

3．业务中台使得企业可以快速、重复的使用电商系统标准、基本的能力，又可以满足各个子业务部门个性化的需求，即允许子部门“各自为战”、又可以形成统一的数据、业务中心。

三、Javashop中台总体架构

1. 基础设施

目前大型企业都有自己的paas平台，或自己搭建、或购买的私有云产品（如腾讯、阿里、青云等）。

1. 电商平台

在基础设施之上我们提供了一套标准的电商中台，包含用户中心、商品中心、订单中心、营销中心、售后中心、支付中心，提供了通用的电商业务能力支撑，如创建订单、支付等。

1. 根据业务抽象的多端多触点

Javashop提供了一套标准的电商前端支撑：PC、WAP、小程序、APP，这部分是通用的电商逻辑，客户会根据自己业务情况定制前端，提供个性化的功能、交互体验等，这些个性化是来源于企业内部个性化的需求。

四、中台落地预览

 

我们以个性化的票务子业务为例，说明基于中台业务的落地。如上图所示，根据子业务的需求（如票务）抽象出子业务前端的功能流程、操作体验：

展示门票的有效期、座位情况等，点击购买时直接转入结算页，并提供选座界面，点击“确定购买”按钮直接下单、支付。

对于商品名称、相册等通用信息展示，前端通过调用“中台核心api”实现，这部分api是中台提供的，现成的，不用开发，只需要前端适配api即可。

对于有效期、座位情况的个性化需求，需要子业务的api提供，这部分是子业务需要开发提供的api，然后又子业务前端整合。

同样地，订单的创建、支付如果中台的通用api不能满足，也需要子业务调用核心api来共同完成。

下面我们以常见的订单创建和支付为例介绍一下常见的几个中心：会员中心、商品中心、订单中心和支付中心

会员中心

核心需求是要解决集团型企业用户来源的多样性，比如线下渠道、非电商用户、OA用户、erp用户等等。用户中心要解决这些用户方便的接入电商系统，方便的进行sso（统一认证）的改造，甚至可以形成整个集团的用户中心。

• 统一的注册api

可提供子业务或其他系统调用

• 统一的身份验证机制

基于token式的身份认证，方便其他系统接入以及sso的实现

 

商品中心

核心需求是统一的商品存储和管理，方便子业务取用商品数据（库存、索引等）。

• 商品基础api

可提供子业务存取商品的基本信息（商品名称、相册等）

• sku api

可提供子业务存取商品的sku信息

• 库存

可提供子业务对商品库存的存取

订单中心

• 统一的订单创建接口，不依赖购物车，方便其他子业务调用。

• 订单的查询接口

• 订单消息总线，提供订单变化消息

支付中心

独立的支付中心，统一支付接口

• 独立的支付中心（配置、api)

• 面向账单的支付体系

集团型企业子业务众多，但需要有统一的支付中心，以便提供统一的参数配置、统一的收款台，方便财务数据的管理。

下面我们以景区售票业务场景做为一个子业务来说明支付中心的架构：

 

用户到景区购票时，可能通过扫码或人工等手段触发景区子业务创建订单操作，接下来子业务引导客户到子业务的收款台。

客户点击确认支付时，在子业务中检测是否可以支付（如库存锁定是否成功等），如果可以支付，调用支付中心付款接口调起支付，支付中心要检测此子业务的订单号是否已经有支付账单、金额是否一致，进而调用第三方支付接口形成调起支付的参数，返回给子业务、引导客户付款。

客户在收款台完成支付操作，当第三方支付系统（支付宝、微信等）确认付款成功后会通知支付中心，支付中心会发出支付账单状态变更MQ消息通知子业务，子业务收到支付成功消息后出票（人工、机器等）。

当子业务发生退票时，调用支付中心退款接口将款项退给客户，退款成功后会发出账单变化消息通知子业务。

支付中心还有一个账单状态查询接口供子业务查询状态使用。

 

总结

综合以上我们的分享，Javashop中台系统希望提供一种能够满足大中型企业的电商落地解决方案，近年来关于中台的讨论、争论愈演愈烈，我们的看法是“适合自己的才是做好的”，一定要从自己的业务模型出发，不能一味的追求“流行”，技术应该为业务服务，中台方式的架构的确一定程度上提供了技术的重用，提高了效率，但如果企业业务没有足够复杂，或者团队对分布式开发、服务式开发不够了解，建议还是先不采用中台式的方案，简单的需求的话，传统的、垂直的架构更快、更灵活，可能经过一段时间的发展，倒逼团队更新架构，那时再服务化、中台化也未尝不可。欢迎大家在评论区中发表自己的看法。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　  　                                     易族智汇（javashop）原创文章