中台和微服务架构计划-模块划分和接口服务识别界说-hth华体会体育全站app

概述对于传统企业微服务架构转型，基于中台和微服务思想举行传统IT系统的革新和优化是一个重要的趋势，特别是在企业IT架构逐步走向云原生技术的时候，微服务自己也是关键的要素。而对于微服务整体的治理框架，我在前面给出一个大的框架图，如下：整个微服务治理框架笼罩了微服务全生命周期治理，其中自己又分为微服务架构计划和微服务开发和运维两个关键的阶段。而在微服务架构计划阶段最重要的又是两件事情，即微服务模块的拆分和拆分后的微服务模块应该提供的API接口服务识别和界说。

而这个自己也是后续多个微服务举行并行开发和连续集成的基础。微服务划分大原则注意这里讲的是大原则不是绝对原则。对于传统的单体应用在转到微服务的时候我们也是给出实际实践总结的一些大的原则做为参考。原则1：划分为<10个微服务模块一个传统的单体应用，在举行划分的时候最好不要凌驾10个微服务模块。

注意这里指的业务功效模块不包罗底层的系统治理，流程引擎等技术模块。大家可能也会看到传统的单体应用一般也不会凌驾10个以上的一级功效菜单，因此在划分微服务的时候也可以参考一级功效菜单举行划分。注：这个原则不停对，好比一些类似OA，IT运维流程治理类系统，所有的业务功效流程之间基本没有任何耦合性，这种业务系统可以将微服务划分的更细也没有大的影响。

原则2：强数据关联模块不要拆分简朴来说就是有些系统基本就是围绕一个焦点数据或业务工具展开的治理系统，好比我们说的资源治理系统，资产治理系统等。对于这些系统的资源，资产等焦点数据，建议都不要再举行微服务拆分，这些数据之间自己存在强数据关联和一致性要求，如果举行微服务拆分后续很难保证事务一致性要求。

原则3：以数据聚合驱动业务功效聚合这个明白起来难题，简朴来说就是微服务划分不仅仅是上层业务功效模块划分，而且包罗了数据库的拆分，因此在划分微服务的时候首先要思量数据域的拆分，基于数据和功效的CRUD分析来思量数据的聚合关联要求。先拆分好数据域，再来思量数据域内里有哪些业务功效。

原则4：从纵向功效划分思路到横向分层思路转变在微服务划分内里，同样需要联合SOA的横向分层思想，即：传统的单体应用你会发现在举行微服务划分的时候，自己微服务也体现出分层属性，即有些属于底层的业务工具，实体，数据提供类微服务；有些数据业务功效和规则类微服务；而另有些属于上层的流程和服务功效组合类微服务。因此在举行微服务划分的时候应该从数据-》功效规则-》流程的分层模型维度综合思量。原则5：高内聚，松耦合的基础原则固然，在举行微服务拆分的时候高内聚，松耦合的原则稳定。

而如何确保拆分的数据库，拆分的业务功效模块满足高内聚松耦合的原则。在前面做企业架构计划分析的时候就经常谈到，在举行业务流程分析，业务架构和数据架构计划的时候，焦点会发生业务流程，业务功效，业务数据工具等关键的信息，而我们要做的就是对这些关键举行交互矩阵分析来识别业务模块，业务数据之间的内聚特征。

微服务模块拆分在IT应用架构计划大中台的观点下，实际上中台包罗了技术中台和业务中台，对于技术中台重点是各个技术组件和技术服务能力的实现，而对于业务中台则主要包罗了数据能力和业务规则处置惩罚能力的提供。对于业务中台自己也是分层，包罗了最基本的数据类中心和业务处置惩罚类中心。

数据类中心自己又包罗了基础主数据类和焦点共享业务票据类，好比我们看到的产物中心，用户中心，属于基础主数据类。而对于订单中心，库存中心则属于业务共享数据类。

业务处置惩罚类则主要是举行焦点业务功效和逻辑的处置惩罚，类似的包罗了生意业务中心，结算中心，计费中心等，都可以看做是业务处置惩罚类的中台模块。固然，业务处置惩罚类中台也包罗关键的领域服务提供组件，即这类组件需要挪用底层更多基础原子模块的焦点接口能力，经常组合后再提供出整合的组合能力。技术中台模块的划分-完全垂直彻底解耦技术中台主要卖力提供各种的技术服务能力，其中包罗了消息，缓存，存储(内存，结构化和非结构化），文件，日志，通知，规则引擎，流程等种种通用的和业务无关的技术能力。

可以看到对于种种技术服务之间，自己没有任何的耦合性，完全是垂直独立，因此对于技术中台中的微服务模块划分粒度，完全可以一个技术服务一个微服务模块，完全独立治理和部署，相互之间没有任何影响。技术中台属于我们传统的PaaS技术平台必须要管控和治理的一部门内容，对于技术服务的接入，消费和挪用，日志等都需要在PaaS管控治理平台能够查询和监控。

业务中台模块的划分-围绕数据仍然是焦点注意这里的业务中台模块，就是一个独立的微服务模块，一个独立的有数据库，逻辑层到前端界面展现的小应用。只是这个业务中台自己还将自己的关键能力以API接口服务的方式开放给前台应用挪用。业务中台模块划分粒度相当重要，粒度太细后期集成和管控都相当庞大，同时由于模块划分太细也容易引入更多前台应用开发带来的漫衍式事务处置惩罚场景。

而粒度太粗的话自己又无法起到独立自治，后期易于变换运维，自己灵活敏捷的作用。如果说做互联网电商，由于有类似阿里等的乐成实践，可能大家闭着眼都知道应该包罗类似产物中心，库存中心，用户中心，订单中心，结算中心等各种的中台模块。可是如果是全新的业务类型，或者说针对企业内部的治理信息化，究竟应该如何去划分中台。

1. 基础主数据类模块划分如果一个基础主数据就一个微服务模块，那么会导致我们的微服务模块的量极大，好比用户中心，组织中心，人员中心，客户中心，物料中心，供应商中心等。那么这种划分方法。

本文来源：hth华体会体育全站app-www.ytjiaxinyasuoji.com