互联网中台思想和建设方法到传统企业为何水土不服？

在前面我已经分享了些关于中台，微服务，传统企业IT架构转型方面的文章。今天准备展开谈下互联网企业建设中台和传统企业建设中台的一些差异点，以及互联网中台建设方法论和架构设计转到企业后为何出现水土不服的问题。

最近这几年，在SOA和微服务后，中台这个词相当热，企业往往也出现两种明显分歧。一种就是中台和技术狂热型，恨不得企业的IT明天就能变成中台和微服务架构；还有一种企业就认为中台就是互联网企业概念炒作，用互联网概念来收割传统企业。因此今天准备对互联网中台到传统企业中台做下对比分析。

首先再次重申，中台本身是一个业务概念，其次才是技术实现。中台的出现一定是业务目标和需求驱动的，总结来说就是如下：

在前端的业务需求和模式快速变化的情况下，我们需要快速响应。

如何做到快速响应？

即从对业务能力的从头开发，变化为对已有业务能力的组合。因此我们需要将共性业务能力进行整合，将这些业务能力以可共享的API服务方式提供给前台使用。

所以你再回顾互联网企业业务组织和架构，你会发现一个关键点，即你看到的类似库存中心，订单中心，结算中心等本身就是业务组织部门或业务单元。而这些业务组织部门本身又对应到业务模块的微服务实现。即：

业务组织部门或单元=》微服务模块实现之间是完全对应和映射的。

简单来说，互联网企业在运营的过程中，业务组织架构本身就已经是共性业务能力下沉，业务组织单元微服务化的了，其次才是技术实现的微服务化。

业务或运营模式变化快才需要快速响应

对于互联网企业我们一定要比较和传统企业关于用户群的一个区别。互联网企业是直接面对最终的B端或C端用户，而传统企业IT系统是面对内部的业务人员和管理人员。互联网企业本身的产品化运营往往就需要配合用户个性化多变需求快速灵活响应，否则就失去机会。

类似互联网的电商平台，你可以看到类似团购，秒杀，企业福利，支付理财，自营，toB或toC等各种运营模式不断在变化以满足业务需求。而这些前台应用的构建都需要用到采购，物流库存，财务结算，用户，产品管理等共性能力。

那么我们期望自然是能够复用和组装这些能力，而不是再去重新开发。

正是由于这种原因，我们需要将共性能力下沉，形成中台各业务单元。如果从业务上来说就是中台里面的各个业务组织部门，能力都相对稳定，不会经常变化。但是前台出现新商业模式后，任何一个新前台应用构建都可以单独组建一个新的业务团队，这个业务团队再对应到前台应用这个微服务模块技术实现。

传统企业和互联网企业中台差异化分析

在了解互联网中台建设背景后，我们再来回顾传统企业是否需要一个完整中台就更加容易点。即我们基于互联网企业出现中台的几个背景要素进行分析来说明。

其一：传统企业业务是否需要像互联网应用一样足够敏捷？

对于企业的完整价值链来讲，我们可以将其分为两个关键阶段。其一就是围绕产品从无到有的核心研发，供应链和生产制造价值链。其二是生产出来的产品如何卖出来并交付到最终消费者手里面的销售运营价值链。

对于大部分企业来说，更加重要的是供应链核心流程，而对于销售这块往往本身就是依托于已有的各大电商平台，或别人的分销体系。除非你自己去构建了一个完整的分销线下网络，类似格力这种自己分销网络体系。

对于企业的供应链核心价值链，企业本身的计划，生产运营模式不可能随时都在变化，同时面对的又是内部用户需求本身时间容忍度也大。

因此IT系统完全不需要类似互联网应用一样的敏捷程度。

其二：传统企业的业务架构和组织模式是否先进行了重构

对于大部分传统企业来说，真正困难和难以推行的都是业务组织架构的重组，其次才是IT系统的建设。很多CIO希望通过IT系统建设或者说当前的中台，微服务来倒逼业务架构重构，往往都是一厢情愿，到最后往往根本推行不下去。

当我们观察大部分企业的时候，你会看到企业本身的业务架构往往就没有中台化。

我们可以举些常见的例子，比如一个制造企业有多个子公司，你会看到各个子公司本身的财务，供应链，售后这些本该业务下沉和集中化的本身就没有统一。在企业内部业务上就没有我们经常谈到的共享中心的概念。

在业务组织本身就没有共享化，拆分化的情况下推进中台往往就是难上加难。

其三：前端应用是否不断推陈出新

在前面我已经强调了，传统企业的内部IT往往就是支撑企业核心价值链一套业务，最多也就是PC端BS应用和手机端两种展现模式，但是本质还是一套应用系统。

对于供应链核心价值链来说根本就不存在要不断推出新应用的可能。只存在会出现业务流程的情况，而对于新业务流程的出现往往基于传统SOA架构思路完全可以解决。即将遗留系统接入和适配，将服务能力共享开放即可。

传统企业什么时候需要一个中台？

经过上面分析我们可以看到，大部分企业并不需要一个类似互联网企业一样的中台。那么什么时候需要这个中台呢？

也就是什么时候会出现类似互联网企业一样的背景需求。

还是会到前面的分析，简单来讲就是：对于本身就是做C端消费类产品的企业，本身又希望实现对终端用户的端到端触达能力，同时营销价值链本身又是完全自建的情况。这种企业往往中台规划建设的需求最强烈。

我们也看到当前很多上中台的企业更多就是属于上面场景的企业，而且中台的构建更多的是面向自己的电商平台，CRM营销网络，面向C端的前台应用需求。

在这种情况下，企业需要去构建一个中台来满足前台应用敏捷化的需求。

也就是说这个企业中台已经不再是简单的满足内部业务系统，内部用户的使用，而是更多的打破了企业边界，面向外部的消费者用户，或者产业链上的生态合作伙伴的需求。

在这种场景下，我们就需要对企业内部已有的业务能力进一步包装和抽取共性，然后将共性能力以API接口服务的方式提供给前台应用。

其次，就是一个大的集团性企业，本身在进行业务重组，将共性业务能力形成共享中心的方式进行统一的情况下，需要去构建一个中台。这个也和我们中台产生背景思路一致。

比如前面谈到的，一个生产制造企业，本身有很多子公司或工厂，但是你可以看到企业的供应链能力，营销服务能力，售后服务能力完全是可以共享和复用的，这些业务能力应该进行整合和统一。真正差异化的仅仅是制造各类产品不同的制造单元。

在这种明确的业务驱动和业务整合背景下，往往也是最佳的构建中台场景。

传统企业更多的是转型到平台+应用构建模式

这里的平台我们指技术平台，或者对应到中台概念里面的技术中台。这个平台即我经常说到的私有云PaaS平台。而私有云PaaS平台的重点就是将企业内部业务系统构建需要的共性技术服务能力下沉并统一建设。这些共性技术能力包括了中间件，数据库资源池，也包括了类似4A，流程引擎，消息，缓存，文件，任务调度等共性技术服务能力。

为何平台建设如此重要？

我们要意识到只有原业务系统中的技术平台完全下沉并移出，上次的业务系统模块才能够实现彻底的组件和微服务化架构。

这个我在前面一篇文章专门谈到过，可以参考：

SOA和云计算-企业私有云PaaS平台建设实践

同时对应平台层规划建设，我们理解重点应该包括：

步骤1:4A和流程平台的下沉和能力开放

这个是我谈的最多的问题，即在实施微服务架构转型的时候必须将4A（也可先狭义理解为原业务系统的系统管理模块）和流程引擎下沉到平台层共性建设，或者说优先要将这两个模块作为微服务模块剥离出来，同时给上层的业务组件模块提供API服务接口能力。

对于4A模块剥离后，我们希望的是涉及到人员，组织，用户，权限等能力的获取都是通过服务接口实时查询获取，这些基础主数据信息也不要落地。在进行这样实施的时候确实会增加上层业务系统的改造工作量。对于流程平台的签出相对来说比较容易，最主要的还是给业务模块提供流程启动，暂停，获取待办已办列表等关系服务接口信息为主。

进行4A和流程平台的剥离核心目的仍然是是的后续需要进行拆分的业务模块只包含业务功能，而不再包含共性的技术能力功能。

步骤2：基础主数据模块能力独立建设

这是我们谈的第二个重点，即希望将提供共享基础主数据的功能单独剥离出来进行独立建设，比如建设独立的主数据平台或叫提供基础主数据的各个数据中心模块。然后数据能力以数据服务的方式暴露出去供上层业务系统使用，同样我们希望上层业务模块在使用这些基础主数据的时候最好主数据不落地，实时用实时查。

在传统PaaS平台建设中会涉及到MDM主数据平台的建设，到了彻底的微服务架构可能并不存在主数据平台的概念，而是各个类似产品中心，供应商中心，客户中心的各个微主数据中心模块，这些微服务模块也是我们常说的中台的核心数据能力提供中心。

要规划和建设中台，首先要考虑的就是这种基础数据中心，其次才是提供业务支撑和业务逻辑处理的中心。

步骤3：及早进行统一门户的建设

要注意，在各个微服务模块建设完成后，单个微服务模块本身是不能提供支撑完整业务流程的能力。对于用户来说并不关心是否进行了微服务架构化，而是关心涉及到业务流程处理的功能和操作是否能够很方便的在一个业务应用里面操作和完成。

而这些业务模块基于业务流程，基于业务场景和使用部门的组装和展现，就需要在门户层完成。对于统一门户不仅仅是提供统一认证和单点登录，也还包括了统一的待办集成和任务处理，统一的消息通知等共性功能能力。也就是说，只要是各个微服务模块共性的一些需要展现的能力，都可以集中化到统一门户层去集中处理和展现。

门户层还有一个重要的功能就是进行微服务模块的组装，这些模块组装后可以为业务用户提供完整的端到端业务流程功能支持，让最终用户的感觉就是在使用一个系统，没有系统不停切换的感觉。因此实际上在门户层不仅仅是简单的模块选择，也还可以做一些展现层的编排和组合工作。

对于微服务模块的灵活组装也是相当困难的，因为很多模块组装最终都是体现到模块提供的南北向接口的自动对接，这往往是比对服务组合和服务编排进行定制更加困难，对于这个问题后续单独进行讨论。

已有的IT架构和遗留系统如何构建中台？

这个估计是大部分企业都会遇到的问题。也是我们经常说的，传统企业中台的构建不能完全照搬互联网企业中台构建思路，而是需要考虑如何最大化的保护遗留IT资产。

即使企业是需要对外构建完整生态链的情况下，也不可能将企业内部已有的IT系统全部完整中台和微服务的架构思路完全推倒重新建设。

正是这个原因，我们提出一个重点，即：

传统企业在最大化保留遗留资产情况下，更多应该是适配方式构建一个能力中台。

在这里我将其称呼为能力中台意思就是，这个中台的服务能力不是全新产生的，而是对遗留IT系统能力的一种适配和聚合形成的。

即能力中台有点类似于我们传统在SOA架构下的ESB总线和服务共享平台建设。

那么这个能力中台和单纯的ESB总线区别在哪里呢？

其中最大的区别就在于这个能力中台，本身不是简单的接口服务接入和集成，而是对已有的遗留IT资产，数据库，接口API等进行了重构，适配，整合和重组，构建了一个满足新业务构建的完整领域服务能力层提供。

也就是说这个能力中台本身是可能存在业务代码和业务逻辑的。

如上面图所示，在构建新的中台能力服务层的时候，为了对已有的业务系统影响最小，我们需要重新构建中台能力接口，这个接口涉及到一定的适配和定制开发工作量。

具体接口的实现本身又包括了三种方式，即：

直接连接遗留系统的数据库，来重新开发接口服务。

通过遗留系统已有的JAR包引入，来重新开发接口服务。

通过遗留系统已有的WS或Rest等接口服务适配，来重新开发接口服务。

可以看到三种模式中对于数据库这种模式是对业务系统依赖最小的模式，但是这个模式本身也是需要我们重新进行完整性校验，业务规则的模式。这种模式本身就可以看到对遗留业务系统的部分业务规则和能力进行了重写，即这部分业务逻辑规则已经在朝中台能力层逐步迁移。

这种迁移形成的接口服务能力，一方面是构建全新的业务应用可以使用。而同时，我们建议是及时对于PMS或SCM等业务系统，如果有全新的业务模块需要开发，也完全可以基于中台已有的接口服务能力进行，只有这样才容易实现后续的业务系统逐步迁移到中台架构上。

数据重构和服务组合是中台另外一个关键能力

在中台能力构建的时候，一定要考虑数据重构和能力组合。

即中台的能力接口不是简单的数据库CRUD能力暴露，也不是已有的遗留接口的简单适配和接入。而是真正根据业务流程和业务需求驱动，实现关键的业务能力，将业务能力转变为服务。这种服务本身是粗粒度的，有明确的业务含义，有点类似我们在领域架构设计里面经常谈到的领域服务能力。

中台构建不要盲目的微服务架构化

最后再次强调下，企业中台的构建不一定要全面微服务化。比如我们前面说的能力中台建设，更多的是适配已有的资产能力进行重构形成能力开放平台。

我始终认为：企业业务共性能力下沉，并形成统一服务对前台提供。

这样满足这个目标要求，构建的就是企业中台，这个中台是否一定微服务化反而不是重点，只是说微服务化后，整体的解耦，扩展性更强而已。

但是一定要注意到，引入微服务本身对企业IT治理管控水平要求相对高。如果企业本身的IT成熟度没有达到一定阶段，显然是不可能推行实施微服务架构的。这个道理前面已经谈到过，在企业IT建设中，如果连粗粒度的业务系统以及它们之间的集成都管理不好，那么更没有能力管理细粒度的微服务模块。

那么如果企业IT成熟度达到一定水平，在推广微服务架构还存在的难点如下：

首先是架构设计能力的显性化，即架构设计这个工作的输入，输出和过程需要更加的显性化出来形成团队都认同的标准工件。一个业务系统没有拆分开时候，虽然有架构设计和组件划分，但是这个工作是属于团队内部的事情，即使架构设计不合理，在后期集成也可以通过诸多变通方式解决掉。而现在是不同的微服务模块可能分派到两个独立的团队开发，原来属于自己内部黑盒的问题变为团队间问题。

简单来说你原来藏着或没做规范的东西太多，而现在这些不能再藏着掖着了，当真要把这些东西拿出来的时候，你才会发现你原来架构能力是有欠缺的。正如我们理解了一个东西，那么要让我们清楚的讲出来困难，那么我们的理解有欠缺。对于我们能讲清楚的东西，要系统写下来有困难，那么说明我们讲的结构和条理有欠缺。

其次管控要求和规范体系的建立，对于管控要求可以看到如果两个微服务模块分给同一个团队开发，如何才能保证开发的团队保持两个模块的完全独立和解耦，两个模块间不会出现相互交叉的数据库直接调用，也不会存在直接绕开Service接口的其它耦合调用？这些如果没有完整的管控和检查体系我们很难约束。

微服务架构下导致的开发复杂度增加

只谈微服务架构的松耦合和高扩展性，而不谈开发和集成复杂度的都是耍流氓。

实际上当前很多企业对微服务架构并没有如此迫切，互联网很多企业推行微服务架构更多的还是考虑到巨大的业务并发量下的系统弹性扩展能力，而实际大多数企业内应用往往并没有如此海量并发。

其次，即使在并发量增加的情况下通过进行代码本身的优化，数据库调优或者升级硬件服务器资源都可以较好解决性能问题。而做这些事情投入的成本远远小于微服务架构带来的开发复杂度增加成本，后期的运维管控成本。

要做到完全微服务模块独立，微服务架构下最大的一个变化就是数据库也拆分开了，原来的一个业务系统如果分为5个微服务模块，那理论上就是5个独立的后台数据库，而且数据库间还不能随便相互连接和访问。只有这样微服务模块才能做到独立部署和管理。

由于数据库拆分带来两个问题，其一是我们原来很简单的一个跨表查询操作现在无法做了，我们必须调用两个微服务模块提供的服务，查询到数据后再到逻辑层进行组合。其次最大的问题就是如果一个业务操作需要同时更新两个微服务模块的数据，由于服务本身无状态，导致了这种分布式事务问题很难解决。

企业内业务系统很大一个特点就是业务逻辑和规则相对互联网更加复杂，而且有更高的事务一致性要求。正是由于这个原因，无法解决好分布式事务的问题都将直接导致后续数据不一致和业务错误。

微服务架构下导致的集成复杂度增加

任何一个微服务模块在外部协同上都存在两个点，一个是模块本身要消费和调用其它微服务模块提供的服务接口，另外一个是模块本身又需要将其业务能力暴露为服务接口给其它微服务模块使用。

如果一个微服务模块要同时支撑PC端和APP端，可以看到微服务模块暴露的服务还需要统一提供给前端的展示用。那么可以看到一个微服务模块需要完成自身组件层和展现层间的集成，同时又需要完成多个微服务模块组件间的横向服务集成。

如果我们将消息，日志，流程，4A等能力下沉到平台层微服务模块，那么一个组件要跑起来还涉及到和平台层的多个技术类微服务模块集成。在如此复杂的集成场景下，要将复杂的跨多个微服务模块的横向端到端业务跑通，其涉及到的模块数，接口数都远超原有单一系统的模式。

一个业务系统如果没有拆分为微服务模块，那么其它内的模块间集成和集成测试是系统内部的事情，但是一旦拆分为多个微服务模块，那么这种集成就变成外部第三方的事情，或者必须要显性的事情。集成复杂度会大增，同时系统健壮性和稳定性下降。

微服务架构下的运维问题

在实施了微服务架构后，运维的复杂度也是成倍增加，任何一个微服务模块出问题都可能影响到整个业务应用的功能使用。我们在运维时候不仅仅要健康单个微服务模块，还需要健康所有的接口服务监控状态。

如果跟Docker集成了，我们看到整个性能监控和问题分析都会变麻烦了，没有实施微服务架构前发现问题，我们直接可以看应用服务器上类似tomcat或jboss日志，而实施了微服务架构后，应用容器已经是自动部署和动态分配的，原有的故障诊断模式行不通，而需要PaaS平台本身提供完整的预警和日志分析能力。