企业微服务架构转型-前后分离

在上一篇讲完中台后，再来分析下在微服务架构实践和实施过程中，在传统企业业务系统转型和迁移到微服务架构过程中比较重要的一点改变就是前后分离。

首先在重申下微服务架构的几个关键点：

1. 原有业务系统拆分为多个离散自治的组件或微服务模块，从数据库到前端完全独立自治。

2. 从单个微服务模块来看，能够实现前端和后端分离为独立的组件

3. 不仅仅是微服务模块间通过RestAPI交互，对于前后端也通过轻量的Rest API接口服务交互。

再简单点来说，如果一个已有的业务系统拆分为4个独立的微服务模块的话，实际在拆分后会有4个独立的数据库实例ID，4个独立的前端JAR包，4个独立的逻辑层JAR包，N个RestAPI服务接口。

对于任何一个企业来讲，只要经营和生产方向没有做出大的转型，其涉及到的供应链，生产，财务流程，包括涉及到基础主数据和核心共享业务单据基本都是固定的，这些是识别中台战略中各个中心的基础。在这里有一个关键的观点如下：

在中台的各个中心规划，定义和建设好后，后续在企业业务发展的过程中，不应该再增加任何大的中心，而是仅仅增加了前端应用类组件和模块。这些模块的构建更多是充分复用已有的各个中心暴露的接口服务能力，为各个中心提供数据，或者消费和使用各个中心已有的数据或业务规则能力。

一个中心在构建的时候，能力的开放性不仅仅体现在暴露已有的数据服务能力，而更加重要的是提供外围数据导入的能力，或者类似网管里面的叫法，提供完整的南向接口和北向接口服务能力。

我们可以举例来说，拿订单中心的构建来说：

最初我们考虑的更多的是正式生效的订单能力以RestAPI接口服务的模式暴露出去，给其它微服务模块和前端应用使用，即已有数据以查询服务方式进行服务能力开放。但是对于订单的生产后续会产生类似通过招投标模块，通过合同系统，通过计划管理模块等多个外部渠道都可以产生订单，即订单的生成不一定非要在订单中心模块中完成，而是可以从外部导入，那么这个时候就需要提供完整的订单导入类接口。

再拿简单点的方式来说，按照完全的前后端分离的构建模式，订单中心的构建更多仅仅是提供订单数据的存储，订单生产的业务规则校验，订单能力的发布，而对于订单如何录入，如何消费等前端应用功能全部不在订单中心中构建，订单中心只把数据和业务规则管理好即可。

在ERP系统的实施过程中，可以看到围绕ERP和ERP外围系统建设很多时候类似该思路，即ERP中的采购，库存等模块进行了中心化，更多的只是提供服务能力接口处理，管理好最终的数据和业务规则逻辑，而对于数据的导入全部都是外部的类似采购系统，合同系统，项目管理系统等外挂系统导入。

因此对于前后分离一般包括了两种典型的实施场景：

1. 中台中的各个中心完全没有前端应用，不录入单据，只提供服务能力接口。

2. 中台中的各个中心既含前端，也含后端逻辑，但是提供完整的南向开发能力接口支持数据导入。

不论是上面哪种方式，我们建议的仍然是对于前端和后端能够完全分开，后端重点是形成完整的提供领域服务能力的微服务模块，前端重点是能够实现接口服务的组合和拼接，形成满足业务需求的功能。