基于企业自建电商平台来思考中台和微服务架构演进

Posted 2021-04-14 IT外包

对于传统企业IT架构微服务转型，包括企业中台构建的方法论等，我在前面已经专门写过专门的文章进行说明，至少在整个框架和思路上基本完整。

但是实际上对于大部分中大型企业来说，往往企业内部IT已经建设相当长一段时间，基本形成了围绕ERP的供应链，生产，财务，营销管理体系。那么在这种情况下面临新的需求，如何进行内部IT转型或重构才是最重要的。

比如一个传统企业，在消费互联阶段，希望能够构建自建的O2O线上线下整合的一体化电商平台，那么在这种场景下新的电商平台完全基于类似互联网电商平台的方式去构建没有问题。但是你可以看到新的电商平台本身涉及到的供应链，物流，财务等仍然是需要使用内部已有IT的能力，而不是自建再重新搞一套。

在这种场景下，要完全推翻内部遗留IT去支撑新构建的电商平台不可能，新电商平台也无法基于类似互联网全独立建设而不和内部协同。

不管是谈消费互联和产业互联，原来的内部IT要打破边界走出去，通过能力开放的方式去实现更多的端到端连接和协同。那么企业原来已有的IT能力如何去平滑演进，如何去支撑，才是最需要去思考和解决的问题。

今天我准备就基于一个传统企业在内部IT已经基本成熟的情况下，如何去支撑构建一个对外自建电商平台来思考下整体中台构建和微服务架构演进思路，特别是里面的一些关键点和问题。

企业内部的IT应用架构简化

我们对企业内部的IT应用架构做下简化，企业本身是涉及到生产制造的电子类企业。前期企业已经围绕ERP构建了自建的整体IT应用架构。

在整个架构中底层有基础的技术平台，同时构建了MDM主数据管理平台，实现了基础主数据的统一管理，在上层是统一门户。

中间核心系统包括了两个方面的内容，也是我想表达的，即：

• 横向是端到端的供应链线条，同时财务也需要贯通

• 纵向是核心的生产制造线条，从PLM研发管理到ERP计划到MES执行层

整体应用我们简化为下图：

在这里专门说明下CRM系统实现外部所有订单的统一入口，其中包括了自建门店订单，也包括了各个大的B端分销商订单，同时CRM系统本身也完成了企业在天猫，京东自营商城的接口对接工作。CRM系统统一接收订单和客户，再流转到内部的ERP和物流类系统处理。

自建电商平台

前面已经谈到企业是在已经的线下销售渠道，线上天猫和京东销售的情况下，自建自营的电商平台。企业本身还生产电视，电视也内嵌有APP应用，也就是说APP应用本身也是新的商品和服务的购买渠道。

客户构建电商平台目的是对APP，PC端电商，电商内嵌小应用全部进行统一管理，同时也希望实现对C端用户的直接触达能力，包括我们常说的完成从公域流量到私域流量的转换。

全新构建一个电商平台，我们完全可以参考互联网中台+应用的方式，同时对中台进行微服务化能力中心拆分，形成一个电商平台的应用架构，类似下图。

中台能力究竟在哪里？

这个是我们必须要回答的一个关键问题，是否就如上图一样，构建的各个能力中心就是电商平台的中台能力层？

实际上我们看到对于商品信息，用户，订单当前都是已经在CRM系统中进行统一管理和配置；对于库存和配送当前在WMS系统进行管理，对于结算当前在ERP系统中进行管理。对于营销和评价，传统的CRM系统暂时没有涉及这两块内容的独立。

也就是说电商规划的多个中台中心，实际上本身并不是能力的最终提供，而是将最终的需求又转发回企业内部IT应用系统去处理和解决，那么电商的中台层仅仅是中台代理和路由。

我们可以分析下梳理的电商C端客户销售流程来进行说明如下：

基于流程交互分析，可以进一步分析自建电商和内部IT系统间的接口集成点。

可以看到自营电商产生的订单信息还是需要首先导入到CRM系统进行统一归口，由CRM系统处理完成订单后，再安排后端的物流系统进行发货，最终的库存和物流管理仍然在企业内部的WMS系统完成，而财务类管理结算在ERP系统里面完成。

你新建的电商平台可以有各个能力中心，但是更多起的是代理路由作用，真正的能力提供还是内部IT的各个业务系统来提供能力，具体如下：

不要以传统集成的方式来构建新电商平台

上面这个图你可以理解为在多年前企业客户实际构建自建电商平台的方式。在这个图里面可以看到电商平台本身是按照中台+前台的模式进行构建。同时电商中台也进行了微服务能力中心拆分，即包括了商品中心，用户中心，订单中心，库存中心等各个微服务能力中心。

整体看起来挺不错。

在实际构建这个电商平台应用的时候，我们谈到传统企业内部的IT能力要考虑复用，同时有一个统一的服务目录库提供和统一的API能力接口出口。

即我们说得通过传统的ESB总线或轻量的API网关来实现内部IT接口服务能力的统一注册接入，并能力开放给上层的电商平台使用。那么聚合了内部IT应用的可复用接口能力并对外统一开放，形成的服务能力中心或能力开放平台。

这个能力开放平台完全可以作为企业内部IT能力聚合后的能力中台。

传统集成方式下数据多点落地

在上面这种方式下，整体看起来不错，构建了电商中台，同时又将内部IT的接口服务能力通过能力开放平台对外开放并实现统一的管理。但是整体还是接口集成方式，接口集成方式的一个典型特点就是同样的数据并没有集中化管理并提供能力，而是数据在多个业务系统中通过接口集成方式落地存储。

比如上图中商品信息和用户信息，订单信息同时在电商平台和CRM系统存在。对于库存和物流信息同时存在于电商平台和WMS系统。这些重要的单据信息，通过接口服务在多个业务系统之间不断地传递，形成了多套数据。

数据的多点传递首先带来的数据不一致性问题，同时由于数据在多个业务系统中存在，因此对于数据的管理能力也同时存在于多个业务系统中。比如上面说的电商平台，CRM系统都同时存在对订单的管理能力，对订单的业务规则处理能力等。

因此我们提出不要以传统集成方式来考虑中台构建。

回到中台核心，即中台的构建本身应该是抽取各个业务系统中共性可复用的业务能力，对这部分共性业务能力统一下沉管理，然后再提供可共享的业务服务能力接口。

新简单的电商平台实际只是电商前台应用

在前面我已经谈到构建的电商平台中的各个能力中心更多的需求的路由和转发，最终还是回到内部IT各个系统来处理各种业务能力。那么新构建的电商平台你会发现更多的应该理解为一个前端的电商应用平台，而对于中台能力应该重新基于内部IT能力重新规划和抽取。

我们来思考下订单有哪些入口？

传统的CRM系统主要处理了自营门店，经销商的订单入口。同时对接了天猫，京东自营电商的订单入口。当前我们增加了电商平台后又增加了自营电商平台的订单入口。

而以上全部都是订单的入口点，而这些订单的入口和统一管理应该通过一个统一的订单中心来进行完成，即订单中心不应该同时在电商平台，CRM中分别构建，而是应该共性抽象后单独构建。包括我们说的用户中心，商品中心也是同样的道理。

大家可以理解下上面这个图：

即我们需要对传统IT系统里面涉及到的订单，用户，商品交给关键能力和新构建电商平台的这部分能力进行整合和下沉，形成独立的订单中心，商品中心和用户中心。

即这个能力不是按原有方式直接在CRM系统里面进行能力扩展，而是直接进行剥离。这个时候CRM系统只保留传统分销类业务管理能力，这部分能力最终的目的也是形成订单，最终和订单中心进行协同。

也就是说我们希望订单只在一个中心进行落地，进行统一管理，其它任何前端应用对于订单的需求都是应该调用订单中心的接口能力来进行完成。在这个过程中我们看到CRM应用本身进行大重构，进行了前台应用和中台能力的拆分工作。

可以将CRM系统要进行上面这种拆分和重构动作比较大，也是真正最难推进的地方。但是如果不这样做，我们中台思想，能力共享思想实际并没有彻底贯彻和执行，仍然还是传统集成的方式来构建中台，这个时候新电商中台和内部IT系统完全是两张皮运作。

这也是我经常强调的，不是简单地构建了一个满足中台和微服务架构的新电商平台，并和内部IT进行了协同和集成就完成了企业内部IT的数字化转型和数字中台构建。

从整个企业数据中台构建角度，中台的构建必须是共性能力下沉，然后统一提供能力，而不是共性能力去通过接口集成。共性数据能力一共实时使用和消费，而不是通过接口多点落地。

企业对外能力开放和协同

企业数字化转型，从消费互联到产业互联，构建自建电商平台可能只是一种打破企业边界对外协同开放的一种形式。而类似的形式还包括了端到端供应链追溯平台，数字化营销平台等很多新的应用模式和新应用平台构建。

那么这些新应用平台实际上都需要使用到内部的IT业务系统能力。那么各个新的应用都独自去和内部IT应用系统做对接显然是不合适的。

因此我们需要在内部IT系统的基础上，抽象一个对外的能力中台，提供统一的内部能力API接口对外开放。具体如下：

注意这个能力中台的构建本身也包括了两种方式。

其一是简单额进行API接入服务的注册和接入，那么只对API接口服务进行路由转发，进行安全，日志，流控等管理能力。

其二是将原来IT系统中的能力剥离出来，在能力中台构建新的能力中心实现该能力。

不论是哪种方式来构建能力中台，我们希望解决的问题都是能力中台提供的API接口服务能力真正的可复用，能够用于上层业务应用的快速构建。同时我们不希望能力中台的构建，导致又新增一份数据拷贝和集成，这样反而导致数据一致性和实时性出现问题。

能力是向上聚合还是向下沉淀

在构建能力中台的时候一定会遇到一个问题，就是对于能力是已有能力向上聚合，还是将共性能力下沉然后再统一提供。

比如我们前面谈到的，如果原来对于采购类供应商在SCM系统中管理，非采购类供应商在ERP系统管理，合作伙伴类供应商在CRM系统中管理。那么当上面的供应链追溯应用需要访问供应商信息的时候，这个时候实际有两种方式来解决，如下：

而实际上在中台能力中心构建的过程中，我们更希望的是共性能力先下沉，提供统一的服务能力给外部前台应用，而不是简单的将内部已有能力进行聚合后能力开放。

简单来讲中台建设的思想，即：

• 对于下层能力可复用，上层基于能力进行组装，是SOA思想

• 而共性能力不是简单集成，而是统一下沉后集中化建设，是云的思想

因此再重新回顾中台，实际上同时包括了SOA，云和微服务三方面的思想融合。

能力组合，中台能力进一步提升

中台已经拆分为多个能力中心，那么我们在前台应用实现的时候，往往需要调用中台多个能力中心的API接口服务进行组装和编排。

在传统的SOA架构体系里面，这个服务编排工作可以通过类似BPEL来实现。而在当前微服务架构体系下，更多的是通过代码来实现服务的组装和编排工作。

如果我们前台应用只有电商平台，那么这种编排没有任何问题。

但是当前台应用还包括了类似供应链追溯平台，数字化营销平台的时候，往往就存在对多个能力中心的组装能力也是可复用的，也就是我们说的组合服务能力。

比如我们在电商购买商品后，需要进行支付。

而一个支付动作往往不仅仅是完成支付，里面还涉及到支付成功后需要对用户积分进行调整同时重算用户等级，同时还需要给物流中心发送货物配送请求。

简单来说，整体逻辑如下：

即用户进行支付只需要调用支付组合服务即可，对于后续的支付，积分和等级计算，发货通知等都通过组合服务内部完成。由组合服务来完成事务一致性控制或事务补偿。

在前面一篇文章我就指出，真正的中台柔性实际上体现在中台能力组合层本身的可配置能力上。如果这个可配置能力强，那么前台应用中通过代码进行服务组装的能力可以全部下移到中台能力组合层去完成。

而这个共性可复用能力提供，服务组装编排本质还是SOA思想。也正是这个原因，我们多次强大你要进行中台规划设计，首先还是要理解SOA，云计算，微服务，领域建模的思想。

图片和内容源自网络分享，若有侵权，请联系删除！