总线技术究竟该不该用?

日期: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和虚拟化

    虚拟化和SOA之间是一种间接的、相辅相成的关系。也许在IT及业务转型中,两者的结合使用会发挥最大的优势。虚拟化有助于更快地显示部署基础设施的投资回报率(ROI)。

  • 移动中间件服务技术手册

    移动中间件是连接不同的移动应用,程序和系统的一种软件。移动中间件实际上隐藏了多种复杂性:在移动环境下工作的复杂性,允许设备对设备的流畅交互的复杂性,移动与计算机集成的复杂性和移动应用开发的复杂性。和其它的中间件一样,移动中间件也是通过提供信息服务来使不同的应用之间进行通话的一个典型。随着多样化的平台和设备进入到移动空间,移到中间件已经变得越越重要。随之而来的结果就是,众多移动中间件厂商纷纷提供开发服务,以解决快速增长的移动硬件与移动软件市场。本技术手册将介绍移动开发对于面向服务架构的影响,以及未来移动中间件可以实现哪些功能,在这个过程中我们有哪些经验和技巧可以参照。

  • 大数据应用分析

    大数据已经不再是媒体炒作的流行词语,它正在不断冲击着政治、商业、社会、科技诸多领域,已经成为新一轮技术变革的最强音。

  • 敏捷扩展:大型网站项目最佳实践

    其实从某种意义上讲,敏捷软件开发是自身成功的一个牺牲品。随着项目的进行,焦点一直集中在需求定义上,一边编写一测试,一边交付工作软件的各个部分,所以可以看出敏捷是多么好,以致于许多组织都在试图扩展它的使用,而不仅只是局限在单一的团队项目中。但怎样才能把敏捷方法从小项目转移到大型项目中呢?

TechTarget

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