架构那点事系列三 - 由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。。。

目录
相关文章
|
2月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
3月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
83 3
|
3月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
2月前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
305 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
11天前
|
传感器 监控 安全
智慧工地云平台的技术架构解析:微服务+Spring Cloud如何支撑海量数据?
慧工地解决方案依托AI、物联网和BIM技术,实现对施工现场的全方位、立体化管理。通过规范施工、减少安全隐患、节省人力、降低运营成本,提升工地管理的安全性、效率和精益度。该方案适用于大型建筑、基础设施、房地产开发等场景,具备微服务架构、大数据与AI分析、物联网设备联网、多端协同等创新点,推动建筑行业向数字化、智能化转型。未来将融合5G、区块链等技术,助力智慧城市建设。
|
3月前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
98 1
服务架构的演进:从单体到微服务的探索之旅
|
2月前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
109 8
|
3月前
|
负载均衡 Java 持续交付
深入解析微服务架构中的服务发现与负载均衡
深入解析微服务架构中的服务发现与负载均衡
172 7
|
3月前
|
消息中间件 运维 Kubernetes
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
65 1

热门文章

最新文章