共计 3676 个字符，预计需要花费 10 分钟才能阅读完成。
纵览企业信息化建设的历史，咱们能够发现：企业应用集成技术是随同着企业信息系统的倒退而产生和演变的。企业的价值取向是推动利用集成技术倒退的原动力，而通过利用集成技术所实现的价值反过来也驱动着公司的竞争劣势的晋升。随着新技术的倒退和企业业务需要的变动，数据集成架构也跟着产生着变迁。数据集成架构的倒退能够分为四个阶段：点对点集成，EDI 星型集成，SOA 集成，互联网集成，如下图所示：
点对点集成架构
点对点集成是最早呈现的利用集成模式，采纳点对点的形式开发接口程序，把须要进行信息替换的零碎一对一地集成起来，从而实现整合利用的指标。点对点的连贯形式在连贯对象比拟少的时候，的确是一种简略和高效的连贯形式，具备开发周期短、技术难度低的劣势。但其最大的问题是，当连贯对象多的时候，连贯门路会以指数形式剧增。
连贯门路数与连贯对象数之间的关系是：连贯门路数 =（连贯对象数 ×（连贯对象数 -1））÷ 2
点对点的集成有着显著的缺点：
● 当须要连贯的利用零碎越来越多时，点对点集成形式将把整个企业信息系统接口变成无奈治理的“凌乱的线团”。
● 点对点的集成架构不能集中管理和监控接口服务，仅反对一对一的数据交换，如果替换协定不统一，开发则十分艰难。即，如果沟通的语言、文字、格局、办法等有差别，则每一个连贯方都要同时反对和保护多种连贯形式。
● 点对点的集成是紧耦合的，当一个连贯变动时，所有与其相干的接口程序都须要从新开发或调试。
基于以上几点，在多点互连的状况下，点对点连贯形式老本高，可用性和可维护性低，显然不是一个好的连贯形式。
总线集成架构
随着利用集成技术的倒退，基于 EDI（电子数据交换零碎）的中间件形式逐步取代了点对点的集成模式。基于 EDI 中间件的集成规定在中间件上进行定义和执行，其拓扑构造不再是点对点集成造成的无规则网状，而次要是核心辐射型的（Hub 型）星型构造或总线结构。因为信息系统的规范不统一，星型架构采纳适配器的形式与利用零碎进行对接，每个适配器实用于一种类型的数据源。
总线结构通过与点对点集成架构相比，采纳总线架构能够显著缩小编写的专用集成代码量，晋升了集成接口的可管理性。不同连贯对象如果连贯形式有差别，能够通过总线齐全屏蔽掉，做到对连贯对象通明，无需各个连贯对象关怀。
总线的连贯形式最早在许多硬件设计上失去宽泛的应用。如解决芯片的数据总线，网络节点的交换机，大型计算机系统处理器与外围存储设备连贯的集线器等。通过总线结构，把原来简单的网状结构变成简略的星形构造，极大进步了硬件的可靠性和可用性。
但因为规范的匮乏，总线集成架构的缺点逐步裸露进去。各厂商的中间件多采纳其专有协定或接口标准，凋谢水平非常低，一经采纳，信息系统降级、欠缺的老本很高，周期很长，间接导致了企业治理流程受到零碎固化，呈现企业治理随着信息化利用的深入反而治理流程被动僵化。
这是因为多个异构零碎通过 EDI 互相关联，单个零碎的欠缺或降级受到关联系统的牵制，后果是信息集成度越高，系统升级和数据保护越艰难，从而间接导致治理改良的艰难、经营效率升高和老本的回升，企业信息化的自由度就大大受限，同时也会付出更高的技术老本；因为受中间件具体产品性能的限度，在发展业务流程集成时，因为集成逻辑须要在中间件上通过变成实现定义与执行，具备较高的技术难度和复杂度，很难实现较简单的流程集成，因此也就不能迅速满足业务变动提出的信息系统调整的需要。
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 宕机会导致多个零碎无奈失常提供服务。
微服务集成架构
互联网是 IT 业的重大革命性翻新，随着挪动互联、互联网的倒退，为放慢 web 和挪动利用的开发过程，呈现了一种“去中心化的”新型的架构——微服务架构。微服务架构强调“业务需要彻底的组件化及服务化”，这将成为企业 IT 架构的倒退方向。原单个业务零碎会被拆分为多个能够独立开发、设计、部署运行的小利用，这些小利用间通过服务化实现交互和集成。
微服务呈现后人们总会拿它与 SOA 比拟，甚至有的人认为微服务架构将取代 SOA，这样的观点仿佛有些偏激。微服务与 SOA 中的服务最大的区别是它能够独立部署、独立运行，不依赖与其余服务，并且是一个分布式架构。每个微服务各自为政，做好本人的事件，即便本人出问题也只会影响有间接调用的服务，灵便弹性扩缩容。微服务架构与 SOA 相比具备更好的可靠性，呈现单点故障不会对其余微服务造成影响。严格意义上说，SOA 是面向集成的架构是面向零碎级、面向集成的，而微服务是面向服务，通过一系列涣散耦合的服务去实现满足业务需要的利用，目标是缩短简单利用从开发到部署的工夫。
SOA 重视服务的重用，但微服务实质是对服务的重写，只管微服务也须要集成。微服务通常由重写一个模块开始，企业向微服务迁徙的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，把它们一个一个剥离进去用麻利办法、微服务技术进行重写，而后独自布署。
微服务集成架构晋升了全局稳定性。因为每个服务负责的性能繁多，各服务的资源需要也绝对更低。从而能够抉择将服务扩散的部署到多台中低配的服务器上，而不是一台高配的机器上。如果某个机器上的服务故障，譬如说内存透露，故障只会影响该机器上的某一个或几个服务，对全局影响不大。
微服务的集成次要波及以下四个层面的集成：
接口集成
接口集成是服务之间集成的最常见伎俩，通常基于业务逻辑的须要进行集成。RPC、REST、消息传递和服务总线都能够归为这种集成形式。微服务应用 REST API 和轻量级音讯零碎实现系统集成。其中，音讯零碎仅提供牢靠的异步音讯传输通道，而不参加音讯路由、编排、转换等环节，也不在音讯零碎中蕴含业务逻辑。
数据集成
数据集成同样能够用于微服务之间的交互，联邦数据库是一个抉择，但也能够通过数据复制的形式实现数据集成。
界面集成
因为微服务是一个可能独立运行的整体，有些微服务会蕴含一些 UI 界面，这也意味着微服务之间也能够通过 UI 界面进行集成。
内部集成
这里把内部集成独自剥离进去的起因在于事实中很多服务之间的集成需要来自于与内部服务的依赖和整合，而在集成形式上也能够综合采纳接口集成、数据集成和 UI 集成。
在数字化、智能化时代，数据成为企业的重要基础设施，无论是技术还是利用都将围绕数据进行。正当地利用数据将为企业发明极大的价值，而在这一过程中，数据集成技术将为更好地利用数据提供撑持。