科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道构建弹性 SOA 基础设施之二

构建弹性 SOA 基础设施之二

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

SOA 将很多异类服务连接为一个具有内聚性的互操作环境。可以在单个事务期间同步调用其中一些或全部服务,从而形成互连服务组件链。

作者:Snehal Antani 来源:论坛整理 2007年12月24日

关键字:

  • 评论
  • 分享微博
  • 分享邮件

在本页阅读全文(共3页)

解决方案:主动计时器

  此问题的解决方案是在同步调用的服务上实现主动调用计时器。恰当的主动计时器可减少应用服务器内共享资源(具体来说,就是托管任务资源)上的压力,因为托管任务不会在可能永远不会响应的服务上不合理地长时间阻塞。

  主动计时器将会在服务调用停止响应时尽快终止服务调用,从而允许托管任务完成其调度并接受新工作。由于有更多的托管任务可用于处理工作,应用服务器可保持较高的服务速率,从而减少了 SOA 内整个同步互连组件链的压力。

  图 6. 主动超时值可以通过更快地释放所使用的资源来减少停止响应服务的影响

  主动超时值可以通过更快地释放所使用的资源来减少停止响应服务的影响

  图 7 和图 8 中的队列理论模型以量化方式说明了主动计时器可如何提高应用服务器的服务速率(或吞吐量)。此模型假定平均服务响应时间为 1 秒,99% 的服务都将在此时间内成功完成。服务停止响应的概率为 1%。在停止响应的情况下,执行服务的托管任务在服务计时器超时前都不会响应。比较两个图,服务超时值从图 7 中的 60 秒(非主动)改为了图 8 中的 20 秒(主动)。

  图 7. 简单量化模型,其中超时值设置为 60 秒,每秒有效吞吐量为 63 个请求

  简单量化模型,其中超时值设置为 60 秒,每秒有效吞吐量为 63 个请求

  由于超时值设置为 60 秒,模型计算的总体服务速率为 1.59 秒,转换后得到的结果是,在包含 100 个工作线程的应用服务器中吞吐量为每秒 63 个请求。图 8 显示了实现更为主动的服务计时器将如何提高服务器的服务速率和吞吐量。

  图 8. 简单量化模型,其中超时值更改为 20 秒,每秒有效吞吐量增至 84 个请求

  简单量化模型,其中超时值更改为 20 秒,每秒有效吞吐量增至 84 个请求

  通过使用更改为主动的 20 秒超时值,模型计算所得的总体服务速率为 1.19 秒,转换为吞吐量为每秒 84 个请求。模型中的计算结果说明了图 8 中的主动计时器可极大地提高应用服务器的总体服务速率和吞吐量。

  务必注意,主动计时器的实现并不能纠正或防止事务失败。事实上,主动计时器的一个后果是,可能会终止服务请求并让事务失败,而在其他情况下提供更多的时间就可能会完成这些事务。但此处更为重要的注意事项是应用服务器的总体状况以及更广泛的 SOA 状况。如上所述,采用主动设置的计时器可以帮助减少服务停止响应时负面影响波及整个 SOA。从最终的结果来看,通过实现良好的主动计时器可得到更具弹性的 SOA。

  结束语

  本文的目的是向您介绍短期而直接的适用解决方案,以处理由于在 SOA 内使用紧密耦合的同步互连组件造成的特定性能与可用性问题。这篇文章说明了单个服务停止响应将如何在整个 SOA 中造成连锁反应,从而影响 SOA 的整体状况,并可能会导致稳定性下降和服务中断。

  此处所述的解决方案——紧密耦合的业务应用程序的搭配以及主动计时器的应用——是在短期的上下文中提出的,可以将其方便地应用于现有 SOA,只需对 SOA 进行很少的重构或重新设计即可。本系列的后续文章将给出更为复杂、需要更多计划、设计或重构工作的长期解决方案。

  这些短期解决方案至关重要,因为可以对可能已经受到本文所述的问题影响的 SOA 起到快速稳定的作用。这些解决方案还可用于可能会形成同步互连组件链的 SOA 基础设施。这些解决方案能够稳定 SOA,并避免 SOA 服务中断,从而提高 SOA 的弹性。

查看本文来源

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章