应用集成技术是市场上被广泛使用的，也是充斥着术语和概念的一个技术领域。集成平台、消息引擎、消息中间件、集成引擎、集成中间件、企业服务总线(ESB)、API 关、API管理… 很多概念与名词。到底它们是什么意思么区别技术适合解决哪种集成问题p>

业务集成的需求和技术的演进是紧随业务系统的软件架构发展而发展的。通过小结软件架构的发展，我们更容易梳理业务集成技术的演进、更容易看清楚各种集成架构的优势和未来发展方向。

软件架构发展简史

大型机架构：上世纪60-70年代。大型机负责数据存储、业务逻辑处理、数据展现等所有工作；客户端只是一个终端，基本上就是键盘加上显示器，负责输入、输出。大型机架构的优势是简单，但显然可扩展性很差。

客户端(PC)分担了很多工作，且数量众多，因此它是一个分布式架构，可扩展性提升。但维护客户端应用，例如升级等带来了很大的管理维护成本。现在很多企业核心应用，例如ERP、HIS都是当时在这个架构下开发出来的，基本都是单体架构应用，业务逻辑间耦合度非常高。应用之间需要做业务的共享交换，主要通过点对点方式集成，也催生了集成技术，尤其是以消息交换为基础的、以消息队列技术为载体的集成方式。在这个时期，HL7组织开发了HL7 V2.x的医疗消息交换标准。

三层架构：上世纪90年代中后期至今。三层架构是展现层(用户界面)、应用层(业务逻辑)和数据层(数据)三层架构。

每个服务都封装有数据和逻辑(代码)，以提供独立的功能，服务之间高度松耦合。而采用XML作为数据格式、以WSDL标准描述服务、以SOAP协议作为交互方式，面向服务架构使不同技术栈的差异对服务透明，使服务在任何技术平台上都可以使用。

随着SOA架构的逐步采纳，企业环境里有了越来越多的服务，企业服务总线(ESB)发展起来。它是一个中心化的软件组件平台，将企业环境中的服务注册在总线上，并协同这些服务。ESB通常借助消息引擎、业务流程引擎、数据转换引擎，执行服务路由、服务协同和服务间的数据结构转换。

更近一步，先进的ESB还融合了接口引擎的技术，有能力将非SOA架构的应用接口封装为服务并注册到总线，使其可以和其它服务一样被调用和协同。这些恰恰都是集成的目的，因此ESB成为一个重要的集成技术。

HL7 在此期间，也推出了基于参考信息模型(RIM)的HL7 CDA临床文档标准用于文档交换和HL7 V3 消息标准用于消息交换，它们都是基于XML的。IHE也推出了基于SOA架构的业务协同服务标准。

ESB中心化的部署模式意味着低维护成本和高一致性，但敏捷性不够。

微服务架构(MSA)：2010年代开始至今。微服务架构类似SOA，强调业务封装和复用、业务解耦，往往和SOA发生混淆。但今天的业务环境已经和10多年前不可同日而语了：

• 业务迭代进化速度上，越来越快；
• 业务范围上，传统的企业内部服务的围墙被突破了，越来越多的业务需要直接和上下游供应链打通，服务延伸到企业之外，直接面向客户。例如以前患者只能去医疗机构看病，医疗机构也只有患者的院中数据，现在不但有互联 医院，医院也需要院前、院后的患者数据和例如基因测序公司来的组学数据来支撑精准医学；
• 业务量上，随着传统业务围墙的打破，业务量越来越大，例如互联 医院和医疗物联 带来了大量的业务和数据。传统可扩展性已经难于满足，需要提供更灵活的、更细颗粒度的业务弹性；
• 部署模式上，云部署、容器化部署越来越主流。

而SOA架构技术上很重：复杂啰嗦的XML、沉重的SOAP协议、中心化的ESB架构，在当今追求敏捷性的今天显得力不从心，甚至从“赋能者”变成了“拖累者”。

基于消息队列/消息引擎/消息中间件的集成方案：

消息引擎是非常有价值的基础技术架构，很多应用都需要基于消息队列处理，例如保证先进先出、异步处理、处理长时间运行的任务、削峰填谷等。因此很多集成场景也需要基于消息队列和消息路由。这类方案适用于消息交换和文档交换范式。

但消息引擎仅仅是集成需要的一个底层基础技术架构，完整的集成方案应该整合好其它技术，例如解决连接问题的适配器、流程建模、数据转换等，也就是说基于消息引擎的方案需要做很好的二次开发和封装才能开发出一个适用的集成平台或集成方案。

同时，我们看到市场上不少基于消息引擎的“半成品”集成方案。这类方案的特点是仅有消息引擎，通过消息路由规则来替代流程建模；同时要求各被集成的应用直接连接消息引擎来收发消息。这意味着：

• 高昂的开发成本：不论各业务系统本身是否已经提供有接口，它们都需要现场使用消息引擎提供的连接技术，如dll，开发出一个模块用来连接消息引擎并收发消息、再和自己的应用做对接。
• 性能和稳定性风险：对于开发本身，要求来自不同技术栈的开发人员按消息引擎提供的技术栈进行开发，面临很高的性能和稳定性风险。
• 能力缺失：显然，没有数据校验能力、数据丰富与转换能力、复杂的流程建模能力…

集成引擎可以满足多种互操作范式，包括消息交换和文档交换。通常都具有：

• 消息引擎：用于基于消息路由和业务流程的交换，保证先进先出、异步处理等。但一般是内部使用，而不会直接暴露给被集成系统直接使用。业务系统还是通过适配器连接。
• 业务流程引擎：创建和运行业务流程模型，实现业务流程自动化。相对路由规则，它提供更复杂流程处理的能力，例如循环处理、数据丰富(按流程从不同数据源补齐数据)。
• 规则引擎：建立并执行规则逻辑，给出逻辑输出。通常规则用于消息路由和业务流程。
• 数据转换引擎：建立数据在各种模型间的转换关系，并使用它们对数据进行转换。

集成引擎提供完整的工具集简化了集成工作，它也是目前市场采用最多的架构方案。但其中心化的架构影响了其弹性，同时为避免成为单点故障和性能瓶颈，需要其提供高可用能力和良好的性能。

基于ESB的集成方案：

企业服务总线是一个中心化的架构，通过封装、注册、协同调用和监控服务，以面向服务架构应用在业务集成领域，且多数用于企业内部的应用集成。

很多ESB产品都具有集成引擎的核心能力，例如适配器、流程建模、数据转换等。在集成架构上，基于ESB和基于集成引擎二者相似度非常高，甚至可能就是不同厂商叫的不同的名字，差异在于集成引擎不一定是基于SOA架构的。

微服务是一个去中心化的架构，但API 关是中心化的，虽然可以部署多个API 关，但其仍有沦为小ESB的风险。另外API 关对于现有的非服务化的IT资产无能为力。

展望

相信随着软件架构的发展，集成技术也会不断发展。但立足于当前的技术，在集成架构和方案上，仍能看到一些趋势。

融合多种集成架构的集成平台

从上面分析可见，面对当前多样化的企业信息化环境，上述各种集成架构恐怕都无法单独满足所有集成需求。融合多种集成架构的集成平台产品能够更好地应对多种集成场景。

这样的集成平台可以梳理和集成现有业务，在保证业务稳定运行的前提下，逐步将现有不具备弹性的业务进行服务化或微服务化，从而安全、平稳地实现数字化转型。

数据与业务集成融合

数据的价值在于决策。随着数字化转型，企业IT架构需要更真实、更及时、更全面地表达现实世界(数据全貌)和更完整的流程(流程全貌)，将开放性分析能力纳入数据和流程，提供基于实时数据的完整洞悉(insight)，并将预测结果甚至是决策结果直接反馈回业务流程。

当今负责数据全貌的是数据中心，承载业务流程的是ESB，它们是不同的产品和架构，业务流程的产生数据要定期同步到数据中心，也造成数据中心的及时性成问题。

如果将数据中心比作数据存蓄的湖，集成平台比作数据流动的江，那我们需要江湖一体的架构，以提高数据实时性和流程决策闭环能力。在数据层面，要能处理、容纳各种模型的数据，支持数据编织(Data Fabric)。同时这个架构下要有强大的分析、决策能力，包括BI、自然语言处理、机器学习等。

业务创新平台

业务创新依赖现有业务基础。使用ESB梳理现有企业信息、流程资产，拥抱新架构将数字资产微服务化，并通过创建新的服务、组合现有服务快速创新。融合行业互操作和数据标准，提供开箱即用的行业价值。拥有这些能力，将帮助现有架构演化为企业的业务创新平台。

当然，这些已经不仅是集成架构的未来，而是整个数字化架构的未来。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92925 人正在系统学习中