负载均衡与集群.docx

1、负载均衡与集群负载均衡与集群一：软件集群1：WebLogic集群首先要对Weblogic的内部有一个大概的了解，什么是 Domain，Server，Machine，Cluster。DomainDomain 是WebLogic Server 实例的基本管理单元。所谓Domain就是，由配置为 Admin Server 的WebLogic Server 实例管理的逻辑单元，这个单元是有所有相关资源 的集合。ServerServer 是一个相对独立的，为实现某些特定功能而结合在一起的单元。 MachineMachine 是可以对应到服务器所在的物理硬件,可以是Unix 或non-Unix 类 型，可

2、以用来远程管理和监控，用于加强fail over 管理。 ClusterCluster 也是一个逻辑概念，用来分组用途相同的服务器实例，一个域中可以有多个集 群。集群用来实现负载均衡和容错。Domain and Server 的关系一个Domain 可以包含一个或多个WebLogic Server 实例，甚至是Server 集群。一个 Domain 中有一个且只能有一个Server 担任管理Server 的功能，其它的Server 具体实现一个特定的逻辑功能。配置集群应用的必要条件a) 集群中的所有Server 必须位于同一网段，并且必须是IP 广播(UDP)可到达的 b) 集群中的所有Ser

3、ver 必须使用相同的版本,包括Service Packc) 集群中的Server 必须使用永久的静态IP 地址。动态IP 地址分配不能用于集群环境。如果服务器位于防火墙后面，而客户机位于防火墙外面，那么服务器必须有公共的静态IP 地址，只有这样，客户端才能访问服务器d) 要以CLUSTER 方式运行，必须有包含CLUSTER 许可的LICENSE 才行（从Oracle 网站上下载的最新版本已经包含了此许可，可进行Cluster 配置）1.1 WebLogic 单机集群 1.1.1 简介单机集群这种架构将所有的 Web 应用以及相关的服务应用全部置于集群中的单一WLS（WebLogic Ser

4、ver）实例中，这种架构的优势在于： 易于管理灵活的负载平衡机制 更强的安全控制1.1.2 配置安装 WebLogic 11g（10.3.2）在实施集群之前都必须有个规划，比如以下例子：上述具体的安装方法见手册：Microsoft Word 文档WebLogic集群安装.docx单服务器版本。安装部署的时候我们把应用程序(lnwl.war) 安装到集群中的所有机器中而不是Admin Server。Admin Server 只用于集群的管理，而不能参与集群事务。文件的同步是由WebLogic 来完成的。实际上应用程序就是被部署到三个受管理服务器中。这样我们访问代理服务器 ,代理服务器会根据情况把

5、访问分发到三个受管理服务器中，实际上真正访问的是7002,7003,7004这三个端口的服务。1.1.3 集群并发测试在这里我们将通过Apache 中所带的ab 包（只需要单个文件ab.exe 即可）来进行并发 访问的模拟测试，使用如下的命令就可以完成压力测试。ab.exe -n 100 -c 10 http:/192.168.2.106:8080/lnwl/test.jsppauseab 是测试程序的名称参数n 代表请求的总数量参数c 代表并发的请求数url 为要测试压力的页面1.1.4 Session 共享问题解决当集群中的机器需要共享session时则编辑 weblogic.xml 配置

6、文件放到WEB 应用程序的WEB-INF 目录下即可。WebLogic.xml ：（只针对10.3.2版本）1.2 WebLogic 多机集群1.2.1 配置安装 WebLogic 11g（10.3.2）目标：建立如下多机版集群：Microsoft Word文档上述具体的安装方法见手册：WebLogic集群安装.docx多服务器版本。1.2.2 启动服务器配置完之后我们就启动服务器并部署应用程序，如下图所示：部署成功之后：这样我们访问http:/192.168.106:8080就可以看到分发效果。1.3 WebLoigc整合Apache实现负载均衡Weblogic整合Apache 非常简单，分

7、为两步。1：安装weblogicmodule扩展模块在D:OracleMiddlewarewlserver_10.3serverplugin目录下可以根据操作系统找到对应的版本，本文需要的是mod_wl_22.so，D:OracleMiddlewarewlserver_10.3serverpluginwin32，将mod_wl_22.so放置Apache安装目录的modules文件夹下，如d: Apache2.2modules。2配置Apache Http Server打开Apache安装目录下conf下的httpd.conf文件，找到Listen配置，默认的是Listen 80，将端口80改

8、成8080（和Weblogic Proxy Server 保持一致，非必须）；在httpd.conf文件的最后加入一段配置如下：Apache首先加载weblogic的负载均衡模块。WebLogicCluster后面就是要分发的真实服务器地址。MatchExpression是拦截的后缀。这样我们访问http:/192.168.106:8080就可以看到分发效果。2：Tomcat 集群部署多个Tomcat服务器，用Apache分发请求。二：硬件集群硬件集群主要功能是分发http请求,它在性能上要高于软件的代理功能，但是不如软件负载灵活。三：负载均衡1：负载均衡算法平均算法，基于权重算法，循环算法，

9、随机算法。2：Apache 分发2.1 Apache简介Apache是一款高性能的HTTP服务器，同时也具备很强的扩展能力，比如分发和反向代理。所谓的整合就是让apache替换Weblogic的 Proxy Server功能。Apache的分发功能配置简单，功能强大，灵活，可以通过算法来控制分发方式。 Apache有2中分配方式：a: 平均分配b: 按权重分配。按权重分配方法就是给 BalancerMember 加上 loadfactor 参数即可，取值范围为1-100，如下所示:默认情况下，负载均衡会尽量让各个服务器接受的请求次数满足预设的比例。如果要改变算法，可以使用 lbmethod 属

10、性。如：lbmethod可能的取值有：3：niginx 反向代理高性能的分发和代理服务器4：HAproxy高性能的分发器四：分布式服务器中缓存的管理1：简介在分布式系统中，缓存管理是一个比较复杂的东西。涉及到缓存读写，同步，并发等一系列操作。实际的系统中，以下几类数据适合放在缓存中：1：很少被修改的数据2：不是很重要的数据，偶尔允许并发问题3：不会被并发访问的数据4：参考数据2：缓存管理的实现2.1：自己实现一个缓存管理器定义一个缓存接口，包括缓存的写入，读取，更新，保存到磁盘，同步等，并考虑并发与事务。具体的缓存管理器的设计有待全面考量。2.2：实现hibernate的二级缓存如果不想直接实

11、现一个在分布式环境中的缓存管理器。那么我们可以用hibernat的二级缓存。Hibernate的二级缓存分为为事物范围和进程范围。缓存中的数据被复制到集群环境中的每个进程节点，通常采用对象的散装数据形式保存。Hibernate的二级缓存的实现要借住第三方的组件：首选的有EHCache 和 JbossCache。 1：EHCache是一个使用比较广泛的，但更适用于单机版。2：JbossCache是集群范围的缓存，支持事务并发策略，可查询缓存，适用于多机版二者都是通过配置文件来集成到hibernate中，具体的实现方式详见文档：hibernate二级缓存的实现.docx。五：工程评审平台集群的实现

12、1.平台性能的分析评审平台一直给人有一种慢的感觉，但一直没有具体去分析是哪使得它慢，都把矛头指向了数据库，电子化评审平台自身的代码的设计，不可否认这两项指标直接影响着性能，但是还有其他的性能指标。比如一个HTTP请求，包括网页的所有元素：图片，JS，CSS等。一：在portal中访问电子化评审和直接访问电子化评审。首先选取几类网页作为测试样本，分别为不带查询数据库的页面，查询少量数据的页面，查询大量数据的页面。A: 不带查询数据库的页面,导入评审计划。我们看到在portal中请求该页面所花的时间为1.75s。这个时间包括请求portal自身的页面元素和导入计划页面。以上是portal请求自身j

13、s所花的时间，也就是YUI框架的js，所花的时间都比较长。以上是请求导入计划的页面所花的时间，比较少，这里不包括一些导入计划的其他页面。我们单独请求导入计划页面看看所耗时间：这里所花的时间为1s。时间为在portal中的近1/2我们第二次请求这个页面看看效果：还是1.72s。也就是说性能没有改进，还是再一次请求的poral的js，css以及图片，这些元素没有在浏览器端缓存下来。B:请求查询少量数据的页面评审计划查询页面所花时间为1.69s.单独访问评审计划查询页面如下：所花时间为801ms，时间为在portal中的1/2C:访问查询数据比较多的页面资料预审页面所花时间为1.36s。单独访问该页

14、面效果如下：所花时间为990ms。本次测试所花时间都比较少，是因为服务器比较好，访问的人很少。但我们也看出了一些问题，就是在portal那块，前端的（JS，css）未做任何的优化，而portal又大量使用了YUI的JS来实现一些放大，缩小等效果。总结一下，我们可以看看一下二：分析电子化评审模块的性能访问其中的一个页面：我们看看具体每个请求所花的时间:这些是所花时间比较多的请求，后台代码花的时间最多为78ms，然后就是richfaces所花的时间。2.解决方案：在portal中优化前端元素。在子系统中主要是优化78ms这块。因为一些原因，我们在系统中都未开启hibernate的一级缓存。这部分可以优化， 然后就是引入hibernate的二级缓存。降低应用程序访问数据库的频率。 然后就是加集群。相信在这些的优化之后，性能肯定有所提升