总结一下维护了一年的一个软件系统的软件体系（一）

       大概一年以前参与到一个大型信息管理软件系统的维护工作中，这个系统是B/S结构，主要负责某省煤炭资源运销管理，应用在了铁路这个渠道管理上，我们的主要的系统维护工作重心在铁路管理维护上，另外还负责一些网站信息发布管理功能的维护。

       这个管理系统有自己的一套网络体系，因为我并没有参与其中的网络体系的搭建与后期的维护工作，只是大概的了解一些：

      1.网络体系的结构为树状拓扑结构，主要依据该公司的组织机构建立，该公司组织机构分为总公司一级，分公司一级，县级公司一级以及直接负责煤炭运销具体的工作的公司一级。网络体系以此而建，也分为四级网络。

     2.使用一套c/s体系的软件，完成基础数据的收集，并定时上报到县级公司或者直属的分公司，然后将数据汇总分析后通过这套软件提交，统一储存到总公司数据库服务器。

    3.根据该行业的业务，每年全省的煤炭运量，特别是通过铁路渠道的运量，在年初通过签订的全年合同决定，该年的业务也以此运量为准。

     这套软件成型与2002年，在当时的条件限制下这是一套最为有效的软件工作体系了，但也有其缺陷：

      1. 尽管基础数据收集大都已经为通过电子称量系统实现自动数据提取，但在上报过程中，仍有可能对数据进行篡改，软件为此专门增设了一个子功能系统，但使用情况不容乐观，收效甚微。

      2. 数据统一存储在总公司数据库服务器中，方便管理，在最初的设计中，数据库没有设计负载分流以及镜像备份的等处理，随着系统的使用，数据量的增加，数据库负载增大，软件反应速度越来越慢。

      这个缺陷在今年年初运量提报和每个月初的各个分公司的运量提报中尤为明显，数据库出现多次当机情况，处理过多次，但收效不明显，在使用高峰期需要注意数据库的使用情况。

     这个系统的网络部分就写这么多吧，毕竟不太熟悉，还是掺杂了软件的非网络部分，:-)。下一篇开始写这个软件的web架构部分，主要是mvc框架和dao框架部分。

评论

1 楼 lfsfxy9 2011-02-12  

恩，有感触，关于数据库超大数据量的问题，设计不到位就很是让维护人员纠结，当数据过大，直接影响软件运行效率。

现在用分区或索引可以一定程度上解决这类的问题。


http://blog.csdn.net/lfsfxy9