查看原文
其他

数据治理:数据集成架构的演进

石秀峰 谈数据 2023-03-25

来源:谈数据,作者:石秀峰

全文共 3654个字,建议阅读 分钟
纵览企业信息化建设的历史,我们可以发现:企业应用集成技术是伴随着企业信息系统的发展而产生和演变的。企业的价值取向是推动应用集成技术发展的原动力,而通过应用集成技术所实现的价值反过来也驱动着公司的竞争优势的提升。随着新技术的发展和企业业务需求的变化,数据集成架构也跟着发生着变迁。数据集成架构的发展可以分为四个阶段:点对点集成,EDI星型集成,SOA集成,互联网集成,如下图所示:


01 点对点集成架构

点对点集成是最早出现的应用集成模式,采用点对点的方式开发接口程序,把需要进行信息交换的系统一对一地集成起来,从而实现整合应用的目标。点对点的连接方式在连接对象比较少的时候,确实是一种简单和高效的连接方式,具有开发周期短、技术难度低的优势。但其最大的问题是,当连接对象多的时候,连接路径会以指数方式剧增。
连接路径数与连接对象数之间的关系是:连接路径数=(连接对象数 ×(连接对象数-1))÷ 2
点对点的集成有着明显的缺陷:
  • 当需要连接的应用系统越来越多时,点对点集成方式将把整个企业信息系统接口变成无法管理的“混乱的线团”。

  • 点对点的集成架构不能集中管理和监控接口服务,仅支持一对一的数据交换,如果交换协议不一致,开发则非常困难。即,如果沟通的语言、文字、格式、方法等有差异,则每一个连接方都要同时支持和维护多种连接方式。

  • 点对点的集成是紧耦合的,当一个连接变化时,所有与其相关的接口程序都需要重新开发或调试。
基于以上几点,在多点互连的情况下,点对点连接方式成本高,可用性和可维护性低,显然不是一个好的连接方式。

02 总线集成架构

随着应用集成技术的发展,基于EDI(电子数据交换系统)的中间件方式逐渐取代了点对点的集成模式。基于EDI中间件的集成规则在中间件上进行定义和执行,其拓扑结构不再是点对点集成形成的无规则网状,而主要是中心辐射型的(Hub型)星型结构或总线结构。由于信息系统的标准不一致,星型架构采用适配器的方式与应用系统进行对接,每个适配器适用于一种类型的数据源。
总线结构通过与点对点集成架构相比,采用总线架构可以显著减少编写的专用集成代码量,提升了集成接口的可管理性。不同连接对象如果连接方式有差异,可以通过总线完全屏蔽掉,做到对连接对象透明,无需各个连接对象关心。
总线的连接方式最早在许多硬件设计上得到广泛的使用。如处理芯片的数据总线,网络节点的交换机,大型计算机系统处理器与外围存储设备连接的集线器等。通过总线结构,把原来复杂的网状结构变成简单的星形结构,极大提高了硬件的可靠性和可用性。
但由于标准的匮乏,总线集成架构的缺陷逐渐暴露出来。各厂商的中间件多采用其专有协议或接口规范,开放程度非常低,一经采用,信息系统升级、完善的成本很高,周期很长,直接导致了企业管理流程受到系统固化,出现企业管理随着信息化应用的深化反而管理流程被动僵化。

这是由于多个异构系统通过EDI相互关联,单个系统的完善或升级受到关联系统的牵制,结果是信息集成度越高,系统升级和数据维护越困难,从而直接导致管理改进的困难、运营效率降低和成本的上升,企业信息化的自由度就大大受限,同时也会付出更高的技术成本;由于受中间件具体产品功能的限制,在开展业务流程集成时,由于集成逻辑需要在中间件上通过变成完成定义与执行,具有较高的技术难度和复杂度,很难实现较复杂的流程集成,因而也就不能迅速满足业务变化提出的信息系统调整的需求。

03  SOA型集成架构

随着Web服务规范的日渐成熟,Web技术被应用于企业内部的应用集成,一种面向服务的集成架构(Service Oriented Architecture,简称:SOA)成为了企业应用集成的主流。SOA架构的其主要特征是基于一系列Web标准或规范来开发接口程序,包括UDDI、SOAP、WSDL、XML,并采用支持这些规范的中间件产品作为集成平台,从而实现了一种开放而富有弹性的应用集成方式。SOA是一种开发思想,是一种松耦合的框架,其主要特点是:
  • SOA是实现IT和业务同步的先进可行技术,它将企业应用中离散的业务功能提取出来,并将其组织成可互动的,基于标准的服务。
  • SOA以提供服务的方式向企业提供了灵活、快捷的系统整合选择,它将模块化和便携化的服务在复合应用中组合和重用,以更为快速的满足业务需求。
  • SOA本身配备的完整、成熟的安全管理保障体系满足了客户进行松耦合集成实施时所提出的安全需求。
在面向服务的集成架构中,ESB(企业服务总线)扮演着重要的角色,甚至有人认为ESB是SOA架构落地的基础。ESB是一个具有标准接口、实现了互连、通信、服务路由。它提供消息驱动、事件驱动和文本导向的处理模式,支持基于内容的服务路由。SOA架构将各应用系统上的各种服务连接到服务总线上,支持分布式的存储及分布式的处理、异步处理。为信息系统的真正松耦合提供了架构保障。简化了企业整个信息系统的复杂性,提高了信息系统架构的灵活性,降低企业内部信息共享的成本。
第一,ESB是一个服务管理中心,服务的消费方无需关系服务实际的生产方,包括生产方的服务名称、物理位置、传输协议和接口定义等,这些都是由ESB平台进行包装和中央的发布式定义。
第二,ESB是服务的中介平台,提供服务的可靠性保证,负载均衡,流量控制,缓存,事务控制,加密传输,支持服务的监控、异常处理、服务调用及消息数据记录,系统及服务的状态监控等。
第三,ESB是一个转换和解耦的平台,支持协议转换,如WebService,Http,JMS等;支持消息转换,如消息的转换 、过滤、填充等;支持消息路由,如同步/异步、发布/订阅、基于内容路由、分支与聚合等。
最后,ESB是一个服务编排和重组的平台,支持按业务的要求将多个服务编排为一个新的服务,正是ESB的这种灵活的服务编排功能,使得ESB具备了随需应变的能力。
ESB将多个业务子系统的公共调用部分抽离整合为一个共用系统,减少了调用链路的复杂性,其服务编排能力增加业务的随需应变的灵活性。但是ESB本质上是一个总线型或星型的结构,所有服务的对接需要依赖于这个“中心化”的总线。一旦ESB在数据量过大时候会成为性能瓶颈,或者ESB宕机会导致多个系统无法正常提供服务。

当然,SOA时代的典型组件除了ESB,还有Portal、BPM、ETL、MDM、DW等,我们后边慢慢分解!

04 微服务集成架构

互联网是IT业的重大革命性创新,随着移动互联、互联网的发展,为加快web和移动应用的开发进程,出现了一种“去中心化的”新型的架构——微服务架构。微服务架构强调“业务需求彻底的组件化及服务化”,这将成为企业IT架构的发展方向。原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用,这些小应用间通过服务化完成交互和集成。
微服务出现后人们总会拿它与SOA比较,甚至有的人认为微服务架构将取代SOA,这样的观点似乎有些偏激。微服务与SOA中的服务最大的区别是它可以独立部署、独立运行,不依赖与其他服务,并且是一个分布式架构。每个微服务各自为政,做好自己的事情,即使自己出问题也只会影响有直接调用的服务,灵活弹性扩缩容。微服务架构与SOA相比具备更好的可靠性,出现单点故障不会对其他微服务造成影响。严格意义上说,SOA是面向集成的架构是面向系统级、面向集成的,而微服务是面向服务,通过一系列松散耦合的服务去实现满足业务需求的应用,目的是缩短复杂应用从开发到部署的时间。
SOA注重服务的重用,但微服务本质是对服务的重写,尽管微服务也需要集成。微服务通常由重写一个模块开始,企业向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始,把它们一个一个剥离出来用敏捷方法、微服务技术进行重写,然后单独布署。
微服务集成架构提升了全局稳定性。由于每个服务负责的功能单一,各服务的资源需求也相对更低。从而可以选择将服务分散的部署到多台中低配的服务器上,而不是一台高配的机器上。如果某个机器上的服务故障,譬如说内存泄漏,故障只会影响该机器上的某一个或几个服务,对全局影响不大。
微服务的集成主要涉及以下四个层面的集成:
· 接口集成
接口集成是服务之间集成的最常见手段,通常基于业务逻辑的需要进行集成。RPC、REST、消息传递和服务总线都可以归为这种集成方式。微服务使用REST API和轻量级消息系统实现系统集成。其中,消息系统仅提供可靠的异步消息传输通道,而不参与消息路由、编排、转换等环节,也不在消息系统中包含业务逻辑。
· 数据集成
数据集成同样可以用于微服务之间的交互,联邦数据库是一个选择,但也可以通过数据复制的方式实现数据集成。
· 界面集成
由于微服务是一个能够独立运行的整体,有些微服务会包含一些UI界面,这也意味着微服务之间也可以通过UI界面进行集成。
· 外部集成

这里把外部集成单独剥离出来的原因在于现实中很多服务之间的集成需求来自于与外部服务的依赖和整合,而在集成方式上也可以综合采用接口集成、数据集成和UI集成。

写在最后的话
在数字化、智能化时代,数据成为企业的重要基础设施,无论是技术还是应用都将围绕数据进行。合理地利用数据将为企业创造极大的价值,而在这一过程中,数据集成技术将为更好地利用数据提供支撑。
未完待续。下篇我们重点分享下数据集成的集中典型的应用模式,例如:联邦数据库,主数据管理、数据仓库、数据湖。
注:本文节选自《一本书讲透数据治理》,机械工业出版社。下附京东5折优惠购书链接,截止目前最低价:

据统计,99%的数据大咖都关注了这个公众号

👇

更多精彩原创:

1、大数据治理:角色、框架和案例!

2、医疗行业的数据治理:一项综合战略!
3、数据管理、数据治理、数据资产管理,到底有何不同?

4、数据治理:数据架构的前世今生

5、你知道数据治理,你听过数据编织吗?

6、数据治理:90%的人搞不清的事情

7、数据治理:治数VS养数,哪个棋高一招?

8、数据治理:商品主数据怎么管?

9、数据治理项目失败,90%都是被这样搞垮的!

10、数据湖 VS 数据编织:泰坦之战

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存