构建弹性 SOA 基础设施之二

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

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

　　图 3. 同步依赖服务的搭配

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

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

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

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

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

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

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

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

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

　　图 4. 停止响应的服务可能会阻塞应用服务器内所有可用的托管任务

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

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

　　图 5. 停止响应的服务可能会给上游调用方带来问题，即阻塞其工作线程和降低其对应服务器的服务速率

　　如图 5 中所示，单个停止响应的服务与非主动计时器的组合所带来负面影响可能会在整个 SOA 中造成连锁反应，对 SOA 的稳定性和可用性造成非常严重的后果。