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

目录
相关文章
|
14天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
12天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
23天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
13天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
31 1
服务架构的演进:从单体到微服务的探索之旅
|
11天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
28 8
|
12天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
38 5
|
14天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
36 7
|
13天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
32 5
|
13天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
下一篇
无影云桌面