论文部分内容阅读
摘要：广东电网公司资产管理系统是全省大集中系统，横跨电网计划、物资采购、项目建设、设备运行维护、退役报废的全过程管理，于2010年上线。随着业务量与日俱增及业务的不断更新，各模块之间的耦合度越来越高，原系统集群架构采用集中式部署，Session共享，单节点性能故障易在集群中扩散；同时单节点程序代码包越来越大，单个server代码内存占用率高、利用率低等问题日益凸显。针对系统部署架构进行了模块化部署改造和无共享架构的应用研究。实验表明，新的部署架构提高了可扩展性、部署灵活性、Web吞吐量和访问性能，优化了资产管理系统部署架构，为公司其他应用系统模块化部署改造和无共享架构的应用提供了经验。
关键词：模块化部署；无共享架构；分布式系统；广东电网公司资产管理系统
作者简介：唐亮亮（1985-），男，广西桂林人，广东电网公司信息中心，助理工程师。（广东 广州 510600）
中图分类号：TM73 文献标识码：A 文章编号：1007-0079（2014）15-0220-04
以往集群架构采用Session共享模式的设计，通过集群节点间Session复制方式实现，而Session复制的成本随着集群服务器的数量增加线性增长，部署的集群服务器越多，集群服务器的Session复制代价越大。为满足系统灵活部署，减少系统模块间的相互影响，提升系统开发效率和整体性能，为使资产管理系统设计更加符合SOA服务设计理念，采用了无共享架构（Shared Nothing Architecture，以下简称SNA）。它是一个分布式的架构，每个节点都是独立的，不需要保存状态信息。由SNA集中保存状态信息在缓存或数据库中，满足Session不共享的无状态服务、与服务请求者到服务提供者的绑定与服务之间松耦合的设计要求。SNA架构思想无论对企业应用还是大型互联网站都极大提高了web应用的吞吐量和性能。
在广东电网业务应用不断增长的背景下，需要一种能适应系统快速升级和功能扩展系统架构，同时保障系统性能不因业务增长而受影响。结合资产管理系统的业务功能模块多、系统功能变更需求多等特点，本文探索了系统模块化部署与无共享架构在资产管理系统上的应用，使资产管理系统性能提升，各子系统松耦合，各子系统运行更稳定，满足SOA设计理念。
一、资产管理系统现状分析
1.资产管理系统子系统依赖关系及部署现状
图1的箭头方向表示依赖方向，蓝色表示单向依赖，黑色表示双向依赖。如图1表示物资子系统依赖项目子系统的7个接口，项目子系统依赖物资子系统的21个接口。从图1可以看出，目前资产管理系统各子系统之间是网状依赖的关系。
图2是资产管理系统集中式的部署逻辑结构图。资产管理系统的项目、物资、设备、财务等子系统代码包发布在同一个Weblogic域中，资产管理系统应用采用集中式集群部署方式，部署9个节点，单个域发布全部资产系统代码。
2.目前的问题
从目前资产管理系统的现状可得知，在这种复杂的网状依赖关系的背景下，整个资产系统部署在单个weblogic域中存在以下问题：
（1）可靠性方面：系统功能集中在单个域，故障影响面大。当其中一个子系统某个代码存在性能缺陷导致宕机，不仅该子系统会产生故障，整个集群其他子系统也会发生同样的故障。
（2）部署成本方面：在集群部署中，Session复制的成本随着集群服务器数量增加而线性增长，部署的集群节点数越多，集群服务器的压力越大。而SNA的实现与服务器的数量无关系。部署的服务器越多，SNA的优势越明显。
（3）资源利用率：代码包在域内内存占有率高，稳定性差、影响响应性能。由于子系统间业务依赖关系较复杂，系统功能集中在单个域中，每个子系统的代码需要冗余其他子系统的代码，才能保证子系统间相互调用接口，代码的大量冗余，导致域内内存占有率高。
（4）开发效率：所有业务模块的代码集中，影响开发效率，代码保存、编译、发布等待时间过长，排错复杂。通常编译一次全部系统代码，并重启服务需要近2个小时，而在开发阶级各业务模块重新编译或重启服务却不可避免，当其中一个业务模块需要重新编译和重启服务，必然会干扰其他业务模块的开发工作进展。
（5）可扩展性：SOA架构的五个特征是可重用、松耦合、明确定义的接口、无状态的服务设计、基于开放的标准，而目前各模块之间是紧耦合，且集群不符合SOA架构的部分特征。
二、模块化部署与无共享架构应用研究
1.无共享架构技术
无共享架构（Shared Nothing Architecture，以下简称SNA）是一个分布式的架构，每个节点都是独立的，不需要保存状态信息。由SNA系统集中保存状态信息在缓存或数据库中。SNA在web层的集群主要依赖的技术是负载均衡和session共享。
session的共享方面，如在应用服务层处理，各节点的session复制将会极大影响性能。替换的一种可行方案是保持每个节点的无状态性，不再使用session来保持全局状态。用户唯一标识从 cookie取得，session放在分布式cache或是数据库中，只要通过用户唯一标识，无论在哪个服务器上都能够获取到该用户的session信息。SNA实现原理如图3所示：
（1）当客户端发起请求时会被SNAfilter（SNA过滤器）拦截，SNAfilter将原始请求对象的获取会话的方法进行重写，并封装为新的请求对象。
（2）WebApp应用在进行会话的查询和存储信息的操作（SessionOperation）时会从SNA服务器查找和存储信息。
（3）此外，为了提高性能，服务器对信息进行了缓存（Local-Cache），避免每次访问都从SNA服务器中读取信息。 由此可见，无共享架构（SNA）有如下优势：
第一，性能优势：各应用服务节点无状态，因此可以不断增加服务节点来满足性能需求，解决了因用户增加而带来的服务器压力问题。
第二，稳定性优势：由于可以部署多个无状态的服务，因此当某个服务器出现宕机等情况，用户的请求可以转发到其他节点上，不会有任何信息丢失，系统的稳定性得到了极大提高。
第三，成本优势：SNA的实现对系统的实现影响接近于0，部署简单，可以以极低的成本完成。
第四，分布式部署优势：由于状态统一保存，因此可以接入不同的子系统，安全、彻底地解决了大集中部署带来的Session共享问题。
第五，成熟的行业应用案例：新浪、阿里巴巴等大型互联网网站都在大规模应用SNA。
2.系统模块化改造与无共享架构应用
（1）资产管理系统模块化改造，首先需要进行资产管理系统拆分。将系统按业务拆分成多个子系统，每个子系统部署独立的服务节点，同时子系统拆分本着一体化的设计原则，以保证系统业务逻辑清晰，避免一个业务数据逻辑在子系统间多次交互，通信中以不处理复杂的计算为前提，进行资产管理系统拆分和系统集成。资产管理系统拆分以项目、物资、设备、财务等主营业务为拆分的基础进行拆分。按照资产现有业务耦合程度确定子系统拆分为投资计划、项目、物资、供应商、财务、预算、设备及基础平台等10个子系统。
通过对资产管理系统进行模块化改造，预期会达到以下效果：
第一，开发高效率：各子系统开发人员只需更新和编码各自子系统的代码，避免长时间等待代码更新编译和本地weblogic服务启动，从而提高开发效率。
第二，系统高可用：各子系统的部署、发布、故障互不影响，系统发布期间可单独停止某个子系统，进行更新并重新启动，避免影响其他子系统的正常运行。如果某个子系统宕机，其它子系统也可以正常运行，从而避免某个子系统的问题造成整个资产管理系统宕机。
（2）资产管理系统应用主从方式SNA共享架构。在进行资产管理系统模块化改造的同时，在资产管理系统上应用主从方式的SNA共享架构，其SNA逻辑架构如图4所示：
SNA服务通过VIP（虚拟IP）对外提供服务，在SNA的主服务与备份之间建立心跳检测，当主服务宕机时备份服务立即接管VIP，对外提供服务，实现故障转移。当主服务修复后，重新加入，作为当前主服务的备份，依此反复。
Keepalived是Linux下面实现备份路由的高可靠性运行件。基于Keepalived设计的服务模式能够真正做到主服务器和备份服务器故障时IP瞬间无缝交接。使用Keepalived的虚拟IP（VIP）来对外提供服务，客户端始终连接VIP。SNA使用Master Slave模式（主从模式），服务启动时VIP绑定在SNA主服务上，并对外提供服务，SNA从服务作为当前主服务的热备，并且从服务并不提供数据读取服务，当主服务挂掉，从服务正常时，从服务接管虚拟IP，并提供服并发送SLAVEOF NO ONE关闭主从复制功能，同时自己提升为主服务，当（原）主服务修复重新加入时，作为当前主服务的从服务，提供备份功能，依此反复，实现SNA服务的故障转移。
3.系统模块化部署
在资产管理系统以项目、物资、设备、财务等主要业务基础进行拆分后，其模块化部署逻辑架构，如图5模块化部署逻辑图。系统拆分后的模块化集成部署：各子系统部署独立的weblogic域，每个域由一个或多个weblogic Server集群，并共用同一数据库；资产管理系统增加主、从SNA共享缓存服务器，采用Redis作为缓存存储系统；资产管理系统建立集群以满足高并发需求；通过F5实现负载均衡，AdminServer和受管Server均部署在管理服务器上；通过F5将请求转发关联各模块子系统。
从图5模块化部署逻辑图中可以看出，资产管理系统未来扩展新业务功能，可以很方便地横向扩展，增加独立的weblogic域，且不影响原有的业务子系统。
基于资产管理系统的Session缓存服务应用实验。
集群环境中需实现多个应用对Session的共享，以达到能够共用Session中存储内容的目的。实验将借助Redis缓存服务能够将Session缓存在服务器内存中，对session进行统一管理，所有应用都访问和修改缓存中的Session，而无需在Session发生改变时，为每一个应用都进行Session的拷贝。同时由于借助Redis缓存Session时，Session被存储于内存中，访问和修改的速度较存储于数据库中要更快。
表1 基于资产管理系统的Session缓存服务应用实验
用例名称 事务 在线用户 事务交易时间（秒） 响应指标
MIX AVG MAX
拆分前
（集中式集群） 登录 1 0.329 0.393 1.291 ≤2秒
50 0.366 2.836 9.302 ≤3秒
100 0.564 3.134 9.642 ≤4秒
200 0.765 3.836 12.916 ≤5秒
访问菜单管理 1 0.38 0.426 0.684 ≤2秒
50 0.145 2.835 7.653 ≤3秒
100 0.123 3.574 13.492 ≤4秒
200 0.039 4.997 13.239 ≤5秒
访问桌面窗口管理 1 0.328 0.379 0.69 ≤2秒
50 0.246 2.925 6.695 ≤3秒
100 0.298 3.993 8.904 ≤4秒 200 0.031 4.807 9.935 ≤5秒
拆分后
（基于Redis缓存服务的无共享架构） 登录 1 0.262 0.371 1.241 ≤2秒
50 0.301 1.771 5.732 ≤3秒
100 0.513 2.818 9.876 ≤4秒
200 0.665 3.344 12.758 ≤5秒
访问菜单管理 1 0.108 0.14 0.23 ≤2秒
50 0.059 0.18 3.336 ≤3秒
100 0.071 0.254 4.127 ≤4秒
200 0.01 1.664 8.695 ≤5秒
访问桌面窗口管理 1 0.029 0.041 0.109 ≤2秒
50 0.024 0.06 1.754 ≤3秒
100 0.023 0.068 1.874 ≤4秒
200 0.025 0.072 2.588 ≤5秒
表1中数据实验表明，基于Redis缓存服务的无共享架构的应用时事务的响应时间优于集中式部署下的访问。
4.系统模块化部署改造与无共享架构应用的效果
资产管理系统进行模块化部署改造，并应用无共享架构后，经过测试验证，系统在可靠性、可扩展性、资源利用率、开发效率等方面均有显著改善和提高。
（1）其中资源利使用状况改善。
应用层内存资源利用率提高：86.26%（拆分后）-43.01%（拆分前）=43.25%
DB CPU高峰期平均使用率降低：优化前高峰期平均使用率-优化后高峰期平均使用率=（35%+65%/2）-（8%+30%）/2=31%
应用架构部署调整：代码占用内存大幅度减少，内存利用率提高显著，如表2所示：
表2 应用架构部署调整前后内存利用率
分配总内存（M） 代码占总内存（M） 运行可使用内存（M）=分配总内存-代码占用内存 利用率
拆分前 71680.00 40852 30828 43.01%
拆分后 94720.00 13016 81704 86.26%
（2）开发效率提高。
开发效率提高：集中式部署（人力投入×工时投入×每月下载编次数）-模块化部署（人力投入×工时投入×每月下载编次数）/集中式部署（人力投入×工时投入×每月下载编次数）×100%=（200×2×2）-（80×0.5×2）/（200×2×2）×100%=80%
表3 代码下载、编译的（等待）成本
人力投入
（人） 工时投入
（小时） 每月平均代码下载、编译次数
（经验值） 运维工时
（小时）
集中式部署 200 2 2 800
模块化部署 80 0.5 2 80
（3）系统可靠性提高：通过广东电网公司资产系统模块化部署，达到了如下效果：
1）子系统之间直接调用业务节点接口集成，降低子系统间耦合度。
2）通过SNA服务器共享Session，避免节点间相互复制Session，有效解决了Session保持问题，解决了分布式系统的Session共享；因此，子系统业务代码单独部署成为接口服务节点供其他子系统调用集成，为系统功能扩展提供架构保障。
3）子系统对外接口服务可独立打包，不依赖于子系统其他原有业务代码，每个子系统应用节点发布全部接口服务包，子系统调用接口服务可以跟调用本地代码一样方便。
4）资产管理系统模块化部署可有效阻止故障在节点间蔓延。故障蔓延指集群中一个节点发生性能缺陷时导致宕机，相应的性能缺陷请求转移到其他节点会依次宕机。系统拆分前集中式部署，共用9节点服务器进行集群，有蔓延时会导致所有依次宕机；系统拆分后进行模块化部署，假定每个子系统采用2个服务器集群（实际中有子系统超过2个节点的），共18个节点，故障蔓延时只造成子系统内部宕机。故障蔓延度：故障节点数/节点总数×100%。如表4对比拆分前后两种部署方式的故障蔓延度。
表4 故障蔓延度
节点总数
（个） 故障节点数
（个） 故障蔓延节点数
（个） 故障蔓延度
（%）
集中式部署 9 1 9 100%
模块化部署 18 1 2 11%
三、结论
从资产管理系统模块化部署改造和无共享架构应用的效果分析得出，通过将集中式部署的资产管理系统拆分并模块化部署改造，同时采用无共享架构技术极大提高了系统的扩展性、部署灵活性、系统性能，有效提高了应用系统吞吐量和访问性能，优化了广东电网公司资产管理系统架构。
参考文献：
[1][美]PaulC.Brown.SOA实践指南：应用整体架构[M].北京：机械工业出版社，2009.
[2][美]Kirk Knoernschild.Java应用架构设计：模块化模式与OSGi[M].北京：机械工业出版社，2013.
[3]李伟，吴庆海.软件架构的艺术[M].北京：电子工业出版社，2009.
[4]杨传辉.大规模分布式存储系统：原理解析与架构实战[M].北京：机械工业出版社，2009.
[5]李智慧.大型网站技术架构：核心原理与案例分析[M].北京：电子工业出版，2013.
[6]张世明.数字教育资源共享生态系统研究[M].上海：复旦大学出版社，2011.
[7]兰锋.网站集群架构[EB/OL].[2013-12-16].http：//wenku.it168.com/d_000056770.shtml.
[8]Wang Yu.Scaling Your Java EE. Applications[EB/OL].[2008-07-01].http：//www.theserverside.com/news/1363681/Scaling-Your-Java-EE-Applications.
（责任编辑：王祝萍）
关键词：模块化部署；无共享架构；分布式系统；广东电网公司资产管理系统
作者简介：唐亮亮（1985-），男，广西桂林人，广东电网公司信息中心，助理工程师。（广东 广州 510600）
中图分类号：TM73 文献标识码：A 文章编号：1007-0079（2014）15-0220-04
以往集群架构采用Session共享模式的设计，通过集群节点间Session复制方式实现，而Session复制的成本随着集群服务器的数量增加线性增长，部署的集群服务器越多，集群服务器的Session复制代价越大。为满足系统灵活部署，减少系统模块间的相互影响，提升系统开发效率和整体性能，为使资产管理系统设计更加符合SOA服务设计理念，采用了无共享架构（Shared Nothing Architecture，以下简称SNA）。它是一个分布式的架构，每个节点都是独立的，不需要保存状态信息。由SNA集中保存状态信息在缓存或数据库中，满足Session不共享的无状态服务、与服务请求者到服务提供者的绑定与服务之间松耦合的设计要求。SNA架构思想无论对企业应用还是大型互联网站都极大提高了web应用的吞吐量和性能。
在广东电网业务应用不断增长的背景下，需要一种能适应系统快速升级和功能扩展系统架构，同时保障系统性能不因业务增长而受影响。结合资产管理系统的业务功能模块多、系统功能变更需求多等特点，本文探索了系统模块化部署与无共享架构在资产管理系统上的应用，使资产管理系统性能提升，各子系统松耦合，各子系统运行更稳定，满足SOA设计理念。
一、资产管理系统现状分析
1.资产管理系统子系统依赖关系及部署现状
图1的箭头方向表示依赖方向，蓝色表示单向依赖，黑色表示双向依赖。如图1表示物资子系统依赖项目子系统的7个接口，项目子系统依赖物资子系统的21个接口。从图1可以看出，目前资产管理系统各子系统之间是网状依赖的关系。
图2是资产管理系统集中式的部署逻辑结构图。资产管理系统的项目、物资、设备、财务等子系统代码包发布在同一个Weblogic域中，资产管理系统应用采用集中式集群部署方式，部署9个节点，单个域发布全部资产系统代码。
2.目前的问题
从目前资产管理系统的现状可得知，在这种复杂的网状依赖关系的背景下，整个资产系统部署在单个weblogic域中存在以下问题：
（1）可靠性方面：系统功能集中在单个域，故障影响面大。当其中一个子系统某个代码存在性能缺陷导致宕机，不仅该子系统会产生故障，整个集群其他子系统也会发生同样的故障。
（2）部署成本方面：在集群部署中，Session复制的成本随着集群服务器数量增加而线性增长，部署的集群节点数越多，集群服务器的压力越大。而SNA的实现与服务器的数量无关系。部署的服务器越多，SNA的优势越明显。
（3）资源利用率：代码包在域内内存占有率高，稳定性差、影响响应性能。由于子系统间业务依赖关系较复杂，系统功能集中在单个域中，每个子系统的代码需要冗余其他子系统的代码，才能保证子系统间相互调用接口，代码的大量冗余，导致域内内存占有率高。
（4）开发效率：所有业务模块的代码集中，影响开发效率，代码保存、编译、发布等待时间过长，排错复杂。通常编译一次全部系统代码，并重启服务需要近2个小时，而在开发阶级各业务模块重新编译或重启服务却不可避免，当其中一个业务模块需要重新编译和重启服务，必然会干扰其他业务模块的开发工作进展。
（5）可扩展性：SOA架构的五个特征是可重用、松耦合、明确定义的接口、无状态的服务设计、基于开放的标准，而目前各模块之间是紧耦合，且集群不符合SOA架构的部分特征。
二、模块化部署与无共享架构应用研究
1.无共享架构技术
无共享架构（Shared Nothing Architecture，以下简称SNA）是一个分布式的架构，每个节点都是独立的，不需要保存状态信息。由SNA系统集中保存状态信息在缓存或数据库中。SNA在web层的集群主要依赖的技术是负载均衡和session共享。
session的共享方面，如在应用服务层处理，各节点的session复制将会极大影响性能。替换的一种可行方案是保持每个节点的无状态性，不再使用session来保持全局状态。用户唯一标识从 cookie取得，session放在分布式cache或是数据库中，只要通过用户唯一标识，无论在哪个服务器上都能够获取到该用户的session信息。SNA实现原理如图3所示：
（1）当客户端发起请求时会被SNAfilter（SNA过滤器）拦截，SNAfilter将原始请求对象的获取会话的方法进行重写，并封装为新的请求对象。
（2）WebApp应用在进行会话的查询和存储信息的操作（SessionOperation）时会从SNA服务器查找和存储信息。
（3）此外，为了提高性能，服务器对信息进行了缓存（Local-Cache），避免每次访问都从SNA服务器中读取信息。 由此可见，无共享架构（SNA）有如下优势：
第一，性能优势：各应用服务节点无状态，因此可以不断增加服务节点来满足性能需求，解决了因用户增加而带来的服务器压力问题。
第二，稳定性优势：由于可以部署多个无状态的服务，因此当某个服务器出现宕机等情况，用户的请求可以转发到其他节点上，不会有任何信息丢失，系统的稳定性得到了极大提高。
第三，成本优势：SNA的实现对系统的实现影响接近于0，部署简单，可以以极低的成本完成。
第四，分布式部署优势：由于状态统一保存，因此可以接入不同的子系统，安全、彻底地解决了大集中部署带来的Session共享问题。
第五，成熟的行业应用案例：新浪、阿里巴巴等大型互联网网站都在大规模应用SNA。
2.系统模块化改造与无共享架构应用
（1）资产管理系统模块化改造，首先需要进行资产管理系统拆分。将系统按业务拆分成多个子系统，每个子系统部署独立的服务节点，同时子系统拆分本着一体化的设计原则，以保证系统业务逻辑清晰，避免一个业务数据逻辑在子系统间多次交互，通信中以不处理复杂的计算为前提，进行资产管理系统拆分和系统集成。资产管理系统拆分以项目、物资、设备、财务等主营业务为拆分的基础进行拆分。按照资产现有业务耦合程度确定子系统拆分为投资计划、项目、物资、供应商、财务、预算、设备及基础平台等10个子系统。
通过对资产管理系统进行模块化改造，预期会达到以下效果：
第一，开发高效率：各子系统开发人员只需更新和编码各自子系统的代码，避免长时间等待代码更新编译和本地weblogic服务启动，从而提高开发效率。
第二，系统高可用：各子系统的部署、发布、故障互不影响，系统发布期间可单独停止某个子系统，进行更新并重新启动，避免影响其他子系统的正常运行。如果某个子系统宕机，其它子系统也可以正常运行，从而避免某个子系统的问题造成整个资产管理系统宕机。
（2）资产管理系统应用主从方式SNA共享架构。在进行资产管理系统模块化改造的同时，在资产管理系统上应用主从方式的SNA共享架构，其SNA逻辑架构如图4所示：
SNA服务通过VIP（虚拟IP）对外提供服务，在SNA的主服务与备份之间建立心跳检测，当主服务宕机时备份服务立即接管VIP，对外提供服务，实现故障转移。当主服务修复后，重新加入，作为当前主服务的备份，依此反复。
Keepalived是Linux下面实现备份路由的高可靠性运行件。基于Keepalived设计的服务模式能够真正做到主服务器和备份服务器故障时IP瞬间无缝交接。使用Keepalived的虚拟IP（VIP）来对外提供服务，客户端始终连接VIP。SNA使用Master Slave模式（主从模式），服务启动时VIP绑定在SNA主服务上，并对外提供服务，SNA从服务作为当前主服务的热备，并且从服务并不提供数据读取服务，当主服务挂掉，从服务正常时，从服务接管虚拟IP，并提供服并发送SLAVEOF NO ONE关闭主从复制功能，同时自己提升为主服务，当（原）主服务修复重新加入时，作为当前主服务的从服务，提供备份功能，依此反复，实现SNA服务的故障转移。
3.系统模块化部署
在资产管理系统以项目、物资、设备、财务等主要业务基础进行拆分后，其模块化部署逻辑架构，如图5模块化部署逻辑图。系统拆分后的模块化集成部署：各子系统部署独立的weblogic域，每个域由一个或多个weblogic Server集群，并共用同一数据库；资产管理系统增加主、从SNA共享缓存服务器，采用Redis作为缓存存储系统；资产管理系统建立集群以满足高并发需求；通过F5实现负载均衡，AdminServer和受管Server均部署在管理服务器上；通过F5将请求转发关联各模块子系统。
从图5模块化部署逻辑图中可以看出，资产管理系统未来扩展新业务功能，可以很方便地横向扩展，增加独立的weblogic域，且不影响原有的业务子系统。
基于资产管理系统的Session缓存服务应用实验。
集群环境中需实现多个应用对Session的共享，以达到能够共用Session中存储内容的目的。实验将借助Redis缓存服务能够将Session缓存在服务器内存中，对session进行统一管理，所有应用都访问和修改缓存中的Session，而无需在Session发生改变时，为每一个应用都进行Session的拷贝。同时由于借助Redis缓存Session时，Session被存储于内存中，访问和修改的速度较存储于数据库中要更快。
表1 基于资产管理系统的Session缓存服务应用实验
用例名称 事务 在线用户 事务交易时间（秒） 响应指标
MIX AVG MAX
拆分前
（集中式集群） 登录 1 0.329 0.393 1.291 ≤2秒
50 0.366 2.836 9.302 ≤3秒
100 0.564 3.134 9.642 ≤4秒
200 0.765 3.836 12.916 ≤5秒
访问菜单管理 1 0.38 0.426 0.684 ≤2秒
50 0.145 2.835 7.653 ≤3秒
100 0.123 3.574 13.492 ≤4秒
200 0.039 4.997 13.239 ≤5秒
访问桌面窗口管理 1 0.328 0.379 0.69 ≤2秒
50 0.246 2.925 6.695 ≤3秒
100 0.298 3.993 8.904 ≤4秒 200 0.031 4.807 9.935 ≤5秒
拆分后
（基于Redis缓存服务的无共享架构） 登录 1 0.262 0.371 1.241 ≤2秒
50 0.301 1.771 5.732 ≤3秒
100 0.513 2.818 9.876 ≤4秒
200 0.665 3.344 12.758 ≤5秒
访问菜单管理 1 0.108 0.14 0.23 ≤2秒
50 0.059 0.18 3.336 ≤3秒
100 0.071 0.254 4.127 ≤4秒
200 0.01 1.664 8.695 ≤5秒
访问桌面窗口管理 1 0.029 0.041 0.109 ≤2秒
50 0.024 0.06 1.754 ≤3秒
100 0.023 0.068 1.874 ≤4秒
200 0.025 0.072 2.588 ≤5秒
表1中数据实验表明，基于Redis缓存服务的无共享架构的应用时事务的响应时间优于集中式部署下的访问。
4.系统模块化部署改造与无共享架构应用的效果
资产管理系统进行模块化部署改造，并应用无共享架构后，经过测试验证，系统在可靠性、可扩展性、资源利用率、开发效率等方面均有显著改善和提高。
（1）其中资源利使用状况改善。
应用层内存资源利用率提高：86.26%（拆分后）-43.01%（拆分前）=43.25%
DB CPU高峰期平均使用率降低：优化前高峰期平均使用率-优化后高峰期平均使用率=（35%+65%/2）-（8%+30%）/2=31%
应用架构部署调整：代码占用内存大幅度减少，内存利用率提高显著，如表2所示：
表2 应用架构部署调整前后内存利用率
分配总内存（M） 代码占总内存（M） 运行可使用内存（M）=分配总内存-代码占用内存 利用率
拆分前 71680.00 40852 30828 43.01%
拆分后 94720.00 13016 81704 86.26%
（2）开发效率提高。
开发效率提高：集中式部署（人力投入×工时投入×每月下载编次数）-模块化部署（人力投入×工时投入×每月下载编次数）/集中式部署（人力投入×工时投入×每月下载编次数）×100%=（200×2×2）-（80×0.5×2）/（200×2×2）×100%=80%
表3 代码下载、编译的（等待）成本
人力投入
（人） 工时投入
（小时） 每月平均代码下载、编译次数
（经验值） 运维工时
（小时）
集中式部署 200 2 2 800
模块化部署 80 0.5 2 80
（3）系统可靠性提高：通过广东电网公司资产系统模块化部署，达到了如下效果：
1）子系统之间直接调用业务节点接口集成，降低子系统间耦合度。
2）通过SNA服务器共享Session，避免节点间相互复制Session，有效解决了Session保持问题，解决了分布式系统的Session共享；因此，子系统业务代码单独部署成为接口服务节点供其他子系统调用集成，为系统功能扩展提供架构保障。
3）子系统对外接口服务可独立打包，不依赖于子系统其他原有业务代码，每个子系统应用节点发布全部接口服务包，子系统调用接口服务可以跟调用本地代码一样方便。
4）资产管理系统模块化部署可有效阻止故障在节点间蔓延。故障蔓延指集群中一个节点发生性能缺陷时导致宕机，相应的性能缺陷请求转移到其他节点会依次宕机。系统拆分前集中式部署，共用9节点服务器进行集群，有蔓延时会导致所有依次宕机；系统拆分后进行模块化部署，假定每个子系统采用2个服务器集群（实际中有子系统超过2个节点的），共18个节点，故障蔓延时只造成子系统内部宕机。故障蔓延度：故障节点数/节点总数×100%。如表4对比拆分前后两种部署方式的故障蔓延度。
表4 故障蔓延度
节点总数
（个） 故障节点数
（个） 故障蔓延节点数
（个） 故障蔓延度
（%）
集中式部署 9 1 9 100%
模块化部署 18 1 2 11%
三、结论
从资产管理系统模块化部署改造和无共享架构应用的效果分析得出，通过将集中式部署的资产管理系统拆分并模块化部署改造，同时采用无共享架构技术极大提高了系统的扩展性、部署灵活性、系统性能，有效提高了应用系统吞吐量和访问性能，优化了广东电网公司资产管理系统架构。
参考文献：
[1][美]PaulC.Brown.SOA实践指南：应用整体架构[M].北京：机械工业出版社，2009.
[2][美]Kirk Knoernschild.Java应用架构设计：模块化模式与OSGi[M].北京：机械工业出版社，2013.
[3]李伟，吴庆海.软件架构的艺术[M].北京：电子工业出版社，2009.
[4]杨传辉.大规模分布式存储系统：原理解析与架构实战[M].北京：机械工业出版社，2009.
[5]李智慧.大型网站技术架构：核心原理与案例分析[M].北京：电子工业出版，2013.
[6]张世明.数字教育资源共享生态系统研究[M].上海：复旦大学出版社，2011.
[7]兰锋.网站集群架构[EB/OL].[2013-12-16].http：//wenku.it168.com/d_000056770.shtml.
[8]Wang Yu.Scaling Your Java EE. Applications[EB/OL].[2008-07-01].http：//www.theserverside.com/news/1363681/Scaling-Your-Java-EE-Applications.
（责任编辑：王祝萍）