引言

　　随着硬件和软件资源的虚拟化变得越来越普遍，中间件基础设施的弹性开始变得越来越重要了。弹性差的服务会对承载于相同虚拟化硬件和软件上的其他服务造成负面影响，例如，在通过可能会造成大量延迟的不可靠网络调用同步服务调用时锁定和保留共享资源。

　　本文将讨论影响SOA基础设施的弹性的若干问题。本文将使用WebSphere Application Server for z/OS来对所述问题的效果进行量化。通过IBM System z提供的虚拟硬件和软件的高级监视功能、WebSphere Application Server for z/OS的多进程服务器体系结构、用于确保弹性的内部机制，以及通过研究大量WebSphere Application Server for z/OS客户部署可以了解的高级概念，能够确定影响广泛的SOA领域的问题，并对所建议的解决方案可能造成的影响进行量化。

　　应用程序服务器、虚拟化基础设施、弹性与SOA

　　SOA指南可帮助进行业务服务开发。业务服务 实际上是能够在整个企业共享的可重用业务功能。这些业务服务的粒度和分配将在设计新SOA时成为两个重要的方面。

　　预先建立的最佳实践

　　所建立的最佳实践以及通过相关技术积累的经验教训可为构建弹性SOA提供很好的指南。例如，通过Java 2 Platform Enterprise Edition(J2EE)技术我们了解到，位于相同应用程序服务器上的依赖Enterprise JavaBeans(EJB)组件的搭配考虑了按引用传递与按值传递的优化，同时还可减少服务器资源的使用，具体来说，这仅需要在一台服务器上使用一个应用程序服务器工作线程，而不是在N台服务器上使用N个线程。类似地，在SOA中紧密耦合的服务 应该带来与J2EE中类似的好处。

　　另一个例子源自Common Object Request Broker Architecture(CORBA)，即数据的序列化和反序列化对性能有重大影响。因此，要构建高性能分布式系统，设计人员必须了解所传输的远程对象，并对此进行简化，以提高性能。这些经验教训和很多其他知识在构建弹性SOA基础设施时都非常重要。

　　应用程序服务器和共享运行时基础设施

　　应用程序服务器已经成为了用于将服务提供者与服务使用者进行连接的平台。在构建可靠的弹性SOA基础设施时，了解应用程序服务器的行为方式非常重要。当应用程序服务器在共享资源环境中运行时，SOA的弹性特别重要，因为脆弱的SOA的负面影响会被放大。对于共享运行时基础设施，在最底层消除了硬件竖井(silo)范式的服务隔离，服务会争用相同的硬件资源（如CPU和内存）。这会产生什么样的结果呢？由于共享资源被锁定、使用或耗尽，脆弱的SOA可能会直接或间接地影响其他服务和子系统。

　　共享运行时基础设施承载很多服务和子系统，包括数据库（IBM DB2®、Oracle等）、遗留事务处理（如 IBM CICS®）、平台消息传递（如 IBM WebSphere MQ）等等。所有这些服务和系统都会在一定程度上争用共享资源。在负载过大的情况下，共享运行时将使用服务策略、相关优先级和其他此类元数据来管理资源的分配。当高优先级服务不能达到所定义的服务级别水平时，基础负载管理器（用于管理共享资源分配的子系统）将决定哪些服务能访问资源，哪些不能。因此，当共享系统必须进行分配决策时，这些具有较高优先级的服务可能会对较低优先级的服务造成负面影响。

　　共享资源争用在采用SOA时将是一个重要的设计注意事项。糟糕的体系结构设计不仅会给SOA造成负面影响，而且会损坏整个共享系统。例如，图1所示的系统中数据库由两台应用程序服务器使用，这两台服务器分别承载两个独立的服务。服务器1中的故障会导致正在进行的事务回滚。回滚由数据库执行，而此任务具有较高优先级。数据库在回滚事务时，可能会从服务器2剥夺共享资源，而后者与故障没有任何关系。

　　图 1. 共享基础设施

 
　　阻塞应用程序服务器线程的影响

　　应用程序服务器在SOA领域中扮演者不可或缺的角色。作为平台，它们允许应用程序开发人员将重点放在业务逻辑的开发上，而将基础硬件和软件相关细节抽象出来。它们提供安全性、事务完整性、高可用性等服务。作为部署业务服务的平台，应用程序服务器可以发展为SOA的基础。因此，务必理解可能会极大影响应用程序服务器的稳定性的一些细节。

　　应用程序服务器由两个基本线程组件组成：托管线程和非托管线程。

　　托管线程 是重量级的，与元数据相关联，如事务上下文和安全上下文等。这些线程是执行业务应用程序的事务工作的实体。托管线程由工作负载管理器监视，用于确定是否需要更多的资源来满足所定义的服务级别策略。出现错误时，它们将回滚所执行的事务。它们通常在服务器进程中形成资源池，以便对其进行高效利用。应用程序服务器内的托管线程直接影响和决定服务器处理工作的容量（图2演示了此场景）。

　　图2. WebSphere Application Server z/OS线程概览

 
　　非托管线程 缺乏与托管线程关联的元数据。这些线程通常都是轻量级的，用于执行缓存清理和对象清理之类的事务。它们的失败并不会直接影响事务的完成，安全需求最小。

　　应用程序服务器中的托管线程执行事务工作负载，因此会直接影响服务器的总体容量和吞吐量。单个工作线程并不会并行执行两个事务，因此，单个事务完成所需的时间越长，工作线程用于处理此事务所花费的时间越多。在工作线程完成其事务并释放以执行下一个事务前，无法处理任何新工作（图3给出了此场景的图释）。应用程序服务器的吞吐量可以通过将单个事务处理的速率乘以服务器内的托管工作线程数量得到。

　　图3. 存在错误的示例拓扑

 
　　以同步方式调用服务（如远程Web服务、EJB服务或从数据库检索数据）时，工作线程将被阻塞，必须等待从该服务返回的响应，然后才能继续处理正在进行的事务。图4显示了服务的多个层次同步连接的场景。在图4中，数据库服务是“中枢”，其中存在某种类型的延迟，如数据库中的锁定争用或网络问题。在此场景中，工作流是同步的，例如，服务器4在从数据库接收到响应之前无法继续处理，服务器3在从服务器4中接收到响应之前无法继续处理，如此形成了一个链。延迟存在时间越长，服务器1、2和3就可能会随着应用程序服务器中越来越多的工作线程被阻塞而变得不可用。实际上，处理此类同步连接过程中的任何延迟都会影响依赖服务，从而最终对承载这些依赖服务的应用程序服务器造成影响。

　　图4. 同步服务及其被阻塞的工作线程

 
　　如果阻塞工作线程，则需要确保仅在合理的时间内阻塞线程。正如前面提到的，单个工作线程无法并行处理多个事务。因此，由于阻塞工作线程会等待某个远程服务发送的响应，因此无法继续处理当前事务，也无法开始处理新事务。对于存在很多阻塞工作线程的情况，在完成正在处理的事务之前，新工作将无法执行，而这意味着新工作必须排队，等待有可用资源时处理。

　　WebSphere Application Server for z/OS之类的产品提供了某种排队机制，能够尝试消除阻塞线程的一些影响。这些队列用于在线程不可用时临时接收请求。在工作线程完成其事务后，将会执行队列中的下一个工作项目。

　　被阻塞的应用程序服务器工作线程可能会对服务器的容量和吞吐量造成负面影响。由于单个托管线程在一次只能执行一个事务，阻塞线程会导致当前线程无法完成，从而使得工作线程无法执行下一个工作单元。

　　图5显示了一个客户体系结构，其中远程服务从应用程序服务器通过非托管网络进行调用。对银行设备的每次服务调用都会阻塞服务器内的工作线程。可以使用超时来约束和控制阻塞工作线程的时间量。例如，如果所有远程方法调用（Remote Method Invocation，RMI）调用必须在120秒内完成，则对银行设备的每次服务调用最多花费120秒时间。

　　图5. 示例客户拓扑

 
　　假定出现了某个网络问题，例如，靠近设备的路由器出错，或一组设备出错。图6显示了应用程序服务器内此类错误的潜在影响。很多工作线程可能会突然阻塞，并等待超时过期，不过同时又有新工作送到服务器。如果服务器的服务处理速率低于传入工作的速率，请求则会在队列中堆积起来。高级应用程序服务器产品（如 WebSphere Application Server for z/OS）会在工作队列过长的情况下采取一些措施。例如，可以执行第二个工作超时，并拒绝为新请求提供服务。

　　图6. 网络问题及其对客户拓扑的影响

 
　　可以采取称为EC3 abend的措施，此方法中将应用程序服务器的部分内容（本例中的WebSphere Application Server for z/OS服务区域）认定为挂起，因此将其重新启动。重新启动WebSphere Application Server服务区域将导致所有正在进行的事务回滚，从而会给数据库造成额外的负载。根据图1中所示，事务回滚可能会影响共享运行时环境中运行的其他工作。形成堆栈的同步服务（例如图4中所示的场景）也可能受到影响；位于堆栈服务链靠后位置的服务执行速度可能会比较慢，从而减少了其调用方的吞吐量。在最复杂的环境中，单个服务可能会存在连锁效应，导致不相关的服务和子系统崩溃，如图7中所示的场景。

　　问题场景示例

　　某个特殊的客户遇到了以下问题，导致一切变得异常糟糕：

　　某个网络路由器出现了问题，导致WebSphere Application Server服务区域的很多工作线程阻塞。
　　工作请求进入队列，等待工作线程。
　　工作负载管理系统判断the WebSphere Application Server服务区域已挂起，发出了EC3 abend来终止服务进程。
　　EC3 abend导致正在处理的事务回滚。
　　服务器服务速率缓慢再加上事务回滚的影响，导致其他WebSphere Application Server服务区域回滚。
　
　　此影响将对很多其他服务和子系统重复，从而导致停机。

　　图7. 阻塞线程的连锁效应

 
　　阻塞工作线程和不当的服务部署与分配可能会极大地降低中间件基础设施的总体性能。这可通过从J2EE和CORBA领域获得的最佳实践予以解决。这些最佳实践包括并列配置相互连接的应用程序模块，并尽可能减少有些分布式域中的远程调用数量。实际上，相同进程（例如Java Virtual Machine[JVM]或寻址空间）中并列执行的服务可以通过优化加以改进，例如按引用传递值、在当前执行线程上执行，以及避免对网络堆栈进行遍历。远程访问服务可能至少会导致随后发生过载。

　　服务使用者必须：

　　对请求参数进行序列化。
　　遍历网络堆栈，以寻找出站调用。
　　如果安全策略要求，则对请求进行加密。
　　阻塞工作线程并等待响应。
　　遍历网络堆栈，以处理返回值。
　　如果安全策略要求，则对请求进行解密。
　　对返回值进行反序列化。
　　恢复阻塞工作线程。

　　服务提供者必须：

　　遍历网络堆栈，以接受入站请求。
　　如果安全策略要求，则对请求进行解密。
　　对请求参数进行反序列化。
　　将请求分配给新工作线程。
　　对返回值进行序列化。
　　如果安全策略要求，则对请求进行加密。
　　遍历网络堆栈，以发送返回值。

　　图8给出了基于实际客户部署的场景。对于此客户，多个组件在单个全局事务范围内进行大量的交互。在此场景中，系统不仅可能会在任意时间存在大量阻塞工作线程，而且还表现出性能低效，且会产生较高的每秒百万条指令（Mmillions-of-Instructions-Per-Second，MIPS）成本。

　　让我们对图8进行一下详细分析，以便您了解应该如何解释此图：

　　组件1通过Remote Method Invocation over Internet InterORB Protocol(RMI/IIOP)调用组件2。组件1阻塞并等待组件2响应。
　　组件2然后通过RMI/IIOP调用组件3。组件2等待组件3响应。组件2和组件1现在都被阻塞。
　　组件3响应组件2。
　　组件2响应组件1，事务完成。

　　最终两个工作线程（服务器1和服务器2上分别一个）在此事务期间都被阻塞。另外，还进行了两次RMI。这些都会带来开销，减少服务器处理容量。

　　图8. 客户事务示例

 
　　从性能而言，开销最大的操作通常是数据和返回值的序列化和反序列化以及请求和响应的加密与解密。这些开销可以在服务并行配置时加以避免。此外，在z/OS之类按照执行指令收取费用（可以作为MIPS 的示例）的平台上，出现这种以事务为单位的开销的费用将会极大地增加部署成本。

　　SOA与队列模型

　　队列模型可以帮助确保SOA的稳定性和生产可用性。通过队列模型，不仅可以可视地对系统和各种参数加以表示（如超时和平均响应时间），而且还能够了解其对系统的影响。图9显示了队列模型的一个示例。
 
　　图9. 队列模型示例

 
　　其中的关键是能够改变超时概率和超时值。然后可以进行计算，以确定每个线程的服务速率（并据此得到整个服务器的服务速率）。代表客户的系统队列模型能够在实际发生前三十秒内预测EC3 abend。

　　队列模型能够帮助标识SOA中阻塞工作线程的影响。但要定义队列模型，必须了解组件及子系统间的相互依赖关系。此类模型的构造是本系列后续文章的重点。

　　总结

　　本文说明了细微（但仍然重要）设计问题会如何对SOA的稳定性造成巨大的影响。文中提出了几个特定的、具有潜在问题的设计领域，如果在实现时未对这些进行恰当考虑，可能会增加SOA基础设施的脆弱性，从而降低SOA部署的总体稳定性。

　　本文的目的是向SOA设计者介绍对SOA弹性造成影响（正面和负面）的重要因素。本系列的后续文章将讨论此处所述问题的解决方案，包括可帮助促进问题SOA的稳定性的短期直接解决方案和用于构建弹性SOA的长期的全面性解决方案。