【系统集成】概览 - hippowc/hippowc.github.io GitHub Wiki

概念

EAI

EAI（Enterprise Application Integration，企业应用集成）是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。一开始软件都是独立应用，不同软件之间没有联系（大约80年代），后来企业应用需要资源整合和共享，出现EAI。一般有两种模式：总线型、和辐射型。后来总线型模式发展成ESB。

EIP

Enteprise Integration Patterns 企业集成模式。来源于Gregor Hohpe 和Bobby Woolf合著的一本书《Enterprise Integration Patterns》

ESB

企业服务总线，是企业应用架构的一种模式。一个企业不用ESB没有问题，但是用ESB可以更好的解决不同异构系统的连接问题。出现ESB后，EAI进入了一个新的阶段，就是ESB阶段。

IPaas

集成平台作为服务，指的是促进开发、执行和集成流治理同任何本地（on-premises）以及基于云的流程、服务、应用和数据连接的一套云服务，可以在独立的或者多个交叉的组织中进行。

EDI

电子数据交换（Electronic data interchange，缩写EDI）是指按照同一规定的一套通用标准格式，将标准的经济信息，通过通信网络传输，在贸易伙伴的电子计算机系统之间进行数据交换和自动处理。由于使用EDI能有效地减少直到最终消除贸易过程中的纸面单证，因而EDI也被俗称为“无纸交易”。它是一种利用计算机进行商务处理的新方法。

SOA

面向服务的架构，本质上是面向服务的思想在企业架构方面的应用。面向服务的思想是面向对象思想以后的一种新的思想模式，其核心特点就是已松耦合、粗粒度的服务形式来构建软件。作为一种思想，SOA不涉及任何具体的技术和平台。但是思想存在一个实现的问题，人们发现ESB是实现SOA的一个最佳方式，因此ESB成为SOA的技术基础。当然，不用ESB，不能说你的系统就没有SOA。

概念比较

ESB和IPaas

企业采用云服务的压倒性速度给使用较早的本地集成系统（如ESB）的企业带来了集成挑战，而ESB的系统并非旨在处理云集成。作为响应，企业正在转向集成工具和解决方案，例如集成平台即服务（iPaaS），以弥补其现有企业服务总线（ESB）安装的弱点。

iPaaS和ESB具有相同的主要目的：集成企业系统和应用程序。iPaaS和ESB之间的主要区别在于它们能够最佳集成的系统类型，集成的复杂程度以及可伸缩性

  • 系统类型。iPaaS是从公共云提供的一组集成工具，不需要内部硬件或软件。iPaaS专为处理当今云应用程序使用的轻量级消息传递和文档标准（REST，JSON等）而设计。ESB是一种本地软件体系结构模型，通常利用云之前的通用技术。因此，其庞大的本地资源占用以及较旧的消息传递和文档标准最适合集成本地和聚合系统（如SAP）。这两种集成模型正在融合。一些iPaaS解决方案已发展为支持本地系统，而一些ESB供应商已引入功能以更优雅地支持云服务的集成。
  • ESB旨在集成复杂的IT系统和体系结构。它把企业的本地和遗留系统结合在一起。另一方面，iPaaS提供了更轻量级的集成解决方案，该解决方案更适合于灵活和实时的应用程序，这是基于云的服务的关键要求。
  • iPaaS和ESB之间的主要区别在于可扩展性的方向。ESB最适合垂直可伸缩性-企业复杂的内部系统和体系结构的集成。另一方面，iPaaS更适合于水平可伸缩性-与第三方，合作伙伴和特定应用程序（例如软件即服务（SaaS）解决方案）集成。iPaaS轻巧而灵活，使企业能够快速连接和集成其云应用程序和系统。
  • 多租户架构。多租户体系结构是指在为多组用户服务时在单个服务器上运行的软件的单个实例。由于其固有的复杂性，大多数ESB解决方案不是多租户。另一方面，iPaaS支持多租户。这使iPaaS解决方案比ESB更具优势，因为多个租户或用户可以共享一个实例，以有效减少集成过程中的冗余。多租户还可以减少集成期间的基础架构和管理成本。
  • 临时集成。对于临时集成项目，ESB太慢且太复杂。iPaaS解决方案的简单性，灵活性和实时功能有助于满足临时集成的快速需求。
  • iPaaS和ESB都可以将SaaS解决方案与本地和旧系统集成。iPaaS本质上使用最适合SaaS集成的轻量级连接器（例如JSON和API），而越来越多的ESB解决方案可以利用相同的轻量级Web服务协议。专家称这些集成技术为轻量级ESB或云ESB。
  • 物联网整合。除了SaaS，另一个新兴趋势是支持互联网的设备或物联网（IoT）的兴起。物联网集成需要巨大的水平可扩展性，这是因为所连接的设备数量庞大，轻巧的连接性以及实现最佳性能所需的低延迟。除了这些要求之外，物联网集成还需要实时连接。这些因素使ESB不太适合这种集成。此外，物联网集成还需要外部集成。综合所有这些因素，很容易得出结论，IoT更好的集成解决方案是iPaaS。
  • 互补而非竞争技术。尽管iPaaS相对于ESB具有看似压倒性的优势，但仍然有其局限性。将iPaaS用于具有复杂组织系统和内部架构的企业仍然不切实际且成本效益高。ESB仍然是将内部系统保持在一起的首选胶水。因此，企业经常同时使用iPaaS和ESB来将其内部体系结构和旧系统结合在一起，同时仍可容纳SaaS，云服务和IoT设备等新的集成端点。

ESB与分布式服务框架

10多年前SOA的理念已经在业界非常风行，其中以传统软件厂商提出的以ESB实现SOA的方案为主流，这也是为什么几乎所有传统企业的客户都认为ESB是SOA理念的最佳实践，甚至是唯一的实现，这是一种"中心化"服务框架。

随着互联网架构和技术的普及，很多人都已经对互联网公司的典型架构和技术有了比较多的了解，其中在服务化框架领域，互联网公司流行一种去中心化的服务框架，有一部分人认为"去中心化"不是SOA架构，为此我们一起回顾下SOA的主要特性：

  • 面向服务的分布式计算
  • 服务间松散耦合
  • 支持服务的组装
  • 服务注册和自动发现
  • 以服务契约方式定义服务交互方式

中心化和去中心化这两套SOA的架构并没有优劣之分，很多互联网公司最终选择"去中心化"服务架构作为整个公司统一的服务框架并不代表"去中心化"服务框架是"中心化"服务框架的升级版，而基于这两套架构解决企业的根本诉求是完全不同的

-- ESB模式的"中心化"服务架构的根本诉求：

"去中心化"服务框架是由互联网业务的特性决定的，就是服务的扩展性，"去中心化"相比"中心化"服务架构最重要的不同就是服务提供者和服务调用者之间在进行服务交互时无需通过任何服务路由中介，避免因为"中心点"带来平台能力难以扩展问题，

"去中心化"的服务交互方式很像IT技术发展早期通过系统间"点对点"打通的方式实现不同系统间的集成，ESB的出现很好的解决了这种系统集成带来的各种弊端，新的"去中心化"服务框架在某种程度上是否是一种倒退？其实忽略了"去中心化"服务框架一般是运行在企业内部网络，基于统一的技术接口和标准、网络协议、规范进行交互，已使服务的交互效率最高，又因为是以服务契约先行的方式进行了服务接口功能的约定，在某种程度上很好的保障了服务接口和稳定性，所以大大降低了服务接口和稳定性，所以大大降低了因为服务接口发生变化给服务调用者带来的影响；同时"去中心化"服务框架中辅以多版本支持、负载均衡的支持，从本质上屏蔽掉了之前"点对点"模式下的各种系统稳定性问题。

那么为什么"中心化"服务框架不适合于互联网场景呢？传统ESB的服务调用方式是，每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的ESB来进行路由。服务调用者-> ESB接受服务请求->服务提供者（服务处理） ->ESB返回结果->服务调用者接受服务返回，经过服务总线路由过的服务交互，共出现4次网络会话创建和数据传输，而"去中心化"服务架构中服务交互，一次服务的调用只有两次网络会话创建和数据传输，在网络上的开销整整减少了一半。从逻辑上看，所有服务调用都通过服务总线，服务总线的访问和计算压力都会非常大。

"中心化"架构可能给平台带来灾难性的雪崩效应。

集成框架概览

系统集成框架：Spring Integration, Mule ESB or Apache Camel，这三个框架有很多相似之处。都实现了EIPs 提供了一致的模型和消息传递架构，不管你要使用哪种技术，都是以同样的方式实现集成，即语法相同，相同的API ，同样的自动测试。唯一的区别是每个端点的配置不一样（例如JMS需要队列名称，而JDBC需要数据库连接URL）。Camel 的路由等于Mule flows“, Camel 组件等同于Spring Integration的adapters。与重量级ESB不同，它们都是轻量框架，你只需要一些库添加到类路径中。可以在JVM环境中到处使用每个框架。

  • Spring Integration：Spring集成只提供了技术非常基础的支持 - 只是“基本的东西”，如文件，FTP，JMS，TCP，HTTP或Web服务，集成是通过编写大量的XML代码（没有一个真正的DSL）实现的

  • Mule ESB：顾名思义 - 它不是仅仅一个集成框架，而是一个包括一些额外功能的完整ESB，骡子只是一个轻量级的集成框架，除了EIP集成以外 没有添加任何附加功能。相比Spring集成，骡子只有提供了一个XML的DSL，骡子的Studio提供了一个很好的和直观的可视化设计。从上面下面的代码片段比较Spring集成代码。比Spring集成它更像是一个DSL。这一点很重要，如果集成逻辑比较复杂。

骡子的主要优点是提供一些非常有趣的连接器：SAP, Tibco Rendevous, Oracle Siebel CRM, Paypal 或 IBM’s CICS Transaction Gateway。

  • Apache Camel几乎和骡子相同。你能想到的几乎每一个技术，提供很多很多的组件，骆驼和Spring集成一样棒。外，有一个不错的（但是商业的）可视化设计器称，Fuse IDE, FuseSource提供 - 生成XML的DSL代码。

另一个很棒功能：Apache的骆驼还提供用Java，Groovy和Scala编写的DSL。你不必写了这么多丑陋的XML。就个人而言，我更喜欢使用这些流利的DSL不是XML的一个集成逻辑。