金税三期工程省级应用集中优化实施方案(编辑修改稿)

金税三期工程省级应用集中优化实施方案(编辑修改稿)内容摘要：

（ 2）性能 优化 方面 22 1） 优化内部服务组件 优化内部服务注册表的查询机制，如使用更优化的 Hash算法替代 Java 默认实现方式以提高查找效率。 优化内部服务调用 机制，如优化 ASM 生成的动态服务代理类代码质量。 根据环境配置信息，动态整合服务的拦截处理方法和服务调用方法， 将解析调用转为按需硬调用。 优化服务版本化管理机制，目前不同版本的服务注册成不同的服务条目，造成服务条目过多，应采用适当机制缩减内部服务的条目数量，提高服务查找和管理性能。 2） 提供状态缓存服务组件 提供状态数据管理平台，通过算法将数据库中的相关状态数据映射到应用服务器的内存状态位上。 提供状态数据访问客户端，业务逻辑调用功能客户端访问 和更新 状态数据缓存中的状态信息。 3） 提供应用级锁管理组件 提供锁管理服务器，用于应用层的锁信息存储，并提供锁的检查和管理功能。 提供锁数据访问客户端，用于业务逻辑与锁服务器进行23 通讯。 （ 3）项目管控方面 1）框架开发者提供详细的开发指导手册，加强开发人员的技术培训，保证开发人员能正确使用框架提供的功能；提供代码扫描工具，提高代码质量。 2）完善代码审查制度，强化制度落实与执行。 3）加强软件测试，提高自动化测试的覆盖率，同时加强边界测试。 （二）应用集成平台方面 1．现状和 问题分析 在省级应用集中，应用集成平台定位在既要承担金三内部系统之间的应用集成，同时 还要承担各省的渠道系统接入到内部系统的应用集成（原来是由前置软件负责），在总局和各省局国地税也要分别部署，这将对应用集成平台的功能性、可靠性、稳定性提出了更高的要求。 应用集成平台采用服务代理模式，不部署业务服务，业务服务部署在提供服务的系统上，应用集成平台作为代理负责转发业务服务请求，所提供服务的业务逻辑由提供服务的系统执行。 而服务容器是指将业务逻辑处理部分封装为独立24 的服务部署在应用集成平台上，应用集成平台可作为服务容器直接接收并执行服务。 目前，应用集成平台采用服务代理模式，实现了平台与业务逻辑的解耦，业 务逻辑变化和部署不影响平台，平台轻量，不直接处理业务逻辑。 在目前的全国应用集中，在总局部署了一套应用集成平台，它提供总局新建系统间的应用集成，如征管和个税、纳服和征管的待办事宜集成、征管和网络发票；在各省国税和地税也分别部署了一套应用集成平台，负责提供省内特色系统和总局遗留系统接入到核心征管的应用集成。 另外，核心前置也部署在总局，承担了纳服、税库银等渠道软件的应用接入；而部署在各省局国地税的核心前置负责国地税大厅的应用接入；这些核心前置和应用集成平台的本身功能差不多，只是接入系统及其服务不一样，并且在核心 前置上部署了业务预处理服务。 从目前 3个已上线省市的应用来看，并基于省级应用集中的考虑，应用集成平台在如下几个方面存在不足： （ 1）异常故障性保障和隔离：在出现异常时的处理和故障隔离还需要完善。 1）异常处理机制：目前对于 JMS 消息处理方式，如果在目标系统网络一直出现异常故障下， JMS 消息会一直连续发送到目标系统，这会无故消耗系统资源，可能会影响系统其他业务运行。 25 2）故障保障隔离：在 EJB/WebSerivce 等同步模式下，目前的流量控制在线程数足够时可以起到故障隔离，如果高并发服务请求过多导致线程不足而 服务处理很慢时，这时可能会造成系统堵塞，并且由于缺少服务优先级控制，可能会导致高优先级业务服务也无法处理。 （ 2）界面化配置：目前应用集成平台的参数配置基本上都是通过 DML 数据库脚本在系统升级或打补丁时执行生效，而没有提供界面在生产环境由系统管理员进行配置。 1）静态参数配置：虽然很多静态参数作为版本信息是可以通过 DML 脚本进行初始化配置，但有些静态参数可能在具体环境有差异，这就最好需要提供界面来配置，如：各种协议的 IP 端口地址等信息。 2）动态参数配置：对于需要根据系统运行情况调整的参数，目前也是通过 DML 脚本执行，如流量配置、接入配置等。 （ 3）扩展性功能：目前业务需求功能的变化，完全是由服务具体来实现，应用集成平台没有提供服务编排等功能，这样就无法实现只需平台级的定制而无需业务服务变化修改。 同时，作为服务提供系统方和服务消费系统方，在使用应用集成平台方面以及各方相互协作配合方面，主要出现如下的问题： 26 （ 1）规范性：在应用集成平台规范还不是很完善和执行协调不到位。 1）服务梳理划分：服务划分太细会造成交互频繁，增加系统压力。 2）超时控制：未结合征管及其他接入系统的整个链路时间进行配置，易出现系统间配置 参数不匹配而引起的服务异常，如网报系统配置超时时间为 5S，征管系统配置超时时间为 10S，应用集成平台配置超时时间为 30S，此种情况将出现应用集成平台在征管系统未有正确返回时因超时而断开请求。 （ 2）协同性：在各方系统集成时，由于同时存在前置和应用集成平台，在选择接入时容易困惑；同时选择了不恰当的集成方式和接入方式，比如应该应用集成而使用了数据集成、本地特色应用和渠道系统过多使用异步方式协议、集成调用的次数较多。 通过这些问题分析，应用集成平台在功能性、可靠性、稳定性还需要完善，并且还需要加强应用集成平台规范 的执行完善和各集成方的协调配合。 2．调整目标 （ 1）简化规范应用集成：尽量简化应用集成，规范应用集成方式和同步异步接入方式。 （ 2）提高配置易用性：增加灵活配置功能界面，动态27 满足系统变化要求，如：系统压力大时动态配置流量以限流等。 （ 3）加强故障处理和可靠性：在系统出现异常故障时，应用集成平台需限制系统的故障范围而不至于系统故障蔓延，提供系统在可承受压力范围内正常运行的保障机制，尽量减缓或限制系统压力，同时保障关键服务可被优先执行。 如流量控制和优先级控制。 （ 4）增强服务扩展性：在业务发生变化时，应用集成平台可根据已有服务编排组合成新的服务，以动态满足适应业务变化，如增加服务编排功能。 3．优化 方案 为了实现上述目标，应用集成平台具体改进措施如下： （ 1）简化规范应用集成 渠道系统改为统一接入到应用集成平台，前置软件将去掉。 合理选择系统之间的集成方式，特别注意选择好应用集成的同步异步接入方式。 （ 2）故障隔离 有两种方案，利用 weblogic 工作管理器分别控制请求和响应线程数和优先级，或自主研发队列机制增加分组、优先级功能。 1）基于 weblogic 工作管理器定制开发：根据业务需求预先在工作管理器中定义不同 的线程组，来自不同渠道、针28 对不同服务的请求会使用不同的线程组，同时对后面不同系统的服务的调用也使用不同的线程组。 使任何服务的拥堵不会蔓延。 优点 ：技术明确，风险可控；工作量可控，通过配置 +资源适配器的定制开发。 缺点 ：使用 weblogic 优先级的应用案例不多，需要验证具体使用策略；和 weblogic耦合紧密，完全依赖 weblogic；服务请求方发起请求时须指定业务组件实例的级别。 2）自主研发队列机制增加分组和优先级处理：通过队列和连接适配器控制服务在请求和响应按照不同分组和不同级别执行。 优点 ：完全自主， 按照 JCA 规范；服务请求方无需关心优先级，通过应用集成平台本身配置实现。 缺点 ：技术上有难度，存在技术风险；工作量大，需要保障稳定性和性能。 建议 先采用方案 1 过渡，最终 过渡 为 方案 2。 （ 3）配置管理 完善超时配置功能界面等，完善现有功能界面。 增加流量配置功能界面等，根据需求增加功能界面。 （ 4）服务监控 完善服务的运行状态、运行效率、运行是否有错误等的监控。 若有问题及时告警，降低运维压力。 29 （ 5）服务编排 针对现有服务提供 XML 报文内容的输入输出处理，也能够把多个服务按照一定规则串接组合起来。 编排后的服务 作为一个新的服务暴露出来，且对原来的服务代码无须修改。 应用集成平台需支持服务编排功能，但是此功能实现优先级低，在遇到有需要业务场景时使用。 除了上述应用集成平台具体改进措施，还需要加强应用集成平台规范的执行完善和各集成方的协调配合。 （ 1）需要不断完善和遵照执行的应用集成平台规范有： 1） GT3HXZJ应用集成平台接口规范 2） GT3HXZJ应用集成平台接入规范 3） GT3HXZJ应用集成平台数据定义规范 4） GT3HXZJ应用集成平台数据交换规范 （ 2）各业务系统需要对服务高度抽 象梳理，对各种系统消费方提供的服务尽量保持一致，并尽量减少系统之间减少次数。 （ 3）各方协调配置好超时时间。 （ 三 ） 工作流 方面 1. 存在问题 工作流系统是金税三期基础软件平台中的重要组成部分。 金税三期系统采用了中创公司提供的工作流软件InforSuite Flow，该软件已在多个大型信息系统项目中应30 用，它是遵循 WFMC 规范、支持采用 XPDL 形式 XML 进行流程定义的工作流中间件，为工作流自动化及流程再造提供基础平台，为金税三期工程提供基础的、统一的流程管理平台。 该工作流产品结构如图所示： 图 InforSuite FS 产品架构 InforSuite Flow工作流软件提供了统一的 BS流程建模平台，可以用于累积业务流程模型，并可便于服用业务模型。 流程建模平台功能众多，包含了流程分级定义、下发、逐级个性化扩展定义同一业务流程等特色功能。 在金税三期中使用工作流工具的目的是增强征管系统的适应性，有效支持业务由职能导向转变为流程导向，由结果 监督转变为过程监督。 工作流软件被用于支撑金税三期工程核心征管、个税、行政办公、纳税服务、管理决策等多个项目，各项目对 InforSuite Flow 工作流软件进行了集成，并分别对工具相关功能进行了封装或个性化扩展，构建了各31 自的工作流框架。 目前核心征管系统的各个应用域分别有对应的工作流域，工作流域主要涵盖了工作流服务框架及工作流引擎和工作流数据库。 简单来说，核心征管系统的工作流的部署方式是“多实例多数据库”。 个人税收管理系统则采用了“多实例单数据库”的工作流部署方式，个税系统各应用域内嵌了工作流服务框架及工作流引擎，但共享一个数据库。 图 金税三期核心征管系统工作流架构概要示意图 金税三期系统用户最常用的功能就是打开待办任务列表或在办任务列表，在办理流程性事务时大量的使用到推送功能，而这两者都是由工作流系统来承载、实现的，对于前台办税的纳税人而言，办事是否便捷、税务机关服务是否高32 效优质，很大程度上是由工作流框架和工作流引擎的功能、性能和开发规范性直接决定的，税务系统内部用户的用户体验也与之息息相关。 从目前已上线单位的反映和双轨测试环境实际体验来看，目前金税三期工作流系统存在以下突出问题： 一是 初 始化配置特别复杂。 当前，工作流配置方面主要存在的问题有三点：一是相关的初始化配置非常复杂，工作量大：初始化配置极为繁琐，耗时很长。 金三系统在工作流配置上有着数倍于大集中系统的工作量：流程类工作建模中需要额外维护职能树，工作流节点的角色对应关系、表单路径、回调服务与关联流程等内容；非流程类税务事项也需要额外维护角色与税务事项对应关系以及职能树相关的内容。 整个金三系统的流程类工作流建模工作量复杂度可以表达为如下： O（流程环节节点数职能树数目税务机关岗位数目角色表单路径回调服务关联流程操作机关 ），对于非流程类事项，其不涉及具体的工作流配置，而是使用特定的角色对应的功能模块进行实现，因此其复杂度同理表达如下： O（非流程类事项数职能树数目税务机关岗位数目角色）；二是因配置而产生的运行出错概率极高，难以在配置时校验配置的合法性，降低了初始化工作的效率；三是排查问题的难度大。 初始化工作流的配置工作包含了工作流图绘制以及每个节33 点的推送规则、标签规则、事件规则、时间期限的配置等工作。 二是 健壮性不佳，待办事宜可能丢失、延迟，偶有出现事务不完整问题，错误处理机制不完备。 在总局集中版本运行期间，遇到 过较多的由于 JMS 消息延时所产生的阻塞问题，造成“待办门户无法及时展现待办任务、甚至一直收不到”，或者是“待办任务点击异常后任务消失或者仍然存在，再次点击仍然异常”、“在流程监控能看到某任务，但在待办事宜中却找不到对应任务”等现象；发生过一次点击后，业务数据、流程数据处理结果不一致的情况，且错误处理机制未能及时解决此类事务不一致的问题。 三是 易用性不佳，部分功能不人性化。 部分单位的同一部门、同一岗位的人员数量较多（广州下属区局的大厅集中办公，约有几百人），推送时选择下一环节办理人员时需拖拽查找，无法通过输 入拼音首字母或税务人员代码来快速定位；部分流程结束后，系统自动触发了关联流程，此时，无法手工选择关联流程推送人员。 四是 部分功能缺失，或尚待改进完善。 未实现批量审批，例如出口退税，影响基层工作效率；当操作。