组件与中间件架构的耦合

日期:2015-12-14作者:Tom Nolle翻译:崔婧雯 来源:TechTarget中国 英文

【TechTarget中国原创】

很多软件开发人员构建分布式应用时都离不开中间件的支撑,不过要在什么架构和中间件是最好的这个问题上达成共识就更困难了。本文探讨为什么组件耦合会带来特别的挑战,以及云计算是如何通过微服务等来引入这一系列变化的。

驱动分布式应用的应用或架构需要能够同时控制组件耦合和中间件。这意味着确定主要耦合模型,从云角度考虑组件耦合模型和趋势,在开发中将耦合模型分类,以及将组件耦合和中间件架构关联起来。

在应用组件之间传递工作是分布式开发的核心需求,也是软件组件重用策略的基准。云所具有的关联组件化和耦合效率带来资源的高效和敏捷,这决定性得揭示了耦合组件以及开发分布式软件的最佳方式。理解基础中间件耦合方案至关重要。

中间件耦合的最基本问题是被调和调用进程是否是实时同步的。这意味着所要求的服务只在其可以被接受的时候才会被分发,这在耦合中加入了多线程限制,除非整个应用程序是单线程的。如今,传递消息的接口支持实时耦合,基于消息的中间件支持基于队列的解耦合,从而在有多个请求并且目的地组件不在线时,能够允许处理消息的组件将消息聚合。

中间件耦合领域需要解决的第二个问题是服务请求是阻隔的还是非阻隔的。当消息发送后,理论上说,发送方可以等待回复(阻隔)或者继续做其他事情(非阻隔)——接受组件也与之类似。其他组件的阻隔调用会在服务完成并且返回结果前将调用进程停止,这很容易实现。当使用非阻隔耦合时,应用程序需要识别发送到别处处理的消息回复,这要求更精细的应用程序实现。该模型通常称为事件处理器,因为它要求组件处理异步呈现的工作。

让我们转向云开发。云推动了RESTful模型的流行。该模型下,消息传递给无状态组件处理。在无状态模型里,每个消息作为一个完整的实体处理,RESTful组件的调用者负责在一系列工作请求链里维护上下文或者状态——比如在事务处理里会发生什么。

针对组件间工作流管理的RESTful方案,和更为传统的通常和CORBA以及SOA一起使用的远程过程调用(RPC)模型相对比。使用RPC方案,应用程序组件通过把远程组件当做本地调用而对其做操作。因此,调用组件的上下文和状态和被调用组件是紧耦合的。

使用合适的组件设计方案,RPC模型能够支持时间同步和异步两种方式,以及阻隔和非阻隔消息处理。主要由支持大量并发事件的Web服务器应用程序设计的RESTful接口,自然会更偏向于异步。良好的云组件设计倾向于鼓励使用事件处理器,和非阻隔应用程序设计模式。

中间件耦合的最后一点和方向性相关。在传统中间件架构里,开发人员可以构建双向(请求/响应)流,或者可以构建单向(一个方向)流,这里请求和响应是单独事件,通过消息内容,而不是流程状态相关联。消息处理接口通常用于双向流,基于消息的中间件内容(MOM)的概念通常用于单向流。

中间件耦合问题,特别随着向云技术的演进,将应用当作一系列进程而不是一系列组件可以很好得控制这个问题。一个Web应用程序线程在客户端形态各异,在服务器端差异不大。大多数情况下,展示给用户的客户端天然是单线程和阻隔的。如果你的应用程序可以使用该模型,那么设计本质上就是一个Web应用,并且主要遵循RESTful原则。这时,必须为耦合使用最小的中间件支持,并且在Web兼容性上关注于中间件的选择。

真正分布式处理中的事务线程是工作流事件链。通常最好使用服务或者消息总线以及流程语言引擎来缓解这样的耦合。将这样的方案应用到云环境里会创建出比很多应用程序规划师和架构师想要的更为严格的耦合性,但是避免这样的方案则要求每个事务一个线程,这在很多场景下可实现,但是要求特别的设计。消息里的状态管理,和基于消息的中间件以及RESTful接口,能够创造出适合云的框架。

中间件耦合的三大主要问题可以通过云上的实践,比如微服务,来加以解决,但是不可否认MOM模型更容易实现。但是,组件可以聚合起来,在其内部使用不同的机制解决耦合问题。在Web应用程序里,这样的方案很常见,在前端使用RESTful耦合客户端线程,然后后台实现基于MOM的事务处理。

重点是耦合组件必须首先基于应用作优化,然后选择中间件和接口来支持这个优化过的模型。当这么做时,使用最简单的中间件架构和最开放的实现。这样会让你的方案尽可能得开放。

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

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

作者>更多

Tom Nolle
Tom Nolle

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

企业中间件>更多

技术手册>更多

  • REST开发者RESTful资源指南

    维基百科把表述性状态转移(Representational State Transfer ,REST)定义为“分布式超媒体系统、如万维网的一种软件架构形式”。Web服务的RESTful方案被广泛视为SOAP的一个更简单的替代方案。许多大型的Web服务提供商如亚马逊、Twitter和谷歌都在广泛地使用它。在这本技术手册中,我们将为您提供一些RESTful资源和技巧。

  • 敏捷开发技巧指南

    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。关于瀑布方法和敏捷方法的分析已经探讨过多次,但瀑布方法在某些项目和开发团队中还存在价值。《敏捷宣言》声明指出,个人和交互高于流程和工具。由于开发项目的利益攸关者已经变得越来越分散,遍布在全球各地,甚至经常横跨了几个时区,基于云的开发环境已成为必备之选而非锦上添花。TT SOA在这本技术手册中将介绍敏捷开发的一些技巧以及瀑布方法和敏捷方法的对比,同时还涵盖了云对于敏捷开发所起到的作用。

  • SOA与敏捷开发实战演练

    SOA是一种架构,敏捷是一种方法论,架构和方法论是可以一同使用的,它们本质上是互补的。而且,SOA和敏捷的目标相同,它们都承认(1)变化是必然的(2)组织需要有效地应对变化。所以,我们期望在构建SOA时,能够选择敏捷方法论,反之亦然。本技术手册给出了二者结合的完美之道。

  • 云集成实践基础教程

    随着面向服务和基于云的架构脱颖而出,IT部门越来越重视良好的集成设计。为了避免过快的云应用集成的潜在危险,需要精心策划架构。随着应用集成需要更多的灵活性和普遍的可适用性,优化设计比以往便得更加重要。在即将到来的云计算应用集成中,以集成为中心的云计算,像iPaaS,显示了云应用者数量的快速增长,未来也将面临着更加复杂的集成和实际挑战。在这本技术手册中,我们将重点关注云集成实践。

TechTarget

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