|
|
以下部分描述 WebLogic Server 群集的几种可选体系结构：
此处的“体系结构”指的是如何将应用程序的层部署到一个或多个群集。
一个 Web 应用程序分为几个层，分别对应应用程序提供的不同逻辑服务。并非所有的 Web 应用程序都是相似的，因此您的应用程序可能不会用到下面描述的所有层。另外，请记住，层代表应用程序服务的逻辑分类，而不一定是硬件或软件组件间的实际分类。在某些情况下，一台运行单个 WebLogic Server 实例的计算机可以提供下面描述的所有层。
“Web 层”为Web 应用程序的客户端提供静态内容（例如，HTML 网页）。Web 层通常是外部客户端与Web 应用程序之间的第一个联系点。一个简单的 Web 应用程序可以有一个 Web 层，该层由一台或多台运行 WebLogic Express、Apache、Netscape Enterprise Server 或 Microsoft Internet Information Server 的计算机组成。
“表示层”为Web 应用程序的客户端提供动态内容（例如，Servlet 或 Java Server Page）。承载 Servlet 和/或 JSP 的 WebLogic Server 实例群集组成 Web 应用程序的表示层。如果该群集也为应用程序提供静态 HTML 网页，则该群集既是 Web 层又是表示层。
“对象层”提供 Java 对象（例如，Enterprise JavaBean或 RMI 类）及其与 Web 应用程序相关的业务逻辑。承载 EJB 的 WebLogic Server 群集提供对象层。
如果群集体系结构中 Web 应用程序的所有层都部署到一个 WebLogic Server 群集，则该群集体系结构称为综合层体系结构。
“De-Militarized 区域 (DMZ)”是硬件和服务的逻辑集合，用于外部的、不可信的资源。在多数 Web 应用程序中，DMZ 中有一系列 Web 服务器，这使基于浏览器的客户端可以访问静态 HTML 内容。
DMZ 可以提供安全保护，能够防止来自外部的针对硬件和软件的攻击。不过，DMZ 可用于不可信的资源，因此其安全性低于内部系统。例如，内部系统可以用拒绝所有外部访问的防火墙进行保护。通过使用防火墙“隐藏”对各个主机、应用程序或端口号的访问，可以保护 DMZ，但将仍然允许从不可信的客户端访问那些服务。
在本文中，术语“负载平衡器”用来描述将客户端连接请求分发到一个或多个 IP 地址的任何技术。例如，简单 Web 应用程序可以使用 DNS 循环算法作为负载平衡器。较大的应用程序通常使用基于硬件的负载平衡解决方案（例如，那些来自 Alteon WebSystems 的解决方案），这些解决方案也可以提供类似防火墙的安全功能。
负载平衡器提供将客户端连接与群集中的特定服务器相关联的功能，对客户端会话信息进行内存中复制时会使用该功能。使用负载平衡产品，必须配置 cookie 持久性机制，以免覆盖 WebLogic Server cookie，WebLogic Server cookie 跟踪用于内存中复制的主、辅服务器。有关外部负载平衡器、会话 Cookie 持久性和 WebLogic Server 会话 Cookie 的讨论，请参阅使用外部负载平衡器实现 HTTP 会话的负载平衡。
“代理插件”是 WebLogic Server 对 HTTP 服务器（例如，Apache、Netscape Enterprise Server、或 Microsoft Internet Information Server）的扩展，它可以访问 WebLogic Server 群集提供的群集 Servlet。代理插件包含用于访问 WebLogic Server 群集中的 Servlet 和 JSP 的负载平衡逻辑。如果承载会话状态的主 WebLogic Server 失败，则代理插件还包含用于访问客户端会话状态副本的逻辑。
推荐的基本体系结构是一个综合层体系结构 - Web 应用程序的所有层都部署到同一个 WebLogic Server 群集。此体系结构如下图所示。
单个的群集承载静态 HTTP 网页、Servlet 和 EJB，因此可以配置整个 Web 应用程序并用 WebLogic Server控制台部署/取消部署对象。要充分利用群集 Servlet，不需要另外维护一系列 Web 服务器（以及配置 WebLogic Server代理插件）。
在 WebLogic Server 群集前面直接使用负载平衡硬件，以便访问 HTML 和 Servlet 内容时都可以使用高级负载平衡策略。例如，可以配置负载平衡，以检测到正确的当前服务器负载和直接客户端请求。
在负载平衡硬件的前面放置防火墙，以便使用最基本的防火墙策略为 Web 应用程序设置De-Militarized区域 (DMZ)。
如果应用程序表示层中的多数或全部 Servlets 或 JSP 经常会访问对象层中的对象（例如，EJB 或 JDBC对象），则综合层体系结构可为该应用程序提供最佳性能。
| 注意： | 使用带有内存中会话复制功能的第三方负载平衡器时，必须确保负载平衡器与承载其主会话状态的 WebLogic Server 实例（点访问服务器）保持客户端连接。有关负载平衡器的详细信息，请参阅使用外部负载平衡器实现 HTTP 会话的负载平衡。 |
当综合层体系结构（例如，推荐的基本体系结构）满足多个 Web 应用程序的需求时，它会限制用户完全部署群集的负载平衡和故障转移功能的能力。只能在 Web 应用层的界面之间引入负载平衡和故障转移，因此，当多个层部署到单个群集中时，只能在客户端和群集之间进行负载平衡。
因为大多数负载平衡和故障转移发生在客户端和群集自身之间，因此，综合层体系结构满足多数 Web 应用程序的需求。
但综合层群集不提供对群集 EJB 的负载平衡方法的调用。因为在群集的所有 WebLogic Server 实例中都部署了群集对象，因此每个服务器都可以在本地使用每个对象实例。WebLogic Server 优化方法总是通过选择本地对象实例来调用群集 EJB，而不是将请求分布到远程对象，将请求分发到远程对象会带来更多网络开销。
多数情况下，共存策略比将每个方法请求都负载平衡到不同的服务器更有效。但如果对不同服务器的处理负载是不平衡的，对远程对象提交方法调用会比本地处理方法更有效率。
要对群集 EJB 的方法调用进行负载平衡，必须将 Web 应用程序的表示层和对象层拆分到不同的物理群集（如以下部分所述）。
决定使用综合层体系结构还是使用多层体系结构时，请考虑表示层调用对象层的频率。如果表示层经常调用对象层，综合层体系结构可能会提供比多层体系结构更佳的性能。
本部分描述推荐的多层体系结构，在该体系结构中，应用程序的不同层会部署到不同的群集。
推荐的多层体系结构使用两个单独的 WebLogic Server 群集：一个提供静态 HTTP 内容和群集 Servlet，另一个提供群集 EJB。建议对有以下要求的 Web 应用程序使用多层群集：
| 注意： | 考虑多层体系结构时，请考虑表示层对对象层的调用频率。如果表示层经常调用对象层，综合层体系结构可能会提供比多层体系结构更佳的性能。 |
在推荐的多层体系结构中，应用程序层由两个独立的硬件和软件层承载。
Web/表示层由一个 WebLogic Server 实例群集组成，这些实例专门承载静态 HTTP 网页、 Servlet 和 JSP。此 Servlet 群集不承载群集对象，表示层群集中的 Servlet 会充当群集对象的客户端，群集对象位于对象层中单独的 WebLogic Server 群集上。
对象层由一个 WebLogic Server 实例群集组成，这些实例仅承载 Web 应用程序所需的群集对象 - EJB 和RMI 对象。承载专用群集上的对象层，会失去默认的访问群集对象的共存优化（如共存对象的优化中所述）。但可以对调用每个群集对象的方法实现负载平衡（如下部分所述）。
在不同的群集分别承载 Servlet 和 EJB，EJB 的 Servlet 方法调用可以在多台服务器间实现负载平衡。多层体系结构中的负载平衡群集对象中对此过程进行了详细描述。
将表示层和对象层放在不同的群集上为分散 Web 应用程序负载提供了更多的选项。例如，如果应用程序访问 HTTP 和 Servlet 内容比访问 EJB 内容更加频繁，可以在表示层群集中使用大量的 WebLogic Server 实例，以将访问集中在少量承载 EJB 的服务器中。
利用其他 WebLogic Server 实例，多层体系结构的单点故障会比基本群集体系结构的单点故障更少。例如，如果一个承载 EJB 的 WebLogic Server 失败，则 Web 应用程序的HTTP 和 Servlet 承载能力不会受影响。
将表示层和对象层放在不同的群集上，可以使用只在 DMZ 中放置 Servlet/JSP 群集的防火墙策略。通过拒绝来自不可信客户端的直接访问，承载群集对象的服务器可以得到进一步的保护。详细信息，请参阅群集体系结构的安全选项。
WebLogic Server 对群集对象的共存优化（如共存对象的优化中所述）取决于与调用对象的复制感知存根控件相同的服务器实例上是否有群集对象（EJB 或 RMI 类）。
分离对象层的影响是，在承载群集对象的服务器上任何客户端（HTTP 客户端、Java 客户端或 Servlet）不再需要有复制感知存根控件。因此，WebLogic Server 无法使用其共存优化（如共存对象的优化中所述），并且群集对象的 Servlet 调用会根据复制感知存根控件中包含的逻辑来自动实现负载平衡。下图描述了在多层体系结构中客户端如何访问群集 EJB 实例。
跟踪客户端连接的路径，可以看到将对象层分离到单独的硬件和软件上所带来的影响。
Servlet 在承载群集对象的 WebLogic Server 群集上查找 EJB。Servlet 收集 Bean 的复制感知存根控件，复制感知存根控件列出所有承载 Bean 的服务器的地址，以及访问 Bean 副本的负载平衡逻辑。
| 注意： | EJB 复制感知存根和 EJB 主页加载算法是用 EJB 部署描述符的元素指定的。有关详细信息，请参阅“WebLogic Enterprise JavaBean 编程”中的 weblogic-ejb-jar.xml 部署描述符参考。 |
在本示例中，如果同一个 WebLogic Server 群集既承载 Servlet 又承载 EJB（如推荐的基本体系结构中所述），WebLogic Server 将不会加载 EJB 的平衡请求。Servlet 总是调用本地服务器上承载的 EJB 副本上的方法。使用本地 EJB 实例比远程方法调用另一台服务器上的 EJB 更有效。但使用多层体系结构，可以对那些进行 EJB 方法调需要使用负载平衡的应用程序进行远程 EJB 访问。
多层体系结构为群集对象调用提供负载平衡，因此，系统会比综合层体系结构更多地使用 IP 套接口。尤其是在使用套接口的高峰时期，承载 Servlets 和 JSP 的群集中的每个 WebLogic Server 对以下组件的使用可能会达到最大值：
例如，在图 8-2 中，Servlet/JSP群集中的每个服务器最多可以打开五个套接口。在最糟糕的情况下，即主会话状态和辅会话状态分散在 Servlet 群集中，且Servlet 群集中的各服务器同时访问对象群集中每台服务器上的远程对象，才会达到此最大值。多数情况下，实际使用的套接口数量会小于最大值。
如果使用纯 Java 套接口实现多层体系结构，请确保配置足够的套接口读取器线程，以满足最大的套接口使用量。有关详细信息，请参阅为 Java 套接口实现配置读取器线程。
多层体系结构使用硬件负载平衡器，因此，如果您使用内存中会话状态复制，则必须配置负载平衡器，以保持对客户端的点访问服务器的“粘滞”连接。详细信息，请参阅为 EJB 和 RMI 配置负载平衡 。
推荐的多层体系结构无法使用共存优化来优化对象，因此，所有群集对象的方法调用都会为 Web 应用程序带来更多网络开销。但是，如果 Web 应用程序需要利用多层体系结构的优点中描述的优点，这些开销是可以接受的。
例如，如果 Web 客户端大量使用 Servlet 和 JSP，但访问的群集对象较少，使用多层体系结构可以适当集中 Servlet 和对象的负载。可以为十个 WebLogic Server 实例配置一个 Servlet 群集，为三个 WebLogic Server 实例配置一个对象群集，而仍然可以充分利用每台服务器的处理能力。
在多层体系结构中，如果在 Servlet 群集和对象群集之间放置防火墙，则必须绑定对象层中的所有服务器以发布 DNS 名称，而不是发布 IP 地址。将服务器与 IP 地址进行绑定，会导致地址翻译问题，从而妨碍 Servlet 群集访问各个服务器实例。
如果 WebLogic Server 实例的内部和外部 DNS 名称不完全相同，请使用服务器实例的 ExternalDNSName属性定义服务器的外部 DNS 名称。在防火墙之外，ExternalDNSName 应转换为服务器的外部 IP 地址。
对于防火墙要执行网络地址转换的配置，必须使用 ExternalDNSName，除非客户端要使用 t3 和默认通道访问 WebLogic Server。例如，对于防火墙要执行网络地址转换且客户端通过代理插件使用 HTTP 访问 WebLogic Server 时，需要使用 ExternalDNSName 进行配置。
可以将 WebLogic Server 群集配置为与现有 Web 服务器一起运行。在此体系结构中，一系列 Web 服务器使用 WebLogic 代理插件或 HttpClusterServlet 将 Servlet 和 JSP 请求直接定向到群集，为 Web 应用程序提供静态 HTTP 内容。
下图中描述的双层代理体系结构与推荐的基本体系结构类似，不同的是静态 HTTP 服务器是由一系列 Web 服务器承载。
代理体系结构利用硬件和软件层来专门执行提供应用程序 Web 层的任务：Web 层由一台或多台相同配置的计算机组成，这些计算机承载以下应用程序组合：
HttpClusterServlet的 WebLogic Server
无论选择哪种 Web 服务器软件，都请记住：Web 服务器的物理层仅提供静态网页。动态内容（Servlets 和 JSP）通过代理插件或 HttpClusterServlet 代理到承载表示层的 Servlets 和 JSP 的 WebLogic Server 群集。
推荐的双层体系结构协议在一个 WebLogic Server 实例群集上承载表示层和对象层。此群集可以部署在一台计算机上，也可以部署在多台单独的计算机上。
推荐的基本体系结构中描述了 Servlet/对象层与综合层的区别，Servlet/对象层不对应用客户端提供静态 HTTP 内容。
也可以使用一组 Web 服务器作为承载表示层和对象层的 WebLogic Server 群集对的前端。下图中显示该体系结构。
此体系结构提供推荐的多层体系结构相同的优点和限制。此体系结构与 Web 层的唯一不同是，它是放置在单独的一组利用 WebLogic 代理插件的 Web 服务器上。
使用独立 Web 服务器和代理插件，Web 应用程序会受到以下限制：
与代理 Servlet 请求相比，直接将 WebLogic Server 群集与负载平衡一起使用有几个优点。首先，将 WebLogic Server 群集与负载平衡一起使用，对客户端设置不需要其他管理 - 不需要设置和维护单独的 HTTP 服务器层，并且不需要安装和配置一个或多个代理插件。删除 Web 代理层，也会减少访问群集所需的网络连接数。
使用负载平衡硬件，可以更灵活地定义适合您的系统性能的负载平衡算法。可以使用负载平衡硬件支持的任何负载平衡策略（例如，基于负载的策略）。使用代理插件或 HttpClusterServlet，会限制您只能使用单循环算法处理群集 Servlet 请求。
注意，如果使用内存中会话状态复制，则可能需要其他配置才能使用第三方负载平衡。在此情况下，必须确保负载平衡的客户端和点访问服务器之间保持“粘滞”连接，以便客户端访问主会话状态信息。使用代理插件时，不需要特别配置，因为协议会自动保持粘滞连接。
在推荐的配置中，物理硬件/软件层的边界提供用于定义 Web 应用程序的非军事区域（De-Militarized Zone，简称 DMZ）的潜在位置。但不是所有边界都支持物理防火墙，有些边界只支持典型防火墙策略的一个子集。
后面的部分介绍几种定义 DMZ 以创建不同级别应用程序安全的几种常用方法。
基本防火墙配置在不可信的客户端和 Web 服务器层之间使用单独的防火墙，该防火墙可与推荐的基本体系结构或推荐的多层体系结构群集体系结构一起使用。
在上图中，单独的防火墙可以使用任何策略组合（应用程序级限制、NAT、虚拟 IP）来筛选对三台 HTTP 服务器的访问。防火墙最重要的作用是拒绝直接访问系统中的其他服务器。换句话说，对不可信的客户端来说，Servlet 层、对象层及数据库自身必须是不可访问的。
注意，在 DMZ 中，可以在 Web 服务器的前面放置防火墙，也可以在 Web 服务器的后面放置防火墙。在 Web 服务器的前面放置防火墙，可以简化防火墙策略，因为只需要允许对 Web 服务器的访问而拒绝对其他所有系统的访问。
ExternalDNSName 属性定义其外部 DNS 名称。在防火墙外，ExternalDNSName 应该翻译为服务器的外部 IP 地址。 | 注意： | 如果群集服务器隔离自定义通道对的 http 和 http 流量，请参阅“设计及配置 WebLogic Server 环境”中的通道、群集和防火墙 。 |
通过只允许访问 Web 服务器层，基本防火墙配置创建占用较少资源的 DMZ，其中只包括三个 Web 服务器。但是，比较保守的 DMZ 定义会考虑这种可能性，即恶意的客户端可以获得对承载表示层和对象层的服务器的访问权。
例如，假设一个黑客获得了对其中一台承载 Web 服务器的计算机的访问权。根据访问级别，该黑客可能可以获得有关协议服务器的信息，Web 服务器会用这些信息访问动态内容。
如果选择使用比较保守的 DMZ 定义，则可以使用共享数据库的其他安全措施中介绍的信息放置其他防火墙。
如果使用带有推荐群集体系结构的负载平衡硬件，必须决定如何部署与基本防火墙相关的硬件。除负载平衡服务以外，虽然很多硬件解决方案会提供其他安全功能，但多数网站还是将防火墙作为其 Web 应用程序的第一道防线。通常，防火墙提供经过检测的熟悉的安全解决方案来限制网络流量，并且防火墙可以在负载平衡硬件的前面使用，如下所示。
以上设置将负载平衡器与 Web 层一起放在 DMZ 中。在此配置中使用防火墙可以简化安全策略管理，因为防火墙只需要限制对负载平衡器的访问。如下所述，此设置还可以简化支持内部客户端访问 Web 应用程序的站点的管理。
如果支持需要直接访问 Web 应用程序的内部客户端（例如，运行专用Java 应用程序的远程计算机），则可以扩展基本防火墙配置，以允许对表示层进行受限访问。根据是将客户端作为可信连接还是不可信连接，可以使用不同的方式扩展对应用程序的访问。
如果使用虚拟专网（Virtual Private Network，简称 VPN）来支持远程客户端，客户端可能会作为可信连接，可以通过防火墙直接连接到表示层。此配置如下所示。
如果不使用 VPN，所有与 Web 应用程序的连接（包括来自使用专门的客户端应用程序的远程站点的连接）都将视为不可信的连接。在这种情况下，可以修改防火墙策略，以允许与承载表示层的 WebLogic Server 实例进行应用程序级别的连接，如下图所示。
如果使用单个数据库，该数据库既支持内部数据又支持外部可用的 Web 应用程序的数据，则应该考虑在访问数据库的对象层之间放置硬边界。通过添加另一个防火墙可以该实现该操作，其结果仅仅是会加强 DMZ 边界（在代理体系结构的基本防火墙中描述）。
以下配置在由 Web 应用程序和内部（可信的）客户端共享的数据库服务器的前面放置另外一个防火墙。对于万一第一道防火墙被突破而黑客获得对承载对象层的服务器的访问权的情况，此配置会提供进一步的安全保障。注意，在生产环境中应该极少出现此种情况 - 您的站点应该有能力在黑客获得对对象层的计算机的访问权之前就检测到并终止恶意入侵。
在以上配置中，使用另一个防火墙强化对象层与数据库之间的边界。此防火墙会保持严格的应用程序级策略，除来自承载对象层的 WebLogic Server 的 JDBC 连接之外，该策略拒绝访问所有其他连接。
  
|
