ESB 是 SOA（即面向服务的架构）的一个重要组成部分，SOA 是 20 世纪 90 年代末出现的一种软件架构。SOA 定义了一种通过服务接口使软件组件可重复使用的方法。这些服务通常使用标准接口（即，Web 服务），从而可以将它们快速合并到新应用程序中，而无需在新应用程序中复制由服务执行的功能。

SOA 中的每个服务都包含执行完整、分散业务功能所需的代码和数据（例如检查客户的信用、计算每月贷款付款或处理抵押贷款申请）。服务接口提供松耦合，这意味着可以在很少或根本不了解如何在底层实施服务的情况下进行调用，从而减少应用程序之间的依赖关系。服务接口背后的应用程序可以用 Java、Microsoft .Net、Cobol 或任何其他编程语言编写，作为供应商的封装企业应用程序（例如 SAP）、SaaS 应用程序（例如 Salesforce CRM）提供，或者作为开源应用程序获得。

服务接口经常使用 Web 服务定义语言 (WSDL) 进行定义，WSDL 是基于 xml（可扩展标记语言）的标准标记结构。这些服务使用标准网络协议（例如 SOAP（简单对象访问协议）/HTTP 或 JSON/HTTP）公开，以发送读取或更改数据的请求。服务治理控制开发的生命周期，并在适当的阶段将服务发布到注册表中，以便开发人员能够快速找到服务并重复使用它们来组装新的应用程序或业务流程。

服务可以从零开始构建，但通常是通过公开记载的旧系统中的功能来创建的。企业可以选择在旧系统前面提供基于标准的服务接口，使用 ESB 通过适配器或连接器直接连接到旧系统，或者应用程序可以提供自己的 API。在任何情况下，企业服务总线都会将新应用程序与遗留接口屏蔽开。ESB 执行必要的转换和路由，以连接到旧系统服务。

可以在没有 ESB 架构的情况下实现 SOA，但这相当于只获得一堆服务。每个应用程序所有者都需要直接连接到其所需的任何服务，并执行必要的数据转换以满足每个服务接口。这是一项繁重的工作（即使接口可重用），并且由于每个连接都是点到点，因此在未来会带来重大的维护挑战。

理论上，集中式 ESB 可以实现标准化并显著简化整个企业服务之间的通信、消息传递和集成。硬件和软件成本可以分摊，从而根据组合使用的需要配置服务器，提供可扩展的集中式解决方案。可以指派一个专家团队（并在必要时进行培训）来开发和维护集成。

软件应用程序只需连接（“对话”）ESB，然后将其交给 ESB 来转换协议、路由消息并根据需要转换为数据格式，从而提供执行事务所需的互操作性。企业服务总线架构方法支持应用程序集成、数据集成和业务流程的服务编排方式自动化场景。这使得开发人员能够花费更少的时间进行集成，而将更多的时间专注于交付和改进应用程序。如果能够在一个项目切换到下一个项目时重复使用这些集成，则有可能进一步提高工作效率并节省下游成本。

但是，尽管 ESB 已在许多组织中成功部署，但在许多其他组织中，ESB 却被视为瓶颈。对一种集成进行更改或增强可能会破坏使用同一集成的其他人的稳定性。ESB 中间件的更新通常会影响现有集成，因此执行任何更新都需要进行大量测试。由于 ESB 是集中管理的，应用程序团队很快发现自己在排队等待集成。随着集成量的增长，为 ESB 服务器实现高可用性和灾难恢复的成本变得越来越高。作为一个跨企业项目，ESB 已证实很难获得资金支持，因此更加难以解决这些技术挑战。

最终，维护、更新和扩展集中式 ESB 的挑战已证实非常艰巨和昂贵，因此 ESB 经常延迟它和 SOA 本来计划获得的效率增幅，这让期望加快创新步伐的业务团队感到沮丧。

要更深入地了解 ESB 的兴衰史，请阅读“ESB 的命运”。

微服务架构支持将单个应用程序的内部结构分解为可以独立更改、扩展和管理的小块。随着 虚拟化、云计算、敏捷开发实践和 DevOps 的兴起，微服务应运而生，并蓬勃发展。在这种情况下，微服务可提供以下功能：

• 支持开发人员将新技术融入应用程序的一部分，而无需触及或“赶上”应用程序的其余部分，从而提高了开发人员的敏捷性和工作效率。
• 支持任何组件独立于其他组件进行扩展，实现更简单、更具成本效益的可扩展性，从而以最快的速度响应工作负载需求并最有效地利用计算资源。
• 具有更大的弹性，因为一个组件的故障不会影响其他组件，并且每个微服务都可以满足自己的可用性要求，而无需让其他组件满足“最大通用可用性”要求。

微服务在应用程序设计方面具备的详细程度也可以应用于集成，并具有类似的优势。这就是敏捷集成背后的理念，它将 ESB 分解为细颗粒度的、分散的集成组件，没有相互依赖关系，各个应用程序团队可以自己拥有和管理这些组件。