“门户运行的速度为何如何之慢？数据库出了什么问题吗？内容是如何传递给用户的？哪些内容存储于缓存中？您所说的‘重定向已发布的内容’是什么意思？”

如果您需要在门户中偶尔或者经常使用Publisher，那么这篇文章适合您阅读。要进行诊断、调优以及解决与性能有关的各种疑难杂症，第一步需要理解Publisher的工作原理。除此之外，这对于portlet问题的故障排除也十分有帮助。

逻辑图

首先，我根据对Publisher的理解画了一个逻辑图，如下所示：

最左侧的是Web客户端。在任何情况下，Web客户端实际上就是门户，用于代表portlet发送请求。我将在稍后详细介绍Web客户端。在这个图中，我们假设每个页面只有一个portlet，并且都没有使用缓存机制。

我将最右侧的内容称为“数据存储器”。任何内容都将符合数据存储器中的一种存储方式。

如图所示，Publisher由以下四部分组成：

这些部分各自的功能是什么，上图表示的是什么意思？请继续阅读……

Publisher管理主机

本文中的“Publisher管理”并不是portlet中的Publisher管理，而是表示与Publisher中的内容管理有关的一切事物：无论是创建新的portlet，通过Publisher浏览器进行导航，还是创建一个工作流，都属于Publisher管理。所有这些服务都是由Java应用服务器提供的，通常可以通过 http://publisherhost:7087/ptcs 页面进行访问，或者类似的URL。值得注意，Publisher管理主机基本上是一个独立的功能。它的实际作用就是处理Publish内容存储器中的信息，并将其发布到发布内容。

Publisher内容存储器

当我们进行编辑、修改、处理或任何需要保存的操作时，经过修改的信息将直接保存于存储器中。存储器实际上只是一个数据库和一个连接到 文档存储库 的Web服务。实际上，存储到文档存储库中的内容永远都只是一些二进制文件（图像、电子表格等等）。任何基于文本的内容项目、表示模板、数据条目模板和版本信息都存储在数据库中。

这对于我们意味着什么呢？这表示我们只需要对数据库和文档存储库进行备份，便可以应对一切灾难性故障。这有助于对数据进行同步，但由于DR中存储的大部分都是二进制内容，因此我们也有可能会损失一些图像和Word文档。可是这对于内容又意味着什么呢？

发布内容

这意味着内容本身都是从存储器发布到文件系统，然后托管在您所使用的Web服务器（Apache、IIS、Tomact等等）上。如果您使用的是“开箱即用”的Publisher配置，则上述所提到的托管主机就是Web服务器。这并不是说我们需要托管这个容器。事实上，我推荐大家不要这样做，因为与内容有关的任何问题都会造成Publisher管理的故障，反之亦然。我们可以为Publisher中的所有文件夹都配置一个发布路径（放置文件的位置——可以在本地也可以通过FTP）和主机路径（Web服务器托管的URL），因此我们可以做各种疯狂的事情（比如说将JSP发布到Java应用服务器上）。

当然，如果Publisher可以将文件放在各种位置，那为什么只有一个Web服务指向所有内容呢？它又怎么知道要如何托管这些内容呢？

发布内容重定向

逻辑图的最后一部分是发布内容重定向。逻辑图左侧的带有编号的请求演示了portlet请求Published Content Web Service（门户中的Web服务，所有的portlet都通过该服务构建而成）时的情况。详述如下：

1. Web客户机向发布内容重定向发起重定向请求（通常类似于 http://publisherhost:7087/ptcs/redirect.jsp）
2. 发布内容重定向实例化Publisher会话，检查数据库中的发布内容URL（参见上文发布内容部分）并抛出一个 HTTP 302（重定向）。
3. Web客户机重定向到新的位置（实际的发布内容），然后由您使用的Web服务器提供这些页面。

负载均衡、故障转移和性能

我并不是要讨论：如何使用DNS或其他方法在门户中建立负载均衡或故障转移。如果您想了解这方面的内容，请参阅 这篇由Gerald Kanapathy撰写的文章。阅读完这篇文章之后，再回来继续阅读Publisher中的具体应用。

返回本文……

与许多COTS产品一样，Publisher也存在这样一个问题：它不是静态的Web主机或数据库，我们无法对它的性能进行调优。实际上，我们需要了解它的运行原理才能够让它为我们所用。对于性能和故障转移，我们都需要处理5个事项。此处列出了这5个事项，并且简要介绍了如何处理它们：

• 数据库——负载均衡、故障转移和性能这些问题最好留给DBA来解决。实现方法相当简单，关于这方面的文档也非常丰富。

• 文档存储库（Document Repository，DR）——DR也是一种后端数据存储器，不过与数据库有所不同。在DR中实现故障转移是可行的（或许应该用一篇文章来单独介绍它）。总的来说，分为以下几个步骤：

  1. 在不同的主机上安装多个文档存储库。
  2. 将各主机上的“documents”目录都指向一个共享文件系统。
  3. 配置一个DNS条目，使其指向负载均衡的DR IP池。
  4. 记住上面几点，配置Publisher文档存储库条目。

• 发布内容重定向——重定向的处境可以说是十分尴尬。它是最容易被忽视的环节，不过却是最重要的，直接关系到Publisher的有效性。如果重定向遇到了问题，则所有发布内容都将无法显示，无论内容本身是否设置了负载均衡或故障转移都是如此。所幸的是，BEA提供了一个称为“Published Content Host”的Publisher安装选项。该选项将安装一个重定向程序。记住这些要点，遵循以下几个步骤：

  1. 在多个主机上安装重定向程序。
  2. 配置一个DNS条目，使其指向IP池的托管重定向程序（通过轮询[Round Robin]DNS或负载均衡解决方案实现）。
  3. 将所有的重定向程序都指定同一个数据库。
  4. 修改Published Content Web Service的URL，使其指向新的重定向程序主机。
  5. 修改Published Content Web Service的首选项，使其重新指向管理服务器（不要忘记这一点，否则在编辑portlets中的内容时会出现问题）。
• Publisher管理——Publisher管理可以设置为集群方式，这种方式类似于相互协作。遗憾的是，实际上我从未尝试过这种方式，因此我也无法提供这方面的指导。另一方面也说明集群式的Publisher管理并不是必不可少的。大多数时候，用户所关心的只是内容的可用性。如果编辑界面在某一段时间内出现了问题，这并不会对门户的终端用户造成影响，因此它只是管理员需要关心的事情。

其他

最后，我们再讨论一下内容、缓存和图像服务器的高可用性。总之，您可能需要将内容显示在每个页面上，几乎所有的用户都可以使用这些内容。或许还需要使用一些不同的缓存策略来缓存其余的Publisher内容。假设，您需要在门户中的每个页面上都显示一个标题portlet，并且希望使用Publisher来发布它。

在这种情况下，我一般会选择建立一个独立于Publisher的Web服务。这样我们便可以为内容 配置一个单独的缓存策略（如果发布内容随时都可以更新，而我的标题每隔6小时才修改一次）。我们还可以避免不必要的加载发布内容重定向，因为我通常将这个单独的Web服务直接指向内容。最后，如果确实要追求性能的话，我会将内容直接发布到图像服务器上。只要对发布URL进行配置，使其指向图像服务器的URL，便可以将二进制内容（比如说标题中的图像）直接发布到静态主机上，并在图像服务器的提供这些图像，而无需通过网关（节省了不必要的HTTP流量）。

最后，我也精疲力竭了

使用上述这些信息，您应该可以配置出一个高可用性的、高性能的Publisher环境。