建设中台最直接的目的一般是为了帮助企业快速且低成本的创新，这就要求了中台必须降低使用方的学习成本，能把各个业务进行集中管理以及需要有较低的学习门槛，简单来讲就是：可视化、配置化、低代码。中台产品设计如何实现可视、可配、可复用？本文作者从常见的中台架构出发，对这个问题展开了详细解析，与大家分享。

中台在这两年是一个非常火的概念，其出现的目的只有一个：帮助企业快速且低成本的进行创新。

二十年前，中国的互联网刚刚起步，在线交易一片荒芜，商品信息极难通过在线进行展示，更别论在线交易；十年前，中国互联网蓬勃发展，以阿里、京东为代表的企业实现了在线交易基础设施的搭建，大部分的消费则能够在网上查找商品并进行交易；

而如今，互联网日益向着成为水电煤的趋势发展，各种模式、形态的电商不断涌现，昨天刚出现蘑菇街、小红书，今天就有有赞、拼多多；昨天刚大力吹捧微博、公众号的自媒体营销，今天又有小程序的出现。

在这个极其不确定的时代里，任何一家企业都害怕错失机会，不断出现的新鲜事物，让企业创新的成本越来越高，如何能够通过尽量少的成本，而不失尝试新鲜事物的机会，成为企业经营中遇到的难题之一。

一、常见的中台架构

在聊中台的时候，我们一定需要聊一聊软件架构，软件架构是系统发展到一定的复杂程度后的必然产物，当系统足够复杂以后我们需要大规模的协作才能完成开发，必然要求我们对整个系统进行横向和纵向的切分，再按切分后的系统进行团队划分。

在切分系统时我们需要从垂直的角度考虑，例如：页面、应用、领域和基础设置；也需要从横向角度考虑，例如：店铺、商品、订单、支付等。对系统进行切分后我们需要定义切分后的模块之间的通信、同步等机制。

而且分系统最终的目的是能够以更小粒度调配人力、物力、财力去完成系统的开发工作，而更小粒度的团队也更加便于管理，有效的降低企业成本。狭义的中台也是一种软件架构（如图），面向消费者的是各种端中的应用，通过统一的API网关能够使用中台各个业务中心的业务能力，而各个中心之间也能通过统一的协议进行调用。

这样一种架构是与我们现在大部分的互联网企业的组织架构相匹配的，离消费者或者客户最近的是各个事业部，也就是软件架构中的应用层；而中台的各个业务中心就像技术部门、财务部门、市场公关等部门，能够为前台的应用提供支撑。而我们把业务中心拆散后也更利于我们进行微服务化，其直接的好处就是硬件资源变得可以按需投入了。

至此，我们简单的对中台的理念以及一些好处进行了说明，那真实的中台就是像我们上图这种架构嘛？答案是：不是。

二、如何解决快速和低成本的创新

首先我们回顾下推行建设中台最直接的目的是：帮助企业快速且低成本的创新。如上的架构我们对企业的系统进行分层，并对中台进行领域的划分，看上去似乎是能够让上层的应用直接通过API网关调用中台的能力进行快速的应用开发。

但我们忽略了一个重要的问题：系统开发不只是API调用，他是包括从产品规划、开发测试、部署上线以及业务运营等一系列的活动。如果中台只是能提供API是无法为应用提供便利，即使有一些便利也会应用接入中台的复杂性而抵消这种便利。那复杂在哪里呢？

首先要能实施中台我们一定会使用微服务，而要实现微服务我们必须要制定一系列的标准进行微服务的划分，也要把业务进行更高层次的抽象，为何要进行抽象呢？

例如：以前我们是单体应用，我的交易流程只有一种就是现款后货，但是由于我们是中台我们面对大量的应用每一个应用虽然只有一种业务流程，但对我们来说可能就是很多种，如此我们需要对所有的业务进行拆解，相同部分进行合并，而不同的部分者需要独立出来，同时在这些业务逻辑之上能够提供统一流程编排服务。

而在这样做了之后，对中台每一个业务中心来说都有巨量的API可供使用，而如何能够进行使用只能通过API文档或者是中台开发直接的讲解，而这种学习域熟悉的成本完全会抵消API复用的便利性。同时由于要中台化，我们制定的诸多标准也会使得应用处处受制，原本可以按照自己喜欢的方式进行开发，而如今需要按照他人的标准执行。

那到底应该如何通过中台进行快速且低成本的创新呢？答案是：可视化、配置化、低代码。

中台的复用性相信大家一定是能够感受到的，但由于其复用性所带来的复杂确实我们缺少思考的。可视化能够有效的降低使用方的学习成本，让其能够直观的感受中台的业务能力；配置化能够把各个业务使用的能力集中起来管理，让最熟悉业务的人员直接控制应用中的业务逻辑，能够把标准更好的执行下去；而低代码则是降低了开发人员学习中台复杂技术框架的门槛，让其能够忽略底层的技术实现，只关心业务逻辑部分。

三、为了实现可视化、配置化、低代码我们需要做些什么？

中台最显现的优势就是复用，复用是快速和低成本创新的基础，那电商中台为什么能够复用呢？首先我们可以对电商业务进行拆解。如图：

在所有的电商中其核心的基础流程都是：开店-发布商品-下单-支付-履约/售后-结算，在商品部分会和库存有直接关联，简单点的直接使用虚拟库存，复杂的库存系统则会包含出入库管理、库存管理、配补管理、盘点等相关功能，而我们主要还是基于虚拟库存进行设计。

而能够对基础流程产生影响的主要有以下这几个方面的因素：业务模式、营销方式和商品类型。具体每一种因素可能对交易流程的影响可见上图。

在应用的分层架构中，我们可以从用户能够接触的层次往系统抽象层次依次分为：页面、功能、能力、数据模型或者是界面接口、应用、领域、基础设施。

而在业务架构下我们电商业务又是怎样的，我们分别看下BBC、B2C商城是怎样的，如图：

我们可以看到在不同的业务模式下，其实我们有大量的业务模块是可以在页面、功能、能力、数据模型这四个维度中的某几个进行共用的，那我们是否可以可以做一个这样的设想：是否能够把每一个应用中的页面、功能、能力和数据模型都打散 分别沉淀到对应的页面、功能、能力、数据模型的公用库中，这样以后每层次来一个新的业务只要通过从共用库中选择自己所需要的页面、功能、能力、数据模型就可以搭建匹配自己业务逻辑的应用。

通过以上的推演，我们可以看到在页面、功能、能力、数据模型这些维度上进行复用是符合逻辑的。我们知道中台不只是能为应用提供接口，而应该是能够提供全套复用资源的，包括页面、功能、能力、和数据模型。而我们设计中台的时候也需要设计相应的管理和使用的工具，以达到可视化、配置化和低代码的最终目的。

四、真实的电商中台架构

在聊电商中台架构之前，还需要和大家说说系统的运行域和管理域。

运行域指的是人们在系统上开展业务时系统运行代码的空间；管理域指的是系统管理员控制系统参数或实现预留业务扩展点的工具的代码运行的空间。运行域是为了解决实际业务而存在的，而管理员则是为了对运行域的业务流程、规则进行动态调整而存在的。

在上文所说的页面、功能、能力、数据模型都是属于运行域的内容，而由于这些内容在随着企业业务不断的发展过程中会越来越丰富，所以我们需要提供一个工具来对这些内容进行管理，随之管理域就出现了。如图基于中台的整体应用架构：

在管理域中有如下三个基础功能模块：元数据管理、能力管理、组件管理。

元数据管理主要完成对数据模型的管理，包括对内置对象的数据结构进行扩展、部分字段的定，也包括对应用中的定制对象进行定义、字段设置等功能，更多元数据相关的功能在此不做表述，在整个业务逻辑中元数只是作为配置参数存在，而更多元数据的能力并未涉及；

能力管理主要是对能力和功能的管理，主要包括两部分，一、是对中台预置的配置项进行注册和发现，二、中台预留抽象类，可让应用自己进行定制化开发，在通过机制进行注册和发现并提供给应用使用。具体的实现机制可参考Java中的SPI机制，简单来说步骤如下：

• 在代码中使用统一注释，通过扫描可以自动把注释部分的代码上报到能力管理实现注册；
• 在能力对应的代码进行修改了之后，扫描机制也能在一定的时机进行更新；
• 通过统一的编码规范，对某些类预留抽象类，可暴露给应用方自己进行实现；
• 应用方对抽象类进行实现后，可通过扫描机制发现，并让应用进行调用。

组件管理主要可以分为页面组件和服务组件的管理，页面组件在设计时需要区分面向用户商城页面组件管理和面向商家或运营人员的管理后台的页面组件库。前端的组件最终是以页面编辑器的方式进行实现，在此不做详细表述，而管理后台的页面组件库则需要与全局管理的中的资源、菜单、角色管理配合起来一起满足业务的需求。

其核心业务逻辑在于：所有系统中的页面、菜单、页签、按钮以及其它页面元素都可以由统一的提供方提供，放到公共库中，消费方只需要按照标准进行调用即可，如此能够实现最大限度的资源复用。统一UI资源的管理还有一个巨大的好处，能够保证数据模型的稳定性，不至于由于页面的交互或视觉而造成对数据模型的冲击，

功能服务组件则是把业务和平台分离的关键，大量具有业务特性的聚合服务从核心业务逻辑中抽离，形成一个一个的服务组件，以插件的方式装配到主干业务流程中，由于使用统一的标准进行开发，在业务组件中预设大量的配置项，通过自动注册和发现机制实现配置项自动化上报，而组件一被生产方生产出来后就会进入统一的服务组件库中，能够被任一业务方进行调用。

通过以上三个能力，能够实现对数据模型、能力、功能以及页面的统一管理的需求，只是对这些内容的管理还是不够的，我们还不能实现最终目的，在能够对其进行管理之后，我们需要能够按业务需求把这些内容组装起来，以满足业务的实际需求，且是通过配置化、低代码的方式。

所有的业务系统按我们第二部分的内容介绍都可以分为页面、功能、能力、数据模型四个部分，电商系统普遍都是由前端商城+管理后台组成。而在电商中整体的业务流程：开店-发布商品-下单-支付-履约/售后-结算，造成业务不同的因素主要是：行业（不同的类目）、卖家、和商品（不同的类型、模式）。

为了解决不同业务动态化配置的问题 我们需要引入业务身份这一概念，业务身份主要是把前后台的应用放在同一个空间下进行管理，我们在管理域可在业务身份下进行业务逻辑的配置，这些配置可以让系统中包含的各个应用在运行域时能够识别所需要使用的页面、功能、能力和数据模型。

业务身份是一个标识，能够在虚拟空间中划分一个独立的系统运行空间，在这个空间内业务可以按设置好的配置在系统中完成，在这个空间中可以有多个应用，空间中应用所对应的页面（也即资源）、功能、能力和数据模型都会被业务身份进行标识。业务空间的示意图如下：

而在端到业务应用之间最为关键的就是如何进行业务身份识别。业务身份不同的影响因素主要有：行业（不同的类目）、卖家、和商品（不同的类型、模式），我们在设计业务身份时首先需要明确这个业务身份是在那个租户下，其次需要把对应的应用关联到业务空间，关联的应用决定了在该业务空间能够设置的配置项的范围，然后我们可以对我们这个业务空间进行四个因素的选择。

例如：行业为酒水、卖家为自营时我们加入购物车和立即下单时需要进行认证，且在商品类型为预售分阶段时订单需要走分阶段订单流程。在用户操作页面产生一个请求后，业务身份识别的过程如下图：

业务身份的整体逻辑示例：在基础的BBC电商系统中我们已经实现了实物商品先款后货的整体业务流程，但我们有些业务需要实现预售这种交易模式，此时我们能很好的运用业务身份进行业务逻辑的扩展。我们需要对BBC商城中的发布商品（此处为设置营销活动）、下单、支付这三个环节进行相关的业务配置：

1. 定义业务身份，当“类目包涵茅台”且“商家为直营”的业务身份为xxx.maotai.zhiying；
2. 把云商APP端关联到该业务身份，把云商APP端对应的发布商品应用、下单应用关联到该业务身份下；
3. 我们需要在业务身份下进行相关的配置设置，在营销活动的配置中开启预售模式，在下单节点需要开启订单支持分阶段交易，支付支持对一个订单进行多次支付；
4. 把相应的配置配好之后，我们把配置以及配置对应的功能组件进行重新打包并发布上线；
5. 我们需要把预售对应的菜单、页面及按钮等资源配置出来（在BOC中）
6. 在发布成功后，后台管理（运营及商家）能够出现预售管理的菜单及相关的功能操作按钮
7. 在发布商品时选择的类目为茅台且发布人对应的商家为自营则能够发货预售活动，
8. 在用户对预售商品进行下单时能够根据类目与卖家的标识进行业务身份识别从而选择对应的业务空间中的交易流程。

以上就是业务身份在整体的业务流程中如何使用的逻辑，业务身份其实是我们自己定义的一个分隔业务的标准协议，在不同的企业可以选取不同过的业务维度决定业务身份，但主要从商品、类目、卖家这几个业务维度，再加上端、应用、租户这几个基础维度即能准确定位到具体的业务空间。

在不同的业务空间中配置有可能会出现冲突，此时需要对冲突进行处理，才能真正把配置发布成功，配置冲突的场景如下：商品ID包涵0947（促销活动那个）时需要校验活动库存；商家为自营时需要校验逻辑库存，此时由于配置都是对库存校验进行作用，需要确定配置是互斥还是叠加起作用，若是互斥，优先使用哪一个？而如果是在业务空间的父子业务空间中的配置则取子业务空间中的配置项值。

通过以上的功能，我们能够做到在复杂业务体系中对能力、功能、页面/资源的可视、可配，而通过建设能力共享中心、业务组件库、服务组件库我们能够沉淀大量的数字资产，实现业务的复用，从而降低重复开发的工作。

在以上的所有业务逻辑中，还需要强调以下几点：

1. 由于所有的实体模型均在中台进定义，所以能够有统一的实体编号生成机制，而这个统一的机制是能够与业务身份所需要的信息进行关联，例如：需要在商品ID中预留6位，表示特定含义，而这种含义是需要被各个应用进行识别的；
2. 组件都是由生产方生产，可以被任一消费方进行调用，而不需要进行代码上的重复开发；
3. 业务中台的能力都是通过接口提供给上方的功能或者页面进行调研，所以所有应用对应的底层业务逻辑代码都是使用业务中台的代码；

以上就是我对整个电商业务中台如何实现可视、可配、可复用的整体思考，而这只是一个真正中台的业务及产品的部分，中台是一个涵盖组织、工程、业务产品、技术、运营等方方面面的系统工程，而这种多维度的复合系统其复杂度与以往的后台系统相比是指数级增长，而这种复杂性也是中台战略落地中的最大障碍。

本文由 @不可分类者 原创发布于人人都是产品经理 ，未经许可，禁止转载。

题图来自 unsplash，基于 CC0 协议