金税三期应用框架研讨会.ppt

国家税务总局应用框架研讨会 应用框架的概念 框架是一个可复用的设计构件 它规定了应用的体系结构 阐明了整个设计 协作构件之间的依赖关系 责任分配和控制流程 表现为一组抽象类以及其实例之间协作的方法 框架包括大量类或组件 每一种类或组件都提供了某种概念的抽象 框架定义了这些抽象如何协作解决问题 框架组件可以重用 框架在更高层次上的组织模型 应用框架的意义 优秀的框架可以在分析 设计和编码阶段上提供良好的重用机制和可控制特性 对提高系统的开发效率和目标系统的建设质量具有重要的意义 业务应用程序结构一致性好 增加了代码的重用度 软件生产效率和质量也得到了提高 业务应用程序设计人员可以专注于对业务领域的了解 使需求分析更充分 降低了业务应用程序开发的复杂度 开发人员可以专注于业务问题的解决 尽量不考虑低层的编程技术 通过合理的模块划分 有利于在一个项目内多人协同工作 并行开发 良好的部署管理机制可以在很大程度上提高系统的可操作性 有利于提高系统的开发效率 并延长系统不停机工作时间 有利于建立更加开放的系统 应用框架设计方法论 SunToneAM方法论SunToneAM SunToneArchitectureMethodology 包含了架构设计分析的各个方面 是一种内涵丰富的分析 找全 机制 框架设计重点关注的问题 1 性能大型应用系统具有高并发 交互频繁 业务复杂 校验多 大数据量处理等特点 因此 在应用架构设计方面 需要研究合理的系统计算模式 以应对业务集中模式下大用户容量 大访问并发量 大数据量处理的客观要求 满足日益复杂的业务应用发展需求 框架设计重点关注的问题 2 可靠性通过应用架构的体系结构 单元组成及组织方式等多个方面的细化分析 包括事后处理方面如完善的错误处理机制 保证系统的系统7x24小时不间断稳定运行 通过合理的冗余设计 避免网络和系统的单点故障 并具有灾难恢复能力 当灾难被发生后 系统应在规定的时间内恢复 框架设计重点关注的问题 3 易用性易用性大体包括针对开发人员的开发易用性和针对终端用户的应用易用性两个方面 针对开发人员要确保API的清晰 明确和简单 便于开发人员根据业务特征做技术选择 易于代码优化 针对终端用户要提供合理的交互界面元素和交互模式 指导开发人员实现应用系统的良好交互性 框架设计重点关注的问题 4 可扩展性以标准化 可扩展的思想为指导进行应用架构设计 使系统可随着业务量的增长而扩容 系统结构无需改变 包括应用扩展和技术架构扩展两个方面的内容 其中应用扩展依赖于应用架构的设计和实现方法 而架构扩展则依赖于框架设计所选取的技术 标准和规范的兼容性程度 框架设计重点关注的问题 5 可移植性应用架构不依赖任何特定操作系统 中间件 硬件 可以很容易地移植到多种平台上 这在典型的异构企业计算环境中是十分关键的 框架设计重点关注的问题 6 可维护性大型应用系统是一个庞大 复杂 艰巨的系统工程 早期的系统运维模式主要是针对应用服务器 操作系统 数据库等层面上的监控 缺乏对核心业务系统运行状态进行跟踪和监控的能力 而有效的监控手段更强调围绕业务应用实时地进行跟踪 分析和故障排除 因此 研究针对业务应用单元自身运行状态的监控和管理技术 是保证大型应用系统实施成败的关键 框架设计重点关注的问题 7 安全性当前及今后相当长时间内 应用系统大都基于Internet技术实现 本身存在着很多安全问题 包括网络安全 主机安全 应用安全等多个层面 就应用架构设计而言 其关注的核心安全问题是应用安全 而应用安全的核心又是数据安全 因此 如何保证业务数据的安全性是应用架构设计重点关注的问题 框架设计重点关注的问题 8 分层体系严格坚持分层架构 表现层 业务层和持久层 下的快速开发 注 象Deplhi VB那样减少层次的快速开发是非常容易的 但是丧失了软件的灵活性和可维护性 快速性和灵活性要综合平衡考虑 它带来了多快好省的简单的解决之道 对于小项目 使用框架可以开发出高质量可扩展的好的系统 对于大项目 使用框架可以更快地开发出系统 框架设计重点关注的问题 9 设计抽象层次在框架的定义中 抽象体是至关重要的 抽象体是框架的目标 要么是一个类库 要么是一种编程语言 光有抽象体还是没有办法工作 还需要定义出抽象体的行为 有了行为之后 还需要规范 穷尽这些行为 分析抽象行为的通用部分和非通用部分 在抽象体的行为中 有些动作是通用的 有些是特殊的 前者就是框架要实现的部分 而后者则作为扩展留给用户 将抽象层次提取为框架 并设计扩展点 有了抽象体 抽象体的通用行为之后 就可以设计扩展点了 最简单的扩展点是采用方法调用的方式 复杂的可能通过设计模式或是配置文件等方式 扩展点设计优劣的评价标准是使用起来是否方便 这里的使用包括应用 调试 测试等 框架设计重点关注的问题 10 适当的使用设计模式设计模式代表了先进的软件设计思路 在框架中适当地使用设计模式有助于改进框架的结构 在框架设计中不宜采用过多的设计模式 这会使得框架理解起来困难 框架设计重点关注的问题 11 有效利用 隔离第三方技术当前的软件开发向着协作的方向发展 在这种情况下 大量的第三方软件出现了 软件业的分工将会给软件业带来繁荣 但是对于软件组织来说 就需要考虑第三方软件的成本 生命力 本组织系统对其的依赖程度等问题 这部分工作应该交给框架 让框架来负责把核心应用和第三方技术隔离开来 因此 设计一个抽象的层次 把这些技术和核心应用隔离起来 框架设计与业务的关系 框架和业务具有很强的关联性应用框架具有专一性 没有放之四海皆准的框架框架的设计要考虑业务处理特征处理模式 前台 后台 周期性 终端模式访问频度功能安全性要求数据安全性要求集成性要求历史资产兼容性要求 面向服务架构 SOA 的应用原则 SOA作为一项业界公认有良好应用前景的技术架构 在金税三期的应用框架设计中 需要着重给予考虑 但要区分应用场景 狭义框架 在系统单元内部 业务和数据的关联性强 架构设计以效率为先 可以借鉴服务的思想 不宜过度采用SOA技术 广义框架 在系统单元之间 业务和数据的关联性相对较弱 而由于采用不同的技术 供应商等因素 松耦合需求较强 宜采用SOA技术 现有流行开源框架 成熟度比较高 在开源社区中支持度也比较高 有类似项目应用基础的开源框架 项目 有 表示层框架 struts SpringMVC业务层框架 Spring持久层框架 Hibernate其他开源框架 缺少类似项目实际应用经验 不建议采用 开源框架不利因素分析 开源框架不利因素分析上述框架 SSH 只是三个提供不同功能的底层技术框架 并不适合直接支撑企业级项目开发 需要有经验的架构师对其做架构设计与规划 对J2EE系统常见的问题提供解决方案 才能支持企业级项目开发 需要大量的二次开发 才能够达到现有成熟平台产品的各项指标 使用第三方框架 当出现框架问题的时候不便快速定位问题原因 开源框架对金税三期的支撑特性 直接应用开源框架无法支撑金税三期的应用需求 主要原因在于 可复用组件方面 无法直接提供可用的业务相关组件 需要大量的二次开发业务相关性方面 无法直接满足业务的特性化需求 需要大量的二次开发系统运维方面 无法直接提供应用级的监控和运维管理特性 需要大量的二次开发技术复杂性 上述开源项目体系复杂 深入了解难度较大 不利于问题处理高风险特性 如果直接基于SSH进行开发 项目风险较大 现有产品的优势特性 以现有平台产品 如中软睿剑业务基础平台 SWORD 为基础研发金税三期框架具有先天优势 可复用组件方面 由于业务自身的延续性 可直接复用已有的大量业务相关组件业务相关性方面 针对行业应用特征研发 能够满足业务的特性化需求系统运维方面 现有框架具有应用级监控和优化特性 可以顺延提供应用级的监控和运维管理技术复杂性 拥有自主知识产权 掌握框架的关键技术 在系统升级 问题处理等方面具有先天优势低风险特性 由于从产品 技术 复用组件等各方面均具有良好的基础 应用系统建设风险较低 行业应用框架研发是一项繁杂工程 1 框架的研发需要一个过程行业应用框架是一个复杂的系统工程 包括基础服务框架 可复用组件 定制化开发工具 应用模式及最佳实践建议等 一般而言 全新研发一个行业应用框架从立项到产品化程度至少需要2 3年时间 行业应用架构是长期应用积累的结果从某种意义上讲 行业应用框架不是 写 出来的 而是 用 出来的 缺少实践验证 促进环节很难保证框架的质量 行业应用框架研发是一项繁杂工程 2 框架的研发需要对业务本身有深刻的理解行业应用框架的研发必须要和具体业务结合在一起考虑 实践证明 纯技术的框架无法适应应用系统