方案模版-非功能性设计

侠雨飞飞

已于 2023-07-18 14:35:09 修改

阅读量2.2k

点赞数 11

文章标签：软件工程

于 2014-06-27 09:47:29 首次发布

本文链接：https://blog.csdn.net/silverswords/article/details/35222783

版权

文件内容来自网络，仅供参考，如有侵权请告知。

功能性设计

（根据项目情况自行编写）

非功能性设计

系统性能

本项目优化重点采用的方法和步骤包括：

（一）从设计和开发上，重点采用的方法：

针对本项目的高并发、高实时的响应需求，在设计开发层面主要采用以下理念的设计，这些关键性技术封装在SWORD平台当中，已经在金税三期关键性技术验证项目中证实，对提高系统的性能、减轻服务器的压力具有关键性的作用：

1、优化业务流程：本项目主要是对行政管理系统进行整合，在项目建设以及后期优化过程中要重点考虑数据流程、功能设计等方面，不要使整合平台成文各系统运行的效率瓶颈。

2、多级缓存：多级缓存是指在多层架构的系统体系中使负载压力尽量均匀分布，即，尽量降低数据库服务器负载，尽量把一些数据和处理分散缓存到应用服务器和WEB服务器上，充分利用众多客户机的处理能力，而数据库服务器更专注于快速地从硬盘上读取数据并把数据持久化（存储）到硬盘上。例如，应用服务器将那些从数据库获取的数据缓存到内存中，然后作逻辑运算和处理；数据库通过预先加载数据到内存中和通过存储一些预先聚合的表来提高访问的速度。

3、并行计算：指采用数据库服务器集群、应用服务器集群、数据分区、并行处理等软硬件集群技术把多台计算机的处理能力合并在一起，从而提供更高的性能和吞吐量；在单台服务器出现故障时，通过把业务切换到其它能够正常工作服务器上，避免了数据库和应用服务器的单点故障。在应用平台和系统设计层面，也采用数据并行处理技术，对大的工作包进行自动拆分、分发到多个应用服务器并行处理。

还采用了包括WEB服务器架构设计优化、应用服务器架构设计优化、数据中心架构设计优化、负载均衡、同步/异步；代码优化：考虑到系统涉及J2EE等多种技术选型，因此我们在本方案针对Java， SQL等不同的代码语言，分别提出了相应的优化方法和编码原则。

（二）从系统支撑环境优化上，重点采用的方法：

数据库优化，提出了针对Oracle、Sybase和DB2等主流数据库的优化方案，从逻辑结构优化，物理结构优化，配置参数优化和管理参数优化等方面提出数据库优化策略。

应用服务器的优化，主要从JVM优化，Server调优，JDBC调优，JMS调优，EJB调优，Web调优等方面多服务器的配置参数进行优化。

操作系统优化涉及磁盘优化，文件系统优化，内存优化和交换空间优化等几个方面。

数据库优化

对于数据库优化，提出了针对Oracle数据库的优化方案，从逻辑结构优化，物理结构优化，配置参数优化和管理参数优化等方面提出数据库优化策略。

一、逻辑结构优化

1.基本表扩展

数据库性能包括存储空间需求量的大小和查询响应时间的长短两个方面。为了优化数据库性能，需要对数据库中的表进行规范化。一般来说，逻辑数据库设计满足第三范式的表结构容易维护且基本满足实际应用的要求。所以，实际应用中一般都按照第三范式的标准进行规范化，从而保证了数据库的一致性和完整性，设计人员往往会设计过多的表间关联，以尽可能地降低数据冗余。但在实际应用中这种做法有时不利于系统运行性能的优化:如过程从多表获取数据时引发大量的连接操作，在需要部分数据时要扫描整个表等，这都消耗了磁盘的I/O 和CPU 时间。

为解决这一问题，在设计表时应同时考虑对某些表进行反规范化，方法有以下几种：一是分割表。分割表可分为水平分割表和垂直分割表两种:水平分割是按照行将一个表分割为多个表，这可以提高每个表的查询速度，但查询、更新时要选择不同的表，统计时要汇总多个表，因此应用程序会更复杂。垂直分割是对于一个列很多的表，若某些列的访问频率远远高于其它列，就可以将主键和这些列作为一个表，将主键和其它列作为另外一个表。通过减少列的宽度，增加了每个数据页的行数，一次I/O就可以扫描更多的行，从而提高了访问每一个表的速度。但是由于造成了多表连接，所以应该在同时查询或更新不同分割表中的列的情况比较少的情况下使用。二是保留冗余列。当两个或多个表在查询中经常需要连接时，可以在其中一个表上增加若干冗余的列，以避免表之间的连接过于频繁，一般在冗余列的数据不经常变动的情况下使用。三是增加派生列。派生列是由表中的其它多个列的计算所得，增加派生列可以减少统计运算，在数据汇总时可以大大缩短运算时间。

因此，在数据库的设计中，数据应当按两种类别进行组织:频繁访问的数据和频繁修改的数据。对于频繁访问但是不频繁修改的数据，内部设计应当物理不规范化。对于频繁修改但并不频繁访问的数据，内部设计应当物理规范化。有时还需将规范化的表作为逻辑数据库设计的基础，然后再根据整个应用系统的需要，物理地非规范化数据。规范与反规范都是建立在实际的操作基础之上的约束，脱离了实际两者都没有意义。只有把两者合理地结合在一起，才能相互补充，发挥各自的优点。

2．索引和聚簇

创建索引是提高检索效率最有效的方法之一，索引把表中的逻辑值映射到安全的RowID，能快速定位数据的物理地址，可以大大加快数据库的查询速度，一个建有合理索引的数据库应用系统可能比一个没有建立索引的数据库应用系统效率高几十倍，但并不是索引越多越好，在那些经常需要修改的数据列上建立索引，将导致索引B*树的不断重组，造成系统性能的下降和存储空间的浪费。对于一个大型表建立的索引，有时并不能改善数据查询速度，反而会影响整个数据库的性能。这主要是和SGA的数据管理方式有关，Oracle在进行数据块高速缓存管理时，索引数据比普通数据具有更高的驻留权限，在进行空间竞争时，Oracle会先移出普通数据，对建有索引的大型表进行数据查询时，索引数据可能会用完所有的数据块缓存空间，Oracle不得不频繁地进行磁盘读写来获取数据，所以，在对一个大型表进行分区之后，可以根据相应的分区建立分区索引。

Oracle提供了另一种方法来提高查询速度，就是聚簇(Cluster)。所谓聚簇，简单地说就是把几个表放在一起，按一定公共属性混合存放。聚簇根据共同码值将多个表的数据存储在同一个Oracle块中，这时检索一组Oracle块就同时得到两个表的数据，这样就可以减少需要存储的Oracle块，从而提高应用程序的性能。

对于逻辑结构的优化，还应将表数据和索引数据分开表空间存储，分别使用独立的表空间。因为如果将表数据和索引数据放在一起，表数据的I/O操作和索引的I/O操作将产生影响系统性能的I/O竞争，降低系统的响应效率。将表数据和索引数据存放在不同的表空间中，并在物理层面将这两个表空间的数据文件放在不同的物理磁盘上，就可以避免这种竞争了。

二、物理结构优化

1．磁盘读写并行优化

对于数据库的物理读写，Oracle系统本身会进行尽可能的并行优化，例如在一个最简单的表检索操作中，如果表结构和检索域上的索引不在一个物理结构上，那么在检索的过程中，对索引的检索和对表的检索就是并行进行的。

2．操作并行优化

操作并行的优化是基于操作语句的统计结果，首先是统计各个表的访问频率，表之间的连接频率，根据这些数据按如下原则分配表空间和物理磁盘，减少系统进程和用户进程的磁盘I/O竞争；把需要连接的表格在表空间/物理磁盘上分开；把高频访问的表格在表空间/物理磁盘上分开；把经常需要进行检索的表格的表结构和索引在表空间/物理磁盘上分开。

3．减少存储结构扩展

如果应用系统的数据库比较脆弱，并在不断地增长或缩小，这样的系统在非动态变化周期内效率合理，但是当在动态变化周期内的时候，性能却很差，这是由于Oracle的动态扩展造成的。在动态扩张的过程中，Oracle必须根据存储的要求，在创建行、行变化获取缺省值时，扩展和分配新的存储空间，而且表格的扩展往往并不是事情的终结，还可能导致数据文件、表空间的增长，这些扩展会导致在线系统反应缓慢。对于这样的系统，最好的办法就是在建立的时候预先分配足够的大小和合适的增长幅度。在一个对象建立的时候要根据应用充分地计算他们的大小，然后再根据这些数据来定义对象Initial、Next和Minextents的值，使数据库在物理存储上和动态增长次数上达到一个比较好的平衡点，使这些对象既不经常发生增长，也不过多地占用数据库。

4．表空间和数据文件优化

尽量把同一时间对磁盘的读写操作分散开，如对一个表中数据进行更新时，数据库将同时去读该表中的数据和该表上的索引信息，如果把表的数据信息和索引信息都放在同一个数据文件中，则数据库的速度将会变慢。最好是把数据信息和索引信息分别放在不同磁盘的两个数据文件中，此时数据库对磁盘的读写操作将分散在两个磁盘上，速度将得到显著提高。因此在设计数据库的表空间和数据文件时，首先给表和表的索引分别创建两个表空间（存放用户数据的数据表空间和存放表索引的索引表空间）。另外，还根据该系统的数据量的大小及系统中的数据的性质不同，再考虑创建几个数据表空间或者给数据表空间添加几个数据文件。

把记录大小相当的表放在同一个表空间中，这时一个表空间的存储参数设置，可以保证表中的记录都放在一个范围中，避免了一条记录跨范围存放，可以明显数据库的性能。

为了避免磁盘的I/O操作冲突，应把数据文件创建在不同位置。

5．重演日志文件优化

由于数据库在利用重演日志文件时是循环使用它们的，而且当LGWR进程在两个日志文件切换时，将自动产生一个检测点，所以重演日志文件的大小会直接影响到检测点出现的频率。而由于在数据库检测点时，对用户而言，数据库的速度会受影响，所以检测点的出现频率大，或者检测点正好出现在数据库处理数据高峰期，将会极大影响数据库的性能。因此，重演日志文件的大小设计，应考虑检测点出现的频率以及检测点应避开数据库处理数据的高峰期。

在ARCHIVELOG模式下时，适当增加重演日志文件组的个数，可以降低数据库存档日志文件的频率。

应把重演日志文件的存档之处设置在磁盘读写更快的物理设备上。这样可以减少日志文件的存档时间。

操作系统优化

一、Unix优化

磁盘优化

对于每一个很大的网站或者那些为很多网站提供网络服务的系统来说，磁盘存储变成了一个问题。一个单面转速为7，200的磁盘每秒可以支撑大概50个静态的HTTP操作，所以你应当在你打算支撑和条带化磁盘直到它们达到极限的状态下，计算出每秒钟有多少个峰值。RAID5 磁盘阵列是一个相当不错的选择。在维护的良好地性能的同时它们提供了一些容错的弹性机制。（主要是因为工作负载恰好是倾向于读）。在一些繁忙的网站，条带化和镜像那些包含HTTP日志的目录是必要的。这些日志将会增长很快的，尤其是在容量高峰期。

文件系统优化

建议创建一个单独的，大的根分区，就像在工作组服务器部分中提到的建议一样。然而，就像以前提到，你应该确保为HTTP的日志文件创建一个分布式的文件系统，同时采取措施去提高写的速度。是否镜像系统硬盘，你自己决定。在大规模的安装系统中，网络服务器是一组Netra Tls，或者是通过一个负载均衡的开关的别的轻量级的机器，或者是一个完全的DNS条目。如果你的内部组织的建立是为了它而工作，一台机器的失败并不是一个大问题。你只能去等待这个机器被替换掉，可以通过一些自动化的工具来重装它。当你被提供给前台页面的实际内容是通过以太络服务器通过NFS（网络文件系统）后备系统，这样效果最好。

内存与交换空间优化

服务器为了达到运行快捷，需要相当多的内存，因为他们趋向于当拥有最大的TCP的缓存的时候性能发挥最好，（当有很多的连接时， TCP缓存消耗内存是很快的）和有广泛的文件系统缓存。作为一个粗略的准则，我将会以256M作为内存的起始值，然后增加文件的大写对于大概可以满足 90％的请求。这些将会有足够的内存去缓存最‘热’的页面。在Solaris8版本之前的系统应当打开页面的优先调度。

网络服务器倾向于不需要太多的交换空间。512M应该足够，就像吸收匿名内存要求它是没有使用过的。

二、Linux优化

磁盘优化

1、优化分区

在安装系统之前，您就需要对硬盘做好恰当的规划。划分一定的文件系统，不仅仅是系统本身的需要，而且在安全层面上也十分有意义。在Linux系统中，我们可以自由地组织磁盘分区。一个优化的分区策略，可以很好地改进Linux系统的性能，减少磁盘碎片，提高磁盘I/O能力。根据磁盘的特点，我们知道越是靠磁盘外部的柱面，旋转越快，而且每次旋转时，磁盘读写头可以覆盖较多的区域，也就意味着靠外部的柱面可以得到较好的性能。所以在分区时，我们应该考虑将访问频率高的，对系统性能影响相对较大的分区置于磁盘的靠外部分。同时，为了减少磁盘碎片，应将内容经常改变的目录放在单独的分区。从方便备份数据的角度考虑，因为很多备份工具对整个分区进行备份的效率要高，所以我们应将Linux系统的几个主要的目录作为单独的文件系统，为它们各自分配一个区。

2、使用elvtune调谐磁盘I/O

在Linux内核2、4以后的版本中，可以通过磁盘I/O的调度操作，来控制磁盘I/O的响应时间和吞吐量。通过调整I/O请求在队列中的最大等待时间，可以在响应时间和吞吐量之间调谐。如果要求较少的响应时间，那么吞吐量将降低，反之，较长的响应时间则可以得到较大的吞吐量。可以使用工具"/sbin/elvtune"来改变最大的响应时间值。查看当前的设置，# /sbin/elvtune /dev/hda1，得到的平均信息（包括平均请求大小和平均队列长度）来监视以上I/O配置的效果，并调整配置，以得到最佳的性能。一般来讲，对于读写频繁，但操作的数据量较少的Linux服务器，且对实时性要求较高，那么可以将参数调小。反之如果对于读写不频繁，但要求具有较大的吞吐量的Linux服务器，可以将参数调大，以获得较大的吞吐量。

文件系统优化

1、块大小

创建文件系统时，可以指定块的大小。如果将来在你的文件系统中是一些比较大的文件的话，使用较大的块大小将得到较好的性能。将ext2文件系统的块大小调整为4096byte而不是缺省的1024byte，可以减少文件碎片，加快fsck扫描的速度和文件删除以及读操作的速度。另外，在ext2的文件系统中，为根目录保留了5%的空间，对一个大的文件系统，除非用作日志文件，5%的比例有些过多。可以使用命令

# mke2fs -b 4096 -m 1 /dev/hda6

将它改为1%并以块大小4096byte创建文件系统。

使用多大的块大小，需要根据你的系统综合考虑，如果系统用作邮件或者新闻服务器，使用较大的块大小，虽然性能有所提高，但会造成磁盘空间较大的浪费。比如文件系统中的文件平均大小为2145byte，如果使用4096byte的块大小，平均每一个文件就会浪费1951byte空间。如果使用1024byte的块大小，平均每一个文件会浪费927byte空间。在性能和磁盘的代价上如何平衡，要看具体应用的需要。

2、不使用atime属性

当文件被创建，修改和访问时，Linux系统会记录这些时间信息。记录文件最近一次被读取的时间信息，当系统的读文件操作频繁时，将是一笔不少的开销。所以，为了提高系统的性能，我们可以在读取文件时不修改文件的atime属性。可以通过在加载文件系统时使用notime选项来做到这一点。当以noatime选项加载（mount）文件系统时，对文件的读取不会更新文件属性中的atime信息。设置noatime的重要性是消除了文件系统对文件的写操作，文件只是简单地被系统读取。由于写操作相对读来说要更消耗系统资源，所以这样设置可以明显提高服务器的性能。注意wtime信息仍然有效，任何时候文件被写，该信息仍被更新。

3、调整缓冲区刷新参数

Linux内核中，包含了一些对于系统运行态的可设置参数。缓冲刷新的参数可以通过调整 /proc/sys/vm/bdflush文件来完成，这个文件的格式是这样的：

# cat /proc/sys/vm/bdflush

30 64 64 256 500 3000 60 0 0

每一栏是一个参数，其中最重要的是前面几个参数。第一个数字是在"dirty"缓冲区达到多少的时候强制唤醒bdflush进程刷新硬盘，第二个数字是每次让bdflush进程刷新多少个dirty块。所谓dirty块是必须写到磁盘中的缓存块。接下来的参数是每次允许bd flush将多少个内存块排入空闲的缓冲块列表。

4、调整文件句柄数和i-节点数

在一个大型的网站服务器其中，可能Linux默认的同时可打开最大文件数不能满足系统需要，我们可以通过调整文件句柄数和i-节点数来增加系统的缺省的限制。不同的Linux内核版本有不同的调整方法。

在Linux内核2、2、x中可以用如下命令修改：

# echo '8192' > /proc/sys/fs/file-max

# echo '32768' > /proc/sys/fs/inode-max

并将以上命令加到/etc/rc.c/rc.local文件中，以使系统每次重新启动时配置以上值。

在Linux内核2、4、x中需要修改源代码，然后重新编译内核才生效。编辑Linux内核源代码中的 include/linux/fs.h文件，将 NR_FILE。

由8192改为 65536，将NR_RESERVED_FILES 由10 改为 128。编辑fs/inode.c 文件将 MAX_INODE。

由16384改为262144。

一般情况下，最大打开文件数比较合理的设置为每4M物理内存256，比如256M内存可以设为16384，而最大的使用的i节点的数目应该是最大打开文件数目的3倍到4倍。

4、使用内存文件系统

在Linux中可以将一部分内存当作分区来使用，我们称之为RamDisk。对于一些经常被访问的文件，而它们又不会被更改，可以将它们通过RamDisk放在内存中，即可明显地提高系统的性能。当然你的内存可要足够大了。RamDisk有两种，一种可以格式化，加载，在Linux内核2、0/2、2就已经支持，其不足之处是大小固定。另一种是内核2、4才支持的，通过Ramfs或者tmpfs来实现，它们不能被格式化，但是用起来灵活，其大小随所需要的空间而增加或减少。这里主要介绍一下Ramfs和Tmpfs。

Ramfs顾名思义是内存文件系统，它工作于虚拟文件系统（VFS）层。不能格式化，可以创建多个，在创建时可以指定其最大能使用的内存大小。如果你的Linux已经将Ramfs编译进内核，你就可以很容易地使用Ramfs了。创建一个目录，加载Ramfs到该目录即可。

# mkdir -p /RAM1

# mount -t ramfs none /RAM1

缺省情况下，Ramfs被限制最多可使用内存大小的一半。可以通过maxsize（以kbyte为单位）选项来改变。

# mkdir -p /RAM1

# mount -t ramfs none /RAM1 -o maxsize=10000

以上即创建了一个限定了最大使用内存大小为10M的ramdisk。

Tmpfs是一个虚拟内存文件系统，它不同于传统的用块设备形式来实现的ramdisk，也不同于针对物理内存的Ramfs。Tmpfs可以使用物理内存，也可以使用交换分区。在Linux内核中，虚拟内存资源由物理内存（RAM）和交换分区组成，这些资源是由内核中的虚拟内存子系统来负责分配和管理。Tmpfs就是和虚拟内存子系统来"打交道"的，它向虚拟内存子系统请求页来存储文件，它同Linux的其它请求页的部分一样，不知道分配给自己的页是在内存中还是在交换分区中。Tmpfs同Ramfs一样，其大小也不是固定的，而是随着所需要的空间而动态的增减。使用tmpfs，首先你编译内核时得选择"虚拟内存文件系统支持（Virtual memory filesystem support）" ，然后就可以加载tmpfs文件系统了。

# mkdir -p /mnt/tmpfs

# mount tmpfs /mnt/tmpfs -t tmpfs

为了防止tmpfs使用过多的内存资源而造成系统的性能下降或死机，可以在加载时指定tmpfs文件系统大小的最大限制。

# mount tmpfs /mnt/tmpfs -t tmpfs -o size=32m

以上创建的tmpfs文件系统就规定了其最大的大小为32M。不管是使用ramfs还是tmpfs，必须明白的是，一旦系统重启，它们中的内容将会丢失。所以那些东西可以放在内存文件系统中得根据系统的具体情况而定。

6、使用日志文件系统

如果Linux系统由于意外情况而没有正常关机，则可能引起文件系统中某些文件的元数据（meta-data即和文件有关的信息，例如：权限、所有者以及创建和访问时间）遭到破坏。文件系统需要维护文件的元数据来保证文件的可组织和可存取，如果元数据处于不合理或不一致的状态，那么就不能访问和存取文件。当系统重新启动时，fsck将扫描/etc/fstab文件中所列出的所有文件系统，确保它们的元数据处于可用的状态。如果发现元数据不一致，fsck将扫描和检测元数据，并纠正错误。如果文件系统很大，这个过程将需要很长的时间。为解决这个问题，可以使用日志文件系统。日志文件系统用独立的日志文件跟踪磁盘内容的变化，在写入文件内容的同时写入文件的元数据。每次修改文件的元数据时，都要先向称为"日志"的数据结构登记相应的条目。这样，日志文件系统就维护了最近更改的元数据的记录。当加载日志文件系统时，如果发现了错误，不会扫描整个文件系统的元数据，而是根据日志检查最近被更改的元数据。所以相对于传统的文件系统（如ext2），日志文件系统大大地加快了扫描和检测的时间。

Linux下可用的日志文件系统很多，如XFS，JFS，Reiserfs，ext3等等。日志文件系统主要被设计为服务器环境提供出色性能和高可用性。当然，

Linux 工作站和家用机器也可从具有高性能的可靠日志文件系统中获益。安装日志文件系统，一般需要下载相应的压缩包、为内核打补丁、重新配置和重新编译内核。

新版本的 Linux 都支持日志文件系统，这类文件系统不仅提供文件完整性上快速恢复，在读写速度上也较普通的 ext2 文件系统有很大提升。

文件的最后存取时间，对很多人来说没有任何用处，因此，我们可以关闭操作系统记录文件最后存取时间的功能，修改： /etc/fstab ：

把 dev/hda6 /home ext2 defaults 1 2

改为：

/dev/hda6 /home ext2 defaults,noatime 1 2

内存与交换空间优化

如果系统内存足够大，而系统又远远用不了那么多的内存，那也就用不到虚存。分区时可以考虑去掉交换分区。不过作为一个Linux服务器，即使内存足够大，还是应该设置交换分区。如果有多个硬盘的话，可以在每个硬盘上各开 swap 分区，另外，建议 swap 分区的大小为物理内存的两倍。

三、Windows优化

Windows Server 2003是从Windows 2000 Server发展而来的，在系统内核和各子系统的性能上都得到了很大的提升。Windows Server 2003是从Windows 2000 Server被设计为自调节的操作系统，一般条件下系统可以提供良好的性能，但在一些特定情况下，指定服务器的设置和参数可以显著提高系统性能。

建议每次只更改一项设置以观察系统性能的提升情况，如果更改设置引起系统性能降低，应该将此设置复原。

处理器调度

Windows使用抢占式多任务机制来分配CPU进程的优先级。这可以防止某进程独占CPU。我们推荐设置Background Services 保证所有的程序使用相同的CPU时间。设置步骤为：打开控制面板的系统――高级――性能――设置――高级。与以上图形界面相对应的注册表项是：

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation

值38：best performance of Programs

值24：best performance of Background services

虚拟内存

Windows中，页面文件是Pagefile.sys，虚拟内存设置步骤如下：控制面板――系统――高级――性能――设置――高级――更改。

配置页面文件优化系统性能：

如果设置为让Windows系统管理虚拟内存，页面文件的大小将被设置为物理内存空间+1MB,这是当系统发生STOP事件（蓝屏）时存放memory dump的最小空间。

页面文件可以在不同分区上创建，最多16个页面文件，每个文件最大4GB。这些不同分区上的页面文件被系统作为一个大的页面文件使用。在同一个分区上创建多个页面文件不是最好的方式。

不推荐使用RAID5阵列存放页面文件，因为页面文件的写强度非常大，这不适合RAID5阵列的特性。

如果可能，不要将页面文件放置在和操作系统相同的一块物理硬盘上――这恰好是系统的默认设置。如果必须这样，那么请确认页面文件和操作系统放置在同一个分区，(如典型的C：)如果把它放在与操作系统相同的物理硬盘的其他分区，将增加硬盘的寻道时间，降低系统性能。原因是磁头将在操作系统分区和页面文件所在分区间来回切换，频繁移动。

记住第一个分区是位于硬盘的边缘，这里硬盘速度最快，性能最佳。

注意如果将页面文件移出引导分区，当系统发生蓝屏错误时将不能创建memory.dmp文件，来帮助分析故障原因。

我们通常推荐手工设置页面文件大小，这优于系统自动设置或根本不设置页面文件。最好将页面文件的最小容量和最大容量设置为相同值，这可以放置在动态调节页面文件大小时处理资源的遗失，尤其是在内存资源紧缺时；还可以确保页面文件在一个单独、连续的区域内，防止硬盘寻道时间增加。

Windows Server 2003自动推荐的页面文件的大小是物理内存的1、5倍，在硬盘空间充足的情况下可以将页面文件设置为内存容量的2倍。执行任务很少的服务器或硬盘空间紧张的情况下可以使用与内存相当的页面文件大小。

文件系统缓存(file system cache)

文件系统缓存是物理内存的一部分区域被用来存放对I/O子系统读写的最近经常访问的数据，包括在硬盘、网卡和网络间传输的数据。

文件系统缓存通过减少对I/O子系统物理设备的访问来提高性能。将经常使用的文件移动到文件系统缓存，磁盘读写操作减少，系统性能从而提高。

应用服务器优化

一、JVM调优

垃圾收集和堆大小

垃圾收集(GC)是指JVM释放Java堆中不再使用的对象所占用的内存的过程，而Java堆(Heap)是指Java应用程序对象生存的空间。堆大小决定了GC的频度和时间。堆越大，GC频度低，速度慢。堆越小，GC频度高，速度快。所以GC和堆大小是一组矛盾。为了获取理想的Heap堆大小，需要使用-verbosegc参数(Sun jdk： -Xloggc：<file>)以打开详细的GC输出。分析GC的频度和时间，结合应用最大负载所需内存情况，得出堆的大小。

通常情况下，我们建议使用可用内存(除操作系统和其他应用程序占用之外的内存)70-80%，为避免堆大小调整引起的开销，设置内存堆的最小值等于最大值即：-Xms=-Xmx。而为了防止内存溢出，建议在生产环境堆大小至少为256M(Platform至少512M)，实际环境中512M~1G左右性能最佳，2G以上是不可取的，在调整内存时可能需要调整核心参数进程的允许最大内存数。对于sun和hp的jvm，永久域太小(默认4M)也可能造成内存溢出，应增加参-XX：MaxPermSize=128m。建议设置临时域-Xmn的大小为-Xmx的1/4~1/3， SurvivorRatio为8。

为了获得更好的性能，建议在启动文件设置WebLogic为产品模式，此时sun和hp jvm JIT引擎为-server，默认情况下打开JIT编译模式对性能也有帮助。调整Chunk Size和Chunk Pool Size也可能对系统的吞吐量有提高。此外还需关闭显示GC： -XX：+DisableExplicitGC。

当然在Intel平台上使用jRockit（使用参数-jrockit）无疑大大提高WebLogic性能。

jRockit调优

jRockit支持四种垃圾收集器：分代复制收集器、单空间并发收集器、分代并发收集器和并行收集器。默认状态下，JRockit使用分代并发收集器。要改变收集器，可使用-Xgc：<gc-name>，对应四个收集器分其他为gencopy， singlecom， gencon以及parallel。为得到更好的响应性能，应该使用并发垃圾回收器：-Xgc：gencon，可使用-Xms和-Xmx设置堆栈的初始大小和最大值，要设置护理域-Xns为-Xmx的10%。而如果要得到更好的性能，应该选用并行垃圾回收器：-Xgc： parallel，由于并行垃圾回收器不使用nursery，不必设置-Xns。

如果你的线程大于100或者在linux平台下，可以尝试使用瘦线程模式：-Xthinthread，同时关闭Native IO：-Xallocationtype：global。

jRockit 还提供了强大的图形化监控工具Jrockit Management Console。

二、Server调优

WebLogic Server的核心组件由监听线程，套接字复用器和可执行线程的执行队列组成。当服务器由监听线程接收到连接请求后，将对它的连接控制权交给等待接收请求的套接字复用器。然后套接字复用器读取离开套接字的请求，并将此请求及相关安全信息或事务处理环境一起置入适当的执行队列中(一般为默认的执行队列)。当有一个请求出现在执行队列中时，就会有一个空闲的执行线程从该队列中取走发来的该请求，并返回应答，然后等待下一次请求。因此要提高WebLogic的性能，就必须从调整核心组件性能出发。

尽量使用本地I/O库

WebLogic Server有两套套接字复用器：Java版和本地库。采用小型本地库更有效，尽量激活Enable Native IO(默认)，此时UNIX默认使用CPUs+1个线程，Window下为双倍CPU。如果系统不能加载本地库，将会抛出java.lang.UnsatisfiedLinkException，此时只能使用Java套接字复用器，可以调整socket readers 百分比，默认为33%。该参数可以在Console Server Tuning Configuration配置栏里设置。

调整默认执行线程数

理想的默认执行线程数是由多方面的因素决定的，比如机器CPU性能、总线体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。WebLogic生产环境下默认的线程为25个，随着CPU个数的增加，WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也就越多，线程数越小，CPU可能无法得到充分利用。为获取一个理想的线程数，需要经过反复的测试。在测试中，可以以25*CPUs为基准进行调整。当空闲线程较少，CPU利用率比较低时，可以适当增加线程数的大小(每五个递增)。对于PC Server 和Window 2000，则最好每个CPU小于50个线程，以CPU利用率为90%左右为佳。由于目前WebLogic执行线程没有缩小线程数的功能，所以应将参数Threads Increase设置为0，同时不应改变优先级的大小。

调整连接参数

WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小，默认值为50。当系统重载负荷时，这个值可能过小，日志中报Connection Refused，导致有效连接请求遭到拒绝，此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用，默认值往往是不够的。Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间，如果客户连接被服务器中断或者SSL容量大，可以尝试增加该值。这些参数可以在Console Server Tuning Configration配置栏里找到。

创建新的执行队列

创建新的执行队列有助于解决核心业务优先、避免交叉阻塞、死锁和长时间处理的业务等问题。通常会将自己的执行队列和默认的执行队列设置不同的优先级，这里优先级不应设为9或者10。定义一个新的执行队列很容易，利用View Excute Queue选项中的Configure a new Excute Queue链接即可定制新的执行队列。创建新的执行队列后，用户需要为应用程序的J2EE组件配置分配策略，以便它可以找到新的队列。举个例子：要将servlet或jsp捆绑到一个特定的执行队列，必须替换web.xml文件项，将wl-dispatch-policy初始化参数设置为自己的执行队列名。

可以为一个jsp或者servlet乃至一个WEB应用设置自己的执行队列。同时也可以为EJB设置自己的执行队列。对于执行时间比较长的MDB，建议使用自己的执行队列。

五、JMS调优

1、增加-Dweblogic.JMSThreadPoolSize=n(至少为5)，以提高处理JMS的线程数，在jRockit上增加-XXenablefatspin以减少加锁冲突；

2、采用文件存储策略，将同步写策略设置为Direct-Write，同时在windows平台上启用磁盘写入缓存；

3、使用分布式目的地时，激活连接工厂Load Balancing Enabled ，Server Affinity Enabled；

4、为减少服务器不必要的JMS请求路由，如果多个目的地之间存在事务，则部署在同一JMS服务器上，尽量将连接工厂部署到JMS服务器所在的WebLogic实例上，集群环境下，则最好将连接工厂部署到集群中的所有服务器上，而集群中每个JMS服务器和目的地成员尽量使用类似的设置；

5、启用消息分页存储功能，以释放内存，可以为JMS服务器和目的地设置，激活Messages Paging Enabled和Bytes Paging Enabled，同时使用限额防止服务器耗尽接收消息的所有可用内存空间；

6、在运行WebLogic Server进程之外的生产者务必使用流控制，并增大Send Timeout；

7、将JMS Server Expiration Scan Interval设很大的值，能禁止主动扫描过期消息；

8、使用FIFO或者LIFO方式处理目的地消息；

9、MDB的max-beans-in-free-pool不应大于最大MDB线程数(默认线程数/2+1)。

代码优化

1）Java代码优化

减小没有必要的操作

对象的创建是个很昂贵的工作，所以我们应当尽量减少对象的创建，在需要的时候声明它，初始化它，不要重复初始化一个对象，尽量能做到再使用，而用完后置null有利于垃圾收集。让类实现Cloneable接口，同时采用工厂模式，将减少类的创建，每次都是通过clone()方法来获得对象。另外使用接口也能减少类的创建。对于成员变量的初始化也应尽量避免，特别是在一个类派生另一个类时。

异常抛出对性能不利。抛出异常首先要创建一个新的对象。Throwable接口的构造函数调用名为， fillInStackTrace()的本地（Native）方法，fillInStackTrace()方法检查堆栈，收集调用跟踪信息。只要有异常被抛出，VM就必须调整调用堆栈，因为在处理过程中创建了一个新的对象。异常只能用于错误处理，不应该用来控制程序流程。

此外，建议关闭Debug输出，尽量少用串行化、同步操作和耗时昂贵的服务（如Date()）。

使用合适的类型

当原始类型不能满足我们要求时，使用复杂类型。String和StringBuffer的区别自不必说了，是我们使用最多的类型，在涉及到字符运算时，强烈建议使用StringBuffer。在做String匹配时使用intern()代替equal()。

带有final修饰符的类是不可派生的，如果指定一个类为final，则该类所有的方法都是final。

Java编译器会寻找机会内联所有的final方法，这将能够使性能平均提高50%。类的属性和方式使用final或者static修饰符也是有好处的。

调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack）中，速度较快。所以尽量使用局部变量。

ArrayList和Vector，HashMap和Hashtable是我们经常用到的类，前者不支持同步，后者支持同步，前者性能更好，大多数情况下选择前者。

尽量使用pool，buffer和cache

使用pool、buffer和cache能大大提高系统的性能，这在J2EE的大部分技术中都是适用的。

2）SQL代码优化

操作符优化

IN 操作符

用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。但是用IN的SQL性能总是比较低的。

推荐方案：在业务密集的SQL当中尽量不采用IN操作符。

NOT IN操作符

此操作是强列推荐不使用的，因为它不能应用表的索引；

推荐方案：用NOT EXISTS 或（外连接+判断为空）方案代替。

<> 操作符（不等于）

不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。

推荐方案：用其它相同功能的操作运算代替，如：

a<>0 改为 a>0 or a<0

IS NULL 或IS NOT NULL操作

判断字段是否为空一般是不会应用索引的，因为B树索引是不索引空值的。

推荐方案：

用其它相同功能的操作运算代替，如：

a is not null 改为 a>0 或a>’’等。

不允许字段为空，而用一个缺省值代替空值，如业扩申请中状态字段不允许为空，缺省为申请。

建立位图索引（有分区的表不能建，位图索引比较难控制，如字段值太多索引会使性能下降，多人更新操作会增加数据块锁的现象）

> 及 < 操作符

大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段A，30万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了，因为A>2时ORACLE会先找出为2的记录索引再进行比较，而A>=3时ORACLE则直接找到=3的记录索引。

LIKE操作符

LIKE操作符可以应用通配符查询，里面的通配符组合可能达到几乎是任意的查询，但是如果用得不好则会产生性能上的问题，如LIKE ‘%5400%’ 这种查询不会引用索引，而LIKE ‘X5400%’则会引用范围索引。

UNION操作符

UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史表UNION。如：

select * from gc_dfys

union

select * from ls_jg_dfys

这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，如果表数据量大的话可能会导致用磁盘进行排序。

推荐方案：采用UNION ALL操作符替代UNION，因为UNION ALL操作只是简单的将两个结果合并后就返回。

select * from gc_dfys

union all

select * from ls_jg_dfys

SQL语句索引的利用

1、对条件字段的一些优化

采用函数处理的字段不能利用索引

2、应用ORACLE的HINT（提示）处理

提示处理是在ORACLE产生的SQL分析执行路径不满意的情况下要用到的。它可以对SQL进行以下方面的提示

1、目标方面的提示：

COST（按成本优化）；

RULE（按规则优化）；

CHOOSE（缺省）（ORACLE自动选择成本或规则进行优化）；

ALL_ROWS（所有的行尽快返回）；

FIRST_ROWS（第一行数据尽快返回）；

2、执行方法的提示：

USE_NL（使用NESTED LOOPS方式联合）；

USE_MERGE（使用MERGE JOIN方式联合）；

USE_HASH（使用HASH JOIN方式联合）。

3、索引提示：

INDEX（TABLE INDEX）（使用提示的表索引进行查询）。

4、其它高级提示（如并行处理等等）

ORACLE的提示功能是比较强的功能，也是比较复杂的应用，并且提示只是给ORACLE执行的一个建议，有时如果出于成本方面的考虑ORACLE也可能不会按提示进行。根据实践应用，一般不建议开发人员应用ORACLE提示，因为各个数据库及服务器性能情况不一样，很可能一个地方性能提升了，但另一个地方却下降了，ORACLE在SQL执行分析方面已经比较成熟，如果分析执行的路径不对首先应在数据库结构（主要是索引）、服务器当前性能（共享内存、磁盘文件碎片）、数据库对象（表、索引）统计信息是否正确这几方面分析。

SQL语句优化

1．尽量避免使用无法使用索引的sql语句

（1）如需要判断数据是否存在，不能用select count(*) from tableName，可以考虑改为：select 1 from tableName fetch first 1 row only；

（2）如果需要进行系列值查询，不建议使用 select col1 from tableName1 where col1 in (select col2 from tableName2 )，建议修改为关联查询：select a.col1 from tableName1 a,tableName2 b where a.col1=b.col2

（3）如果需要进行时间段查询，不建议使用select col1 from tableName1 where dateCol >= date1 and dateCol <= date2，建议修改为：select col1 from tableName1 where dateCol between date2 and date2。

2．避免查询不需要的字段

（1）尽量避免使用select * from tableName的做法，只检索必须的字段；

（2）不检索已经知道的字段，比如select col1,col2 from tableName where col2=’Value’，可以考虑修改为：select col1,’Value’ as col2Name from tableName where col2=’Value’。

（3）在只使用一条语句即可做到时避免使用多条语句；

（4）多个 SQL 语句到一个 SQL 表达式；

（5）使用 SQL 的一次处理一个集合语义；

易用性

针对“易理解”性

通过合理的功能界面设计保证系统所有的业务功能界面风格和操作流程一致；通过合理的功能界面设计保证界面美观、简洁、高效，界面各部件的布局应保持合理性和一致性；通过合理的功能界面设计保证界面颜色调和、提示清晰、窗口大小适当，使用方便；通过有丰富税务和IT经验的专业人员专门设计符合税务行业习惯的快捷键、缩写、提示和图标时应。通过智能表单工具支持业务表单应做到所见即所得。

针对“易学习”

通过有丰富税务和IT经验的专业人员专门设计在线帮助和操作使用手册，使系统关键业务操作应提供在线帮助文档和提示信息，使操作人员能够快速直观的利用这些信息进行相应的业务操作，并对各种状态和操作结果进行及时的反馈和提示。

通过有丰富税务和IT经验的专业人员专门设计使操作使用手册符合税务行业习惯，详细、易读、易理解。

针对“易操作”

此外，通过易用性设计，以及通过有丰富税务和IT经验的专业人员专门使设计能更好的改进系统的易用性。使得软件方便操作，用户能够容易操作和控制。保证常用操作提供快捷键支持，大部分操作能够在小键盘上完成；信息录入能够完全通过键盘完成；逻辑步骤和操作步骤应简单明了，避免超过三次以上的功能选项或菜单选择（纵深层次）；提供软件操作错误的前台回退和纠错功能。保证软件实现过程中，减少客户端插件或客户端软件。提供友好的帮助支持，包括此操作界面的详细操作方法、上下文、有关链接条目等。

可靠性

我们采用有针对性的设计方案以解决相关可靠性问题：

一、三系统架构

本项目应用应该采用三系统架构，即开发系统、测试系统和为生产系统三套系统。

开发系统用于支撑开发人员的日常研发工作及本地测试工作。开发人员开发完成的代码都将提交到开发系统进行统一集成编译，并将相关编译错误信息反馈给开发人员，由开发人员解决相关问题。开发系统的代码由开发人员测试通过后统一打包传送到测试系统以便进行后继工作。

测试环境主要用于完成用例的测试，同时用于应用系统的培训工作。测试系统是保证整个系统用例业务逻辑准确无误的关键环节。在此系统不但需要进行用例正确性测试，同时还应该进行关键用例的性能测试工作，以此来保证系统的业务的准确实现和系统的性能。当生产环境功能用例发生性能问题时，应首先测试环境进行测试分析，应尽可能的重现问题，从而对性能问题展开分析，并提出有针对性的解决方案。功能用例在测试系统中测试无误后将统一打包传送到生产环境进行集成发布。

生产环境用于完成实际日常业务的处理工作。

三系统架构可以让用例代码从开发到测试再到发布生产环境都经过严格的测试，代码得到了很好的控制。三系统之间的代码传输引擎很好的解决了代码的发布集成问题，有效降低了生产环境发布的风险，从而提高了生产环境的可靠性。

二、数据备份机制

对于数据的保护是实现应用容灾的基础，通过数据备份机制，采用数据同步复制技术，可以对数据进行有效的保护，防止数据丢失。

集群可靠性分析：集群系统把系统的可靠性从单机的95% 提高到了99.999%，为本地的高可靠性提供了有效保证。

三、系统架构的可靠性

基于应用支撑平台的系统可以支持当前世界上各种提高系统可靠性的方式，比如可以支持双机热备，可以支持异地的灾难备份，可以支持异地的磁盘级存储镜像等等。

在系统可靠性方面，应用支撑平台能够与硬件合作伙伴提供的产品紧密集成在一起，为客户提供整体的高可用性解决方案。

系统一般通过调用数据的备份功能实现数据库备份。但是备份管理的工作是由应用支撑平台来执行的，同时应用支撑平台以完全图形化的方式管理和执行备份，减少了操作的复杂性和出错的机会。在应用支撑平台中可以建立备份的计划模版和备份周期。通过应用支撑平台的备份策略，系统管理员可以自动调度数据库备份的执行时间，比如在晚上12:00自动执行，那么系统管理员只要在下午5:00下班时，将对应的磁带放入磁带机，系统就会在晚上12:00自动进行系统备份，实现真正的无人值守的数据库管理。

在数据库层，应用支撑平台和数据库厂商一起支持软硬件容错，支持数据库逻辑备份/恢复和物理备份/恢复。同时支持磁盘镜象，多CPU模式(SMP、Cluster、MPP)系统，双网络环境，支持数据库日志，联机备份和恢复，及各种复杂技术，因些具有极高的容错性。

应用支撑平台架构中没有单点故障，能实现WEB一级的对用户透明的高可用性及负载均衡。

应用支撑平台中引入并实现了应用层次的事务处理，保证了应用层次的数据完整性，任何业务数据在系统中只有两种状态，一种是完全更新，一种是不能更新，不存在第三种更新状态。同时应用支撑平台中实现了跨越不同应用模块的数据完整性，一个应用支撑平台，不论有多少个用户，运行哪些应用模块，它都是基于一个公共的数据库环境的。数据只需输入一次，即可被整个企业共享。我们以多年税务行业的经验，成熟的应用代码，保证系统范围的所有应用模块间数据的集成、完整性和一致性。

可用性

可用性是指系统要求24×7×365的连续可用。基础技术平台必须提供满意的系统可用性，包括计划和非计划的停机都必须满足规定的服务水平要求。需要在以下几个方面进行考虑：

一、本地的高可用性和冗余部署

本项目应用系统的本地的高可靠性通过以下的方式实现：

WEB层、核心层部署多台服务器；

数据库服务器采用双机并行处理方式；

数据资源通过磁盘的镜像技术消除磁盘、存储系统的单点故障；

二、数据同步备份，保证数据的安全性

对于数据的保护是实现应用容灾的基础，通过建立数据备份，采用数据同步复制技术，可以对数据进行有效的保护，防止数据丢失。

数据备份建议采用存储设备的同步复制技术，提高数据的可靠性并且不会对服务器主机的性能产生大的影响。

可用性设计

一、本地的高可用性和冗余部署

系统架构采用三层体系架构，部署分为数据库层、应用层和Web接入层，当数据库服务器发生故障时，应用支撑平台的应用服务器可以自动连接到新的数据库服务器，而不必停止重启动，这样缓冲区中的大量数据就得以保留。软件切换的容错技术可使系统的有效工作时间占原设计工作时间的比例达到99.99%。

WEB层、应用层通过部署多台服务器：利用负载均衡技术实现系统的高可用性和高性能，消除单点故障，满足业务连续性的要求；

数据库服务器：通过采用双机并行处理方式，消除单点故障，提供系统的可用性和可靠性；

数据存储层：通过高端存储设备的本身的冗余，通过磁盘的镜像技术，消除磁盘的单点故障，存储系统的单点故障，保证业务的连续性要求；

数据备份：定时的将数据备份到备份阵列，可以对数据进行有效的保护。

应用支撑平台一般是通过调用数据的备份功能实现数据库备份。但是备份管理的工作是由应用支撑平台来执行的，同时应用支撑平台以完全图形化的方式管理和执行备份，减少了操作的复杂性和出错的机会。在应用支撑平台中可以建立备份的计划模版和备份周期。通过应用支撑平台的备份策略，系统管理员可以自动调度数据库备份的执行时间，实现真正的无人值守的数据库管理。

在数据库层，应用支撑平台和数据库厂商一起支持软硬件容错，支持数据库逻辑备份/恢复和物理备份/恢复。同时支持磁盘镜象，多CPU模式(SMP、Cluster、MPP)系统，双网络环境，支持数据库日志，联机备份和恢复，及各种复杂技术，因此具有极高的容错性。

系统管理工具确保了服务器、网络和数据库的易管理性。有效地使用分布资源可产生如行业标准基准测试中所示的高性能级别。扩展的功能和指导方针致力于高级系统的可用性。

二、设计基于SOA系统架构的热部署机制

基于SOA的系统实现了系统的模块化，不同的业务需求对应不同的功能模块。当业务发生变更时，可以通过系统架构所支持的热部署机制，可以实现生产环境不停机情况下针对业务模块的动态更新操作。此项机制不但可以用于生产环境的发布，同时可以用于修复生产环境中发现的需要紧急处理的错误。

除了维护或升级之外，确保一周7天，每天 24 小时理想的无停机运行。高可用性是每个 IT 部门的关键任务。应用平台提供功能以允许故障转移、分发请求到其它服务器、DB 再连接等，从而提供高可用性。

可维护性

一个可维护的程序应是可理解的、可靠的、可测试的、可修改的、可移植的、效率高的、可使用的。但要实现这所有的目标，需要付出很大的代价，而且也不一定行得通。因为某些质量特性是相互促进的，例如可理解性和可测试性、可理解性和可修改性。但另一些质量特性却是相互抵触的，例如效率和可移植性、效率和可修改性等。因此，尽管可维护性要求每—种质量特性都要得到满足，但它们的相对重要性应随程序的用途及计算环境的不同而不同。所以在对程序的质量特性提出目标的同时，还必须规定它们的优先级。这样有助于提高软件的质量，并对软件生存期的费用产生很大的影响。

健全程序的文档

程序文档是对程序总目标、程序各组成部分之间的关系、程序设计策略、程序实现过程的历史数据等的说明和补充。程序文档对提高程序的可理解性有着重要作用。即使是一个十分简单的程序，要想有效地、高效率地维护它，也需要编制文档来解释其目的及任务。

而对于程序维护人员来说，要想对程序编制人员的意图重新改造，并对今后变化的可能性进行估计，缺了文档也是不行的。因此，为了维护程序，人们必须阅读和理解文档。那种对文档的价值估计过低的看法，是由于过低估计了用户对改变的要求而造成的。

程序应当成为其自身的文档，也就是说，在程序中应插入注释，以提高程序的可理解性，并缩进、空行等明显的视觉组织来突出程序的控制结构。如果程序越长越复杂，则它对文档的需要就越迫切。

另外，在软件维护阶段，利用历史文档，可以大大简化维护工作。例如，通过了解原设计思想，可以指导维护人员选择适当的方法去修改代码而不危及系统的完整性；又例如，了解系统开发人员所认为的系统中最困难的部分，可以向维护人员提供最直接的线索，来判断出错之处。历史文档有三种：

系统开发日志：记录了项目的开发原则、开发目标、优先次序、选择某种设计方案的理由、决策策略、使用的测试技术和工具、每天出现的问题、计划的成功和失败之处等。系统开发日志在日后维护人员想要了解系统的开发过程和开发中遇到问题时是非常必要的。

运行记录：把出错的历史情况记录下来，对于预测今后可能发生的错误类型及出错频率有很大帮助，也有助于维护人员查明出现故障的程序或模块，以便去修改或替换它们。此外，对错误进行统计、跟踪，可以更合理地评价软件质量以及软件质量度量标准和软件方法的有效性。

系统维护日志：记录在维护阶段对系统修改和相关信息。

软件升级：软件通过严格的版本控制，正常的优化迭代，确保已发生的问题完善的解决并发布到新的版本中，形成良好的迭代。

可扩展性

我们在构建系统架构时，为了确保架构设计的可扩展性，考虑了下面几个要素：低耦合，接口以及封装。SOA架构的设计原则已经隐含地解决了这几个可扩展性方面的要素。这是因为SOA架构中的不同服务之间本身就保持了一种无依赖的低耦合关系；服务本身是通过统一的接口定义（可以是WSDL）语言来描述具体的服务内容，并且很好地封装了底层的具体实现。因此我们在构建征管系统的架构时，充分理解和吸收SOA架构设计理念。

为了更好的满足系统可扩展性的需求，我们采用了以下的创新理念和技术。

分层的系统架构

我们将应用系统主要分为客户层、前置层、核心层和数据资源层。在客户层和web层，主要实现系统的各种功能界面展现，提供跨平台的多种访问方式，可以通过客户端、浏览器、以及一些其他的集成办公工具；在前置层和核心层，通过集成的分发器实现将各种不同的前端访问请求分发到各服务点；在数据资源层，支持标准的关系型数据库，通过远程SQL访问获取、写入数据。

应用支撑平台的支持

1、流水线式的开发方式

模拟工业生产的流水线体系，将软件产品开发过程、岗位设置和工作内容标准化、规范化，各环节充分共享中间产品成果，从而实现大规模协同开发。采用流水线的开发方式，可以建立起完善的团队协作机制，降低人员的技术要求，提高软件开发效率和质量。

2、随需自变式的维护方式

基于应用支撑平台，我们不但负责软件的开发，同时兼顾软件的运行维护。软件产品在运行过程中，借助工作流、业务规则管理系统等提供的定制功能，只需简单进行调整配置，就可以满足大部分的业务需求变化，实现用户需求的快速响应。

3、企业技术体系的积累机制

应用支撑平台提供了一套完整的构件模型和构件库，可以帮助企业建立起有效的知识积累体系，将企业成熟的业务与技术以构件方式不断积累到企业构件库中，在软件开发过程中可以重复使用这些构件，实现最大程度的复用。

4、插拔式的开放体系结构

基于应用支撑平台基于完全开放的体系结构，并提供插件式的扩充机制，第三方开发商在此基础上可以简单、快速地开发出依赖于基于应用支撑平台的功能工具，使得平台的功能可以不断的得到扩充和完善。

5、开发与管理相结合的开发工具

基于应用支撑平台将软件开发工具与开发过程管理工具相结合，从而使得开发人员可以随时了解自己的开发任务和工作要求；管理人员可以及时掌握项目的开发进度，并对项目下一步的工作做出正确的规划。

工作流（WorkFlow）技术

采取流程无关的工作流引擎设计，符合业界标准，满足简单到复杂的流程需求。底层引擎采取完全开放式的接口设计方法。同时，我们针对税务系统的岗责体系及稽查业务的业务流程嵌套等特殊业务，在标准的工作流产品基础上扩展了税务业务特殊需求的行业定制流程处理框架。这也体现了我们的工作流产品具备良好的可扩展性。

安全性设计

通过SSL来保障数据传输安全；

通过统一认证、CA等方式来保障操作用户的操作权限安全。

通过运行监控、运行审计和日志记录机制的结合实现信息的安全性。从而可以记录该信息的来源、目的地和操作人员信息，有利于划清事故责任。

通过各种安全加密硬件，确保了数据传输过程的安全，防窃取和防篡改。

系统提供的交易监控和任务监控工具可以实时监控到当前系统正在处理的事务，可以帮助系统管理员及时掌握系统的状态。除了全记录监控外，还需要提供筛选的功能，使监控程序只把符合条件的交易列出来，比如只列出处理错误的交易、或者受控的交易记录等。

系统提供日志记录机制，不仅利用中间件产品的系统日志，而且要在应用系统中开发日志服务，为各平台提供统一地日志记录机制。在多用户并发访问的环境下，它能够在运行过程中精确记录运行时的上下文；日志信息可以根据需要分为不同的等级，并能够根据需要选择不同级别的日志信息的输出；日志信息可以输出到不同的地方（控制台，文件，日志服务器等等）以备查阅。