从软件架构发展谈业务集成技术演进与展望_软件系统集成方案演变 企业服务总线 api

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

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

软件架构发展简史

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

 

在大型机时代，几乎没有集成的需求。

客户端/服务器（C/S）架构：上世纪80年代到90年代。服务器负责数据存储和处理，以及服务器端端业务逻辑处理；客户端（PC）负责客户端逻辑处理、数据验证、数据展现等工作。

 

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

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

 

这里的三层架构不仅指软件功能的层次，而且指软件运行的基础架构的层次。由于在软件功能和基础架构上的分层和分布式设计，三层架构应用通常有很好的可扩展性和可维护性，虽然仍是单体架构应用，但它降低了业务逻辑的耦合度和基础架构层次间的耦合度。另一方面，三层架构让整体复杂程度上升了。分层架构和不断涌现的技术实现，如.net、java、EJB…使这些应用间的互相调用变得越来越复杂了，接口引擎或集成引擎应运而生，并在这个时期发展壮大起来。它们要解决这么多技术平台的连接问题，适配器是主要手段。

面向服务架构（SOA）：上世纪90年代末期至今。前面的所有架构，基本都是单体架构模式 – 也就是孤岛模式，业务耦合度高而难以拆分，代码复用性低。不同应用中有大量功能重复的业务逻辑代码和数据，例如医疗行业的患者管理，几乎每个科室系统都有