IT应用系统重构技术方案

1、应用系统重构技术方案目录目录I（一）技术方案21.1应用系统TD总体技术方案21.1.1应用系统重构技术方案2-i-（一） 技术方案1.1 应用系统重构1.1.1 应用系统重构技术方案1.1.1.1 系统重构概述重构就是通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。一是，系统重构。由于技术架构不支持、业务需求变化或系统过于老旧（十二五或更早时期建设的应用系统），需要对原有应用系统进行大量代码改造的应用系统，纳入重构开发的范畴，最后需进行国产化迁移适配工作。系统重构主要指对使用C/S架构（不支持XC的架构）；或者使用C#、C、C+、Ruby等非JAVA不能进行国产化改造的相关代码；或相关厂商无法进行开发、丢失源代码、系统过于老旧已不满足当前业务发展需要；应用系统代码改动量超过40%的应用系统需纳入重构开发。二是，系统整合。响应国家31号文的集约化建设和整合要求，对具有相同属性或者业务功能接近的业务系统，进行部分功能和合并和整合改造、数据库合并等工作，并重新合成新的应用的过程。1.1.1.1.1 重构的目的本次项目中应用系统重构，是对技术

2、架构不支持、业务需求变化或系统过于老旧，需要对原有应用系统进行大量代码改造的应用系统，纳入重构开发的范畴，并通过国产化迁移适配工作，使业务系统在满足国产化改造的前提下，有效支撑办公人员日常办公。应用系统重构，有效提高开发的效率，方便快速迭代化开发；增加登录校验、参数校验、统一日志格式、异常处理；删除多余的功能模块。从而更好的支撑业务开展。1.1.1.1.2 重构的模式与方法论重构模式大致分为架构重构、模式重构和代码重构。架构重构。在不改变业务逻辑的情况下，根据单一职责和依赖倒置原则的思想：对系统进行模块拆分与合并，以明确职责降低耦合度；对包进行重新规划，划分包之间的边界，减少代码间的耦合。模式重构。对于特定代码不完善产生的问题，通过结合架构模式、设计模式来提升可读性。如：使用工厂模式统一管理对象的创建；使用策略模式降低复杂度。代码重构。对于一些小的代码不完善，可以通过IDE重构来快速改善即有代码，而不会影响到业务功能。如：复杂条件语句的提取；使用参数对象重构参数过多。重构的步骤分为识别需要重构的地方、制定重构计划、执行计划的重构任务、使用测试对重构是否影响业务功能进行检察、调整下一次重

3、构策略。1.1.1.1.3 重构的流程应用系统重构需对系统进行整体分析判断，并建立系统重构后的愿景，设立目标，按照不同的重构模式，采取不同的技术方案进行重构，主要流程如下图。图 （一）1应用系统重构流程图1.1.1.1.4 应用系统界面整合该界面整合平台需至少具备如下功能：1. 页面框架集成后所有系统显示在页面框架内。页面框架包括页面框架，菜单，导航树，标签页面组件等几个部分。2. 单点登录集成集成后用户只需要登录本框架一次，便可访问所有授权的业务系统。在退出本框架后，同时退出用户已登录需要作退出动作的业务系统。3. 业务系统界面集成集成后，业务系统的业务功能界面在框架内统一展现。业务系统具有多个功能页面，每个功能页面定义为框架的一个功能模块。功能模块一般定义为在工作区的标签页面组件打开或显示页面。4. 监控管理提供对用户登录退出，用户操作的监控管理。可以监控当前在线系统用户，如用户信息，用户登录时间等，并可终止指定在线用户的会话。还可以监控本框架用户登录历史，如用户信息，用户登录时间，用户退出时间等信息。5. 公共消息集成提供公共消息集成接口标准和消息展现的框架。1.1.1.1.5

4、应用系统接口服务整合应用系统接口服务整合，具备以下功能：1. 协议转换，支持多种协议的转换；2. 消息格式转换，支持各种常见格式的报文的转换和消息的处理；3. 服务路由，支持直通、基于内容、结果、并发、合并等灵活的路由方式；4. 服务调度，支持同步、异步以及发布订阅等方式；5. 服务编排，能支持原子服务的灵活组合；6. 支持消息的发布订阅机制；7. 流量控制，支持流量控制机制、能在大并发量的情况下，保证服务的质量；8. 服务优先级，能够对优先级高的服务，配置独立资源保证服务质量；9. 服务故障隔离，在服务系统或服务出现故障，能自动隔离。10. 交易一致性保证，在交易失败时能够提供冲正机制；11. 具备完善的交易异常处理机制；12. 服务元数据管理，支持服务生命周期中，服务元数据的管理；13. 服务注册库，支持服务的注册和发现机制；14. 服务的管理和监控，支持服务的配置以及动态生效；支持服务各项参数的仪表盘展现；1.1.1.2 系统重构原则.省XCTD工程项目工程集成（C包）中应用系统建设纳入重构方式建设的，应遵循以下原则：l 技术架构不支持、业务需求变化的；l 系统过于老旧（十二五或

5、更早时期建设的应用系统）；l 原有应用系统进行大量代码改造的应用系统；l 系统架构采用C/S架构（不支持XC的架构）；l 使用C#、C、C+、Ruby等非JAVA不能进行国产化改造的相关代码；l 相关厂商无法进行开发、丢失源代码；l 系统过于老旧已不满足当前业务发展需要；l 应用系统代码改动量超过40%的应用系统；l 系统整合，对具有相同属性或者业务功能接近的业务系统，进行部分功能和合并和整合改造、数据库合并等工作。1.1.1.3 系统重构主要工作1.1.1.3.1 基础环境准备本项目中采用重构方式进行改造的应用系统，要基于国产化基础软硬件环境进行开发，拟达到应用系统重构目标及满足国产化环境部署的要求，并保证终端用户通过国产化终端进行日常办公的需要。1、服务器本次项目建设过程中使用的服务器按照.省选型原则，按照SM网络和非SM网络划分，拟在建设中SM网络采用“龙芯”芯片技术路线，非SM网络采用“鲲鹏”芯片技术路线，结合技术路线的选型，分别选择搭载以上两种技术路线的服务器整机，以构建本次项目的基础硬件环境。2、国产化终端本次重构的应用系统采用国产化操作系统，采用B/S结构，JAVA语言开

6、发。用户同时使用国产化操作系统内置的浏览器或其他安全浏览器作为访问系统的工具。重构的应用系统对国产化操作系统携带浏览器的适应程度将直接影响到用户的体验度。应用系统中所有运行于客户端代码及功能，需要根据国产化操作系统内置的浏览器的功能、标准、稳定性、可靠性、对JAVASCRIPT的解析能力、对CSS样式的解析能力、对图片信息的展示效果、响应速度等进行全面的分析、开发、调试、压力测试等工作。3、数据库软件本次项目中应用系统服务端将采用安全可靠数据库软件。系统中所有涉及到与数据库之间的交互操作功能，比如数据库连接方式、数据库表建立与存取、SQL语句表达、视图、触发器、存储过程调用等，都需要根据安全可靠要求进行建设，改造工作包括分析、设计、开发、调试、压力测试等工作。4、中间件本次项目中应用系统服务端将采用安全可靠中间件。系统将运行在安全可靠中间件软件中为用户提供服务。系统中所有代码及功能，都需要根据安全可靠中间件软件的服务（部署服务、数据源管理服务、安全服务、日志服务、监控服务、集群服务、负载均衡服务、灾难恢复服务）、稳定性、可靠性、处理事务的效率、吞吐能力等进行全面的分析、设计、开发、调试

7、、压力测试等工作。5、操作系统本次项目中应用系统服务端将采用安全可靠操作系统。用户将在国产操作系统上访问重构后的应用系统。系统中所有代码及功能，都需要根据国产操作系统的稳定性、可靠性、处理事务的效率、响应速度等进行全面的分析、设计、开发、调试、压力测试等工作。6、浏览器本次项目中应用系统服务端将使用国产操作系统内置或其他安全的浏览器作为访问系统的工具。系统中所有运行于客户端代码及功能，都需要根据国产操作系统内置的浏览器的功能、标准、稳定性、可靠性、对JAVASCRIPT的解析能力、对CSS样式的解析能力、对图片信息的展示效果、响应速度等进行全面的分析、开发、调试、压力测试等工作。7、办公软件能够在桌面程序、WEB浏览器插件和API等层次提供应用接口，实现文件编辑、拟稿和成文等过程的相关集成适配，实现各应用系统配套表单与格式对流式文件编辑套件的兼容性适配支持。OFD版式文件集成适配验证通过版式文件写入插件实现流式文件格式的公文转换成OFD版式文件，并确保文件编码、字段、字符集、段落格式、图标等兼容性。实现对OFD版式文档的浏览器与客户端支持。实现OFD版式文件的转换、写入、读取与各应用系

8、统的兼容性适配。1.1.1.3.2 重构前序工作开展1.1.1.3.2.1 充分的业务沟通技术团队进行系统重构的工作的时候往往忽略掉了业务方，认为这是技术团队内部的事情，不需要知会业务方，这个想法是非常错误的，进行重构的目标就是为了改善改进业务流程，而不去和业务方提前沟通进行闭门造车，最后的结果很可能和进行重构的初衷背道而驰。进行系统重构首先必须了解现有系统的业务需求，是否有待改进的业务需求点，是否有新的业务诉求等，这些需求往往会影响到重构的进度和目标，甚至出现南辕北撤的事情。技术团队和业务方往往对待问题的出发角度不同，思考问题的方式也不同，在进行重构之前和业务方沟通获得业务方的支持，往往能够事半功倍。1.1.1.3.2.2 采用迭代的方式重构项目是个时间跨度很长的工作，需要将整个重构进行合理拆分，采用全部开发完成，再进行系统切换的方式会对整个重构引入很大的风险。首先长时间的时间跨度内业务会进行持续变更，其次团队面临长时间没有结果输出面临来自各个方面的压力，还有系统问题持续累积，这种方式往往造成了项目失败或是目标便宜。采用迭代方式进行重构，可以以更小的颗粒度持续交付工作成果，交付 -

9、试用 - 反馈 - 调整，持续有交付，持续有反馈，持续调整能够保证团队的目标不会偏移，形成一个正向循环，保证最后的重构目标。1.1.1.3.2.3 清晰掌握旧系统借助现有系统运行环境，充分了解现有系统架构、业务以及数据情况，从旧系统的开发人员处或许系统有关的建设资料及代码，并深入与旧系统的开发人员沟通，了解系统目前运行情况及使用情况，通过了解旧系统设定目标基准值避免引入老旧问题，也是避免重蹈覆辙的一个好办法。1.1.1.3.2.4 规划系统切换方案系统切换是在重构中重要的一个步骤，在做最初的计划就应该考虑到如何进行系统切换，一个设计好的切换方案也应该贯穿重构始终，避免因为切换方案引起服务不可用或是引入系统 BUG。1.1.1.3.2.5 高度重视系统数据一次系统重构大多数情况下会涉及到数据结构的修改，对数据结构进行修改必然引入很大的风险，尤其在一些老旧的业务系统重构精简，业务去掉冗余数据的时候，往往需要将老数据的业务数据重新写入到新系统的数据库。重构的目标是为了比旧系统更好，无论是性能还是业务方面，如果我们对数据的操作导致外部依赖旧系统的业务无法正常运行，那将是影响 SLA 指标的问题。1.1.1.3.2.6 采用成熟的技术选型技术选型是重构工作的基石，选择一套成熟稳定的技术方案是重构项目完成的必要条件。对于本次采用重构方式进行改造的应用系统，拟采用如下技术。1、微服务架构微服务架构是一项在云中部署应用和服务的新技术。微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么

《IT应用系统重构技术方案》由会员感性****远分享，可在线阅读，更多相关《IT应用系统重构技术方案》请在金锄头文库上搜索。