我们将涉及的最佳实践领域不仅仅是经典IT领域，其中包括：业务流程分析和建模，规划和设计与BPM应用程序的终端用户交互，定义操作拓扑以满足可伸缩性和可用性要求，操作系统及其基础设施，通过经典IT管理方法在从开发到日常操作的过渡过程中管理产品和依赖项，以及扩展性能工程以将业务服务和业务流程包含到各种性能工程领域范畴中。

　　如今包含SOA和BPM的应用程序解决方案通常跨越一个复杂的操作拓扑分布，如图 1 所示。

图 1. 操作拓扑样例

　　业务流程提供给业务服务的质量直接取决于所涉及的IT系统的完整性、可用性和性能特征。涉及的组件越多，解决方案在其生命周期内的每个方面就会越复杂。

　　本文将简要介绍一些最重要的性能特征，通过以下方法处理这样一个复杂环境：

• 　　识别性能相关领域。
• 　　描述在这些领域中需要注意的重要项目。
• 　　讨论处理性能问题引起的完整性问题的一些治理原则，以及计划停用或计划外停用。

　　处理复杂环境

　　除了简单的概念证明、技术证明和演示配置外，实际的业务流程自动化环境都是高度复杂的。查看如此复杂的环境的方法有很多种，，其中一些视图表明重叠的内容，而另一些视图可能是分离的，还有一些视图可能与其他视图是正交的。如果您有一个 SOA 环境，当您在评审架构时考虑性能相关问题时，您应该参考SOA参考架构，如图 2 所示。

图 2. SOA 参考架构

　　脑海中有这样一个架构图有助于您评估一个解决方案的性能表现和确定性能问题；但是，展示操作拓扑和应用程序架构的图表也许更有帮助。这些图表展示所有相关组件是如何互联的，描述请求流是如何通过系统的，如图 3 中的图表所示。

图 3. 操作拓扑图表样例

　　这两个关于一个BPM解决方案的视图对入门非常有用，但要更完整地理解BPM解决方案，还应该考虑几个补充视图。下面几个小节将描述这些视图。

　　BPEL流程定义

　　WebSphere Process Server能够处理两种不同的BPEL流：长期运行流（也称为宏观流或可中断流）和短期运行流（也称为微观流火不可中断流）。

　　长期运行流

　　通过一个长期运行流表示的业务事务拥有一个可以跨越几分钟、几小时、几天、甚至几个月的生命周期，通常被划分为几个技术事务（由几个 “开始” 和 “提交” 动作包含）。这样一个流程实例的状态在两个事务之间被持久化在一个数据库（BPE数据库）中，以便操作系统资源仅在一个实时事务期间被占用。WebSphere Process Server允许调优技术事务边界，以便开发人员在流程定义时可以通过将几个事务合并到一个事务中来扩展一个事务的范围，从而改善事务处理开销。

　　短期运行流

　　另一种类型的流 — 短期运行流 — 的适用条件为：对应的业务事务被完全自动化，在一个较短的时段内完成，且没有异步请求/响应操作。这里，所有流活动在一个技术事务内运行，导航全部在内存内完成，中间状态不会存储到数据库中。这样的短期运行流比等效的长期运行流快 5 到15倍，因此建议尽量使用。

　　在业务层编程

　　BPEL可视为一种编程语言。但是，我们不能得出这样的假设：BPEL 适合用作开发通常用 C++ 或 Java? 这样的语言编写的应用程序的基础。相反，BPEL应该被视为一种经过解释的语言，尽管有一些调查检查了已编译的 BPEL 的潜在优势。通过在内部比较一个 BPEL 流的执行特征和通过SOA提供的已编排服务的交互和调用的灵活性，可以清晰地看到，总体执行路径长度大部分归功于 SOA 的一些调用机制，比如 SOAP 和消息传递。因此，拥有一个 BPEL 编译器只能优化总体执行路径长度的一小部分，使用经过编译的 BPEL，可能会牺牲当前实现提供的部分灵活性和互操作性。

　　在20世纪80年代，IT行业的一个趋势称为业务流程再造。为此开发的解决方案通常是大型单片电路程序，在一些模块中包含硬编码的业务层面逻辑。在基于BPEL的业务应用程序中，这种业务层面逻辑被转移到 BPEL 层中。必须考虑的一点是，BPEL层和已编排的低级业务逻辑服务之间的分界线应该放置在何处。BPEL中放置的流逻辑细节越多，总体处理中的 BPEL 相关份额也就越大，最终，您可能会在BPEL中实现低级或细粒度编程，但这不是BPEL的设计用途。毕竟，BPEL中的 “B” 代表 “业务（business）”，因此，BPEL应该只用于在业务逻辑层面上编程。

　　业务流程数据

　　每个业务流程都处理一些易变数据，这些数据可用于支持流中的决策，或者用作某些流活动的输入或输出参数。数据量或大小可能会对需要执行的处理量产生重大影响。对于大型业务对象，需要的内存量可能会迅速耗尽可用JVM堆，对于长期运行的流程，业务对象的大小与在每个事务边界上需要保存和从一个数据存储获取的数据量直接相关。CPU的能力也受到对象序列化和反序列化的影响。建议在业务流程实例中尽量少用数据。例如，不要通过一个流来处理大图像，一个以文件名或图像ID形式指向图像的指针将大大减小业务流引擎中的开销。

　　调用类型

　　Service Component Archictecture (SCA)环境提供了各种各样的调用机制。有些调用可以同步进行，另一些则异步进行。同步调用通常比异步调用需要更少的内部处理。异步调用通常还需要提交一个当前打开的事务，以允许出站消息对消息指向的目标使用者可见。如果目标服务驻留在同一个Java Virtual Machine (JVM)中，即使在使用同步绑定时，也可以避免不必要的序列化和反序列化，以便在内部只需要传递对象指针。如果目标服务驻留在同一个模块中，您还可以节约一些内部名称查询处理工作。

　　图 4 展示了本地和远程调用活动的SCA和web服务绑定的流量比较。

图 4. 本地和远程SCA和web服务绑定比较

　　审计日志记录

　　大多数BPM引擎允许您对在业务逻辑层面上发生的所有活动保持一个记录。但是，生成这样的审计日志并不是没有代价的，因为至少需要一些 I/O。建议将审计日志记录限制为只与业务真正相关的那些事件并忽略其他事件，以便尽量减小日志记录开销。

　　终端用户交互考虑

　　当您设计终端用户接口和与BPM系统的交互时，您必须主要处理获取需要完成的任务列表，请求任务并完成任务。

　　查询需要完成的任务

　　经验表明，当终端用户在过滤和排序他们拥有访问权的任务列表方面拥有极大自由度时，他们可能会形成一种择优挑选行为。这可能会导致不必要地执行过多任务查询。事实上，我们发现了一些20选1的情况。当业务性质需要任意过滤和排序的灵活性时，则这种行为不会提供帮助，但如果这种自由度不必要，建议以一种不提供不必要过滤和排序功能的方式设计终端用户与系统的交互。

　　并发任务访问

　　当两个或多个用户尝试从他们的组任务列表请求或检查同一个任务时，只有第一个用户将获得成功。当某些用户尝试请求已被另一个用户请求的任务时，他们将收到某种访问错误消息。这种请求冲突将降低生产力，因为它们通常会引发额外查询。一个补救措施是，只要一个请求企图报告冲突，则代码就会随机尝试请求列表中的下一个任务并向用户显示那个任务。

　　随着访问公共组任务列表的并发用户数量和任务列表的刷新频率的增加，以及不适当的从公共列表选择任务的机制，请求冲突的可能性也会增加。请求冲突不仅会导致处理更多请求，还会使用户感到沮丧。

　　多任务分配

　　上一小节建议控制对公共任务列表拥有访问权的用户数量。如果将一个任务分配给多个用户，而不是将一个任务放置到公共任务列表上，也会发生类似的冲突效果。一个好策略是使分配给一个任务的用户数量尽可能地少。

　　部署和应用程序打包

　　当前SOA运行时环境通常在基于J2EE的应用程序服务器上实现。业务应用程序作为一个或多个SCA模块部署在这些环境中。

　　使用公共对象库

　　通常，一组这样的业务应用程序共享公共的数据和接口定义，经典应用程序设计实践建议将这些公共对象放到一个公共对象库中，如图 5 所示。

图 5. 一个库，多个模块

　　然而，某些SOA运行时环境以一种意想不到的方式对待这样的打包模式。模块1的特定于模块的类加载器找到对另一个模块（公共对象库）的引用并加载那个模块。当模块2的特定于模块的类加载器加载它的模块的代码并找到对另一个模块（同样是公共对象库）的引用时，它加载那个模块。这种情况将继续应用到所有的应用程序模块。平台的应用程序类加载器对已经被其他应用程序级类加载器加载的模块一无所知，这个事实意味着共享的对象库实际上通过复制共享。如果共享对象库的一个副本的内存占用是几百个MB，那么可用堆空间将被迅速耗尽。

　　这种过量内存使用并不一定会影响性能，但当JVM的垃圾收集功能执行时，受影响的应用程序的响应能力将大幅降低。

　　一种内存消耗较少的方法是为每个应用程序模块定义一个库模块，如图 6 所示。

图 6. 每个模块一个库对象

　　尽管这种方法需要更多的开发和打包工作，但它能极大地减少总内存需求 — 已观察到的最大内存减少为 57%。

　　模块化效果

　　我们的一个内部基准测试工作负载被组织为3个SCA模块，因为那似乎是一个生产应用程序实现最自然的模式 — 一个模块创建并使用业务事件，而第二个模块包含负责同步的业务逻辑。为了便于代码维护，SCA开发人员可能想将一个应用程序分割为更多模块。为了展示模块化引发的性能成本，这个基准测试的3个模块被组织为两个或一个SCA模块。

图 7. 模块化效果

　　与原始工作负载实现相比，测量显示流量在两模块版本中提高了14%，单模块版本中提高了32%。不出所料，SCA组件之间的数据共享在跨多个模块时比在同一个模块中使用多个组件时更昂贵，因为后者可以进行额外优化。

　　流程引擎配置

　　不同的流程引擎拥有不同的调优选项。在本小节中，我们将讨论WebSphere Process Server的一些相关选项。

　　并发性

　　尽管长期业务流程将其大部分生命周期花费在默认线程池（基于 JMS 的导航）或 WorkManager 线程池（基于 WorkManager 的导航）中，但短期运行流程没有被分配任何特定线程池。根据将运行微观流的请求的来源位置，一个微观流可能在以下线程池中运行：

• 　　ORB线程池—微观流通过远程EJB调用从一个不同的JVM启动。
• 　　Web容器线程池—微观流使用一个HTTP请求启动。
• 　　默认线程池—微观流使用一条JMS消息启动。

　　如果微观流平行度不足，则检查您的应用程序并增加相应的线程池。关键是最大化端到端应用程序流的并发性，直到可用处理器和其他资源被最大化。

　　长期运行流的导航机制

　　WebSphere Process Server中的业务流程引擎使用几个链式事务来处理长期运行流。从V6.1开始，WebSphere Process Server中就有两种流导航技术：基于JMS的导航和基于WorkManager的导航。这两种导航都能提供相同的服务质量。在实验室测试中，基于WorkManager的导航显示出最高100%的流量增加。

　　但是，系统的行为会根据您选择的导航技术而略有不同。如果使用基于JMS的导航技术，则没有任何方案（比如基于年龄或基于优先权）来优先处理更早或高优先权的业务流程实例。这使您很难预测单一实例的实际延续时间，尤其是在负载很高的系统上。如果使用基于 WorkManager 的导航技术，则只要有未完成的工作，当前处理的实例将持续被处理。

　　资源依赖项

　　您可以首先调整SCA和MDB以及WorkManager线程（如果使用）的激活规范，然后继续沿着这条依赖项关系链进行调整，如图8所示。

图 8. 资源依赖项

  　图 8 中左边的所有引擎线程都需要JDBC数据库连接，如果这些线程不需要等待来自相关连接池的数据库连接，那么这对于数据库流量是非常有益的。

　　一个完全不同的资源池调优策略是将所有依赖资源的最大池大小设置得足够高（例如200），并通过只限制web容器和默认容器线程池这样的顶级资源来控制总体并发性。对于这些线程池，已经发现的实用限制位于30至50之间。所有实际使用的依赖资源按需调节，但绝不会达到它们的最大限制（至少对于目前实现的依赖关系而言）。这种调优策略极大地减少了持续监控和调节依赖资源池的工作。

　　其他流程引擎调优选项

　　业务流程引擎环境拥有记录环境中发生情况的方法，这可用于监控目的，也可用于发现问题。这样的记录需要一定的处理能力，因此，您应该尝试最小化任何监控记录，并务必禁用常规操作的问题发现跟踪。

　　某些基于开箱即用配置的数据存储可能默认使用Derby这样的基于文件的单用户简单数据库。由于可以免除某些数据库管理任务，因此这可以促进简单的设置。然而，当性能和生产级事务完整性更重要时，建议将这些数据存储放置到生产级数据库系统上。流量指标将改进 2 到 5 倍。

　　使用WebSphere Process Server的公共事件基础设施（CEI）记录业务相关事件时，禁用WebSphere Process Server内的CEI数据存储可能会有帮助，因为 CEI 使用这些事件并将其存储到自己的数据库中。您还应该关闭CEI事件有效性校验，因为一旦通过验证，发出事件就是有效的。

　　系统和子系统配置

　　本小节介绍JVM和数据库这些相关子系统的一些可伸缩性相关调优选项和一些相关调优参数。

　　集群拓扑

　　为处理增长和工作负载分发，现代业务流程引擎能够在一个集群设置中运行，将工作负载分布到各个物理节点（水平缩放），或者更好地利用现有节点中的闲置空间（垂直缩放）。

　　对于WebSphere Process Server，[6] [7]识别和描述了三个不同的集群拓扑模式，如图9所示。

图 9. 集群拓扑模式

　　第一种模式（如图左所示）也称为 “青铜拓扑”。这种模式包含一个应用程序服务器集群，其中，形成系统集成总线（SIBus）的WebSphere Process Server业务应用程序、CEI和BPC Explorer等支持应用程序、以及托管消息传递引擎（ME）的消息传递基础设施全部驻留在构成集群的每个应用程序服务器中。

　　青铜拓扑适合这样的解决方案：只包含同步web服务和同步SCA调用，最好只有短期运行流。

　　第二种模式（如图中所示）也称为 “白银拓扑”。这种模式拥有两个集群：第一个集群包含WebSphere Process Server业务应用程序和支持应用程序，第二个集群包含消息传递基础设施。

　　白银拓扑适合这样的解决方案：使用长期运行流程，但不需要CEI、消息排序、异步延迟响应、JMS或MQ绑定、以及消息排序机制。

　　第三种模式（如图右所示）也称为 “黄金拓扑”。与前面的模式不同，支持应用程序被分隔到第三个集群中。

　　黄金拓扑适合其余的所有情况，其中，异步处理在解决方案中发挥举足轻重的作用。这种拓扑还为应该在这种环境中运行的业务流程应用程序提供大部分JVM空间。如果可用硬件资源允许设置一个黄金拓扑，建议使用这种拓扑模式从头开始，因为它是用途最广的拓扑。

　　图 9 没有展示控制集群的管理基础设施。这个基础设施包含一些节点代理和一个部署管理器节点，后者充当这些集群所属的整个单元的管理中心点。这个管理基础设施的一个调优技巧是关闭节点配置的自动同步功能。根据设置的复杂性，最好在非高峰时间在已定义维护窗口期间手动开启这个同步处理功能。

　　JVM垃圾收集

　　详细垃圾收集并非像其名称暗示的那样详细。verboseGC开启时生成的那几行信息并不会真正损害系统性能，在诊断和排除性能问题时，这些信息可能非常有用。

　　WebSphere Process Server V6.1使用的JVM支持几种垃圾收集策略：流量垃圾收集器（TGC）、低暂停垃圾收集器（LPGC）、以及新一代垃圾收集器（GGC）。

　　TGC通过最小化垃圾收集器的成本来为JVM上运行的应用程序提供最好的开箱即用流量。但是，它在垃圾收集期间会出现100ms到几秒的 “停止一切” 阶段。
 
　　LPGC提供与JVM的工作并行的垃圾收集功能。由于同步成本上升，流量会降低。如果响应时间比最高流量更重要，这个垃圾收集器可能是一个不错的选择。

　　GGC是IBM? JVM 1.5的新功能，它非常适合生成大量短期存活的Java小对象的应用程序。由于它减少了暂停时间，您应该在上述情况下尝试GGC，而不是TGC或LPGC。经过适当调优，GGC能够为SOA/BPM工作负载提供最好的垃圾收集性能。

　　JVM内存考虑

　　增加应用程序服务器JVM的堆大小能够提高业务流程的流量。但是您需要确保有足够的真实内存可用，以便操作系统不会开始交换空间。

　　数据库子系统调优

　　除前面提到过的应用程序服务器调优外，SOA/BPM解决方案中的长期运行流和人工任务的性能很大程度上取决于适当调优的企业级数据库管理系统。本小节以IBM DB2数据库系统为例，提供一些数据库调优规则。这些规则中的大部分也适用其他生产数据库管理系统。

　　不建议使用Cloudspace或Derby这样的基于文件的简单数据库作为WebSphere Process Server的数据库管理系统，单元测试除外。

　　配置建议器

　　DB2自带了一个内置的配置建议器。创建数据库之后，可以使用这个建议器来为预期的使用场景配置数据库。配置建议器的输入取决于实际系统环境、负载假设、等等。

　　MINCOMMIT强烈推荐使用值1 。建议器有时会推荐其他值。

　　NUM_IOSERVERS  NUM_IOSERVERS的值应该等于数据库驻留的物理磁盘的数量（大于 2）。

　　NUM_IOCLEANERS应该有足够的IO清理器来确保缓存池中的脏页面被写到磁盘上，特别是在多处理器机器上。每个处理器至少应提供一个IO清理器。

　　数据库统计数据

　　最优数据库性能还需要数据库优化器很好地发挥作用。优化器的操作基于数据表中的行数、数据表或索引使用的空间以及其他信息的相关统计数据。当系统新建时，这些统计数据是空白。因此，优化器常常作出非最优决策，从而导致低劣的性能。

　　因此，当您最开始在系统上加载负载之后，或者无论何时数据库中的数据量剧烈变化，都应该通过运行DB2 RUNSTATS实用程序更新统计数据。运行RUNSTATS之前，确保数据库中有足够数据（>2000个流程实例）。避免在空数据库上运行RUNSTATS，因为那将导致低劣的性能。

　　支持重优化

　　如果您的系统上定期使用BPC API查询（比如，BPC Explorer使用的），建议允许数据库重优化SQL查询一次。这个调优步骤将极大地改进BPC API查询的响应时间。在实验室测试中，同一个查询的响应时间从超过20秒大幅下降到300毫秒。鉴于这样巨大的改进，重优化SQL的额外开销应该是可以接受的。

　　数据库索引

　　在多数情况下，BPM产品的数据存储没有以以下方式定义：有可能使用的所有数据库索引都已经定义。为了避免不必要的开箱即用处理，可能性更大的是只有那些以可接受的响应时间运行最基本的查询所需的索引已经定义。

　　作为一个调优步骤，您可以对终端用户查询生成的SQL语句进行一些分析，以便查看终端用户（或者相关的API调用）使用的查询过滤器与生成的SQL语句中的WHEERE子句之间的关系，并在相关表上定义其他索引来改善这些查询的性能。定义新索引之后，需要运行RUNSTATS来启用新索引。

　　有时，客户在定义额外索引时不能确定是否正在将他们的环境调优为一个不支持的状态。实际上完全不是这种情况。我们鼓励客户应用这样的调优步骤并检查它们是否有所帮助。如果没有帮助，可以通过删除索引来轻松恢复。

　　进一步数据库调优

　　任何优雅的数据库管理系统都能将其数据缓存在称为缓冲池的内存缓冲区中来避免物理 I/O。这些缓冲池中的数据在被引用时不需要从磁盘读取，而是可以直接从这些内存缓冲区提取。因此，合理的做法是将这些缓冲区设置得足够大，以容纳尽可能多的数据。

　　需要检查的关键调优参数称为缓冲池命中率，该参数描述物理数据与索引读取和逻辑读取之间的比率。首要原则是，只要能够获取一个对应的缓冲池命中率增加，就可以增加缓冲池的大小。一个良好调优的系统可以轻松实现远高于 90% 的命中率。

　　WebSphere Process Server通过多个并发线程访问其数据库，并使用行级锁定来确保其事务期间的数据一致性。这样，在处理繁忙时可以有大量活动行锁。数据库用于在其中维护锁信息的空间的相关数据库参数可能需要调整。

　　对于DB2而言，受影响的数据库配置参数是 LOCKLIST 和 MAXLOCKS。锁维护空间不足可能会导致所谓的 “锁提升”，其中，行锁被提升为不必要的表锁，这甚至可能会导致死锁情况。数据完整性在这样的情况下仍然得到维护，但相关的等待时间可能会严重影响流量和响应时间。

　　常见硬件和I/O考虑

　　在开始调优一个系统之前，应该确保使用的计算机已针对调优任务良好平衡；也就是说，可用 CPU 和 I/O 拥有适当的关系。如果一台计算机拥有一个（或多个）超快 CPU，但内存不足或 I/O 性能低下，那么它很难调优，对于长期运行流程而言，数据库端上形式为多个快速磁盘驱动器（RAID 阵列、SAN）的高 I/O 性能与足够的处理能力和充足的内存量同样重要。

　　小型场景

　　对于小型生产环境，WebSphere Process Server 应用程序服务器和数据库可以在同一台物理机器上运行。除了快速 CPUs 和足够的内存外，磁盘 I/O 的速度非常重要。一个重要原则是，建议每个 JVM 使用 1GB 至 2GB 内存，并为数据库提供尽可能多的内存。对于磁盘子系统，至少使用两个磁盘驱动器（一个用于 WebSphere 和数据库事务日志，另一个用于数据库和持久队列中的数据）。或者，使用一个带有尽可能多的磁盘驱动器的 RAID 系统，以便打消顾虑。

　　大型场景

　　对于大型生产系统，建议使用一个 WebSphere Process Server 机器集群来运行业务流程，单独使用一台机器来运行数据库。在这样的配置中，运行 WebSphere Process Server 的机器只使用两个物理磁盘就足够用了，一个用于操作系统，另一个用于 WebSphere Process Server，特别是用于 WebSphere 事务日志。如果事务日志成为一个性能瓶颈，可以使用带状磁盘来提高写入流量，如 [9] 所述。

　　运行数据库管理系统的机器需要许多带有大型缓存的高速 CPU、大量物理内存、以及良好的 I/O 性能。考虑使用 64 位系统来托管数据库。64 位数据库实例能够处理的内存比 32 位实例多得多。大型物理内存能够改进数据库的可伸缩性，因此最好使用一个 64 位实例。

　　要获取高速 I/O，考虑使用一个高速存储子系统（NAS 或 SAN）。如果您正在使用一个带有单独磁盘的设置，大量的磁盘优势明显。下面的实例描述一个使用 12 个磁盘驱动器的配置：

　　一个磁盘用于操作系统和交换空间。

　　两个磁盘用于 BPC 数据库的事务日志，可以采用逻辑带状设置，但最好采用硬件支持的带状设置，以实现更低的延迟和更高的流量。

　　4 个磁盘用于数据库管理系统中的 BPC 数据库。如果更多磁盘可用，则实例表应该在三个或更多磁盘上分布。如果需要人工任务，则必须考虑其他事项。

　　两个磁盘用于消息传递数据库的事务日志，同样，这两个磁盘应该采用上述带状设置。

　　三个磁盘用于消息传递数据库表空间。这些磁盘可以采用带状设置，且所有表空间都可以跨越该阵列进行分布。

　　在不需要最高流量的场景中，几个磁盘就足以实现可以接受的流量。使用 RAID 阵列代替单独磁盘时，考虑到部分磁盘用于提供故障转移功能，最优的磁盘数量更高。

　　数据库大小考虑

　　对于一个表现良好的SOA/BPM设置，数据库将占用多少磁盘空间这个问题相当无关紧要。原因何在？因为当今的磁盘通常至少拥有40（或80）GB空间。职责重大的生产级磁盘甚至更大。

　　生产需要高性能。为实现良好的I/O性能，您需要跨多个专用物理磁盘（带状逻辑卷或文件系统、RAID 0等）分布您的I/O。这也适用SAN存储。

　　SOA/BPM生产数据库的典型数据库大小（就磁盘上的占用空间而言）是良好性能所需的空间（就磁盘驱动器数量而言）的一小部分。实际上，为了实现理想的生产级性能，高达80%的可用总磁盘空间可能会被浪费掉。

　　因此，不必担忧生产数据库将会有多大 — 为获得高性能而所需的磁盘阵列能够很好地容纳它。

　　就绝对数量而言，典型生产级数据库大小很少超过 200GB。对于一个大型安装，可以假设最高达到500GB，现今一个磁盘就可以容纳这样的数据库，但是，肯定不会有人会不顾牺牲性能而企图那样做。

　　在实验室测试中，当仅使用几个小业务对象作为一个流程中的变量时，200 万个流程实例占用了大约100GB空间。一些真实世界数据包括100万个流程实例（最多包含500万个人工任务）占用100GB，5000万个流程实例（没有人工任务）占用 1TB。

　　性能工程和管理

　　本小节介绍性能工程（PE）和如何在 SOA 项目中使用性能工程。

　　为何使用性能工程？

　　就性能而言，系统经常令用户感到失望。在 [10] 中，Gartner 问：“当您推出一个新应用程序时，到底发生了什么？” 只有 14% 的人回答：“它达到了所有测试和预期响应时间指标；用户对此感到满意。” 其他答案是：

　　我们的 IT 部门接电话都忙不过来了（15%）

• 　　我们只是增加带宽来消除问题（9%）
• 　　我们损失收入、时间和资源（7%）
• 　　我们的工具不能识别出现的问题（9%）
• 　　我们听说应用程序测试时表现很好（34%）
• 　　我们十指交叉，祈求好运（12%）

　　这些问题的根源可能在解决方案交付伊始就被引入了。对于其中的性能缺陷没有检测到的每个开发阶段，补救成本将高达80到1000倍。

　　在当今的复杂系统堆栈中，性能问题可能发生在系统的多个不同部分。在16个已分析案例中，只有约35%关于供应商产品和环境，而65%与应用程序相关。在这65%中45%关于后端资源，18%关于客户的应用程序设置，36%关于客户的代码。

　　性能工程和生命周期

　　PE的主要目标是确保一个开发项目导致交付一个满足预先指定的性能目标集并能在生产中有效运行的系统，显然，PE必须覆盖整个系统生命周期 — 从设计到构建再到操作和管理（参见 [12]），如图 10 所示。

图 10. 性能工程和生命周期

　　在需求、早期设计和容量分析（volumetrics）阶段，您根据Business Service Level Agreements (BSLAs)收集顶级业务服务目标，需要将业务级计量单位（比如每小时100个预定）转换为对IT有意义的计量单位（比如每小时20.000个事务）。BSLAs也相应转换为对应的ITService Level Agreements (SLAs)。这包括将业务关键性能指示符（KPI）转换为所有相关IT组件的服务质量和性能目标。

　　对于技术研究，您可能想分析现有系统的特征（如果这些系统将重用于SOA解决方案），并考虑将引进的一些新型技术（比如ESB中间件），甚至SOA设备，比如DataPower机器。

　　在测算和建模中，您需要考虑一些性能影响，尤其是对持久性、大容量和复杂性来说，并将这些影响因素作为服务模型和性能模型的输入。用例的事务映射从业务服务层面开始，工作负载被分割为一些低级服务，以便低级工作负载可以被估计。业务处理率被分割为技术处理率。

　　在图 10 所示的设计中，开发和跟踪方案 1 识别可能拥有较大性能影响的子系统并给予它们额外的关注，比如更详细的性能预算分析，原型、或早期实现。减小低劣的端到端性能风险的一个好方法是创建一个非常早的原型（它也可用作敏捷开发的凝结核）。所有的架构设计决策都必须考虑性能。为实现跟踪目的，您可能想考虑用于合成应用程序跟踪的工具，或者将一个解决方案特定的合成心跳应用程序作为开发交付软件的一部分。

　　测试计划和执行将不得不应对一些挑战，比如端到端流中的一些动态变体。这种动态变体出现的原因可能是流程由业务规则驱动，也可能是消息传递基础设施中有动态应用程序组件或者可能有大型变体（可能是由大批量提交请求时产生的高队列深度所致）。测试类型范围从委员会测试（commission testing），通过可伸缩性、并发性和组件加载的单线程测试，干扰测试，到目标容量、压力和开销情景测试，后者通常需要更多努力，解决方案越复杂，测试也就越重要。

　　这些测试阶段获得的经验和使用或开发的工具是实时监控和容量规划方案的理想基础，例如，当来自不同公司的SLA报告需要被合并以进行 BSLA报告时。

　　SOA生命周期（如图 11 所示）与传统生命周期类似，但引入了一些新术语。但是，我们此前讨论的内容也适合SOA生命周期。

图 11. SOA生命周期

　　在图 11 中：

　　Model包括BSLAs、SLAs和相关性能目标的定义，以及性能建模和模拟。

　　Assemble包含一些组件级性能测量和监控，或者至少包含那些功能的支持组件以及心跳组件。

　　Deploy包含性能测试的主要部分。

　　Manage可能包含合成应用程序及其相关子系统的管理，以实现性能目标。

　　Governance and Processes 包含SLA和BSLA报告，以及（例如）容量管理。

　　结束语

　　SOA和BPM带来了一系列新挑战，因为复合应用程序引入了更高的复杂性和更多依赖项。要了解这种复杂环境的全貌，需要从多个视角进行考虑，还需要检查各种各样的事情。在本文中，我们讨论了一些最重要的事项。除了所有架构和操作方面以及调优领域，应用大量原则和适当的治理以适应这种环境的复杂性同样重要。

　　传统性能工程被扩展为包含比传统开发项目更多的业务级方面和业务用户。性能工程在确保解决方案的业务成功方面至关重要，不仅在于它有助于解决经典 IT 相关问题，还在于它支持解决方案的治理和正在其中运行的环境。