谈大集中系统的性能优化策略

1.1 前言

　　税务大集中信息系统性能优化方面，我们从技术和业务两个方面，进行前后台架构如何优化、多层架构各层如何优化、编码程序如何优化等，以及对业务的改进和系统功能优化。

　　技术方面，除了考虑硬件平台、系统资源外，考虑软硬件资源分配等系统性能优化手段，以及应用架构体系、数据库架构的优化;另外，从应用系统编码方面，考虑编码的调整与优化;业务方面，考虑业务规则的调整优化。

1.2 正文

　　税务大集中信息系统的基本性能保障目标，最起码达到几点要求：

　　前台税务登记保存时间不超过3秒。

　　前台申报开票保存时间不超过2秒。

　　其他前台保存时间不超过3秒。

　　后台操作保存时间不超过5秒。

　　后台查询时间不超过1分钟

　　在此目标基础上进行系统性能改进，我们从以下几个方面进行描述。主要优化的范围和手段说明如下：

　　


　　由此可见，性能优化的范围，主要从操作使用层、业务层、架构层、数据存储、操作系统等几个方面进行分析。

　　操作使用方面，主要考虑操作的简便性、减少系统请求、合理控制分配各个功能点的使用等方面。

　　业务层主要考虑业务体系的优化，如对一些流程复杂的业务如何进行流程统一;应用系统功能如何进行拆分以达到功能配置最优化。

　　架构层从系统架构和应用架构两个角度考虑，包括事务控制、代码缓存、权限管理体系、远程调用、工作流引擎等内容。其优化手段主要有优化缓存管理、支持多数据源、应用服务部署优化等方面。

　　数据库层的优化范围包括数据库的库表结构设计、数据存储、数据库操作等方面考虑，主要优化手段包括表结构设计的规范化、分区存储、查询优化、索引的使用等策略。

　　操作系统层的内容考虑系统的并发用户数、吞吐量，系统可靠性等方面，优化手段包括多任务处理、负载均衡等手段。

　　1.2.1 应用系统优化

　　1.2.1.1 架构体系
　　大集中系统应用框架主要包括：业务逻辑层模式，事务控制，数据源获取，代码缓存，客户端对核心应用的调用方式，持久层，web框架，用户权限，工作流，GUI，EAI，任务队列等模块，实现了客户端的独立、分布式的、可扩展的、基于组件的架构、通过EAI集成内部和外部的其他系统。

　　(1) 缓存的使用：对系统经常使用的代码表、SQL语句和配置信息等内容进行缓存，提高系统的运行效率。

　　(2) 资源池：资源池技术使用的是一套准备好的资源，与在请求和资源之间维持1：1 的关系的不同，这些资源可被所有请求所共享。资源池的使用是有条件的，需要衡量下面两种方式的代价：A,维持一套可被所有请求共享资源的代价B,为每个请求都重新创建一个资源的代价。当前者小于后者时，使用资源池才是有效率的。

　　1.2.1.2 应用程序编码
　　编码有关的优化手段，主要是考虑架构的编码，性能优化方面主要有以下几个手段：

　　1、 把常用但是变化不大的代码(主要是代码表和参数表)放在缓存中，以加快系统的访问速度。

　　2、 对查询结果的条数进行限制，否则一旦一个客户进行了大数据操作，服务器就会死机，建议现在采用web的路由方式解决。

　　3、 灵活支持多数据源的存取，满足省局集中后市局个性化数据的处理，即各个地市不同的数据库存取。

　　1.2.1.3 核心业务优化
　　现在2.0系统的业务体系是建立在地市集中的基础上，适合于地市级业务模式。省集中模式下，相应的业务体系需要进行调整，以使用新的业务模式，从从规范化业务流程，优化业务内容的角度，业务层优化考虑以下方面的内容：

　　1.应用部署的分离：如个人所得税全员申报进行部署分离，通过单独部署应用、独立存储、开发个税客户端软件等手段，分离个人所得税有关的业务和数据;

　　2.业务功能拆分：由于省集中情况下用户范围和数量发生了变化，从性能角度出发，需要对原有的业务进行规划，把大的重量级业务进行分解，减轻业务操作的压力。如在开业登记环节，为了减轻登记录入的工作量，建议增加一个受理环节，进行简易数据审核，录入必要的输入项，满足打证的需要，详细的数据在事后进行补录。

　　3.前后台业务分离，根据前台业务量特点，保证性能的角度出发，将一些业务进行前后台内容分离，确保前台办税服务事项等性能保障。

　　1.2.2 平台及数据库优化

　　1.2.2.1 应用服务器
　　选择硬件平台需要考虑许多因素，至少包括：价格，硬件部署，厂商的表现，性能，等等。

　　应用开发完毕、服务器选定之后，还要考虑操作系统和Java虚拟机的配置选项，适当地配置这些选项无疑也能够提高性能。

　　(1) 任务并行处理：一个任务分解为更为简单的子任务，并能够同时在不同的线程中执行。。

　　(2) 异步处理：异步处理是通过缩短那些在将控制返回给用户之前必须处理的时间来提高性能。虽然都做同样多的事情，但是用户不必等到整个过程完成就可以继续发出请求了。但这种方式降低了服务器的处理压力，使服务器可以接收更多用户的申报请求。

　　(3) 负载均衡：负载均衡的思想是将原本在一台服务器上的压力按照人为设定的规则分流到功能类似的一类服务器上。这一思想的具体表现是通过路由的方式使不同区域或不同业务的请求分流到不同的服务器上。这将减少应用服务器的压力，使服务器的性能得到优化。

　　1.2.2.2 数据存储优化
　　1.借助ORACLE的分区技术，将历史数据进行分离。

　　大集中的税务管理信息系统，在数据量上达到T级， 对业务应用系统有了更高的要求。要适应大集中， 那就必须对地市级数据保有量超过50万的数据表(如鉴定数据、发票资格认定数据等)。对数据的月增量超过50万的数据表不光要进行按地市按时间进行分区， 还要对长期历史性数据和短期活动性数据分离，在生产数据库中只保留两年的数据，提供必要的业务数据支撑，保障生产库以更高的效率为征管业务服务， 对两年以上数据的查询在数据库仓库和ODS数据库中提供数据服务。

　　2.在分区技术的基础上，进一步根据时间、机关、税款类型等条件对数据表级进行物理分离。

　　在应用系统集中以后，我们还要对分区后的数据，根据业务和需要进一步的分离， 如根据时间、机关、税款类型等条件进一步进行分表、分库、分设备存储。保证数据的存储满足查询等操作的实时性需要。

　　1.2.2.3 数据库查询性能优化
　　从应用层对查询的需要，针对不同管理用户的实际需求进行分析分类定制，确保依据管理视图不同，使用尽量少的数据来满足尽量多的需求，避免大量数据直接操作。

　　对于实时查询和实时统计的业务需求，原则上采用物化视图等手段，首先统计后台系统已迁移、已加工的明细或汇总数据，再加上当天发生的实时明细数据，进行累加后计算出实时结果的方式。避免直接访问生产库。

　　结合数据库部署和数据存储的有关设计，通过对查询的条件进行优化，使之有效利用分区和索引技术，提高查询效率。

　　1.3 总结

　　性能与应用系统的代码、应用服务器都都有着密切的关系。应用的代码写得再好，如果应用服务器的配置不当，性能也不会好;同样地，应用服务器调整得再好，也难以掩盖应用代码中存在的缺陷。因此，首先要保证应用有一个稳固可靠的体系结构，有最优质高效的代码，在此基础上再来集中精力调整应用服务器，这样才能达到大集中应用系统性能优化的理想效果。