|
以下这些主题推荐了一些设计和部署实践,这些实践能够使 WebLogic Server 群集所承载应用程序的可伸缩性、可靠性和性能达到最佳。
分布式系统本来就非常复杂。出于各种原因,都应将简单作为重要的设计目标。将“移动部件”减到最少,不要在多个对象之间分布算法。
避免从客户端或 Servlet 代码访问 EJB 实体 Bean。而是使用会话 Bean(称为“外观”)来包含复杂的交互并减少从 Web 应用程序到 RMI 对象的调用。当客户端应用程序直接访问实体 Bean 时,每个获取器方法都是远程调用。会话外观 Bean 可以本地访问实体 Bean、收集结构中的数据,并按照值返回数据。
EJB 执行时要使用大量系统资源和网络带宽 - 它们不太适合用于实现应用程序中的每个对象。
使用 EJB 可对信息及关联业务逻辑的逻辑分组进行建模。例如,使用 EJB 可对发票上行项目的逻辑分组进行建模 - 例如要应用打折、回扣、征税或应用其他调整的项目。
与之相反,发票上的单个行项目则是细粒度的 - 将其实现为 EJB 会浪费网络资源。将只表示一组数据字段的对象(这些对象只需要 get 和 set 功能)实现为传输对象。
传输对象(有时称为“值对象”或“辅助类”)非常适用于对包含总是一起访问的一组特性的实体进行建模。传输对象是 EJB 中对相关特性进行分组从而形成组合值的可序列化类。此类用作远程业务方法的返回类型。
客户端通过调用粗粒度的业务方法接收此类的实例,然后本地访问传输对象中的细粒度值。在一个服务器往返中提取多个值会降低网络流量,也会将滞后和服务器资源用量减到最低。
避免跨越多个服务器实例的事务。分布式事务会发出远程调用,因此要使用网络带宽以及用于资源协调的开销。
下列部分介绍群集 Servlet 和 JSP 的设计注意事项。
要启用 Servlet 和 JSP 的自动故障转移,会话状态必须持久保存在内存中。有关为 HTTP 会话状态配置内存中复制的说明,请参阅 HTTP 会话状态复制的要求和配置内存中 HTTP 复制。
失败或者用户耐心不足可能导致发出重复的 Servlet 请求。请将 Servlet 设计为允许重复的请求。
根据服务器实例失败时它正在进行的工作,并不总是能够确定它是何时失败的。例如,如果某个服务器在处理某个客户端请求之后、响应返回之前失败,则根本无法知道是否已处理该请求。没有收到响应的用户会重试,从而导致额外的请求。
RMI 对象的故障转移要求方法具有幂等性。幂等方法指的是可以重复使用、但不会产生负面副作用的方法。
下表概述了 EJB 的用法和配置指南。有关可配置群集行为的列表,请参阅表 10-2。
|
||||
|
||||
weblogic-ejb-jar.xml 中的 home-call-router-class-name 可以指定用于为这些类型的 Bean 路由 Bean 方法调用的自定义类的名称。此类必须实现 weblogic.rmi.cluster.。有关详细信息,请参阅 WebLogic 群集 API。
|
|
weblogic-ejb-jar.xml 中的 stateless-bean-call-router-class-name 可以指定用于路由无状态会话 Bean 方法调用的自定义类的名称。此类必须实现 weblogic.rmi.cluster.CallRouter()。有关详细信息,请参阅 WebLogic 群集 API。
|
|
WebLogic Server 群集中的不同服务提供了不同类型和水平的状态管理。此列表定义了四种类别的服务,这些类别是按照它们在内存中或持久性存储中维护状态的方式进行区分的:
表 10-3 概述了 J2EE 和 WebLogic 如何支持上述每种服务类别。
| 注意: | 在表 10-3 中,介绍了对下列两种类型客户端的无状态服务和对话服务支持: |
将可群集对象部署到群集,而不要部署到群集中的单个受管服务器。有关信息和建议,请参阅将应用程序部署到 WebLogic Server。
有关其他群集架构、负载平衡选项和安全选项的信息,请参阅群集体系结构。
有关服务器实例的命名以及它在群集中的地址的指南,请参阅标识名称和地址。
要启动参与群集的 WebLogic Server 实例,则每个受管服务器都必须能够连接到管理服务器(该管理服务器管理包含该群集的域的配置信息)。出于安全考虑,管理服务器必须与该 WebLogic Server 群集位于同一个 DMZ 中。
管理服务器可以维护参与该群集的所有服务器实例的配置信息。位于管理服务器中的 config.xml 文件包含了管理服务器所在域中的所有群集服务器或非群集服务器的配置数据。请不要为群集中的每台服务器创建各自的配置文件。
要启动群集的 WebLogic Server 实例,管理服务器必须是可用的。但是请注意,一旦开始运行群集,管理服务器的故障就不会影响正在进行的群集操作了。
管理服务器不应参与群集。管理服务器应该专门用于服务器的管理过程:维护配置数据、启动和关闭服务器,以及部署和取消部署应用程序。如果管理服务器也处理客户端请求,则有延迟完成管理任务的风险。
让管理服务器参与群集没有任何益处;管理对象既不可以群集化,也不可以在管理服务器出现故障时向另一个群集成员进行故障转移。在管理服务器上部署应用程序可能会降低服务器的稳定性,而且会减少它提供的管理功能。如果您在管理服务器上部署的应用程序的行为不正常,则可能会中断该管理服务器的操作。
基于上述原因,请确保管理服务器的 IP 地址不包括在群集范围的 DNS 名称中。
如果您的配置包括防火墙,则请将 DMZ 中的代理服务器或负载平衡器、群集、Web 和 EJB 容器都放在防火墙的后面。建议不要将 Web 容器放在 DMZ 中。请参阅代理体系结构的基本防火墙。
如果将防火墙放在多层架构中的 Servlet 群集和对象群集之间,则要将该对象群集中的所有服务器绑定到公共 DNS 名称,而不要绑定到 IP 地址。将这些服务器与 IP 地址进行绑定可能会导致出现地址转换问题,使得 Servlet 群集无法访问单个服务器实例。
如果 WebLogic Server 实例的内部和外部 DNS 名称不同,则请使用该服务器实例的 ExternalDNSName 特性来定义该服务器的外部 DNS 名称。在防火墙之外,ExternalDNSName 应转换为服务器的外部 IP 地址。在管理控制台中使用“服务器”->“配置”->“常规”选项卡设置此特性。请参阅管理控制台联机帮助中的“服务器”->“配置”->“常规”。
在使用一个或多个防火墙的任何群集架构中,很重要的一点是要使用公共可用的 DNS 名称来标识所有 WebLogic Server 实例,而不是使用 IP 地址进行标识。使用 DNS 名称可以避免出现与用于保护内部 IP 地址不会受到不可信客户端访问的地址转换策略相关的问题。
| 注意: | 对于防火墙要执行网络地址转换的配置,必须使用 ExternalDNSName,除非客户端要使用 t3 和默认通道访问 WebLogic Server。例如,对于防火墙要执行网络地址转换且客户端通过代理插件使用 HTTP 访问 WebLogic Server 时,必须使用 ExternalDNSName 。 |
下图说明了使用 IP 地址标识 WebLogic Server 实例时可能会出现的问题。在此图中,防火墙会将子网“xxx”的外部 IP 请求转换为具有子网“yyy”的内部 IP 地址。

如果外部 IP 地址和内部 IP 地址之间没有转换,防火墙在上述场景下不会对客户端带来任何问题。但是,大多数安全策略都涉及隐藏(和拒绝访问)的内部 IP 地址。
群集的架构会影响系统的容量。在部署生产使用的应用程序之前,要对性能进行评估以确定您是否需要添加以及在何处添加服务器或服务器硬件来支持实际的客户端负载。您可以通过像 Mercury Interactive 公司的 LoadRunner 等测试软件来模拟较高的客户端使用量。
|