基于集中采购的分布式系统的设计与实现
2017-06-16吴香兰
吴香兰
[摘要]近年来,随着反腐政策的不断深入,政府行业预算控制日益严格,为了更加规范政府行业的采购行为,使之更加公开和透明,政府行业的集中采购规模将不断加大。各个单位企业纷纷建立自己的电商网站,进行集中采购行为,并采用分布式系统设计优化性能,提升整体采购量。
[关键词]集中采购;分布式系统;宕机;负载均衡
[中图分类号]G642 [文献标识码]A [文章编号]1671-5918(2017)06-0108-03
一、引言
随着大型企业集中采购范围的不断拓展和集中采购模式的不断创新完善,大型企业集中采购正朝着专业化、集约化、信息化、标准化、规范化方向发展。集中采购适用于大型企业、集团或跨国公司中能够形成一定规模优势的大宗、批量且标准化程度较高的同类货物和服务,如大批量主要零部件、生产原材料或战略资源货物。随着反腐政策的不断深入,政府行业预算控制日益严格,为了更加规范政府行业的采购行为,使之更加公开和透明,政府行业的集中采购规模将不断加大。集中采购是政府采购的主要形式,是指由在政府设立的集中采购机构依据政府制定的集中采购目录,包括由中央财政部预算直接划拨和地方省份财政预算划拨。为实现集中采购模式,各集团纷纷采用成立集中采购类的电商公司来专门运作,并且拉入更多的集团外公司一同提升采购量,特别是集采量,并在这个基础上整理出各个行业的数据分析等功能,为集团提供一手数据,提供决策能力。
二、基于集中采购的分步式系统提出
(一)什么是分布式系统
分布式系统(distributed system)是建立在网络之上的软件系统。正是因为软件的特性,所以分布式系统具有高度的内聚性和透明性。因此,网络和分布式系统之间的区别更多的在于高层软件(特别是操作系统),而不是硬件。内聚性是指每一个数据库分布节点高度自治,有本地的数据库管理系统。透明性是指每一个数据库分布节点对用户的应用来说都是透明的,看不出是本地还是远程。在分布式数据库系统中,用户感觉不到数据是分布的,即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。
(二)集中采购行业软件弊端
传统的集中采购系统架构比较简单,采用四层设计,从上到下分别是Web浏览器、界面层、业务层(数据访问层)和数据存储层,根据实际可以是B/S模式,也可以是C/S模式。
在各个集团成立了电商公司专门运作集中采购系统,借助这个架构的平台,各个集团的采购量不断上升,系统运营效果较好,但是随着用户量不断增大后,系统出现宕机情况也不断增多,即使生产环境的操作系统及JDK都升级到64位,并且扩展了JVM管理的内存,宕机情况有所减少,但是还是无法达到不宕机的要求,这长期困扰着集中采购的电商平台,也极大地影响了集中采购系统的使用效果和推广进程。
在这种情况下,尝试采用分布式系统架构来满足其日益增长的业务需求,解决宕机的困扰,真正让电商网站服务于集中采购,提高采购的便捷性。
三、分布式系统在集中采购行业中的设计与应用
(一)分布式系统架构
分布式集中采购系统的架构彻底打破了传统集中采购的四层设计,采用五层的系统架构的设计,从上到下分别是页面层、页面交互层、控制层、数据交互层和持久化存储层,并且通过一定的开发工具和外部技术的配合使用来实现分布式的优越性能。
(二)軟件内部架构设计
页面层:EXT-JS的不仅大而全,而且太过重量级,页面风格也太过单一,在网站端开发使用起来比较麻烦,比较适合于传统企业级应用,不适合分布式电商系统架构。由于JavaScript库里的JQUERY的开源性和共享的特点,使用起来会更方便,所以页面层选用了JQUERY,主要使用了easyui、jqgrid等工具。开发报表选用了EcCade。
页面交互层:采用Servlet接收前端数据,json作为传递数据的功能,自己通过过滤器实现安全管理,同时设计缓存借口模块。
控制层:由于J2EE的Spring是一个轻量级的DI和AOP容器框架,并且Spring的高度可开放性,并不强制依赖于spring,开发者可以自由选择spring部分或全部选用,所以控制层选用了Spring,Spring Core进行依赖注入,Spring Aop进行事务管理,同时设计流程管理模块。
数据交互层:由于Hibernate简化了持久层的开发,可以运用面向对象的语言操作数据库,且具有平台无关性开发的产品更具移植性。所以数据交互层选用Hibernate。设计文件存储模块。
持久化存储:由于传统的系统使用的是oracle,所以电商平台继续使用Oracle。由于加入了电商网站,需要更多的图片存放,所以需要架设了一个Http Server,这个服务器可以展示静态资源,其中文件存放在共享的磁盘阵列上,通过Http Server对其进行访问,将其访问地址存放在Oracle数据库中,网站或者内部应用访问图片等文件资源时,就直接通过地址进行访问即可,同时也避免了网站或者内部应用重新发布时,还需要备份这些文件(特别是文件太大后,根本无法备份)。数据库连接池管理使用DBCP。
(三)外部工具
操作系统:由于传统的系统是一个集中部署的系统,一般采用的是IBM小型机作为应用服务器和数据库服务器,使用AIX操作系统。现在将系统修改为分步式系统,将原来的集中部署系统修改为企业内部系统、供应商管理系统、第三方采购系统、集团领导决策分析系统和电商网站(B2B)五个系统。而对于客户全部购买IBM小型机可能是一个巨大的经费压力,所以整个系统在保留传统的AIX服务器的基础上,增加的服务器可以全部采用RedHat Linux作为操作系统。
应用服务器:由于客户的IBM的WPS免费服务已经过期,续费太贵(20万每年)。所以放弃使用了,改用免费版的JBOSS。由于2008年为他们部署系统时采用的是IBM JDK 32位,现在改用了64位的JDK。因为32位JDK最多只能管理1.5G内存,而64位JDK理论上可以管理128G的内存。
缓存服务:采用EcCache,将原有的JVM内部缓存移植到EcCache中。由于有多台服务器,所以需要安装多个EcCache,并且之间数据需要共享,可以考虑做一个EcCache集群。但是这个缓存最大的缺点就是缓存需要被多次拷贝,占用更多的服务器的内存空间。
负载均衡:选择了市场上使用的比较流行的Apache HttpServer作为负载均衡服务器,同时也可以作为静态网站的服务器来使用。
(四)开发工具
由于Eclipse的程序更加面向对象、提高了生产率、方便移植(修改配置文件)、无侵入性等优点,开发工具选用了Eclipse,数据库可以使用plSql。
四、分布式系统的好处
集中采购系统采用了分布式系统架构的设计后,随着用户量不断增大系统宕机的问题彻底解决,并且具有以下好处:
(一)实现了数据库的读写分离,将数据库操作的读操作和写操作分离到不同的数据库实例上面去了,即使由于数据库读操作的脚本执行效率太低,也不会造成写操作无法进行。
(二)由于使用了负载均衡,不再仅依靠一台JVM来实现应用程序的内存管理,即使是64位JDK可以管理很大的内存,但是内存太大会降低JVM的回收時间,拖慢系统的整体性能。
(三)采用了负载均衡后,应用程序可以被部署到多个服务器上面,每个服务器上面可以部署多个应用服务器,每个应用服务器可以使用一个JVM,每个JVM可以设置的比较合适,从而保证系统的整体运行性能。
(四)由于缓存是各个应用服务器都会使用到的,需要一个集中的区域将缓存管理起来,现在采用JVM的外部缓存,可以将缓存数据集中管理,各个应用服务器从一个入口获取缓存。
(五)由于有了负载均衡,各个应用服务器可以作为相互备份了,即使一台服务器宕机或者性能很慢了,负载均衡服务器会通过访问的响应速度,将新的访问指向到性能更优的服务器上面。
(六)采用多服务器部署后,使得每个服务器的资源都得以充分的利用。可以将动态资源和静态资源分开部署。
五、分布式系统的未来展望
由于分布式系统的优越性能,未来大有可为,未来在以下方面将得到较大的发展:
(一)数据库、操作系统、应用服务器未来免费和开源的情况肯定会越来越多。
(二)关系型数据库不能完全满足业务增长的需求,未来的系统会是关系型数据库和NOSQL数据库并存。对于事务操作要求高的业务采用关系型数据库,对于事务要求不高的业务可以采用NOSQL数据库。
(三)缓存技术的发展会形成不再是本地缓存,而是远程缓存,缓存还可以在多台服务器上互相备份。
(四)未来的应用程动静分离的情况会越来越多,对于系统中变化不多的信息,以静态页面展示,对于业务数据的获取使用动态的应用服务器去获取数据信息。
(五)随着数据量越来越大,系统必须引入全文检索工具,以满足用户快速搜索信息的需求。
(六)由于可以连接网络的设备越来越多,而各种不同设置的屏幕尺寸又不统一,系统页面需要同时满足这些不同的屏幕展示。为了不开发多套页面,未来的页面将以响应式布局为主。
六、结论
集中采购电商系统引入分布式系统后,随着用户量不断增大后,系统出现宕机情况彻底杜绝了,同时由于引入了jQuery技术,可以快速的引入很多前端的技术框架,比如jqGrid、AutoComplete等。通过oracle的同义词技术可以实现多个数据库之间的数据同步,引入了Http Server较好的实现了静态资源展示和负载均衡。这样整个集中采购系统就能够很好地满足企业的要求,更好地服务于采购企业。
(责任编辑:章樊)