负载均衡与集群.docx
《负载均衡与集群.docx》由会员分享，可在线阅读，更多相关《负载均衡与集群.docx（12页珍藏版）》请在冰豆网上搜索。
负载均衡与集群
负载均衡与集群
一：
软件集群
1：
WebLogic集群
首先要对Weblogic的内部有一个大概的了解，什么是Domain，Server，Machine，Cluster。
Domain
Domain是WebLogicServer实例的基本管理单元。
所谓Domain就是，由配置为AdminServer的WebLogicServer实例管理的逻辑单元，这个单元是有所有相关资源的集合。
Server
Server是一个相对独立的，为实现某些特定功能而结合在一起的单元。
Machine
Machine是可以对应到服务器所在的物理硬件,可以是Unix或non-Unix类型，可以用来远程管理和监控，用于加强failover管理。
Cluster
Cluster也是一个逻辑概念，用来分组用途相同的服务器实例，一个域中可以有多个集群。
集群用来实现负载均衡和容错。
DomainandServer的关系
一个Domain可以包含一个或多个WebLogicServer实例，甚至是Server集群。
一个Domain中有一个且只能有一个Server担任管理Server的功能，其它的Server具体实现一个
特定的逻辑功能。
配置集群应用的必要条件
a）集群中的所有Server必须位于同一网段，并且必须是IP广播（UDP）可到达的b）集群中的所有Server必须使用相同的版本,包括ServicePack
c）集群中的Server必须使用永久的静态IP地址。
动态IP地址分配不能用于集群环境。
如
果服务器位于防火墙后面，而客户机位于防火墙外面，那么服务器必须有公共的静态IP地址，只有这样，客户端才能访问服务器
d）要以CLUSTER方式运行，必须有包含CLUSTER许可的LICENSE才行（从Oracle网
站上下载的最新版本已经包含了此许可，可进行Cluster配置）
1.1WebLogic单机集群1.1.1简介
单机集群这种架构将所有的Web应用以及相关的服务应用全部置于集群中的单一WLS（WebLogicServer）实例中，这种架构的优势在于：
易于管理
灵活的负载平衡机制更强的安全控制
1.1.2配置安装WebLogic11g（10.3.2）
在实施集群之前都必须有个规划，比如以下例子：
上述具体的安装方法见手册：
MicrosoftWord文档WebLogic集群安装.docx单服务器版本。
安装部署的时候我们把应用程序（lnwl.war）安装到集群中的所有机器中而不是AdminServer。
AdminServer只用于集群的管理，而不能参与集群事务。
文件的同步是由WebLogic来完成的。
实际上应用程序就是被部署到三个受管理服务器中。
这样我们访问代理服务器,代理服务器会根据情况把访问分发到三个受管理服务器中，实际上真正访问的是7002,7003,7004这三个端口的服务。
1.1.3集群并发测试
在这里我们将通过Apache中所带的ab包（只需要单个文件ab.exe即可）来进行并发访问的模拟测试，使用如下的命令就可以完成压力测试。
ab.exe-n100-c10http:
//192.168.2.106:
8080/lnwl/test.jsp
pause
ab是测试程序的名称
参数n代表请求的总数量
参数c代表并发的请求数
url为要测试压力的页面
1.1.4Session共享问题解决
当集群中的机器需要共享session时则编辑weblogic.xml配置文件放到WEB应用程序的WEB-INF目录下即可。
WebLogic.xml：
（只针对10.3.2版本）
1.2WebLogic多机集群
1.2.1配置安装WebLogic11g（10.3.2）
目标：
建立如下多机版集群：
MicrosoftWord
文档
上述具体的安装方法见手册：
WebLogic集群安装.docx多服务器版本。
1.2.2启动服务器
配置完之后我们就启动服务器并部署应用程序，如下图所示：
部署成功之后：
这样我们访问http:
//192.168.106:
8080就可以看到分发效果。
1.3WebLoigc整合Apache实现负载均衡
Weblogic整合Apache非常简单，分为两步。
1：
安装weblogicmodule扩展模块
在D:
\Oracle\Middleware\wlserver_10.3\server\plugin目录下可以根据操作系统找到对应的版本，本文需要的是mod_wl_22.so，
D:
\Oracle\Middleware\wlserver_10.3\server\plugin\win\32，将mod_wl_22.so放置Apache安装目录的modules文件夹下，如d:
\Apache2.2\modules。
2．配置ApacheHttpServer
打开Apache安装目录下\conf\下的httpd.conf文件，找到Listen配置，默认的是Listen80，将端口80改成8080（和WeblogicProxyServer保持一致，非必须）；
在httpd.conf文件的最后加入一段配置如下：
Apache首先加载weblogic的负载均衡模块。
WebLogicCluster后面就是要分发的真实服务器地址。
MatchExpression是拦截的后缀。
这样我们访问http:
//192.168.106:
8080就可以看到分发效果。
2：
Tomcat集群
部署多个Tomcat服务器，用Apache分发请求。
二：
硬件集群
硬件集群主要功能是分发http请求,它在性能上要高于软件的代理功能，但是不如软件负载灵活。
三：
负载均衡
1：
负载均衡算法
平均算法，基于权重算法，循环算法，随机算法。
2：
Apache分发
2.1Apache简介
Apache是一款高性能的HTTP服务器，同时也具备很强的扩展能力，比如分发和反向代理。
所谓的整合就是让apache替换Weblogic的ProxyServer功能。
Apache的分发功能配置简单，功能强大，灵活，可以通过算法来控制分发方式。
Apache有2中分配方式：
a:
平均分配
b:
按权重分配。
按权重分配方法就是给BalancerMember加上loadfactor参数即可，取值范围为1-100，如
下所示:
默认情况下，负载均衡会尽量让各个服务器接受的请求次数满足预设的比例。
如果要改变算法，可以使用lbmethod属性。
如：
lbmethod可能的取值有：
3：
niginx反向代理
高性能的分发和代理服务器
4：
HAproxy
高性能的分发器
四：
分布式服务器中缓存的管理
1：
简介
在分布式系统中，缓存管理是一个比较复杂的东西。
涉及到缓存读写，同步，并发等一系列操作。
实际的系统中，以下几类数据适合放在缓存中：
1：
很少被修改的数据
2：
不是很重要的数据，偶尔允许并发问题
3：
不会被并发访问的数据
4：
参考数据
2：
缓存管理的实现
2.1：
自己实现一个缓存管理器
定义一个缓存接口，包括缓存的写入，读取，更新，保存到磁盘，同步等，并考虑并发与事务。
具体的缓存管理器的设计有待全面考量。
2.2：
实现hibernate的二级缓存
如果不想直接实现一个在分布式环境中的缓存管理器。
那么我们可以用hibernat的二级缓存。
Hibernate的二级缓存分为为事物范围和进程范围。
缓存中的数据被复制到集群环境中的每个进程节点，通常采用对象的散装数据形式保存。
Hibernate的二级缓存的实现要借住第三方的组件：
首选的有EHCache和JbossCache。
1：
EHCache是一个使用比较广泛的，但更适用于单机版。
2：
JbossCache是集群范围的缓存，支持事务并发策略，可查询缓存，适用于多机版
二者都是通过配置文件来集成到hibernate中，具体的实现方式详见文档：
hibernate二级缓存的实现.docx。
五：
工程评审平台集群的实现
1.平台性能的分析
评审平台一直给人有一种慢的感觉，但一直没有具体去分析是哪使得它慢，都把矛头指向了数据库，电子化评审平台自身的代码的设计，不可否认这两项指标直接影响着性能，但是还有其他的性能指标。
比如一个HTTP请求，包括网页的所有元素：
图片，JS，CSS等。
一：
在portal中访问电子化评审和直接访问电子化评审。
首先选取几类网页作为测试样本，分别为不带查询数据库的页面，查询少量数据的页面，查询大量数据的页面。
A:
不带查询数据库的页面,导入评审计划。
我们看到在portal中请求该页面所花的时间为1.75s。
这个时间包括请求portal自身的页面元素和导入计划页面。
以上是portal请求自身js所花的时间，也就是YUI框架的js，所花的时间都比较长。
以上是请求导入计划的页面所花的时间，比较少，这里不包括一些导入计划的其他页面。
我们单独请求导入计划页面看看所耗时间：
这里所花的时间为1s。
时间为在portal中的近1/2
我们第二次请求这个页面看看效果：
还是1.72s。
也就是说性能没有改进，还是再一次请求的poral的js，css以及图片，这些元素没有在浏览器端缓存下来。
B:
请求查询少量数据的页面
评审计划查询页面
所花时间为1.69s.
单独访问评审计划查询页面如下：
所花时间为801ms，时间为在portal中的1/2
C:
访问查询数据比较多的页面
资料预审页面
所花时间为1.36s。
单独访问该页面效果如下：
所花时间为990ms。
本次测试所花时间都比较少，是因为服务器比较好，访问的人很少。
但我们也看出了一些问题，就是在portal那块，前端的（JS，css）未做任何的优化，而portal又大量使用了YUI的JS来实现一些放大，缩小等效果。
总结一下，我们可以看看一下
二：
分析电子化评审模块的性能
访问其中的一个页面：
我们看看具体每个请求所花的时间:
这些是所花时间比较多的请求，后台代码花的时间最多为78ms，然后就是richfaces所花的时间。
2.解决方案：
在portal中优化前端元素。
在子系统中主要是优化78ms这块。
因为一些原因，我们在系统中都未开启hibernate的一级缓存。
这部分可以优化，然后就是引入hibernate的二级缓存。
降低应用程序访问数据库的频率。
然后就是加集群。
相信在这些的优化之后，性能肯定有所提升
升级会员 