什么是 ESB？
原文地址 zhuanlan.zhihu.com
企业服务总线（Enterprise Service Bus，ESB）的概念是从服务导向架构 (Service Oriented Architecture， SOA) 发展而来。
SOA---- 面向服务架构，实际上强调的是软件的一种架构，一种支撑软件运行的相对稳定的结构，表面含义如此，其实 SOA 是一种通过服务整合来解决系统集成的一种思想。不是具体的技术，本质上是一种策略、思想。
ESB---- 企业服务总线，像一根管道，用来连接各个节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转换、解释与路由等工作，让不同的服务互联互通。
ESB 是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于：
面向服务的架构 - 分布式的应用由可重用的服务组成
面向消息的架构 - 应用之间通过 ESB 发送和接受消息
事件驱动的架构 - 应用之间异步地产生和接收消息
ESB 就是在 SOA 架构中实现服务间智能化集成与管理的中介。
ESB 的工作就是提供和调用集成系统的服务。使用了 ESB，在大多情况下，每个系统和 ESB 之间，只需要定义一个访问方法，一个接口。如果这样，像上面的图一样，你有 8 个系统，就只有有 16 个接口（1 个方向 1 个）需要被创建、维护、管理和关注。否则你就需要 56 个接口需要去思考和处理。（假设每个系统都需要跟其他系统对话），少了 40 个接口意味着更少的成本。
下面可以看出 ESB 在各个系统服务之间发挥的作用
可以看出，ESB 既能为各个系统服务又能管理各个系统，可以利用现有的服务系统组合新的系统。
ESB 作为企业级的服务联通、管理平台，需要穿透 ESB 的服务应该是企业内重用可能最大、价值最大的那些服务，应用程序对这类服务的访问应该非常频繁，因此同一时刻需要 ESB 支撑的业务可能非常繁重。所以，ESB 实现的是一个无状态、高吞吐的服务总线，要具备为企业内重要的业务服务提供透明、标准、开放的接入能力。
得帆云产品矩阵：
得帆云低代码平台（aPaaS）、企业集成服务平台（iPaaS）、主数据管理系统（MDM）、数据中台（DeHoop）、身份管理（iDaaS）、得帆云门户（DPortal）等产品和解决方案。
- 得帆云 iPaaS 以 API + ESB 为双引擎的集成平台， “一站式” 应用、服务、数据集成解决方案。
- 得帆云 aPaaS 无代码配置 + 低代码定制开发，支持公有云使用和私有化部署，超过 300 + 客户的共同选择。
- DMDM 主数据平台 功能完备的主数据管理平台，提供建模、数据清洗、创建、管控、共享、探查等全生命周期管理。
- DeHoop 数据中台 企业级数据管理平台，集成数据资源，开发数据资产，发布数据服务。
- iDaaS 身份管理 实现公司信息化系统账号统一对应、集中的管理，实现员工用户身份的统一认证和单点登录，对用户集中认证和安全审计。
- DPortal 企业门户 具有强大配置、集成能力的门户平台，兼具多租户、国际化、千人千面等特性。
· TechPaaS 技术中台 以云原生技术为核心，提供丰富的技术组件库，助力企业数字化应用构建。
什么是 ESB？
ESB（即企业服务总线）是一种架构模式，集中式软件组件通过该模式在应用程序之间执行集成。它执行数据模型的转换、处理连接、执行消息路由、转换通信协议并可能管理多个请求的组合。ESB 可以将这些集成和转换作为服务接口，以供新应用程序重复使用。
ESB 模式通常使用专门设计的集成运行时和工具集（即 ESB 产品）来实现，以确保实现最佳工作效率。
ESB 和 SOA
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 的挑战已证实非常艰巨和昂贵，因此 ESB 经常延迟它和 SOA 本来计划获得的效率增幅，这让期望加快创新步伐的业务团队感到沮丧。
要更深入地了解 ESB 的兴衰史，请阅读“ESB 的命运”。
ESB 和微服务
微服务架构支持将单个应用程序的内部结构分解为可以独立更改、扩展和管理的小块。随着 虚拟化、云计算、敏捷开发实践和 DevOps 的兴起，微服务应运而生，并蓬勃发展。在这种情况下，微服务可提供以下功能：
支持开发人员将新技术融入应用程序的一部分，而无需触及或“赶上”应用程序的其余部分，从而提高了开发人员的敏捷性和工作效率。
支持任何组件独立于其他组件进行扩展，实现更简单、更具成本效益的可扩展性，从而以最快的速度响应工作负载需求并最有效地利用计算资源。
具有更大的弹性，因为一个组件的故障不会影响其他组件，并且每个微服务都可以满足自己的可用性要求，而无需让其他组件满足“最大通用可用性”要求。
微服务在应用程序设计方面具备的详细程度也可以应用于集成，并具有类似的优势。这就是敏捷集成背后的理念，它将 ESB 分解为细颗粒度的、分散的集成组件，没有相互依赖关系，各个应用程序团队可以自己拥有和管理这些组件。