• / 9

关于ESB实施的几点建议.doc

资源描述:
《关于ESB实施的几点建议.doc》由本站会员分享,支持在线阅读,更多《关于ESB实施的几点建议整理版.doc》相关的内容可在三九文库网上搜索。

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

本文是这样安排的:第一部分,简单介绍ESB在SOA中所起的作用。第二部分:介绍三种常见的ESB的误用。第三部分,介绍三种推荐实施。第四部分,对ESB产品发展方向的展望。申明:文中的出现所有观点仅代表作者个人看法,不代表作者所供职公司的观点。正确理解ESB在SOA中的作用平心而论,ESB的确是SOA中一个非常重要的集成层组件(IntegrationLayer),不论是OpenGroup发布的SOA参考架构,还是几大主流SOA供应商(参考IBM通过参考架构实施SOA解决方案,Oracle与F5的SOA参考架构,Microsoft的BizTalkESBToolkit中对ESB的定义)。

都将ESB置于SOA架构的核心位置。事实上,ESB在SOA中扮演着重要的角色,在技术层解决了SOA的整合问题,耦合了应用与应用之间的集成逻辑,使得SOA更灵活,更易于扩展,更敏捷。有了ESB,新建的服务消费者应用程序不需要关心服务的提供者在哪里,使用何种通讯协议,与其交互的数据是怎样的……,它只需向ESB发出请求,使用开放的、标准的通讯协议。相反,若某个可重用的价值较大的服务位于某一个遗留系统中,而由于种种原因,该遗留系统不能在短期内重写,此时ESB可以架起该服务与其使用者之间沟通的桥梁。当然,ESB的作用远不止这些,业内也有很多讨论,本文不再赘述。读者可在Google上搜索ESBPatterns获得相关资料。

然而,ESB并非“救世主”,它注定也不可能解决应用系统整合中出现的所有问题。道理很简单,计算机发展历史长从没有出现过一个产品/工具可以满足所有的应用需求,技术发展得很快,需求发展更快,所以技术永远跟不上需求。此外,ESB或ESB产品有其特定的适用范围,它是基础设施层的概念/产品,解决的是整合中的常见问题,比如服务连通、路由、消息丰富、服务的注册/查找/发布等服务的管理、服务监控和质量保证等。ESB不能解决的问题比其能解决的问题多很多。比如,让它去做人工流程的编排是不合适的,让它提供门户类产品那样的用户交互也是极其困难的……。笔者支持过许多客户项目。在这些项目中,有的客户将ESB用的好,

有的则勉强用上,用的功能很简单,有的则用ESB做一些原本不属于它该做的工作。在这里,笔者仅从个人的立场,分享自己这些年来积累的ESB实施经验。下面列出笔者常看到但不推荐的实施和笔者在实施ESB的过程中积累的一些较好的实践方式,供读者参考。同时欢迎批评指正。不推荐实施挟ESB以令外围应用现象:ESB的架构师在ESB上设计一套标准的数据接口(通用的XML格式),规定使用统一的协议(如WebService/HTTP)。所有的ESB服务消费者和接入ESB的服务必须符合该标准。其目的是为了简化ESB上的开发工作。这就是一种“挟天子以令诸侯”的做法,因为在实际情况中,可能领导规定了“所有的服务必须要经过ESB。

即便是透传”。分析:国内的ESB实施者大多数是一些SI/ISV,出于成本/人力或其他个方面的原因,总会有一些架构师希望达成这样一个目标:我能否设计/实现一个一劳永逸的ESB中间平台,将来不论哪种服务都可以方便地接入到ESB上?这是一个很浪漫很理想的目标,但这个目标是不可能实现的。原因有二:其一,仲裁逻辑一般是非常具体的,具体的服务有具体的整合需求。譬如,一个服务提供者基于HTTP提供了一个Web服务WS1,而我们希望将这个服务通过ESB暴露给两个客户端ClientA,ClientB;ClientA使用XML/HTTP访问服务,而ClientB却使用SOAP/JMS访问该服务,如图1所示。

有过ESB实施经验的人都能看出里面的仲裁逻辑是非常具体的,我们要考虑的不仅仅是协议之间的差别,还需要考虑消息格式的差别。其二,如果有这样的设计/实现存在,ESB产商为何不把这个特性直接实现了呢?你也许会说产商不理解具体的业务,而具体的业务是复杂的,SI/ISV却了解这些复杂业务。而事实上,ESB解决的更多是技术层面的工作,业务层面的工作大多数不属于ESB的范畴,复杂的业务逻辑不是在业务系统中实现,就是在其它SOA组件中实现,如流程管理引擎。图1.ESB的主要功能之一是连接异构协议和数据。原因及危害:该实践出现的根本原因是:没有认清ESB本身的作用,过分看重了ESB之上的设计能力。其实。

ESB针对的是一个个功能各异的整合逻辑,服务之间的整合逻辑也是迥异的。所以,一劳永逸的ESB之上的架构是不存在的。其危害是:丢失了ESB本身最强大的连通性方面的功能,正式因为需要联通的应用之间的差异性,才逐渐发展出了ESB这样的组件。如果要求所有的外围应用的协议标准和数据标准都统一了(事实上,这是不可能实现的,特别在与第三方应用整合时),那么ESB的必要性就逊色不少。建议:不要试图实现一个一劳永逸的ESB之上的架构,这个架构不存在也没有其存在的必要性。不过,笔者并非反对设计。实际上,ESB上可以设计,也可以通过一定的设计实现某种程度的自动化,灵活性和通用性。举个例子,某一组功能类似的服务。

对这一组服务的所有请求必须进行审计、安全加固等操作,对于这一类需求,我们可以事先在ESB上设计好相应的技术组件/服务,然后在ESB的仲裁流中间调用该组件/服务即可。用ESB实现业务流程现象:有些架构师看到ESB支持服务组合(ServiceComposition)模式,进而认为可用该模式来实现业务流程。因此,ESB产品就演变成了BPM产品。分析:如果读者关心过ESB的通用使用模式,就会发现ESB的服务组合模式(ServiceComposition)与BPM中的服务编排(ServiceCherography)非常相似,二者都是将细粒度的服务组合/组装起来,形成大粒度的服务,或者业务流程。

事实上,二者有着本质的区别。其一:ESB是一个偏向技术层整合的组件,比如将“客户资料查询”服务与“日志”服务组装起来,得到的结果还是“客户资料查询”服务,只是在仲裁流中间插入了一个新的附加功能,即“日志”服务。BPM中的服务编排的含义很侧重于业务流转的概念。比如“项目立项审批流程”,该流程的实现可能需要来自几个相关系统中的服务的参与,它们可能是“立项申请”,接着是“一级职能经历审批”,然后是“部门经理审批”,“财务审批”等。这些服务流转起来形成的是一个完整的业务流程。其二:ESB上的服务组合是无状态的,ESB运行时会为每个请求建立一个实例来执行其仲裁逻辑,请求与请求之间没有时序关系,是互不相干的、各自独立的。

相反,BPM上的服务编排这不一样,未完成的业务流程实例一直会存活在BPM运行时中,存活期可能为一天、一周、甚至1个月或更长;请求与请求之间可能存在着一定的关联性,比如对与一个项目(相同的项目ID)的立项审批流程,一级职能经理、部门经理和财务对流程发出的请求都是针对同一运行时实例的。原因及危害:除了其他非技术的因素外,导致该实践的一个重要原因是:混淆了ESB的服务组合与BPM的服务编排两个概念。危害:让ESB实现BPM,特别是长运行的流程时,虽然在技术上可以实现,但是这违背了ESB产品的设计理念,会大大影响其ESB运行时的整体运行效率。建议:认清技术上的服务组合与服务编排之间的差异。

分析每个产品所属的概念范畴,选择合适的产品解决合适的问题。用ESB实现大数据传输现象:将ESB用于在两个系统间传输大量数据,比如传输视频文件、大文档等。在这些场景中传输的信息/文件/消息有一个共同的特点:只使用了ESB提供的连通性功能,而没有使用其他功能,如消息解析,转换,路由等。分析:为了在ESB市场上抢占有利位置,各大厂商提供的ESB产品的能力越来越强。ESB产品的设计是支持消息从一个系统传到另一个或几个系统的。所以,一些架构师利用ESB产品本身提供的此项功能架设了一个数据传输总线。可是ESB并不适合完成该项功能,虽然它可以实现这一功能,但这并非最佳实践。ESB作为企业级的服务联通、管理平台。

需要穿透ESB的服务应该是企业内重用可能最大、价值最大的那些服务,应用程序对这类服务的访问应该非常频繁,因此同一时刻需要ESB支撑的业务可能非常繁重。所以,ESB产品的设计初衷是实现一个无状态、高吞吐的服务总线,为企业内重要的业务服务提供透明、标准、开放的接入能力。原因及危害:这种实践的原因是过分放大了ESB对数据的传输能力,如果在ESB传输巨大的信息,可能会导致ESB整体性能的下降,损害其他重要服务的QoS。建议:如果需要传输的数据有解析或转换的需求、或者需要根据数据里的信息进行某种路由或其他仲裁逻辑需求时,则建议使用ESB;但如果同时消息体又过与庞大,可以考虑将需要解析的消息与不需解析的数据部分进行拆分。

通过其他专门的数据传输平台去传输不需解析的部分,如FTP,数据库备份机制等,而在ESB中实现该传输任务的控制流。推荐实施服务要管理起来ESB的一个重要功能是将企业内/合作伙伴处的服务以开放的、标准的服务方式暴露出来,使得服务消费者能够便利地查找到服务,以促进服务的重用、管理。而许多ESB产品不包含服务的注册、存储、发布、订阅等功能,这些功能包含UDDI库中。所以,ESB一般需要一个服务注册/存储库与之协作。ESB执行各种仲裁逻辑,而注册库为ESB提供必要的元数据信息。服务注册库可以存储服务的元数据,包括服务的描述、功能、版本、输入/输出消息的模式、服务端点、SLA、安全策略等内容。

这些信息可被ESB用来进行消息格式验证、服务的动态路由、执行安全策略和SLA保证等。ESB可以多级实施,可以实现整个企业级/全国级的ESB,也可以实现部门级/地市级的ESB。服务消费者应该能在注册库中找到自己所需要的服务,获得调用该服务所需的位置、服务的描述文件、请求/相应消息格式等信息。若是没有注册库,则随着ESB接入的服务越来越多,仲裁逻辑不断增加,必将造成服务管理的混乱。最后抵消了ESB带来的价值。复杂的动态路由规则应服务化路由是ESB中非常重要的仲裁逻辑之一。路由场景是非常普遍的。譬如,针对不同的客户提供不同QoS的场景,执行时需根据客户的类型将其路由到不同执行能力的服务提供者。

展开阅读全文
 温馨提示:
下载提示
关于本文
本文标题:关于ESB实施的几点建议.doc
链接地址:https://www.999doc.com/661871.html
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 联系我们

copyright © 2016-2021  999doc三九文库网 版权所有

经营许可证编号:苏ICP备2020069977号  网站客服QQ:772773258  联系电话:0518-83073133