Weblogic 中文文档——第二章 理解Weblogic Server域

本文详细介绍了WebLogic Server中的域概念,包括域的组成、管理服务器与托管服务器的作用,以及如何通过集群提高应用的可伸缩性和可用性。此外,还探讨了域的设计考虑因素和约束条件。
      
以下章节介绍Weblogic Server域和域的内容:

域是什么

组织域

域的内容

域约束



域是什么?

一个Weblogic Server管理域是逻辑上相关的Weblogic Server资源组。域包括一个特殊的Weblogic Server实例,叫做管理服务器(Administration Server),这是你配置和管理域的所有资源的关键。通常,你配置的一个域会加入另外的WebLogic Server实例,叫作托管服务器(Managed Server)。你的Web应用、EJB和其他资源会部署在托管服务器上,而管理服务器只是用于配置和管理。



多个托管服务器可以组织成集群(clusters),这使你能够保持负载平衡和对于临界的应用提供失败保护,同时只使用一个管理服务器会使托管服务器实例的管理变得简单。



组织域



如何将WebLogic Server装置组织成域,这取决于你的业务需求。你可以基于系统管理员职责、应用边界或者server运行的地理位置的不同定义多个域。与之相反,你也可以决定将所有WebLogic Server管理行为集中于一个域。



根据你特定的业务需求和系统管理实际,你可以按照如下标准决定如何组织你的域:



应用的逻辑区分。比如,你可以有一个域用于类似购物车的终端用户功能,另一个域用于后台记账。

物理位置。你可以为业务的不同地理位置和分支分别建域。

大小。你会发现域被组织成更小的单元可能会使不同的系统管理员管理效率更高。反之,你也会发现维护单个域或者少量的域,配置更容易保持一致。



一个域由一个管理服务器和一个或多个托管服务器组成,也可以只由单个孤立的server组成,既扮演管理服务器的角色又驻留应用。



由分散的托管服务器组成的域:简单的产品环境由几个驻留应用的托管服务器,一个执行管理操作的管理服务器组成。在这种配置下,应用和资源部署在各自的托管服务器中;类似地,访问应用的客户端与各自的托管服务器连接。



如果产品环境对增强应用性能、吞吐量或者可用性有要求,那么应该将两个或者更多的托管服务器配置成集群。机群允许多个托管服务器作为单个个体驻留应用和资源。关于在孤立的和集群托管服务器之间差异的更多信息,参见“托管服务器和托管服务器集群”。

孤立的server域:对于开发或测试环境而言,你可能想在部署单个应用和server独立于产品域中的server。这种情况下,你可以部署一个简单域,只由单个server实例组成,既作为管理服务器,又驻留你开发的应用。你用WebLogic Server安装的wl_server域就是一个孤立server域的例子。

注意:在产品环境中,BEA建议你只在域中的托管服务器部署应用,管理服务器应当只负责管理任务。



域的内容



尽管域的范围与目的会有很大差异,但是大多数 WebLogic Server域都包含本章节中描述的组件。



下图展示了产品环境,包括一个管理服务器,三个孤立的托管服务器和三个托管服务器组成的集群。

 

管理服务器

每个Weblogic Server域都必须有一个server实例作为管理服务器。你使用管理服务器(编程或者通过管理服务器)来配置域中的所有其他server实例和资源。



管理服务器的角色



在启动域的托管服务器之前,应先启动管理服务器。当你启动一个孤立或集群托管服务器时,它会按配置信息与管理服务器相联。这种方式下,管理服务器在整个域配置中充当核心控制体。



当管理服务器启动时,加载域的config.xml文件,除非你在创建域时指定另一个目录存储config.xml。



BEA_HOME/user_projects/domains/mydomain/config



这里mydomain是特定域的目录,名称与域相同。config.xml引用的其他配置文件,位于域的config目录的子目录下。



管理服务器每一次成功启动后,将在域目录中创建一份命名为config-booted.jar的备份配置文件。万一配置文件在server实例生命周期内有损坏,有可能恢复原先的配置。



如果管理服务器出错会发生什么?



域的管理服务器出错不会影响域中的托管服务器的操作。如果域的管理服务器变得不可用,而它所管理的server实例——集群或者其他方式——仍在运行,那么那些托管服务器将继续运行。如果该域包含集群server实例,那么由域配置支持的负载平衡和失败性能保持可用,即使管理服务器出错。如果域的管理服务器停止运行而托管服务器继续运行,那么每一个托管服务器会周期性地尝试重新连接管理服务器,周期由ServerMBean属性AdminReconnectIntervalSecs指定。AdminReconnectIntervalSecs默认为10秒。



如果管理服务器因为主机的硬件或软件错误而失败,同一台机器的其它server实例都可能受到同样的影响。然而,管理服务器自身的失败不会中断域的托管服务器的运行。而且即使管理服务器不在运行状态,你也可以启动托管服务器。这种情况下,托管服务器使用配置文件的本地拷贝来作为它的启动配置,然后周期性地向管理服务器作连接尝试,连接后利用管理服务器来同步配置状态。



对于重启管理服务器的指令,参见“管理服务器启动与关闭”。





托管服务器和托管服务器集群



在域中,非管理服务器的server实例,指向托管服务器。托管服务器驻留构成你应用的组件和相关资源,比如JSP和EJB。当某个托管服务器启动后,它会连接域的管理服务器来获得配置和部署设置。



注意:即使管理服务器不可用,域中的托管服务器也可以独立于管理服务器启动。更多信息参见“管理server启动与关闭”中的“避免server失败与恢复”。

两个或更多的托管服务器可以配置成一个WebLogic Server集群,来增加应用的可伸缩性与可用性。在WebLogic Server集群中,大多数资源与服务平均部署给每一个托管服务器(与单个托管服务器相反),来使失败与负载平衡。要想了解哪种组件类型和服务可以进行集群(部署给集群中的所有server实例),参见“使用WebLogic Server集群”中的“理解WebLogic Server集群”。

你可以创建一个非集群的托管服务器,然后通过配置有关server实例和集群的参数将其加入集群。你也可以通过重新配置参数从集群中删除某个托管服务器。在集群与非集群托管服务器之间的根本区别在于对失败和负载平衡的支持。这些特性仅在集群托管服务器中可用。

你对于可伸缩性与可靠性的要求将决定你是否采用集群托管服务器。比如,如果你的应用不常遇到易变的加载,应用服务中可能的中断也是可以接受的,那么就没有必要采用集群。

关于WebLogic Server集群的好处与性能的更多信息,参见“使用WebLogic Server集群”中的“理解WebLogic Server集群”。单个域可以包含多个WebLogic Server集群,同样多个托管服务器也可以不被配置成集群。



资源与服务



除了管理服务器和托管服务器之外,域还包括托管服务器所需的资源和服务及部署在该域上的应用。



域配置包括域运行的网络计算机环境信息,比如:

Machine definitions identify a particular, physical piece of hardware. A machine definition is used to associate a computer with the Managed Servers it hosts. This information is used by Node Manager in restarting a failed Managed Server, and by a clustered Managed Server in selecting the best location for storing replicated session data. For more information about Node Manager, see Using Node Manager to Control Servers in Designing and Configuring WebLogic Server Environments.

网络通道,一个可以用来定义默认端口、协议和协议设置的可选资源。在创建一个网络通道后,可以将它分配给域中任意一个托管服务器和集群。更多信息,参见“设计与配置WebLogic Server环境”中的“配置网络资源”。

域配置还包括与驻留在域中应用相关的资源和服务信息。这些资源和服务的例子包括:

应用组件,比如EJB

连接器

JDBC连接池

JMS server

启动类

资源和服务可能被限制于域中一个或多个托管服务器,而不是对于整个域可用。你可以选择托管服务器或者集群进行部署资源与服务。



域约束



WebLogic Server环境可以由单个域组成,包括驻留应用所需的所有托管服务器,也可以是多个域。你可以选择创建多个域,根据组织单元、系统管理员职责、应用边界或者其它要考虑的事项来划分。在设计域配置时,注意以下约束:



每一个域都需要自身的管理服务器执行管理操作。当你使用管理控制台执行管理和监控任务时,你可以在域中来回切换,同时你会连接不同的管理服务器。

同一个集群中的所有托管服务器必须位于相同的域,你不能将集群拆分至多个域。

同一个域中的所有托管服务器运行的WebLogic Server软件版本必须相同。域中的管理服务器可以和托管服务器运行相同的版本,也可以是更新的版本。

你不能在域中共享配置资源与子系统。比如,如果你在一个域中创建了一个JDBC连接池,你就不可能在另一个域中的托管服务器或集群中使用。代之,你必须在第二个域中创建一个类似的连接池。
标题基于Python的汽车之家网站舆情分析系统研究AI更换标题第1章引言阐述汽车之家网站舆情分析的研究背景、意义、国内外研究现状、论文方法及创新点。1.1研究背景与意义说明汽车之家网站舆情分析对汽车行业及消费者的重要性。1.2国内外研究现状概述国内外在汽车舆情分析领域的研究进展与成果。1.3论文方法及创新点介绍本文采用的研究方法及相较于前人的创新之处。第2章相关理论总结和评述舆情分析、Python编程及网络爬虫相关理论。2.1舆情分析理论阐述舆情分析的基本概念、流程及关键技术。2.2Python编程基础介绍Python语言特点及其在数据分析中的应用。2.3网络爬虫技术说明网络爬虫的原理及在舆情数据收集中的应用。第3章系统设计详细描述基于Python的汽车之家网站舆情分析系统的设计方案。3.1系统架构设计给出系统的整体架构,包括数据收集、处理、分析及展示模块。3.2数据收集模块设计介绍如何利用网络爬虫技术收集汽车之家网站的舆情数据。3.3数据处理与分析模块设计阐述数据处理流程及舆情分析算法的选择与实现。第4章系统实现与测试介绍系统的实现过程及测试方法,确保系统稳定可靠。4.1系统实现环境列出系统实现所需的软件、硬件环境及开发工具。4.2系统实现过程详细描述系统各模块的实现步骤及代码实现细节。4.3系统测试方法介绍系统测试的方法、测试用例及测试结果分析。第5章研究结果与分析呈现系统运行结果,分析舆情数据,提出见解。5.1舆情数据可视化展示通过图表等形式展示舆情数据的分布、趋势等特征。5.2舆情分析结果解读对舆情分析结果进行解读,提出对汽车行业的见解。5.3对比方法分析将本系统与其他舆情分析系统进行对比,分析优劣。第6章结论与展望总结研究成果,提出未来研究方向。6.1研究结论概括本文的主要研究成果及对汽车之家网站舆情分析的贡献。6.2展望指出系统存在的不足及未来改进方向,展望舆情
【磁场】扩展卡尔曼滤波器用于利用高斯过程回归进行磁场SLAM研究(Matlab代码实现)内容概要:本文介绍了利用扩展卡尔曼滤波器(EKF)结合高斯过程回归(GPR)进行磁场辅助的SLAM(同步定位与地图构建)研究,并提供了完整的Matlab代码实现。该方法通过高斯过程回归对磁场空间进行建模,有效捕捉磁场分布的非线性特征,同时利用扩展卡尔曼滤波器融合传感器数据,实现移动机器人在复杂环境中的精确定位与地图构建。研究重点在于提升室内等无GPS环境下定位系统的精度与鲁棒性,尤其适用于磁场特征明显的场景。文中详细阐述了算法原理、数学模型构建、状态估计流程及仿真实验设计。; 适合人群:具备一定Matlab编程基础,熟悉机器人感知、导航或状态估计相关理论的研究生、科研人员及从事SLAM算法开发的工程师。; 使用场景及目标:①应用于室内机器人、AGV等在缺乏GPS信号环境下的高精度定位与地图构建;②为磁场SLAM系统的设计与优化提供算法参考和技术验证平台;③帮助研究人员深入理解EKF与GPR在非线性系统中的融合机制及实际应用方法。; 阅读建议:建议读者结合Matlab代码逐模块分析算法实现细节,重点关注高斯过程回归的训练与预测过程以及EKF的状态更新逻辑,可通过替换实际磁场数据进行实验验证,进一步拓展至多源传感器融合场景。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值