ESB 或 企业服务总线是一种架构模式,在这里,集中的软件组件会执行应用程序之间的集成任务。 它执行数据模型的变换 、处理 连接/消息 传递、执行路由、转换通信协议,且可能会管理多个请求的组合。 ESB 可以将这些集成和转换 作为服务接口提供,以供新应用程序复用。
通常使用专用的集成 运行时 和工具集(即 esb 产品)来实施 ESB 模式,以确保最佳的生产力。
ESB 是
SOA( 面向服务的架构
)的基本组件,它是 二十世纪九十年代后期出现的架构。 SOA 定义了通过服务接口来复用软件组件的方法。 此类服务通常会使用标准接口(即 Web Service),能够快速合并到新应用程序中,而不必复制服务在新应用程序中执行的 功能 。
SOA 中的每项服务都包含执行完整的独立业务功能(例如,检查客户信用、计算每月还贷额或处理抵押申请)所需的代码和
数据
。 服务接口可提供松散耦合,这意味着即便对底层的服务
实施方式知之甚少或根本不了解,也可以调用这些服务,减少了应用程序之间的依赖性。 服务接口背后的应用程序可在 Microsoft 中以 Java 编写 。Net、Cobol 或任何其他编程语言,由供应商(如 SAP)作为打包软件应用提供,作为 SaaS 应用(如 Salesforce CRM)提供,或作为 开源 应用获取。
服务接口经常使用 Web 服务 定义语言 (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 细分为若干个去中心化的集成组件,这些组件不存在相互依赖关系,并且单个应用程序团队可以拥有并自主管理此类组件。
如需更深入地整体了解 微服务,请阅读“
微服务:完整指南
”以及“
SOA 与 微服务:区别在哪里?
”,并观看 Dan Bettinger 的解读视频“什么是 微服务?”:
随着贵公司将 IT 基础架构转向
混合云
方法,因此很可能需要将各种工作负载(包括基于 SOA 和 ESB 模式的工作负载)转变为更轻量、更灵活的部署模型。
随着对客户体验的要求越来越高以及对业务和 IT 运营产生影响的应用程序越来越多,这些转换只会是
应用现代化
其中的 一部分 。 提高自动化程度对于满足这些需求很有帮助。 理想情况下,应该从小型且明显成功的项目开始,然后针对组织的其他过程和其他部分进行扩展和优化。
通过与 IBM 合作,您可以访问
AI 驱动的自动化功能
,包括预先构建的工作流程,帮助您通过提高每个流程的智能化水平来加速创新。
采取下一步行动:
了解如何通过
IBM Cloud Pak for Integration 来利用和扩展中间件投资并将其现代化,
它是一种混合集成解决方案,为多种样式的企业集成提供自动化的闭环生命周期。
要了解如何跨多个
私有
和公有云连接您的所有应用程序和数据,以创建个性化的客户体验,请访问
IBM Cloud 集成解决方案
。
获取
IBM 应用现代化领域指南
,了解如何加速现代化、改善开发人员的生产能力,并提高操作效率和标准化。
进行
集成成熟度评估
,以评估您的跨关键维度的集成成熟度 ,并发现您可以采取哪些措施以达到 更高的成熟度。
下载我们的
敏捷集成指南
,此指南将探讨基于容器且与微服务一致的分散式解决方案集成方法的优点。
阅读这份 HFS 研究报告,了解
有关自动化取得成功的五个“必备条件”(链接位于 IBM 外部)
。
立即创建
IBM Cloud 账户
以使用该产品。