评论专栏: Tom Alcott：欲言又止的 WebSphere Application Server 的相关问题，第 4 部分

在刚刚结束的 WebSphere Technical Exchange 上，我很荣幸地举办了一个与本文（以及前面三篇文章）同主题的讨论会。讨论会的参加者使我相信，在这里所提供的内容是有效的，受到了广大读者的认可，并为各位同事和客户提供了很大的帮助。我原本猜想有些参加者可能只是想找个舒适的位置坐一下，但出于自负，我却并不这么认为。因此，在这里提供了关于我反复被问到的问题的第 4 期，还包括我反复给出的解答。与以前一样，我最常使用的回复是“视情况而定”，参加了 WebSphere Technical Exchange 的 WebSphere 性能“专家咨询”讨论会的人对此不会感到奇怪，因为在该讨论会上，三位专家都使用了这个回复，并且有时候非常一致。当然，如果我用这句话来解答所有的问题，那么你们一定不会赞成的，所以下面提供的内容可以作为您在为所面临的特定情况确定最佳解答时的指导，加上对一些常见问题的确定性的解答。

问：WebSphere Application Server Network Deployment（和 WebSphere Extended Deployment）支持运行混合版本的单元（运行不同版本的单元节点）吗？

答：是的，WebSphere Application Server Network Deployment（和 WebSphere Extended Deployment）支持混合版本单元，但是这被认为是一种临时性的方案，意味着仅使用几周或几个月。这种适应能力使得您可以轻松地从一个版本迁移到另一个版本，而无需在一个星期（或更短的时间）内完成这项工作，但是这并不是一个长期的解决方案。IBM 当然为那些在运行混合环境时碰到问题的客户提供了相应的支持，但是在大多数情况下，“支持的”和“推荐的”并不是同一回事。

我个人的建议是不要长期运行混合版本单元，因为运行两个（或更多）不同版本的时间越长，碰到问题的可能性就越大。（您在一个单元中运行两个相同的节点时碰到过问题吗？）当从 WebSphere Application Server 的一个版本迁移到另一个版本时，我通常建议，将新版本与当前已经安装的版本安装到同一台计算机上（这称为共存），在相同的硬件中运行两个单元（一个是旧的版本，一个是新的版本），然后在迁移过程中调整每个单元中的 WebSphere Application Server 实例，例如，减去一个 WebSphere Application Server V5.x 实例，添加一个 WebSphere Application Server V6.x 实例。

对于 Version 6.1 来说有点特殊，它具有一种“缺省安全”的新的安全基础结构，并且包括了证书的生成（使用主机名）。如果您需要将单元迁移到 Version 6.1，那么迁移的单元在缺省情况下是不安全的，除非已您按照确保以前的 WebSphere Application Server 环境的安全中的说明进行了操作。这并不表示您无法在 Version 6.1 中运行 Version 6.1 之前的单元（或者不支持它们），但是需要考虑一些附加的步骤。

我再次建议 您不要运行混合版本单元。并再次说明，这并不 意味着混合版本单元无法工作（它们可以工作），或者不支持您这样做（允许这样做）。当有客户问我这个问题时，我通常的回答是“是的，在您碰到问题时 IBM 将为您提供支持，但我情愿您最好不要碰到问题”。大多数人同意这种逻辑，并以此结束了该问题的讨论。

问：我是不是应该使用 WebSphere Application Server（和 WebSphere Application Server Network Deployment）来管理我的 HTTP 服务器？

答：与前面关于运行混合版本单元的讨论一样，我建议您不要使用 WebSphere Application Server 来管理您的 HTTP 服务器，即使 WebSphere Application Server 提供了完成该任务的功能，即使在您选择这样做时 IBM 将为您提供支持。我建议不要这样做的理由是，因为不应该在 DMZ 中加强 HTTP 服务器的功能。尽管 WebSphere Application Server 为 IBM HTTP 服务器的远程管理提供了一种安全的和支持的解决方案，但不使用这个功能将大大减少攻击的途径。

作为 WebSphere Application Server V6 高级安全性加强 一文中所提到的第一项内容，这并不是巧合，这篇文章介绍了“在没有 WebSphere Application Server 的情况下，将 Web 服务器放在 DMZ 中”。（在这个上下文中，WebSphere Application Server 包括所有的 WebSphere Application Server 组件，包括部署管理器、节点代理、应用服务器，等等。）

在这个建议的基础上，我还要补充一点，如果您的基础结构在 DMZ 中包括反向代理安全服务器，这样一来，您的 HTTP 服务器并不位于 DMZ 中，则可以使用 WebSphere Application Server 进行 HTTP 服务器管理，而不用操那么多心了。然而，我并不确定通过这样做来节省一点时间是否真的非常合理。

问：WebSphere Application Server 中附带的某些开放源码实现是什么版本的？

答：经常有人问我，“WebSphere Application Server 中附带什么版本的 Xerces（或 Xalan）？”，人们通常会担心因为 WebSphere Application Server 运行时所使用的版本与他们自己的应用程序所使用的版本不同而产生冲突。实际上这根本不是问题，因为 WebSphere Application Server（V5 和更高版本）中的类加载器允许您对应用程序中希望使用的版本进行打包，然后指定您希望使用的类的版本。这时将加载您希望使用的类（而不是运行时所使用的类）。可以通过将应用程序或 Web 应用程序的类加载模式指定为“PARENT_LAST”来实现这项任务。这样做可以确保您的应用程序使用 EAR（或共享库）中的实现，并且可以防止当 WebSphere Application Server 维护更改版本时出现破坏。在 Integrating Jakarta Commons Logging 一文中对这个问题进行了深入的讨论。

当然，如果您只是感到好奇的话，有一种比较简单的机制可以用来确定 WebSphere Application Server 中附带的版本。在每个 JAR 中都包含了一个“Version”类。执行 WebSphere Application Server V6.1.0 中的这个类，可以得到如下的输出：

C:\WAS61\AppServer\java\jre\bin>java -cp .\lib\xml.jar org.apache.xalan.Version
XSLT4J Java 2.7.4
	
C:\WAS61\AppServer\java\jre\bin>java -cp .\lib\xml.jar org.apache.xerces.impl.Version
XML4J 4.4.5

问：我应该在 WebSphere Application Server 中使用刀片服务器吗？

答：这也是“视情况而定”的。（您知道我会这样回答的，对吗？）通常，如果您有许多容易复制的小对象，刀片策略可能非常有效。如果您有非常大的对象，而难以将其划分为小的块，那么刀片的效率将非常糟糕。我通常不建议在数据库中使用刀片，因为数据库通常使用两个以上的 CPU，而我担心大型的 WebSphere Application Server 应用程序所使用的刀片并不适合用于具有两个 CPU 的计算机。说得清楚些，如果您确定了应用程序的大小，并证明了它们将非常适合，那么刀片是个很好的主意。如果您没有这样做，对于较大的计算机来说，采用风险较小的方法更合适。所以，这取决于应用程序、部署和硬件的大小（CPU、内存，等等），也许在将来还需要考虑这些因素。

问：我应该从 32 位 WebSphere Application Server 迁移到 64 位 WebSphere Application Server 吗？

答：同样，这也是“视情况而定”的，64 位并不会自动地提供更好的性能，实际上对大多数的应用程序来说，并没有什么优势。下列的应用程序可以获得最大的性能提升：

• 内存限制——64 位所提供的额外内存可以支持更好的缓冲策略，使得应用程序可以避免开销很高的查询，等等。
• 计算上开销很高的代码，如数值分析、算法，等等。与使用 32 位的寄存器相比，由于使用了 64 位的寄存器，要执行相应的计算工作，只需使用更少的指令。

如果您的应用程序符合上述的标准，那么您可以在 64 位的环境中对您的应用程序进行测试，以分析是否有迁移的价值。请记住，很多从 32 位迁移到 64 位的人并没有实现性能的优势，相反带来了更大的内存占用，因为 64 位地址所占用的空间是 32 位地址所占用空间的两倍。更大的内存占用还将很快地填满 L2/L3 缓存，这样会对性能产生负面的影响。

回页首

结束语

现在进行一个总结。希望我关于一些最常见问题的观点能够为您提供相应的思路。