注: 图片来源于阿里云数字化转型解决方案配图

本周我准备再展开谈下企业中台规划和咨询方面的内容，在我们整个传统企业IT架构和数字化转型解决方案里面可以看到实际上就两个内容，一个是中台规划咨询，一个是云原生解决方案。前者偏向于业务和架构咨询，后者偏向于技术和架构实施。

大家都比较清楚，中台架构咨询和建设来源于互联网企业，然后逐步转入到传统企业内部，对于互联网企业基本也给出了中台建设的初步思路和方法论，但是如果简单的照搬这些思路到传统企业内部，往往行不通。那么我就需要首先分析互联网企业和传统制造类企业在业务和IT建设中的一些差异。初步比较关键点如下：

1. IT系统的用户受众： 互联网企业后台管理类用户少，而外部C端用户多；而传统企业大部分为内部用户

2. 前台应用的业务敏捷述求： 互联网对前台敏捷度要求高，而传统企业前台应用敏捷度要求并不高

3. 业务逻辑复杂度和强事务要求： 互联网相对低，而对于传统制造类企业IT系统业务逻辑更加复杂

当我把上面几点想清楚后，实际上对于传统企业中台构建的差异点或思路基本就想清楚。对于第1和2两点刚好对应到我们在进行横向分层构建上的差异，第3点对应到纵向拆分上的差异。具体为：

1. 横向分层上： 不是所有传统IT模块都要转为中台+前台模式，而是需要考虑受众和敏捷性要求

2. 纵向上： 不是微服务拆分的越细越好，而是要考虑业务逻辑和事务处理需求

如果企业内部中台构建不考虑上面两点，而是完全照搬互联网企业的中台多个中心+前台应用的构建模式，那么就是走极端，为了中台而中台。因此在企业中台构建时候又一个关键点思考，即：

企业内中台的构建不能脱离实际业务需求和场景，所有技术动作一定要追溯回业务需求和目标。

1. 横向分层：中台和前台分层构建思路上的思考

首先我们来看下横向分层上面的思考，即中台+前台构建思路上的差异思考。前面已经谈到过了企业内的IT系统建设更多的是面向企业内部员工或业务部门，其受众相对来说比互联网应用小很多。那么在这种情况下如何来构建中台，或者说中台+前台分层构建的思路从哪里入手呢？

1.1 企业业务需求从内朝外扩展和延申的时候

第一个思考点就是企业内部业务从内到外延申的时候，比如企业需要自建电商平台直接服务于外部的C端客户，比如企业需要和外部的上下游，合作伙伴对接的时候。当出现这种延申的时候，我们就可以理解为可以参考中台+前台构建思路来进行。

其核心原因就是，延申业务本身业务敏捷性述求高，而且延申业务不会产生企业需要的核心业务对象和数据，仅仅是产生中间过程对象。在这种场景下最合适进行中台+前台模式进行构建。

即当企业构建自建电商平台的时候，你完全可以参考互联网电商平台中台+前台的构建方式来构建。其次企业内部的围绕ERP为核心的IT系统需要开放能力给业务系统用，而这个时候你可以将企业内部的业务能力整合后形成一个能力中台再开放给电商平台使用。

这个能力中台可以理解为企业内部IT系统能力服务的代理和整合。

1.2 对应企业内部面向全体员工的业务系统建设

企业内部有很多IT系统，其中类似采购，财务等核心系统往往只面向供应链，财务部门。而对于人力资源，办公，报账平台等业务系统往往则是面对全体员工。正是由于人力资源管理，报销平台这些系统受众广，我们才看到企业内部业务架构和IT架构优化转型的时候回提出共享的概念。即经常看到的企业财务共享中心，企业人力服务共享中心。

面向全员的系统受众广，往往导致了业务敏捷述求高，再业务敏捷述求高的情况下我们就可以考虑优先采用中台+前台的建设模式进行构建。提升前台应用的敏捷响应度。

1.3 企业新构建的核心业务系统的外围系统，本身无核心业务对象数据产生

最后一种常见就是企业新构建的核心业务系统的外围系统，这类系统的特点就是本身无核心业务对象数据产生，更多是产生输入到企业内部核心业务系统的正式数据。

比如我们常见的企业招投标管理系统，这个系统存在的价值就在于产生招标评审通过的供应商信息导入到供应商或采购系统中，其他都是招投标过程业务数据。还有类似的就是我们常见的员工报销系统，员工报销系统同样不产生核心数据，更多是生成中间过程的报销单据，形成最终的应付凭证信息导入到企业内部的财务系统。这类系统本身往往就适合采用中台+前台模式构建。

2. 纵向切分：从单体应用到微服务化的思考

首先我想说明下，在中台和微服务的概念还没有提出的时候，我在企业私有云PaaS平台构建中就在谈企业内部信息系统建设的组件化拆分，提出了平台+应用构建，业务能力组件化，组件能力服务化。

在拆分后不再强调业务系统的概念，因为业务系统的概念和边界已经模糊了，业务系统已经被打散为多个微服务模块。对于这种思路我们再来回顾下更多的是纵向的思路。即：

原有业务系统拆分为多个业务组件，每个业务组件从数据库+中间件+业务逻辑和前台完全独立并松耦合。

也就是说原来的一个采购系统可能拆分为了招投标，供应商物料管理，采购请购，采购订单，采购执行监控，配额管理6个微服务组件。这6个组件都对应独立拆分后的数据库。这个和我们现在的微服务架构完全纵向拆分独立的思路完全是一致的。

但是我们仍然发现了一些问题，即业务组件间耦合性很强，导致后续应用开发，团队协同困难。其次，拆微服务必须是横向和纵向两个维度结合共同来拆，而不是监控的模块划分，这个我在后面几篇文章还要详细谈。那么对应纵向拆分，从单体应用到微服务化，我们实际需要考虑的关键点有哪些？

2.1 以是否拆分数据库的粒度来考虑业务组件粒度

在这里我提出以是否拆分数据库的粒度来考虑业务组件的粒度。比如供应商和物料两个核心对象的管理，我们发现两者耦合性相当强，因此我划分为一个大的业务组件为采购基础数据中心组件。

对应采购基础数据中心组件里面，我们的思考如下：

a. 只存在一个独立数据库，不再根据对象继续拆分

b. 只存在一个中台逻辑层提供服务，不再拆分

c. 可以构建多个前端或前台应用，这个粒度可以灵活拆分

即我们打破原来我们经常谈到的前端前台，中台，数据库必须1对1的模式。这样既兼顾了底层的数据库逻辑处理和事务管理要求。同时又满足了前端的细粒度构建。

2.2 对外服务提供和上层应用支持逻辑层组件拆分

这个也是我这次提出的一个观点，即再构建中台的时候，我们将对外服务能力提供做为中台层的核心模式，而对应上层应用支持的逻辑层不再纳入到中台层，这个逻辑层可以和上层应用紧绑定，可以走类似RPC或直接的jdbc模式进行数据库访问协同。

这种拆分的好处是我们真正将应用功能的逻辑层，和中台服务逻辑层关系和边界划分清楚。在这样划分后我们更加清楚后续中台的范围，包括在性能出现瓶颈后组件的弹性扩展范围。

相关文章