微服务架构-数据中台和业务中台(3.27)

标签: IT咨询 | 发表时间:2019-03-27 19:45 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
首先我们看下阿里巴巴Aliware团队对企业中台的定义。 即企业中台是由业务中台和数据中台构建起数据闭环的运营体系,实现以数字化资产的形态构建企业核心差异化竞争力。

在原来我谈企业中台的时候,很少专门谈到数据中台和业务中台,更多谈的是技术中台和业务中台,技术中台类似我们原来说的技术平台层和业务不相关。而对于业务中台,其中包括了以数据能力提供为主的微服务模块组件,也包括了业务规则处理为主的组件,还包括了各种能力组合组装的能力组件。

在原来自己的概念里面,是将以数据能力提供为主的组件仍然是业务中台里面的数据中台,类似人员中心,用户中心,产品中心等。而对于业务处理为主模块类似计费中心,结算中心等做为业务中台模块。但是这个概念本身和阿里的概念有出入。因此今天专门找资料看了下, 阿里谈到的数据中台更多的是指数据中心平台建设,其中包括了传统的ODS库,也包括了上层的数据仓库,这个数据中心也可以上升到大数据平台。比如一个企业构建的大数据平台,可以划归到数据中台。一个企业构建的ODS共享数据中心,可以划归到数据中台。

参考下面这篇文章


数据中台是指通过数据技术,对海量数据进行采集、计算、存储、加工,同时统一标准和口径。数据中台把数据统一之后,会形成标准数据,再进行存储,形成大数据资产层,进而为客户提供高效服务。这些服务跟企业的业务有较强的关联性,是这个企业独有的且能复用的,它是企业业务和数据的沉淀,其不仅能降低重复建设、减少烟囱式协作的成本,也是差异化竞争优势所在。

数据中台建设的基础还是数据仓库和数据中心,并且在数仓模型的设计上也是一脉传承,之所以我们现在处处推崇数据中台建设及应用,一个是因为数据中台确实有过人之处,另一个是这套模型在阿里体现了巨大的应用价值。数据中台一般包括了数据模型和数据资产管理,数据服务开放,上层的数据类应用和标签管理等。从构成上数据中台一般包括以下几个部分的内容。

1.数据仓库:用来存储数据的,结构性数据、非结构性数据等,还有离线数据和实时数据等;
2.大数据中间件:包含了大数据计算服务、大数据研发套件、数据分析及展现工具;
3.数据资产管理:按照阿里的体系应该分为垂直数据、公共数据和萃取数据3层;

从这个内容一看,更加明确了阿里谈到的数据中台就是一个数据共享能力提供中心。在前期可以是一个基于大数据技术构建的分布式ODS库,在后期可以发展到数据仓库和大数据分析。底层的核心仍然是数据建模。

当我们把这个概念搞清楚后,我们才基本清楚了企业一个开始建设企业中台,如果仅仅是满足业务流程和业务处理需求,只会涉及到业务中台构建。 在业务中台构建完成后,考虑到后续端到端流程监控分析,大数据分析的需求才会涉及到数据中台的构建。

当然数据中台本身也为上层应用提供各种数据服务能力,比如上层的针对性营销,用户画像和标签化,这个就部署业务中台能够提供的能力,而是需要数据中台来提供这个能力。只有数据中台对用户相关的所有静态数据,动态行为数据进行了集中,也进行了关联分析和建模。

其次你会发现,当你在构建上层业务应用的时候,如果需要的不仅仅是传统业务中台的单个业务模块提供的单数据对象数据服务能力,而更多的是需要提供跨多个业务组件提供的整合后的数据能力,那么这件事情也应该是数据中台来做最合适。因为这个职责本身也不在业务中台。

因此数据中台是多个共享数据对象的汇总和集合,能够提供跨业务中台多组件的共享数据服务提供能力。正因为具备这个能力,你会发现当你构建上层一个分析类应用前台的时候,原来需要和业务中台多个业务组件打交道,同时自己还需要进行数据整合清理。但是新架构下你只需要消费和使用数据中台提供的共享数据服务能力即可。

另外一篇可参考文档: https://www.jianshu.com/p/f8a7c33709b3

 

相关 [微服务 架构 数据] 推荐:

微服务下的数据架构

- - IT瘾-dev
微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微服务,而本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地方,旨在帮助大家在构建微服务架构时,提供一个从数据方面的视角:. 按照 Martin Fowler 的定义,微服务是一个软件架构模式,通过开发一系列的小型服务的方式来实现一个应用.

微服务架构--服务框架,metrics 和调用链数据

- - 行业应用 - ITeye博客
微服务化以后,为了让业务开发人员专注于业. 务逻辑实现,避免冗余和重复劳动,规范研发. 提升效率,必然要将一些公共关注点推到框架. 服务框架 ( 图 9) 主要封装公共关注点. 服务注册、发现、负载均衡和健康检查,. 假定采用进程内 LB 方案,那么服务自注. 册一般统一做在服务器端框架中,健康检.

微服务开发中的数据架构设计

- - ITeye资讯频道
GitChat 作者:陈伟荣. 原文: 微服务开发中的数据架构设计. 关注微信公众号:「GitChat 技术杂谈」 一本正经的讲技术. 微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性. 为业务创新和业务持续提供了一个良好的基础平台.

微服务架构-数据中台和业务中台(3.27)

- - 人月神话的BLOG
首先我们看下阿里巴巴Aliware团队对企业中台的定义. 即企业中台是由业务中台和数据中台构建起数据闭环的运营体系,实现以数字化资产的形态构建企业核心差异化竞争力. 在原来我谈企业中台的时候,很少专门谈到数据中台和业务中台,更多谈的是技术中台和业务中台,技术中台类似我们原来说的技术平台层和业务不相关.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

微服务架构-模块迁移

- - 人月神话的BLOG
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难. 对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出. 下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.