载风月|互联网中台思想和建设方法到传统企业为何水土不服？( 四 ) 作者：人月神话

门户层还有一个重要的功能就是进行微服务模块的组装，这些模块组装后可以为业务用户提供完整的端到端业务流程功能支持，让最终用户的感觉就是在使用一个系统，没有系统不停切换的感觉。因此实际上在门户层不仅仅是简单的模块选择，也还可以做一些展现层的编排和组合工作。
对于微服务模块的灵活组装也是相当困难的，因为很多模块组装最终都是体现到模块提供的南北向接口的自动对接，这往往是比对服务组合和服务编排进行定制更加困难，对于这个问题后续将在单独进行讨论。
已有的IT架构和遗留系统如何构建中台？
这个估计是大部分企业都会遇到的问题。也是我们经常说的，传统企业中台的构建不能完全照搬互联网企业中台构建思路，而是需要考虑如何最大化的保护遗留IT资产。
即使企业是需要对外构建完整生态链的情况下，也不可能将企业内部已有的IT系统全部完整中台和微服务的架构思路完全推倒重新建设。
正是这个原因，我们提出一个重点，即：
传统企业在最大化保留遗留资产情况下，更多应该是适配方式构建一个能力中台。
在这里我将其称呼为能力中台意思就是，这个中台的服务能力不是全新产生的，而是对遗留IT系统能力的一种适配和聚合形成的。
即能力中台有点类似于我们传统在SOA架构下的ESB总线和服务共享平台建设。
那么这个能力中台和单纯的ESB总线区别在哪里呢？
其中最大的区别就在于这个能力中台，本身不是简单的接口服务接入和集成，而是对已有的遗留IT资产，数据库，接口API等进行了重构，适配，整合和重组，构建了一个满足新业务构建的完整领域服务能力层提供。
也就是说这个能力中台本身是可能存在业务代码和业务逻辑的。
如上面图所示，在构建新的中台能力服务层的时候，为了对已有的业务系统影响最小，我们需要重新构建中台能力接口，这个接口涉及到一定的适配和定制开发工作量。
具体接口的实现本身又包括了三种方式，即：

直接连接遗留系统的数据库，来重新开发接口服务。
通过遗留系统已有的JAR包引入，来重新开发接口服务。
通过遗留系统已有的WS或Rest等接口服务适配，来重新开发接口服务。

可以看到三种模式中对于数据库这种模式是对业务系统依赖最小的模式，但是这个模式本身也是需要我们重新大量完整性校验，业务规则的模式。这种模式本身就可以看到对遗留业务系统的部分业务规则和能力进行了重写，即这部分业务逻辑规则已经在朝中台能力层逐步迁移。
这种迁移形成的接口服务能力，一方面是构建全新的业务应用可以使用。而同时，我们建议是及时对于PMS或SCM等业务系统，如果有全新的业务模块需要开发，也完全可以基于中台已有的接口服务能力进行，只有这样才容易实现后续的业务系统逐步迁移到中台架构上。
数据重构和服务组合是中台另外一个关键能力
在中台能力构建的时候，一定要考虑数据重构和能力组合。
即中台的能力接口不是简单的数据库CRUD能力暴露，也不是已有的遗留接口的简单适配和接入。而是真正根据业务流程和业务需求驱动，失败关键的业务能力，将业务能力转变为服务。这种服务本身是粗粒度的，有明确的业务含义，有点类似我们在领域架构设计里面经常谈到的领域服务能力。
中台构建不要盲目的微服务架构化最后再次强调下，企业中台的构建不一定要全面微服务化。比如我们前面说的能力中台建设，更多的是适配已有的资产能力进行重构形成能力开放平台。