架构那点事系列三 - 由EAI到ESB

简介:         最近在梳理公司的EAI平台 — JCAPS,顺便翻阅了一些“历史”文献,梳理成文,希望能加深大家对SOA的认识。         ESB 是软件行业的下一代集成产品的名称。ESB 沿用企业应用程序集成 (EAI) 的技术道路前行,在改进 EAI 中的某些技术环节的同时,采用了 EAI 技术中的更为有效的方面。尽管 EAI 和 ESB 的目标相同,但是在技术体系结构方面,这

        最近在梳理公司的EAI平台 — JCAPS,顺便翻阅了一些“历史”文献,梳理成文,希望能加深大家对SOA的认识。

        ESB 是软件行业的下一代集成产品的名称。ESB 沿用企业应用程序集成 (EAI) 的技术道路前行,在改进 EAI 中的某些技术环节的同时,采用了 EAI 技术中的更为有效的方面。尽管 EAI 和 ESB 的目标相同,但是在技术体系结构方面,这两项产品的区别仍很大。

       从历史上看,EAI 技术是软件行业首次尝试将市场上各种不同中间件解决方案整合为单一产品套件。当各公司开始寻求在不同的自动化系统间交换信息时,对 EAI 的需求也就应运而生了。在上世纪的九十年代,企业范围内诸如客户关系管理 (CRM) 和企业资源计划 (ERP) 等业务举措是促使 EAI 系统诞生的主要驱动因素。

        在 EAI 面世之前,中间件的蓝图主要是由一系列协议栈(例如 CORBA、Tuxedo 和 MQ)以及数据格式(XML、XDR、固定格式、可变格式等)构成的。这些技术中的每一项都能够在很大程度上满足企业自身的集成需要,但是这需要选定的协议和数据格式在企业中完全通用才能够实现。事与愿违,实际情况却是,大中型 IT 企业都不可避免的具有异构特点。 


                           图 1 EAI 代理程序充当交换中心角色

        如图 1 所示,EAI 采用了一种简单有效的方式来解决不同应用程序间的集成问题。EAI 软件创建了一个交换中心,用于转换不同应用程序间的数据和消息。EAI 交换中心使用这些适配程序将所有进入数据的格式重新转换为一种 EAI 交换中心内部和外发适配程序都可以理解的通用格式,并将其称为规范格式。每个适配程序都是一个有自主权的实体软件,存在多个分别负责管理各种应用程序特定交互操作的管理层,同时还另具有一些传输层,用于管理与应用程序和交换中心的连接。  
        为实现 EAI 各组件间的连接,EAI  交换中心会在所有的内部集成过程中都采用一个如 JMS 的异步消息代理程序。除了重新更改消息负载格式外,所有应用程序间的交互都要经过中间件的多次转换。而且,应用程序所需的,例如事务处理和验证/授权安全等服务质量功能通常都无法实现这些转换。


      图 2  交换中心不断进行数据编组
       作为第一代产品,EAI 是成功的,它提供了一个前所未有的解决方案。但是 EAI 体系结构有其固有的局限性,因此限制了它提供企业级可持续解决方案的能力。如图 2 所示,集中式交换中心使得企业(或者至少是企业中的几个特定的人)可以采用中央控制的方式。但是不断地将数据编组为规范格式或转变回原有格式的代价就是造成额外的处理负担,也就是需要购买高端服务器和管理程序实现对其的管理。虽然大多数 EAI 解决方案都允许您在集群中部署多个交换中心以便获取更大的可缩放性,但这只是在某个限度内是实用,而当您添加更多专用硬件时很快就会变得非常昂贵。

       相对人工编码而言,每次改变企业应用程序组合的中间件和应用程序接口时 EAI 具有明显的优势。这是一项技术上的突破,当整个行业的想法都聚焦在为支持整个企业的举措而需要大型应用程序交换数据时它将发挥最大的作用。因为这是第一代的 EAI 工具,供应商尝试使用增量的方式来处理 EAI 的缺点。但是,因为不断地添加新功能,这使得 EAI 系统变得庞大、缺乏灵活性且难于管理。从长远来看,如果要实现真正的企业集成需要一种更好的技术。

       ESB  是下一代的企业集成技术,在 EAI  退出市场后取代了它的位置。与 EAI 一样,ESB 也是一项允许开发人员集成使用不同中间件技术创建的异构系统的技术。ESB 一方面利用了它面向服务的优势,同时还通过使用更有效、更灵活的内部体系结构进一步改进了它的上一代 EAI 产品。

 
    了解 SOA 和 ESB 之间的关系非常重要。SOA 代表策略、架构,这些因素使得应用程序可以提供各种功能并且可以作为服务集合供其它应用程序使用。服务是一种业务完整的逻辑工作单元,可以通过直接开放的文档接口从独立设计环境以编程方式进行访问。可以调用、发布和发现服务,也可以使用单一的基于标准的接口方式抽象实现。应用程序软件由以松散 1 对 1 耦合关系存在的服务和服务消费者(即客户)构成。 


图3  ESB 提供轻量级的分布式体系结构

       SOA 是软件行业为应对单一大型应用程序的管理问题产生的解决方案。正如我们想象的那样,应用程序体系结构的这一变化对于怎样才能获得最佳的应用程序集成产生了极大的影响。如图 3所示,ESB 为服务提供者和服务消费者之间的集成提供了一个平台。在现代平台上开发的新应用程序,其本质都是面向服务的应用。但是,有一些现有的企业应用程序并没有使用 SOA 的设计理念。在此情况下,ESB 应该能够提供将这些应用程序暴露为服务的能力。而因为以下一些原因,大家正在转而使用最新的 ESB架构:

        a 更智能的端点 — ESB 启用的体系结构在应用程序与外界的接口点处配置了更多的智能功能。ESB 允许每个端点使用各种标准(如 WSDL 等)以服务的形式呈现自己,因此不需要为每个应用程序编写专用接口。可以在端点(客户机和服务器)创建时将集成智能性部署在这些端点上。可以绕过规范格式而将负载直接转换为目标格式。这一方法有效的去除了 EAI 产品所固有众多复杂特性。 
        b 集中式与分布式 — 当 EAI 完全采用中心辐射型通信方式时,ESB 采用了轻量级的分布式体系结构。当必须将程序间的每次交互转换为规范格式时,集中式的交换中心才有意义。ESB可以将更多的处理逻辑分配到端点上。这与大型主机和现代的分布式系统体系结构间的区别相似。交换中心与大型主机一样,仍然可以用于某些需要它的体系结构中,但它们只是开发人员的一项选择,而不是供应商指定的要求。 
       c 无集成堆叠 — 过去,当客户需要使用 EAI 产品来解决更多问题时,各供应商就会在 EAI 中附带添加多种堆叠的专用功能。随着时间的推移,这些堆叠的集成都成为专用的语言,需要具有更高的技术水平才能使用。与此不同的是,ESB 是一个具有相对少层级的软件,您可以使用开放式标准应用其它处理层。例如,如果某个 ESB 用户希望部署某个     c.特定的业务流程管理工具,您只需使用行业标准接口(如用于协调这些业务流程的 BPEL)就可以很轻松地将该工具集成到 ESB 中。


        ESB 方法的立即见效的短期优势在于它在获得与 EAI 方法相同总体效果的同时,花费的总拥有成本更低。这一节省不但可以通过减少硬件和软件的花费来实现,而且还可以通过因使用灵活的分布式框架而节约成本。也正因为此,企业应用也越来越重视SOA,SCA。。。

目录
相关文章
|
5天前
|
敏捷开发 监控 数据管理
构建高效微服务架构的五大关键策略
【4月更文挑战第20天】在当今软件开发领域,微服务架构已经成为一种流行的设计模式,它允许开发团队以灵活、可扩展的方式构建应用程序。本文将探讨构建高效微服务架构的五大关键策略,包括服务划分、通信机制、数据管理、安全性考虑以及监控与日志。这些策略对于确保系统的可靠性、可维护性和性能至关重要。
|
17天前
|
API 数据库 开发者
构建高效可靠的微服务架构:后端开发的新范式
【4月更文挑战第8天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构面临着可扩展性、维护性和敏捷性的挑战。为了解决这些问题,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、实施策略及其带来的优势与挑战,为后端开发者提供一种全新视角,以实现更加灵活、高效和稳定的系统构建。
23 0
|
5天前
|
消息中间件 监控 持续交付
构建高效微服务架构:后端开发的进阶之路
【4月更文挑战第20天】 随着现代软件开发的复杂性日益增加,传统的单体应用已难以满足快速迭代和灵活部署的需求。微服务架构作为一种新兴的分布式系统设计方式,以其独立部署、易于扩展和维护的特点,成为解决这一问题的关键。本文将深入探讨微服务的核心概念、设计原则以及在后端开发实践中如何构建一个高效的微服务架构。我们将从服务划分、通信机制、数据一致性、服务发现与注册等方面入手,提供一系列实用的策略和建议,帮助开发者优化后端系统的性能和可维护性。
|
16天前
|
Kubernetes 安全 Java
构建高效微服务架构:从理论到实践
【4月更文挑战第9天】 在当今快速迭代与竞争激烈的软件市场中,微服务架构以其灵活性、可扩展性及容错性,成为众多企业转型的首选。本文将深入探讨如何从零开始构建一个高效的微服务系统,覆盖从概念理解、设计原则、技术选型到部署维护的各个阶段。通过实际案例分析与最佳实践分享,旨在为后端工程师提供一套全面的微服务构建指南,帮助读者在面对复杂系统设计时能够做出明智的决策,并提升系统的可靠性与维护效率。
|
26天前
|
存储 监控 Kubernetes
探索微服务架构下的系统监控策略
在当今软件开发领域,微服务架构因其灵活性、可扩展性和容错性而日益受到青睐。然而,这种架构的复杂性也为系统监控带来了新的挑战。本文旨在探讨在微服务环境下实现有效系统监控的策略,以及如何利用这些策略来确保系统的健壮性和性能。我们将从监控的关键指标入手,讨论分布式追踪的重要性,并分析不同的监控工具和技术如何协同工作以提供全面的系统视图。
|
3天前
|
监控 API 持续交付
构建高效微服务架构:后端开发的新趋势
【4月更文挑战第23天】 随着现代软件开发实践的不断演进,微服务架构已经成为企业追求敏捷、可扩展和弹性解决方案的首选。本文深入探讨了如何构建一个高效的微服务架构,涵盖了关键的设计原则、技术选型以及实践建议。通过分析微服务的独立性、分布式特性和容错机制,我们将揭示如何利用容器化、服务网格和API网关等技术手段,来优化后端系统的可维护性和性能。文章旨在为后端开发人员提供一套全面的指南,以应对不断变化的业务需求和技术挑战。
|
7天前
|
机器学习/深度学习 运维 Prometheus
探索微服务架构下的系统监控策略
【4月更文挑战第18天】在当今快速迭代和持续部署盛行的软件工程实践中,微服务架构因其灵活性和可扩展性受到企业青睐。然而,随着服务的细粒度拆分和网络通信的增加,传统的监控手段已不再适用。本文将探讨在微服务环境中实施有效系统监控的策略,包括日志聚合、性能指标收集、分布式追踪以及异常检测等关键技术实践,旨在为读者提供构建稳定、可靠且易于维护的微服务系统的参考指南。
12 0
|
7天前
|
监控 持续交付 开发者
构建高效微服务架构:后端开发的新趋势
【4月更文挑战第18天】在数字化转型的浪潮中,微服务架构已成为企业提升系统灵活性、加速产品迭代的关键。此文深入探讨了构建高效微服务架构的实践方法,包括服务划分原则、容器化部署、持续集成/持续部署(CI/CD)流程以及监控与日志管理等关键技术点。通过分析具体案例,揭示了微服务在提高开发效率、降低维护成本及促进团队协作方面的显著优势。