JBOSS是一个企业级的J2EE APP Container,所以它和任何一种成熟的企业级中间件同样具备Thread Group的概念。
所谓Thread Group就是一个HTTP队列机制,利用Thread Group在JBOSS内能够设置如“阻断”,“升级”,“降级”等机制。
来看一个这样的实际应用场景:
当你的JBOSS连着一堆核心应用时,此时忽然你的HTTP的并发请求在某一个点激增,若是把这些HTTP请求都放进后台,那么将意味着你全部的核心模块将会受到严重的影响,所以通常来讲对于这样的场景咱们会采起以下的几种措施:javascript
在JBOSS里使用的正是Thread Group来支持这几种机制的,咱们来看一下这几种机制在JBOSS中的实现:css
作过开发的相信一眼就看出来,其实这6种JBOSS提供的HTTP Thread Group正是JAVA多线程内ConcurrentThreadPool的线程种类。
本文对6种线程不作一一探讨,他们的区别从字面上相信读者能够立刻理解,在配置时参数略有不一样,对于每一个不一样种类的Thread Group读者能够自行经过JBOSS官方文档(以下URL)获取它们的区别:
https://developer.jboss.org/wiki/ThreadPoolConfiguration
本文只做JBOSS EAP6中如何进行Thread Group的配置。html
打开$JBOSS_HOME/standalone/configuration/standalone.xml文件
找到<subsystem xmlns=”urn:jboss:domain:threads:1.1“>这句,把它改为:前端
找到<subsystem xmlns=”urn:jboss:domain:web:2.2“ default-virtual-server=”default-host“ native=”false“>这句,再往下找到:
<connector name=“http” protocol=“HTTP/1.1”这一句,把这一句改为:java
重启JBOSS便可node
为何要加密? 咱们来看下面这个例子:mysql
虽然,你能够说这个配置文件是位于企业内网的,内网就安全了?万一有有心人。。。由于安全的宗旨是“宁肯信其有(小偷),不可信其无”。
所以通常来讲在生产环境咱们是须要对这个配置文件中的敏感信息进行加密的。
JBOSS对配置文件中的加密有两种方式:
1. Picketbox(推荐所有用这种方式)
2. Vault(不适合于DOMAIN模式、很繁琐)nginx
确保你使用的是JBOSS EAP6.2-6.4或者更高版本,在Linux中启动一个shell,敲入以下命令行:git
此处的”EncryptedPassword”就是咱们须要加密的“明文”,接下去它会输出如:
Encoded password: -6e9c0a6a3bb1e4c0
这边的“Encoded password:”后的就是被加密后的密文
而后,咱们须要创建一个Security-Domain,咱们在<profile name=“full”>段下找到
<subsystem xmlns="urn:jboss:domain:security:1.2">
<security-domains>
因为咱们用的是domain模式启动的jboss,所以,你不能找到一个”security-domains”就去改,由于domain模式是根据profile name来区分配置段的,若是你的security-domain加在default下,而启动使用的是full模式那么你的配置是无效的。
咱们在
<subsystem xmlns="urn:jboss:domain:security:1.2">
<security-domains>
段下加入
web
有了security-domain咱们就能够在咱们的配置中应用它了,如咱们在datasource配置处使用security-domain
使用vault模式要求咱们先须要在JBOSS中创建本身的VAULT,咱们使用以下命令:
出现以下字符界面:
JBoss Vault
JBOSS_HOME: /Volumes/Disk01/appservers/center/jboss-eap-6.1
JAVA: java
============================================================
**********************************
**** JBoss Vault ***************
**********************************
Please enter a Digit::
0: Start Interactive Session 1: Remove Interactive Session 2: Exit
按选0
Enter directory to store encrypted files:[输入] ../vault/
Enter Keystore URL:[输入] ../vault/ymkeyes.keystore
Enter Keystore password: [输入]aaaaaa
Enter Keystore password again: [输入]aaaaaa
Enter 8 character salt: [输入]12345678
Enter iteration count as a number (Eg: 44): [输入]44
Enter Keystore Alias: [输入] ymkeyes
Initializing Vault
2013-7-18 11:08:02 org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Vault Configuration in AS7 config file:
********************************************
</extensions>
<vault>
<vault-option name="KEYSTORE_URL" value="../vault/ymkeyes.keystore"/>
<vault-option name="KEYSTORE_PASSWORD" value="MASK-1TWrTaqRsEC"/>
<vault-option name="KEYSTORE_ALIAS" value="ymkeyes"/>
<vault-option name="SALT" value="11136231"/>
<vault-option name="ITERATION_COUNT" value="8"/>
<vault-option name="ENC_FILE_DIR" value="../vault/"/>
</vault> ...
********************************************
Vault is initialized and ready for use
Handshake with Vault complete
Please enter a Digit::
0: Store a secured attribute 1: Check whether a secured attribute exists 2: Exit
按选0
把上面从<vault>开始到</valult>这一块复制进standalone.xml文件中,放于</extensions>段后
对于屏幕中输出的以下信息,注意红色加粗字体便是你用vault加密后的加密串。
Secured attribute value has been stored in vault.
Please make note of the following:
********************************************
Vault Block:ds_MegaeyesDS
Attribute Name:password
Shared Key:MjY5Nzc0OWItMmI2OS00NWMyLTlkZTYtOWY0MWE5YzAyOGMwTElORV9CUkVBS21lZ2FleWVz
Configuration should be done as follows:
VAULT::ds_oracleds::password::MjY5Nzc0OWItMmI2OS00NWMyLTlkZTYtOWY0MWE5YzAyOGMwTElORV9CUkVBS21lZ2FleWVz
********************************************
有了VAULT,你就能够在你的配置文件中如咱们在<datasource>中,以下配置:
注意加密串还要先后加上${加密串}才可生效
能够看出,使用这种方式的加密,太繁琐,并且它不支持DOMAIN模式即不可以使用在集群环境中。
啊。。。集群,又是集群。
JBOSS集群是从3.X开始那差很少是在14年前就开始支持集群了。
目前的JBOSS EAP6.2-6.4或者是JBOSS8.0(WILDFLY)对于集群的支持已经到了登峰造极的地步了,并且最主要的是JBOSS的集群具备如下特点:
试想一下这种架构:
若是在这个架构中任何一个SLAVE发生了宕机,那么对于整个集群来讲用户的访问是依旧能够用的。
可是,咱们试想一下,若是JBOSS MASTER都宕机了呢?
因而,咱们有了以下的架构:
这样,在任意一点发生不可预料的宕机时,咱们的整个集群的服务仍是持续可用的只要不是全部的节点都宕掉。
所谓横向、纵向
JBOSS能够纵横交错,任意划分出无数台“JBOSS虚拟机”从而构成一个“网状”结构
因为JBOSS采用了相似于IBM WAS的域控理念,所以它能够作到“集中统一布署”,即只要在主控端发布一个程序,该主控端下属全部的MASTER、SLAVER所有会自动布署。而这个自动化“分发”的过程,是不须要人为干涉的。它意味着咱们的运维开发不须要一个个手工COPY war包到每一个J2EE APP SERVER上去了。
JBOSS也引入了时下最时髦的“VM”技术,即你能够启动一个JBOSS Instance,而后在这个JBOSS的Instance中为每个不一样的JBOSS子Container指定它们的参数、甚至JVM核心参数
说了这么多,咱们就来搭建一个JBOSS集群吧!
先来规划咱们的JBOSS集群,在咱们的例子中咱们不使用JBOSS虚拟机,咱们使用2个真正的JBOSS Instance即启动两个不一样JVM进程的JBOSS来实现MASTER-SLAVER的模式。
咱们先来规划咱们的JBOSS集群。
咱们创建两个JBOSS实例,使其分别名为:
JBOSS_MASTER1
JBOSS_SLAVE1
JBOSS集群必定用的是DOMAIN模式来去运行的,即$JBOSS_HOME/bin/domain.sh来运行的,所以咱们记得把两个JBOSS的$JBOSS_HOME/domain/configuration/host.xml文件中的下面这段:
以上配置中的9999与9990确保两个JBOSS Instance中的这两个端口必定不能同样,如个人slave中的此处配置为:
你也能够把slave中的host.xml文件COPY一份而后使用host-slave.xml更名成host.xml文件
MASTER和SLAVE的host.xml文件的区别还有一点,来看SLAVE的host.xml文件下面这一处:
从这边能够看到slave中有一个<domain-controller>段,在这个段内所指向的 ManagementRealm的IP与端口必须是它的master即Master主机中host.xml文件中的ManagementReal所设的IP与PORT。
注意host.xml文件中的头部信息
不要忘了把<host后加入一个”name”,这边的name很重要!!!
JBOSS集群有一个很重要的步骤,即:
加入每一个MASTER的SLAVE,是以JBOSS中的用户名和密码来“认证”的,即每一个SLAVE要加入Master,Master必须容许。
所以,此处的host name=“”就是SLAVE 用户名,那么密码呢?
请在JBOSS MASTER所在的目录中运行add-user.sh命令,而后建一个用户名,这个用户名必须=host后的name,另外,在建完用户后把该用户的密码(显示为MD5值)记下,而后在slave所在的host.xml文件中把密码设进去,按照以下例子:
由于JBOSS是以GROUP的概念来管理它的集群的,以下图:
因此咱们须要把咱们的8080与8081这两台主机加入到一个GROUP中去。
在slave的host.xml文件中增长入下内容
这边几个地方须要注意的:
相应的,在master机上的host.xml文件中也须要有这么一句:
配置domain.xml文件,你能够把slave上的domain.xml备份一下,而后把domain-slave.xml文件更名成domain.xml文件来做修改(若是你不是一个熟手的话),事实上JBOSS对于domain.xml和host.xml文件分别提供了master, slave模式供你使用,若是你改坏了,你也能够经过JBOSS对修改过保存过的配置文件自动进行备份和版本控制这个功能来回退。
其实domain.xml文件中主要的是对JBOSS“资源”的配置,如:
datasource,system properties, jvm。
因为JBOSS使用的是Domain Controller模式,所以对于JBOSS中一切资源的使用只须要在Controller上配置便可。
你能够把JBOSS的controller相像成一个“狮子座”,它的占有欲极强。
因为在本例中咱们使用的是一台MASTER,一台SLAVE,所以这台MASTER又同时是CONTROLLER,固然在机器富足的状况下你也能够考虑CONTROLLER挂一台MASTER,而后MASTER下再挂一台或者是多台SLAVE。
此处还须要注意的是domain.xml文件很长,它里面有这样的开头:
而这样的profile会有3处重复,所不一样的是profile name=“full”, profile name=“full ha”,所以你的<server group>设的是什么profile,你的须要设置的资源也须要在domain.xml文件中放在哪一个profile段。 此例中咱们使用的是full,所以咱们的DataSource, System Properties等就都放在了这个段里。
咱们以前在MASTER和SLAVE的host.xml文件中分别把2台主机都加入到了一个叫kie-server-group的段,所以咱们须要在domain.xml文件中加入一个server group的声明段,以下示例:
此处须要注意的是,若是使用domain模式启动,各group中的jboss实例虽然都各自使用domain.sh命令启动,而且你在domain.sh所调用的环境配置命令domain.conf中设置了如: -Xms6144m -Xmx6144m 这样的JVM参数,但其实你还须要在domain中划分出的不一样的jboss实例中再次做一下声明,为何?
由于JBOSS启动实例用的是domain.sh+domain.conf中JVM所设的JVM参数,而JBOSS真正运行起来后用于RUN相关的布署的应用用的倒是JBOSS内的“Domain JVM”,而你在domain.conf中设置的JVM参数只是给JBOSS启动时所使用的,并非这个JBOSS实例如:运行某个布署的.war包时所使用的真正的JVM,而一旦该JBOSS实例加入了某个group时,当这个实例开始布署或者是运行某个.war包或者是.ear包时,若是你没有设过domain jvm参数,那么它的实际可用JVM堆默认只有256MB。
这就是为何外面不少人说,JBOSS集群一旦启动,发觉原本在单节点运行的好好的web应用在集群环境下却会报out of memory或者是gc overhead limit。
让咱们在MASTER和SLAVE上的host.xml文件中为咱们的2个JBOSS实例配置虚拟JVM参数吧
Master上的host.xml文件中的设置
Slave上的host.xml文件中的设置
所有配完后分别使用:
/opt/jboss_master1/bin/domain.sh
/opt/jboss_slave1/bin/domain.sh
命令把master和slave启动起来吧。
启动后咱们打开主控端的WEB管理界面http://192.168.0.101:9990,能够看到以下网络拓扑结构。
其实,嘿嘿!
刚才那一段繁琐枯燥的配置,你也彻底能够把MASTER先启动起来后经过http://192.168.0.101:9990界面进入后可视化进行操做,看到这儿有人可能会想“打我”了,但是。。。若是你拿图形界面配过无数次后也能像我同样手配XML文件了,并且手配XML文件。。。速度更快!
布署一个应用,在这边我也想用xml文件来说解。。。但是又怕有人“打我”,可是在集群环境下的布署分为:
.war包
.war格式的目录(exploded war)
而JBOSS的自带的http://192.168.0.101:9990只支持图形化布署.war包。。。不支持布署.war格式的目录,所以咱们仍是用xml文件配置的方式来讲吧(大家最终反正是要把我打一顿的,?)
先来讲一下集群环境下的.war包的布署吧,咱们以petstore.war来举例,咱们把master-slave结构搭完后,直接按照以下步骤操做
JBOSS会把这个变成一个两进制文件并以GUID的方式重命名该文件,并把它置于MASTER的/domain/servers/master_name/data目录。
咱们注意这个$MASTER_JBOSS_HOME/domain/server目录,这下面还会有一个slave1的目录,这是JBSOS自动生成的,所以MASTER所挂集群下全部节点的日志、启动信息、布署都必须在此目录内寻找,而不是再手工跑到每一个JBOSS节点中去寻找了。这也正是JBOSS的domain controller集中管控思想的体现。
在此步骤,你只是把须要deploy的文件上传到了主控域上且并未开始布署,为了完成真正的布署,你须要点击【Assign】按钮
一旦你点击了Assign按钮后,你会获得一个弹出界面,在此界面内会提示你要把这个.war Assign给哪个group,此时,一旦当你把一个war Assign给了某个group并点击了【肯定】后,JBOSS会做以下的事情:
若是你的Controller下挂的节点是一颗很复杂的“树”,它也会一键完成全部节点的deploy。
布署完后,咱们来查看一下咱们的集群应用:
看,2个地址均可以访问了。
网上不少教程使用的都是Apache的mod_模块,至关的繁琐。
与Nginx相比Apache弱到爆了,咱们来看一下Nginx是怎么完成对jboss集群的分发的吧。
咱们来实验一下吧。
cd /usr/local/nginx
./nginx –c /usr/local/nginx.conf
启动后访问:http://192.168.0.101/petstore (此时不用加端口号了)
而后咱们在后台,随意杀掉master或者是slave进程
咱们来杀master进程吧
从新访问http://192.168.0.101/petstore, look,仍是跑得刚刚的!咱们的集群成功了。
这边咱们也不用做什么动静分离了,就让NGINX所有转发JBOSS的请求便可,由于你公司也不差这点内存、CPU,作什么动静分离。。。non sense!
所谓exploded war即“打碎了的war”,意思就是一个文件目录,它是以.war结尾的而且要符合war的目录结构标准。
要布署这样的文件目录形式其实很简单,你只要打开主控域上的domain.xml文件,在其中加入这样的语句,.war目录能够随便置放在何处, wherever u want:
而后回到http://ip:9990 这个图形化界面中就会看到在主控域上有一个.war已经被Deploy,但尚未被Assign,此时你只要作相应的Assign操做便可完成整个JBOSS集群的布署了。
Nginx须要依赖下面3个包
1. gzip 模块须要 zlib 库 ( 下载: http://www.zlib.net/ ) zlib-1.2.8.tar.gz
2. rewrite 模块须要 pcre 库 ( 下载: http://www.pcre.org/ ) pcre-8.21.tar.gz
3. ssl 功能须要 openssl 库 ( 下载: http://www.openssl.org/ ) openssl-1.0.1.tar.gz
注意:若是用源码安装的话,后面nginx安装的时候须要指定 --with-pcre 对应的压缩包路径
openssl:
pcre:
zlib:
经过 http://nginx.org/download/ 下载nginx最新版,本例中使用的是nginx-1.8.1.tar.gz,下载解压后进入nginx源码目录使用下面命令进行一键式编译安装:
所有成功后,在/usr/local目录下就会生成一个nginx目录,nginx就安装在此目录内了。