本系列讨论构建弹性面向服务的体系结构(SOA)基础设施，本文是其中的第2部分，重点讨论与跨服务器和层次使用同步互连SOA组件相关的问题的短期解决方案。之所以重点讨论这里给出的解决方案，是因为其可以平息这种类型的问题导致的负面影响，从而提高SOA的弹性。

　　引言

　　SOA将很多异类服务连接为一个具有内聚性的互操作环境。可以在单个事务期间同步调用其中一些或全部服务，从而形成互连服务组件链。链中的每个服务都依赖于下游服务——即在接收到所调用的下游服务发回的响应前，服务将不会继续执行。随着不可预测的情况的出现（如连接互操作服务的总线突然出现大幅度延迟），可能会导致服务阻塞和失败。这些失败将传播到链中，导致其他服务失败，并可能会降低整个SOA部署的稳定性。

　　无法响应的服务对整个SOA基础设施的影响程度取决于SOA的弹性。弹性（即服务的持续可用性和性能，不会受其环境的负面更改的影响）对于维护状况良好的SOA至关重要。本文将讨论各种短期解决方案，以提高容易形成同步互连服务组件链的SOA的弹性。

　　短期解决方案

　　短期解决方案 是能够方便地应用到现有SOA框架的解决方案，无需更改（或只需少量更改）整个体系结构。这些解决方案涉及配置调整和其他小的优化，仅需要对SOA进行极少的重构。在最糟的情况下，所需的重构工作是可管理的，可以快速而方便地实现。

　　短期解决方案的主要目标是：

　　·通过降低脆弱性提高SOA基础设施的总体稳定性。
　　·提供此类基础设施中对异常条件的容错能力。
　　·提高性能和降低每秒百万指令数（Millions-of-Instructions-Per-Second，MIPS）。
　　·通过提高的服务能力改进可管理性。

　　本文重点讨论两个短期解决方案：

　　·紧密耦合SOA服务的搭配
　　·在SOA服务调用上实现主动计时器

　　短期解决方案1：紧密耦合SOA服务的搭配

　　搭配 实际上就是SOA服务或应用程序在同一物理系统上的部署。术语紧密耦合 描述同步调用的两个或更多服务之间的关系，即调用服务（客户机）在服务调用时阻塞，直到从其调用的服务接收到响应才能继续。多个紧密耦合的服务可能会参与单个事务，在SOA内形成同步互连组件链。

　　此部分讨论的短期解决方案将要把在同步互连组件链中作为组件的紧密耦合的业务应用程序部署在一起（在可能的情况下）。其重点是部署到独立服务器上但共享大量同步相互通信（即彼此紧密耦合）的业务应用程序。通过重新部署到相同的服务器上，这些业务应用程序可能会获得很大的好处，从而改进SOA的整体状况和稳定性。

　　搭配的好处

　　将紧密耦合业务应用程序部署在一起的最明显原因之一是可测定的性能改进。将应用程序部署在一起可利用进程内通信协议，而这样通常可促进应用程序间的直接通信。进程内通信可以避免远程服务调用的所有开销，包括序列化、加密、遍历网络堆栈和网络延迟。

　　将紧密耦合业务应用程序部署在一起的第二个原因是可减少对资源的压力，特别是任务或线程级别的资源。通过本地进程内通信协议的同步服务调用通常对本地服务器资源的压力要比通过远程通信协议进行的调用带来的压力要小得多。可以通过示例对此进行最好的说明，详见下面的部分。

　　问题场景：高工作负载与有限资源

　　请看图1，其中部署在服务器1上的业务应用程序A将同步调用服务B，而服务B承载于业务应用程序B中，部署在服务器2上。这两个服务器通过服务总线（通常是网络连接）以物理方式连接。

　　图1. 承载彼此不同但同步的依赖应用程序（通过某种通信通道连接，如HTTP或RMI）的应用服务器
 
　　外部客户机调用服务器1中的应用程序A。工作请求将派发到服务器1中的托管任务。因为应用程序A和服务B之间的通信是同步的（例如，通过Remote Method Invocation over Internet InterORB Protocol (RMI/IIOP)），因此服务器1中的对应用程序A派发工作的托管任务必须阻塞，直到从服务B收到响应为止。阻塞时，托管任务不能执行其他工作。

　　如果承载服务器（服务器1）负荷非常重，仅有部分托管任务资源可用，则可能会出现问题。随着越来越多的托管任务在同步远程服务调用上阻塞，服务器调度工作的能力将降低，从而导致服务器的总体服务速率降低。

　　如果服务速率低于新工作的到达速率，则服务器将会跟不上，在有托管任务可对其进行调度前，新工作都将排队等候。如果所有托管任务都被阻塞，服务器完全不能执行任何工作，看起来像挂起了一样。如果此情况持续很久，队列中的工作和已派发的工作将超时并失败。

　　图2. 外部服务可能会通过长时间阻塞线程动态地降低服务器的服务速率
 
　　服务器1的总体服务速率会受到影响，服务器1承载的所有服务的服务速率也都会下降。尽管实际问题可能分为故障或应用程序A和服务B之间的长延迟通信，但问题的影响贯穿整个服务器。托管任务资源是共享资源——服务器1承载的所有应用程序都共享相同的一组托管任务。由于应用程序A使用并阻塞了托管任务，因此其他应用程序无法调度。这可能会导致其他状况良好的服务失败，因为无法获得执行所需的足够资源。

　　解决方案：将紧密耦合的应用程序部署在一起

　　将两个紧密耦合的应用程序部署在相同服务器内可以减轻对资源的压力。如果恰当搭配，应用程序A可以使用本地进程内协议调用服务B，此类信息实际上支持直接调用。避免了远程调用；因此也避免了与远程延迟相关的问题。不会阻塞托管任务资源，从而能更高效地完成要执行的任务。

　　由于阻塞的托管任务更少，服务器可以维持较高的服务速率，从而更可能避免队列增长。避免队列增长可防止调度超时，从而防止会影响SOA内的其他组件的突发事故。所得到的将是更为稳定且弹性更好的SOA。

　　图3. 同步依赖服务的搭配
 
　　正如此处所示，应用程序及其同步调用的服务之间的通信故障或性能低下对整个服务器有负面影响，而这反过来会对该服务器承载的所有应用程序和服务造成负面影响。正如服务器1的所有服务都受到影响一样，SOA内使用这些服务的所有组件也都会受到影响。因此，服务器1出现的问题可能波及整个SOA，大幅度影响SOA。作为短期解决方案，紧密耦合业务应用程序和服务的搭配可以减少SOA环境中可能造成的一些不稳定性。

　　短期解决方案2：在服务器调用上实现主动计时器

　　能够提高SOA基础设施的稳定性（特别是以同步方式通信的紧密耦合服务领域内）的第二个短期解决方案是应用主动计时器来控制服务调用。在紧密耦合服务无法搭配的情况下，可以应用主动型服务调用计时器来减少停止响应的服务造成的负面影响。

　　主动型服务调用计时器设置为服务合理的预期响应时间，并对传输延迟予以一定的考虑。在实践中，很多计时器都比服务的平均响应时间长得多。例如，通常在一到两秒内调度并完成请求的服务，其调度超时可能设置为300秒（5分钟）。这是一种非主动 计时器。

　　其思想是，如果服务通常在两秒钟内响应，但某个特定的调用30秒都没有响应，则完全可以假定服务遇到了导致其停止响应的情况。服务不可能会在特别长的时间内响应，因此再等待270秒让请求超时可能没有必要。采用这种方式配置的计时器尽可能等待服务作出响应。不过，这样没有考虑长延迟可能会对事务中同步调用的其他组件造成影响，也没有考虑使用和阻塞共享资源对本地服务器中承载的其他服务的影响。

　　问题场景：阻塞托管任务资源

　　非主动计时器的问题在于，对于异常可能导致服务突然变得暂时不能响应（例如，网络连接断开）的情况，其反应时间过长。在共享资源虚拟基础设施（如应用服务器）中，在非主动调用计时器过期前，托管任务都会被阻塞，计时器过期后将终止服务请求并调整服务调用阻塞的托管任务，。

　　在阻塞的情况下，托管任务将继续持有其在调度期间获得的所有共享资源（例如，存储资源、任务级别的资源和互斥锁定）。阻塞的托管任务所持有的共享资源不可用于其他任务，而这可能会妨碍服务器内其他已分派工作，可能会导致应用服务器的总体服务速率下降。

　　而且，根据通信失败的性质不同，应用服务器内的其他托管任务可能会遇到相同的服务停止响应问题。对于负荷大且有限的任务资源，服务器内所有可用的托管任务都可能会由于停止响应的服务而阻塞。所有托管任务资源用完之后，应用服务器就不能处理其他传入的工作了。

　　图4. 停止响应的服务可能会阻塞应用服务器内所有可用的托管任务
 
　　实际上，应用服务器本身也变得停止响应——与其线程尝试调用的服务一样。就像下游服务停止响应会导致应用服务器变得停止响应一样，应用服务器停止响应对同步互连组件链中的其他上游组件也具有类似的负面影响。

　　在调用计时器过期前应用服务器都会停止响应，计时器过期后将终止服务调用并继续所阻塞的托管任务，允许托管任务完成其调度，接受新任务。调用计时器的主动性设置越弱，应用服务器保持停止响应的状态的时间越长。应用服务器停止响应的时间越长，SOA内对该应用服务器上的服务进行调用的其他组件就越可能受到类似的影响。这可能会导致整个SOA受到影响，变得不稳定。

　　图5. 停止响应的服务可能会给上游调用方带来问题，即阻塞其工作线程和降低其对应服务器的服务速率
 
　　如图5中所示，单个停止响应的服务与非主动计时器的组合所带来负面影响可能会在整个SOA中造成连锁反应，对SOA的稳定性和可用性造成非常严重的后果。

　　解决方案：主动计时器

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

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

　　图6. 主动超时值可以通过更快地释放所使用的资源来减少停止响应服务的影响
 
　　图7和图8中的队列理论模型以量化方式说明了主动计时器可如何提高应用服务器的服务速率（或吞吐量）。此模型假定平均服务响应时间为1秒，99%的服务都将在此时间内成功完成。服务停止响应的概率为1%。在停止响应的情况下，执行服务的托管任务在服务计时器超时前都不会响应。比较两个图，服务超时值从图7中的60秒（非主动）改为了图8中的20秒（主动）。

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

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

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

　　结束语

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

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

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

　　作者简介

　　Snehal Antani供职于IBM Software Services(ISSW)Advanced WebSphere团队，并且是WebSphere Extended Deployment的技术负责人。他专攻的领域主要是使用WebSphere品牌的产品在所有平台上（z/OS和Distributed）为面向服务的体系结构(SOA)设计基础结构。他有丰富的开发经验，帮助开发和交付了WebSphere z/OS、WebSphere XD-Distributed和WebSphere XD-z/OS。Snehal在SOA、企业应用程序基础结构和网格计算等领域获得了多项专利和发表了许多技术文章。他获得了普渡大学的计算机科学学士学位，并将获得位于纽约特洛伊区的伦斯勒理工学院(RPI)的计算机科学硕士学位。有关详细信息，请访问IBM软件服务。
 
　　Rob Alderman在IBM WebSphere Application Server for z/OS开发团队工作。他是WebSphere for z/OS运行时开发团队的技术负责人。他的开发重点是WebSphere for z/OS运行时领域，WebSphere Application Server代码在其中利用z/OS提供的本机操作系统服务并与之进行交互。Rob获得了位于纽约特洛伊区的伦斯勒理工学院(RPI)的计算机系统工程与计算机科学双学士学位。