加载中…

加载中...

个人资料
人月神话
人月神话 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:4,131,692
  • 关注人气:5,912
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

谈中台构建-模块划分(1.11)

(2019-01-11 16:48:32)
标签:

中台

微服务

分类: 微服务架构
在SOA和微服务架构体系下,或者说我们在构建企业中台能力层的时候,一个关键点就是微服务模块的划分,包括划分的方法,划分的粒度。今天就先谈下微服务模块的划分。

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

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

业务处理类则主要是进行核心业务功能和逻辑的处理,类似的包括了交易中心,结算中心,计费中心等,都可以看做是业务处理类的中台模块。当然,业务处理类中台也包括关键的领域服务提供组件,即这类组件需要调用底层更多基础原子模块的核心接口能力,经常组合后再提供出整合的组合能力。

技术中台模块的划分-完全垂直彻底解耦

技术中台主要负责提供各类的技术服务能力,其中包括了消息,缓存,存储(内存,结构化和非结构化),文件,日志,通知,规则引擎,流程等各种通用的和业务无关的技术能力。可以看到对于各种技术服务之间,本身没有任何的耦合性,完全是垂直独立,因此对于技术中台中的微服务模块划分粒度,完全可以一个技术服务一个微服务模块,完全独立管理和部署,相互之间没有任何影响。

技术中台属于我们传统的PaaS技术平台必须要管控和治理的一部分内容,对于技术服务的接入,消费和调用,日志等都需要在PaaS管控治理平台能够查询和监控。

业务中台模块的划分-围绕数据仍然是核心

注意这里的业务中台模块,就是一个独立的微服务模块,一个独立的有数据库,逻辑层到前端界面展现的小应用。只是这个业务中台本身还将自己的关键能力以API接口服务的方式开放给前台应用调用。

业务中台模块划分粒度相当重要,粒度太细后期集成和管控都相当复杂,同时由于模块划分太细也容易引入更多前台应用开发带来的分布式事务处理场景。而粒度太粗的话本身又无法起到独立自治,后期易于变更运维,本身灵活敏捷的作用。

如果说做互联网电商,由于有类似阿里等的成功实践,可能大家闭着眼都知道应该包括类似产品中心,库存中心,用户中心,订单中心,结算中心等各类的中台模块。但是如果是全新的业务类型,或者说针对企业内部的管理信息化,究竟应该如何去划分中台。

1. 基础主数据类模块划分

如果一个基础主数据就一个微服务模块,那么会导致我们的微服务模块的量极大,比如用户中心,组织中心,人员中心,客户中心,物料中心,供应商中心等。那么这种划分方法在企业内信息化上并不太合理。

如果是按标准的主数据管理系统的业务模块划分,实际上它不是按照数据维度进行划分,一般我们说主数据系统会包括了元数据和数据对象管理,数据集成和调度,数据清理,流程引擎,数据内容管理等各个模块。而无法真正体现出以数据为中心的思想。

因此对于基础主数据类微服务模块,最好的方式是按数据域进行拆分,比如对于用户,组织,岗位,人员等划分到一个人力域数据中心,对于供应链,物料编码,采购类别等划分到采购或供应链域微服务模块。这样划分的好处就是既实现了一定程度上的模块拆分和松耦合,同时按域划分后,同一个域的基础主数据本身在一个数据库中进行管理,这些基础主数据本身可能存在一定的耦合关系,那么这些耦合关系的处理将不再需要提升到分布式事务层面去处理。

2.业务功能类模块划分

谈业务功能类模块的划分,实际上又回到我们在传统进行单个业务系统架构设计的时候如何进行组件划分这个话题。如何划分组件,简单来说就是要高内聚和松耦合,确保每个组件尽可能的独立自治,组件和组件之间的干扰最小。

当时我们在做单系统的时候,往往对于组件划分考虑的并不彻底,就是说在代码层面确实划分了组件,组件也可以进行独立打包,但是对于各个组件仍然对应一个数据库。那么我们就经常犯一个错误,即虽然在业务和逻辑层两个组件看似松耦合了,但是很多耦合性转变到了数据库层了。举个简单的例子,数据库的一个关联查询很容易就实现了,但是涉及到关联的两个表,其核心Owner确是不同的两个组件模块。

所以对于上层的业务组件划分,本身原来我们也谈两个方法,这里拿采购管理系统举例。

方法一:按大阶段划分,可以分为采购请购,采购订单,采购执行,采购绩效评估,供应商,物料等模块。
方法二:按数据维度划分,可以划分招投标中心,采购中心,绩效中心,供应商中心,物料中心等。

不论是哪种方法,我们看到在进行微服务模块划分的时候,关键还是要把基础和共享数据找出来,然后才是去处理上层的业务。再来考虑业务流程,业务规则处理等还需要单独设置哪些微服务模块。即使是用方法一,我们也看到每个模块都一定有自己关键的主属Owner数据。

划分微服务模块,实际上相对关键的一个步骤就是拆分数据库的过程。要把原来我们一个数据库的内容,拆分并对应到各个微服务模块上。主属Owner,对该数据具备了完全的CRUD能力。而其它模块更多的是单纯的数据导入或数据查询。

大中台更多的是体现其核心数据集中和共享能力,而不是业务流程和规则处理能力,因此更多的业务流程处理都应该归结到前台更加合适。一个大中台的订单中心,可以和各种各样的前台微服务模块对接,不管是网页还是APP应用,不管是渠道,政企还是电商,但是最终都是将正式流程处理完成后生效的订单数据导入到订单中心。然后订单中心再提供完整的订单能力开放。

主流微服务架构框架的使用

要注意到,对于传统企业IT转型微服务架构,即使原来单体的一个业务系统拆分为多个微服务模块,而实际上每个微服务模块的体量仍然相对来说还是很大。就拿采购管理来说,一个招投标中心单独拆分处理,这个微服务模块本身就是一个完整的业务系统,而且规模不小。

那么在拆分到微服务模块后,各个微服务模块的实现,如采用SpringCloud框架来做。这个本身没有任何问题,但是在这个微服务模块内部,仍然还涉及到划分不同的组件包的问题。那么这些组件包之间就仍然存在接口调用,那么这些接口调用是否需要微服务架构中心的注册中心去管理?

这个是一个很现实的问题,在这点上我们的理解如下:

对于一个传统的单体应用,在拆分为多个微服务模块后,对于微服务模块内部可以用类似SpringBoot去开发,但是内部的接口调用不用走注册中心,直接通过内部API接口去调用即可。因为一个微服务模块本身也不存在还需要进行拆分部署的问题。

而对于一个完整的单体应用,存在多个微服务模块,这些微服务模块之间存在接口调用,因此对于一个完整的单体应用,需要部署一套服务注册中心去统一管理接口。

再次,如果这个单体应用存在和外部其它单体应用间的接口交互和集成,比如单体应用内部存在多个个微服务模块都需要开放能力接口给外部调用。那么这个单体应用微服务架构化后需要进一步启用微服务网关。当然,即使没有和外部应用交互,但是前台存在网页,APP,智能电商或Pad多种展示端的时候,仍然存在独立部署微服务网关的必要。

那么对于一个企业在彻底进行微服务架构化后,可能涉及到上100个微服务模块,如何进行管理?如果全部都采用一个注册中心和网关去管理,实际上存在的可靠性和性能风险将会很大。

企业在微服务架构实施过程中我们建议的方式仍然是进行分域管理,而分域的基础就是传统的单体应用的边界,即采购管理时候独立个一个域,财务管理是独立的一个域,每个域都有自己独立的微服务注册中心和微服务网关。那么域和域之间的接口服务调用就存在需要到不同的网关中去跟踪和查询日志的问题。

基于该点,我们仍然推荐方式是,进一步采用SOA总线或轻量的ESB来实现多个微服务网关暴露的接口服务的集成和统一管理。以方便进行跨越集成的时候,多个接口服务的运行监控。即我们的服务治理管控本身也是分层的额,对于域内的由各个域的微服务架构管控体系自己完成,对于域外的由上层的SOA管控平台完成。

0

阅读 收藏 转载 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

新浪公司 版权所有