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

谈企业中台能力服务层构建02(5.14)

(2019-05-14 08:27:02)
标签:

soa

中台

微服务

分类: IT咨询
这篇文章接上篇内容进一步细化。

谈企业中台能力服务层构建02(5.14)

在前面有一篇博客文章我曾经谈到过,通过服务代理的方式来构建企业中台能力服务层,今天基于这篇文章的思路进一步细化整理,同时对构图进行了重新调整。

中台能力适配的三种方式

如上面图所示,在构建新的中台能力服务层的时候,为了对已有的业务系统影响最小,我们需要重新构建中台能力接口,这个接口涉及到一定的适配和定制开发工作量。具体接口的实现本身又包括了三种方式,这个在前面一篇博客文章也谈到过,即:

1. 直接连接遗留系统的数据库,来重新开发接口服务。
2. 通过遗留系统已有的JAR包引入,来重新开发接口服务。
3. 通过遗留系统已有的WS或Rest等接口服务适配,来重新开发接口服务。

可以看到三种模式中对于数据库这种模式是对业务系统依赖最小的模式,但是这个模式本身也是需要我们重新大量完整性校验,业务规则的模式。这种模式本身就可以看到对遗留业务系统的部分业务规则和能力进行了重写,即这部分业务逻辑规则已经在朝中台能力层逐步迁移。

这种迁移形成的接口服务能力,一方面是构建全新的业务应用可以使用。而同时,我们建议是及时对于PMS或SCM等业务系统,如果有全新的业务模块需要开发,也完全可以基于中台已有的接口服务能力进行,只有这样才容易实现后续的业务系统逐步迁移到中台架构上。

数据重构和服务组合是中台另外一个关键能力

在中台能力构建的时候,一定要考虑数据重构和能力组合,即中台的能力接口不是简单的数据库CRUD能力暴露,也不是已有的遗留接口的简单适配和代理接入。而是真正根据业务流程和业务需求驱动,失败关键的业务能力,将业务能力转变为服务。这种服务本身是粗粒度的,有明确的业务含义,有点类似我们在领域架构设计里面经常谈到的领域服务能力。

领域服务本身同意,有提供领域数据对象的数据类服务,也有提供业务逻辑和规则处理的业务类服务,这些都是领域服务能力。在前期中台构建的时候我们看到数据类服务相对容易构建,但是业务类服务本身较难,因为遗留系统已经实现的业务处理规则和逻辑在代码里面,如果我们用数据库适配模式很容易遗漏已有的业务规则实现。

因此在前期中台服务能力构建的时候,建议还是先以查询能力服务能力开放为主来构建。当然我们也可以提供一些期初的领域对象导入服务能力,这种导入服务提供一些基础的数据完整性校验能力,形成业务系统的单据草稿。而实际的业务单据规则处理和流程仍然还是在遗留业务系统中。

服务组合是中台存在的另外一个关键价值,即我们可以根据业务需求一次返回组合后的领域对象数据,这个领域对象可以是多层结构,可以一次返回。这个领域对象也可能是涉及到多个数据库表间的关联。如果多个数据库表是跨物理数据库的。我们可以

1. 在中台能力实现的时候,调用多次底层原子服务返回多个数据集对象。
2. 在中台实现的时候对多个数据集对象进行数据重构和组合,并返回组合后的领域对象给消费方。

中台层对接口服务进行标准化和规范化

中台层在接口服务实现的时候,最好在适配的过程中对对接口服务进行标准化和规范化,即提供标准的WS或Rest接口服务能力,服务预先制定的服务契约或规范要求,同时符合日志审计,安全管控要求。

中台层的标准WS接口服务最后统一注册和接入到API网关,这样API网关本身能够更加轻量,不需要做太多的适配,数据映射,转换等工作。而重点是实现服务代理和统一服务目录提供,负载均衡,日志审计,安全能力,流量控制能力即可。

即这种模式类似于构建了一个厚中台+轻API网关的模式。

0

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

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

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

新浪公司 版权所有