总线技术究竟该不该用?

日期:2015-11-12作者:Tom Nolle翻译:boxi来源:TechTarget中国 英文

总线技术   ESB   

【TechTarget中国原创】

今天的企业应该为总线技术的使用操心吗?Tom Nolle通过检视包括老企业服务总线在内的总线的角色回答了这个问题。

曾几何时企业服务总线(ESB)被视为企业IT的核心。今天,不仅ESB受到了比被废弃还要糟糕的攻击,若干开发趋势似乎对更简单的消息总线也发起了质疑。在本诀窍提示中,我们将探讨这个关键问题:总线技术该不该用,如果不该用,替代方案是什么?

总线还是不总线?要想回答这个问题,我们先从理解总线的类型和价值开始,然后再看看针对当前的分布式应用和Web应用有哪些替代方案,最后再看看如何同时做到总线和非总线并存。

IT总线技术是用来对软件要素进行解耦的,解耦后的要素以事务或消息的形式配合处理工作。总线架构不是从特定目的地来源发放工作,而是把工作放到总线上,并让合适的流程取走工作。这种做法比传统设计更加敏捷,因为后者的组件之间要显式地相互调用,这样哪怕简单得变化也会传导到应用的整个结构内。

总线技术已经演变

现在的总线技术无疑是从分布式流程提供简单交互手段的基本型消息总线演变过来的。随着时间的转移,越来越多复杂的功能已经被添加进来,提供对信息的格式控制以及流程的注册。还有一种转变是从简单的总线方法,即每个消息通常只有一个目的地,转变为可支持多个的代理结构,在很多情况下也提供发布和订购的灵活性。这一演变引起了对何为消息系统的相当大的困惑,而这也是面向消息中间件的一般概念背后的一个驱动力。

今天,我们有归类为消息的总线,也有归类为服务的总线,后者包括了ESB。所有目前的产品相对于早期总线的基本功能集已经追加了相当一部分功能,这种功能增加得越来越多(有人称之为膨胀),导致了反对总线声音的反弹。大多数总线都是当作不透明产品提供出来的,哪些使用它们的人也许没意识到与他们能做的所有事情有关的过载问题,这会导致设计上的悲剧性错误,引发性能问题。

总线的基本问题应该是:你是否需要这些功能?总线架构已经演变到支持组件耦合宽松到临时起意的地步,现在往往会包含有转换能力去协调接口和逻辑以便驾驭消息。如果你希望组件注册和工作流协调在运行时完成或不需要软件架构仲裁就发生的话,所有这一切都很好,但这的确增加了成本和过载。

评估总线先看替代方案

评估总线价值的最好办法也许是看看替代方案如何。如果你没有总线替代方案,你就得管理通过某些其他手段进行的组件间的工作转移。最有名的是店面(storefront)设计模式。一个组件充当“店面”,代理多个通过它来访问的功能,但这些功能都是被店面抽象化了的,以便对店面用户不可见。

店面设计模式成为微服务非常流行的一个模式;它们代表了实现微服务的优选方式。店面的使用使得复杂进程被分成为简单任务,只要是合理的,并且这些任务是按照有用的方式分布,且不会对进程的用户造成任何影响,怎么分都行。

店面系统的成功依赖于商店的选择,这意味着功能要向上划分,以便高层进程可以用商店(store)表示,然后分解为微服务。很容易会定义太多的高级进程,这么做会把进程细节暴露出来,而这些细节有可能会随着软件设计演变或甚至在虚拟化或云计算的使用中被改变。

现代WebyuREST组件化、API设计的组合,再加上微服务和店面设计模式的使用,有可能几乎在任何情况下消除新应用对总线的使用。软件架构师的问题是没有太多可以利用的机会来测试这一理论。现在大多数的开发都会与现有设计发生相互作用或影响,而后者往往都是基于总线的。

必要时刻假定你要进行总线化

总的来说,最好的办法是,在必须如此的时候假定你会进行总线化。今天的应用演进聚焦在移动和Web访问驱动的功能性演进,以及虚拟化和云推动的资源动态化上。处理这两种你有可能就能有效处理好用不用总线的问题。

对于Web和移动功能演进,你可为已有应用开发前端元素,采用店面-微服务架构,然后把结果提供给传统基于总线的应用后端,让它来进行处理,从而保留现有的软件。最好的处理办法是,把Web流终结到一个组件里面,用它来管理无状态前端要素的状态,然后用对静态数据结构的支持来隔离连接总线的组件,免受前端变更的影响。

对于资源动态化的演进,预期你的问题大多数情况下会是支持负载变化下的组件实例伸缩性上,或者在出现失败的情况下替换实例。要处理这个问题,可考虑开发新的连接总线的组件,让它充当某用来为水平伸缩性和故障切换服务的微服务集的店面。最终,你可能用多个店面中的一个来替换掉总线结构。

如果使用得当,服务和消息总线可改善安全性和合规性管理。如果你已经在靠总线技术来支持这些任务,现在打算不用总线,那你就得在安全和治理相关方面增强你的应用生命周期管理实践,否则就会有连累到信息和业务流程的风险。不要一下子跟风去上全新的流行技术,总线也有自己的好处。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者>更多

Tom Nolle
Tom Nolle

关于作者:Tom Nolle是CIMI公司的总裁,这家公司成立于1982年,是致力于电信和数据通信的战略顾问公司。Tom Nolle是IEEE、ACM、Telemanagement Forum和IPsphere Forum的一员,著作有关于Netwatcher方面的书籍。

ESB>更多

相关推荐

技术手册>更多

  • SOA标准组织:W3C

    W3C是专门致力于创建Web相关技术标准并促进Web向更深、更广发展的国际组织。到目前为止,W3C已开发了超过50个规范(草案)。这些规范(草案)包括人们早已耳熟能详的HTML、HTTP、URIs、XML等,也包括针对语义Web的RDF、OWL等。

  • OSGi模块化技术手册

    最近有一些争论,主要是关于是否完全成熟的OSGi模块化是严格意义上必须的东西,或者Jigsaw是否一种足够好的“更简单”的方法。但是也许关键点在于对于任何既定的组件在哪里适合什么模块化。OSGi是Java领域里无可辩驳的最成熟的模块系统,它与Java几乎是如影相随。在这本技术手册中我们将分三部分来和大家聊聊OSGi模块化以及它和Java千丝万缕的关系。

  • SOA与REST混合使用指南

    大多数应用架构师都意识到,如果应用合适,开发实践反映了双方的目标和好处的话,在某些情况下,将表述性状态转移(REST)与SOA结合起来是有可能且有优势的。最大的问题是目标是否要开发一个自始至终的RESTful接口,同时满足大部分SOA目标,或者混合使用REST和SOA。

  • 企业应用集成EAI

    EAI(企业应用集成)是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI通过建立底层结构,来联系横贯整个企业的异构系统、应用、数据源等,完成在企业内部的 ERP、CRM、SCM、数据库、数据仓库,以及其他重要的内部系统之间无缝地共享和交换数据的需要。有了EAI,企业就可以将企业核心应用和新的Internet解决方案结合在一起。

    EAI(企业应用集成)将进程、软件、标准和硬件联合起来,在两个或更多的企业系统之间实现无缝集成,使它们就像一个整体一样。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算