微服务架构 接口交互问题_中台和微服务架构规划模块划分和接口服务识别定义...

作者：人月聊IT

原文：https://www.toutiao.com/i6897541960978924043/

概述

对于传统企业微服务架构转型，基于中台和微服务思想进行传统IT系统的改造和优化是一个重要的趋势，特别是在企业IT架构逐步走向云原生技术的时候，微服务本身也是关键的要素。

而对于微服务整体的治理框架，我在前面给出一个大的框架图，如下：

整个微服务治理框架覆盖了微服务全生命周期管理，其中本身又分为微服务架构规划和微服务开发和运维两个关键的阶段。而在微服务架构规划阶段最重要的又是两件事情，即微服务模块的拆分和拆分后的微服务模块应该提供的API接口服务识别和定义。而这个本身也是后续多个微服务进行并行开发和持续集成的基础。

微服务划分大原则

注意这里讲的是大原则不是绝对原则。对于传统的单体应用在转到微服务的时候我们也是给出实际实践总结的一些大的原则做为参考。

原则1：划分为<10个微服务模块

一个传统的单体应用，在进行划分的时候最好不要超过10个微服务模块。注意这里指的业务功能模块不包括底层的系统管理，流程引擎等技术模块。

大家可能也会看到传统的单体应用一般也不会超过10个以上的一级功能菜单，因此在划分微服务的时候也可以参考一级功能菜单进行划分。

注：这个原则不绝对，比如一些类似OA，IT运维流程管理类系统，所有的业务功能流程之间基本没有任何耦合性，这种业务系统可以将微服务划分的更细也没有大的影响。

原则2：强数据关联模块不要拆分

简单来说就是有些系统基本就是围绕一个核心数据或业务对象展开的管理系统，比如我们说的资源管理系统，资产管理系统等。

对于这些系统的资源，资产等核心数据，建议都不要再进行微服务拆分，这些数据之间本身存在强数据关联和一致性要求，如果进行微服务拆分后续很难保证事务一致性要求。

原则3：以数据聚合驱动业务功能聚合

这个理解起来困难，简单来说就是微服务划分不仅仅是上层业务功能模块划分，而且包括了数据库的拆分，因此在划分微服务的时候首先要考虑数据域的拆分，基于数据和功能的CRUD分析来考虑数据的聚合关联要求。先拆分好数据域，再来考虑数据域里面有哪些业务功能。

原则4：从纵向功能划分思路到横向分层思路转变

在微服务划分里面，同样需要结合SOA的横向分层思想，即：

传统的单体应用你会发现在进行微服务划分的时候，本身微服务也体现出分层属性，即有些属于底层的业务对象，实体，数据提供类微服务；有些数据业务功能和规则类微服务；而还有些属于上层的流程和服务功能组合类微服务。

因此在进行微服务划分的时候应该从数据-》功能规则-》流程的分层模型维度综合考虑。

原则5：高内聚，松耦合的基础原则

当然，在进行微服务拆分的时候高内聚，松耦合的原则不变。而如何确保拆分的数据库，拆分的业务功能模块满足高内聚松耦合的原则。

在前面做企业架构规划分析的时候就经常谈到，在进行业务流程分析，业务架构和数据架构规划的时候，核心会产生业务流程，业务功能，业务数据对象等关键的信息，而我们要做的就是对这些关键进行交互矩阵分析来识别业务模块，业务数据之间的内聚特征。

微服务模块拆分

在IT应用架构规划大中台的概念下，实际上中台包括了技术中台和业务中台，对于技术中台重点是各个技术组件和技术服务能力的实现，而对于业务中台则主要包括了数据能力和业务规则处理能力的提供。

对于业务中台本身也是分层，包括了最基本的数据类中心和业务处理类中心。

数据类中心本身又包括了基础主数据类和核心共享业务单据类，比如我们看到的产品中心，用户中心，属于基础主数据类。而对于订单中心，库存中心则属于业务共享数据类。

业务处理类则主要是进行核心业务功能和逻辑的处理，类