ESB拓扑方案

2008 年 7 月 02 日

摘要

在实施 SOA 时,现在非常流行使用象企业服务总线(ESB)这样的基础设施。在一个企业中,对于这种基础设施至少有两种不同的实现思路:在公司内使用多个的 ESB 服务器,每个服务器解决一个特定部门的特殊集成问题;或使用一个覆盖全公司的 ESB,它负责将信息系统所有部分链接在一起。本文将讨论这两种方式在架构与管理方面的若干问题。

不同的基础设施

5 年来,ESB 一直是 SOA 基础方面的一个时髦词汇。ESB 这个概念是 David Chappell 提出的,但时至今日仍然没有真正适合它的定义。的确,每个 ESB 厂商都鼓吹各自的愿景,另外在基础设施层面也存在着不同的实现方式。每种方式都有其优点和缺点。

第一种方式是让各个部门用自己的 ESB 实现去管理自己的 SOA。它管理应用的集成与业务过程的开发。通过使用分散独立的 ESB,每个部门可以自由地实施它想要的解决方案。但是当需要与其它合作伙伴进行通信时,部门 ESB 要通过一种标准的“桥接”技术(如 Web 服务)才能访问和提供一些业务服务。在这种情形下,通信可以依赖于诸如 HTTP 这样的协议,而服务质量(如可靠性或安全)则必须依靠手工实现。

第二种方式将 SOA 基础设施视为一个整体视图,在其中 ESB 是全公司统一的。这种 ESB 遍布于各个部门的各台服务器上,以确保它们之间能进行通信。对另一个部门提供的服务进行调用非常简单,因为消费者与 ESB 通信的方式与它调用本地服务的方式没有分别。

在这个视图中,ESB 真正被视为一个主干基础设施,就像一个以太网。实际上,ESB 是一个天生内部互联的节点集合。一个节点就是服务消费者或提供者的连接点。

注:一个 ESB 节点实际上是一个具有网络能力、能与其它实例互联的 ESB 服务器。

## 覆盖全公司网络的 ESB 并不是一个老大哥

首席信息官的第一反应可能会说“哦,不!我不想要一个允许任何人都可浏览和访问公司内任何东西的‘无处不在的’工具”,管理员们可能会嚷道“我如何管理和监督?”,“其它管理员可以修改我服务器上的东西,这不可能”,或大家经常听到的“安全性怎么办?”,等等诸如此类……

显然,一个通用 ESB 不会允许每一件事。它只是简化了整个网络的通信,并以一种简化的方式提供一组全网络的服务质量。

统一 ESB 中的域(Domain)

域和子域定义了实体间的边界。这样,从管理上来,每个 ESB“节点”只能由子域管理员来管理。子域管理员是唯一能启动、停止、安装连接器、部署服务等活动的人,他管理被域中 ESB 节点所使用的端口,并可以设置代理或防火墙来保护这些端口。

部署于一个域中节点上的业务服务可以是公共或私有的。也就是说,在注册中心中,一个私有服务只对同一域中的消费者可见。而且,私有服务只能由相同域的消费者访问。

注:除非明确说明,在以下几节中将不会讨论私有服务。

服务和过程监测只能显示本域信息或其他域的公共信息,不能看到其他私有域的过程或服务统计。

既然我们已经清除了若干关于统一 ESB 是什么的潜在误解,让我们看看它的优点。

注册中心

在一个非互联 ESB 环境中,对于其他域的服务,只有在两个域的 ESB 之间显式地为该服务创建一个桥接才能访问该服务。比如,某域中的一个服务被暴露为一个经典的 Web 服务,另一个 ESB 必须知道 URL 才能调用它。要引用所有这样的 Web 服务需要一个公司范围的注册中心。在这种情形下,每个域的管理者必须将本域的 Web 服务发布到这个公司注册中心中。这些 Web 服务可以被认为是公司的“公共”服务,因为它们对所有消费者可见。

在一个统一 ESB 中,业务服务注册中心本身就是统一的;每个 ESB 实例的注册中心会与其它 ESB 的注册中心进行同步。一个消费者或服务浏览器只要连接到其中一个域的 ESB 就可以看到总线上的所有服务。每当有新服务被暴露于 ESB 上,每一个 ESB 实例上的所有消费者都可以立即发现并访问它,与这个 ESB 的物理位置无关。所有服务以同一方式被访问;它们是“ESB 服务”。不管它们是如何实现的,也不管使用的是什么协议。

编配

要编配遍布于多个非互联 ESB 上的服务有两种方案。一种方案是将 BPEL 引擎置于 ESB 环境之外,例如将它作为一个 Web 服务 BPEL 引擎。按照这种方式,过程设计者要对各个域上的所有服务均有所了解才行。而且,可能还得把这些服务整合为 Web 服务以便访问。在运行时,BPEL 引擎要在整个网络上建立起 HTTP 连接才能访问这些服务。

另一种方案是将 BPEL 引擎被集成到 ESB 里,调用那些本地环境可用的服务。当它需要访问其他域中的服务时,必须先通过桥接(如一个 Web 服务调用)访问对方的 ESB,然后再调用对方服务。

对于统一 ESB,“内部”注册中心包含了总线上所有的服务及描述。只要将 BPEL 设计器连接上 ESB 注册中心,就可以很容易地进行过程设计。过程设计只涉及 ESB 服务。可以在统一注册中心检索所有可用的服务,并将它们直接集成到过程里。在运行时,由于在 BPEL 引擎和服务间没有桥接,所以事务与补偿问题也比较容易解决。

## 可靠性

在像 SOA 这样的集成环境中,应用之间基本上会有大量通信。它们遍布于不同的服务器,信息大量地通过网络传递。为了避免信息丢失,基础设施的传输层要尽可能的健壮。ESB 传输层常常提供了消息可靠性,但是 ESB 和应用之间的桥接的消息可靠性则要依赖底层协议(如 Web 服务、FTP、JMS、RMI 等)的能力。

对于非互联的 ESB 实例,同样需要确保实例之间的消息可靠性。对于每个位于其他 ESB 实例上的服务,必须配置一个可靠的通信。为每个服务配置一个 JMS 队列可以解决这个问题。此外,发送者 ESB、JMS 队列和接收者 ESB 间的通信可能要支持事务才行。当需要大量访问其他域的服务时,这项工作会变得很困难。

使用一个统一 ESB 时,可以在作为集成应用宿主的每台物理服务器上安装一个 ESB 实例。这种情况下,一个 Web 服务调用或一个 FTP 连接仍然在那台服务器上。一次网络崩溃不会影响应用和 ESB 节点间的通信。网络通信通过 ESB 节点完成。可靠性由节点的传输层保证(通常是基于一个 JMS MOM(面向消息的中间件))。

当然,在每个应用的宿主服务器上安装一个 ESB 节点是理想情形。那些无需完美可靠性的应用可以连接到一个寄存在单独的服务器上的远端 ESB 节点;同样,在一个网络安全的环境,ESB 服务器也可能被几个应用所共享。这依赖于管理员资源、成本等等。

服务治理

在一个非互联的环境中,管理服务生命周期和版本不是件易事。每当有新服务被暴露在一个 ESB 实例中,为了允许其他实例的消费者可以访问它,必须对连接器加以配置,以便将服务暴露给其他实例。当这个服务的新版本可用时,每个连接器必须被更新,以确保与该新版本一致。此外,如果没有引用所有 ESB 实例服务的公司范围的注册中心,来自其他 ESB 实例的消费者将永远不会知道还有某些服务存在于一个实例之上。

在统一 ESB 中,因为每个实例都是天生内部互联的,部署在一个实例上的服务可以立即被其他实例上的消费者使用。在每个实例的注册中心中都可以看到这个服务。当这个服务改变时,每个消费者都能从这个新版本受益。

## 管理

大多数时候,非互联 ESB 环境的管理员(他负责执行连接器安装、服务部署和其他生命周期管理)不得不连接到域的每个 ESB 管理控制台上来完成管理任务。管理员是分别配置各个 ESB 实例的行为的。

使用统一 ESB,可以让域管理员使用一个管理控制台来管理域中所有节点,在这个控制台中他可以看到全部的拓扑结构。这种方式的主要好处在于管理员可以查看域中所有实例活动(资源消耗、服务调用统计等)以及管理 ESB 的行为。例如,如果一个服务(如 XSL 转换服务)被过度使用,管理员就可以实例化这个转换服务的一个副本,将它部署到其他实例上,然后定义一个负载均衡规则来分发请求。这在非互联的 ESB 环境中是无法做到的(即使能,也很困难)。

业务监测

业务活动监测是 SOA 基础设施给运营管理者带来的最有趣的特性之一。服务统计可以实时获得;业务过程被监测且能被优化;当异常状况出现时,通过电子邮件发送警报……

在非互联的 ESB 环境中,收集关键性能指标(KPI)并不轻松。必须单独收集各个 ESB 实例的 KPI,而且两个实例间的通信(如一次 Web 服务调用)也很难被监测。所有数据必须先相互关联起来才能被监测工具读取。

统一 ESB 又一次简化了域内的 KPI 收集工作。因为实例间没有不匹配的协议,从消费者到提供者的一次交换的生命周期亦可被监测,即使不是相同的 ESB 实例托管它们。监测控制台可连接到域的任意实例,然后显示域的统计结果。

## 总结

每个 ESB 都提供了集成应用的一组功能和工具。使用一组连接器和服务(如转换或编配),应用集成变得简单了。

对于一个给定的集成问题,人们可以使用一个“中心”ESB、一些连接器,并使用它来成为粘合 2 或 3 个应用之间的胶水。大多数时候,这种“点对点”的方式很简单,可快速安装,无需业务服务定义(WSDL 等)。正如我们在这篇文章中看到的,这种“集成”视图也许对简单情形是够用的,但对于真正的“服务平台 ”(ESB 必须是企业的 SOA 主干)并不够。

选择一个允许真正网络通信的 ESB 实现是在企业中实施“服务平台”的关键。它允许我们以全局视图来观看信息系统中的所有活动与业务,并增强了它的机动性,因为整个企业中的每一个服务均可按业务步骤的方式被方便地使用。

作者简介

Adrien Louis 是 EBM WebSourcing 的首席架构师,他拥有 8 年的使用 Java EE 技术的经验。目前,他正致力于解决企业集成方面的问题。Adrien 是一位 SOA 顾问,同时是 PEtALS 开源项目的架构师。PEtALS 提供了支持 SOA 的领先开源 ESB,并致力于成为同时适用于 A2A 和 B2B 的一个轻量级、高度分布式和伸缩性的平台。由于它的特殊的分布式架构和提供的工具,PEtALS 提供了非常具有竞争性的集成解决方案,并支持范围广泛的协议、格式和集成特性。

查看英文原文 ESB Topology Alternatives

2008 年 7 月 02 日 04:502446
用户头像

发布了 255 篇内容, 共 45.2 次阅读, 收获喜欢 1 次。

关注

评论

发布
暂无评论
  • PushToTest 研究 SOA TCO:TIBCO 的 ActiveMatrix BusinessWorks 独占鳌头

    PushToTest公布了其2011年度SOA开发和部署方案分析结果,研究厂商包括IBM、Oracle和TIBCO,最终TIBCO以其诸多方面的高效率而脱颖而出成为赢家。PushToTest已将分析报告的所有细节,包括开发者日志,以开源SOA知识工具包的形式发布。InfoQ对Frank Cohen进行了访谈以期了解到更多细节。

  • SOA != Web 服务

    许多人认为SOA和Web服务是一码事——但是它们不是。在最近的一篇文章中,Zapthink的分析师试图为此查找些原因,并称到了更清楚地区分这些术语的时候了。

  • 案例研究:SOA 在 CISCO 公司取得成功

    Cisco公司的首席架构师在最近一次SOA联盟会议上分享了他们的制品、逸闻和技巧,内容涵盖由四步骤组成的成熟流程、主要的设计关注点和SOA平台。他还谈论了涉及人员、流程和技术维度的成功因素,包括企业参与的重要性,以及流程、策略和规则的业务所有权。

  • 第 32 讲 | 区块链与供应链(一)

    当供应链遇到区块链,区块链的一些优秀特性刚好可以解决目前供应链领域的痛点。

    2018 年 6 月 6 日

  • 书评:《应用 SOA》

    《应用SOA》是由四位一流SOA专家合著关于SOA的新书,其主旨是帮助你成功地实施SOA。尤其是,这本书将帮助你把你的SOA项目与企业架构、IT治理、核心数据和BPM项目结合起来。

  • 深入理解微服务架构:银弹 or 焦油坑?

    微服务与SOA究竟有什么关系?

    2018 年 7 月 14 日

  • 微内核架构详解

    微内核架构,也被称为插件化架构,是一种面向功能进行拆分的可扩展性架构,通常用于实现基于产品的应用。

    2018 年 7 月 21 日

  • 资助 SOA

    在Web上的一个快速搜索表明,资助SOA几乎像禁忌话题一样很少有人提到。Todd Biske为我们提供了一个Gartner应用体系结构开发与集成(AADI)高层会议上对这个话题讨论的概要。

  • 文章:ESB 拓扑方案

    ESB作为一个重要的SOA基础设施现在已经广为人知,甚至有人直接将其与SOA划上等号。虽然这个观点有失偏颇,但是从另一侧面反映了其流行的程度。对于部署ESB的企业,不可避免地面临着选择其拓扑结构的问题。今天,来自EBM WebSourcing的首席架构师Adrien Louis将围绕这个问题讲述一下他自己的理解。<a href="http://www.infoq.com/cn/articles/louis-esb-topologies" target="_blank">直接点击阅读完整文章</a>。

  • 《Open Source ESB in Action》作者谈开源 ESB

    InfoQ已发布了Tijs Rademakers和Jos Dirksen所著新书《Open Source ESBs In Action》的样章,借此机会,我们对作者在现实项目中使用开源ESB的经验进行了采访。

  • 第 145 讲 | 李列为:技术人员的商业思维

    “劳心者治人,劳力者治于人。”

    2018 年 12 月 25 日

  • SOA= 集成?

    SOA的存在已经有些年头了,但就“SOA到底是什么”这个问题而言,在SOA从业者中依旧未形成一个统一意见。最近在Gartner AADI峰会上由Yefim Natis发表的演讲引发了一场关于SOA/集成之间关系/区别的无尽争论。

  • 关于 ESB 实施的几点建议

    谈及企业服务总线(ESB),在有面向服务的架构(SOA)实施经验的开发者眼中一定不会陌生。这些年,人们一直在谈论它,以至有些人认为“实施SOA一定需要ESB”,或“只要将ESB架起来了,我们就SOA了”。这些说法有可取之处,也存在片面之嫌,由于业界对于ESB没有统一、标准的定义,所以一千个人眼中有一千个“ESB”也就成了情理中的事情了。然而,怎么才能将ESB用好?我们需要清楚地认识ESB在SOA中所扮演的角色,理解哪些工作是ESB的职责之内,哪些却不是。只有正确地认识了ESB的职能,并委以恰当的任务,才能将它用在刀刃上、发挥其巨大的能量。

  • 文章:在 ESB 中选择路由还是编配?

    在这篇文章中,Adrien Louis和Marc Dutoo在一个典型的ESB场景中讨论了编配和路由的区别和优缺点。他们讨论了几种连接服务的方法,从使用如自定义路由这样的低级别方法,到使用如工作流和编配这样面向业务的高级别方式,并总结说不存在“一边倒”的解决方案。<a href="http://www.infoq.com/cn/articles/louis-dutoo-esb-routing" target="_blank">直接点击阅读完整文章</a>。

  • 域名里有哪些门道?

    与HTTP协议有重要关系的域名和DNS,你都了解吗?

    2019 年 6 月 10 日

  • 克服 SOA 实施过程中的障碍

    在本文中,Jonathan Mack分享了从业务、技术和组织角度来应付SOA挑战的第一手经验。他指出了成功实施SOA的关键要素、主要障碍以及克服这些障碍的方法。

  • 文章:使用 NetKerne 实现 REST 风格的 ESB

    凯捷咨询公司的技术构架师——Jeremy Deane对使用NetKernel来编写REST风格的ESB应用做了一番深入的研究。他以新英格兰大学的一个为期多年的基础建设现代化项目为案例,详细地剖析了选择商业ESB应用的决策过程,以及最后的实现。

  • ESB 是通向 SOA 的简单解决方案吗?

    在ebizQ 6月间发布的一个播客上,IBM的Lief Davidsen讨论了如何将ESB作为实施SOA的简单解决方案使用。围绕ESB和SOA之间关系的“应该还是不应该”之争一直以来以来都相当热闹,而且这个访谈也并非最终结论。

  • 使用 JBoss ESB 和 LegStar 实现大型机整合

    在本文中我们将看到,如何使用开源的JBoss ESB集成遗留的COBOL CICS应用,而这不一定非得依赖XML和Web服务栈。

  • 我们高呼的下一代微服务 Service Mesh 到底是什么?

    考虑到有的同学之前可能没有接触过 Service Mesh 这个概念,所以这里我先对 Service Mesh 做一个简单介绍,作为后续内容的基础。

    2018 年 3 月 17 日

发现更多内容
ESB拓扑方案-InfoQ