系统架构说明书模板

系统 架构 酒店人事架构图下载公司架构图下载企业应用架构模式pdf监理组织架构图免费下载银行管理与it架构pdf 说明书模板 秘密 [XXXX项目] 系统架构说明书 [说明: 1. 本文件中“[]”中内容为举例和说明文字，请在文件拟制时替换或删除; 2. 若文中某章节内容可省略、不需要或适用，请保留该标 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 ，并根据实际在内容部分写明 “略”、“勿需”或“不适用”等，同时适当说明原因 3. 请作者注意在文档右上角修改该文档的密级。] 第 1 页 共 15 页 秘密 文件修订历史 作者 修订时间 修订说明 审核 模板修订历史 版本 作者 生效时间 变更概要 审核 批准 1.0 2008-8-1 创建模板文档 杨军 1.1 2008-11-21 文字错误修改 杨军 EPG 马智涛 1.2 2009-02-17 增加典型用例、风险说明 杨军 1.3 2009-03-20 修改计算&存储层资源评估表 杨军 1.4 2009-03-29 3.4.3章节名称调整 杨军 1、3.4.1增加可重用组件的说明 1.5 2009-04-09 杨军 EPG 马智涛 2、增加3.7集成 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 增加5.3软件要求，描述对逻辑实体的软件版1.6 2009-12-02 杨军 本信息 第 2 页 共 15 页 秘密 目录 1. 简介 5 1.1 目标 5 1.2 范围 5 1.3 术语和缩略语 5 2. 整体说明 5 2.1 方案 5 2.2 架构约束 6 2.3 整体概要 6 2.3.1 系统上下文 7 2.3.2 整体架构 7 3. 应用层 7 3.1 设计思路 7 3.2 结构视图 7 3.2.1 包视图 7 3.2.2 外部服务 7 3.3 配置视图 8 3.3.1 配置视图 8 3.3.2 配置描述 8 3.4 行为视图 8 3.4.1 关键问题的技术解决方案 8 3.4.2 部署视图 9 3.4.3 核心架构模式及设计模式 9 3.4.4 典型用例流程 9 3.5 进程视图 9 3.6 升级注意事项 9 3.7 集成方案 9 4. 虚拟平台层 9 5. 应用基础层 10 5.1 固化在平台中的机制 10 5.2 自定义机制 10 5.3 软件要求 10 6. 企业服务层 10 6.1 配置视图 10 6.2 升级注意事项 10 7. 计算&存储层 10 7.1 升级注意事项 12 8. 网络基础层 12 8.1 配置视图 12 第 3 页 共 15 页 秘密 设备 12 9. 10. 服务级别需求 12 10.1 列举服务级别需求 12 10.1.1 性能、吞吐量和可伸缩性 13 10.1.2 可用性和可靠性 13 10.1.3 安全性 13 10.1.4 可管理性 13 10.1.5 易用性 13 10.1.6 可维护性 13 10.1.7 扩展性和灵活性 13 10.1.8 可重用性 13 11. 容灾设计 14 11.1 容灾目标值 14 11.2 容灾环境 14 11.3 关联系统容灾要求 14 11.4 其他补充说明 15 12. 风险 15 12.1 技术风险列表 15 12.2 风险识别 15 第 4 页 共 15 页 秘密 系统架构说明书 1. 简介 [建立上下文，提出所有读者在下面章节期望看到的内容。] 1.1 目标 [请说明此系统完成后，达到什么架构目标，产生什么架构意义。或者对别的系统架构可以提供什 么借签. 例如，pafa系统的架构文档这里可以这样写:构建平安J2EE应用的开发框架，使所有系统能 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 开发组件，提高开发效率，易于统一升级和维护] 1.2 范围 [列出本系统支持的业务范围，包括时间使用年限，业务需求范围，包括已确定支持的业务需求和 未明确确定的业务需求。如果有未明确的业务需求，需要说明如果需求变更的话，采取什么措施 列出所有和当前架构有关的参考文档，包括每一个确定的标题、版本、日期以及发布组织。详细说 明资料的出处，也可以通过一个附件或另一个文档提供。需求分析可参看需求分析文档] 1.3 术语和缩略语 [定义本文档中所有的术语和缩略语。] 术语/缩略词 说明 Pafa3 PingAn Foundational Architecture 3 2. 整体说明 2.1 方案 [概述架构设计的方法，包括简要的方法论描述。定义系统中不同的视图，然后叙述本系统架构说 明书中使用到的那些视图。] <系统名称>的架构方案是基于Sun Tone的架构方法论，由可伸缩性、安全性、可维护性等服务级 别需求所驱动。依次分析逻辑层tier和技术层layer，如下图的图示: 第 5 页 共 15 页 秘密 图1 架构框架 系统描述是通过一组架构视图来组织的，每一个视图都是从不同观点描绘系统特征的一个方面。系统层由大量的视图组织起来。 以每个或组服务级别需求作为一个次标题，加入架构设计中如何达到其需求的描述，需要的话引用其它视图;最后用一个总的服务级别需求视图把这些内容串联起来。 视图对读者是很有帮助的。不同的读者在特定的时间可能只对部分的视图感兴趣。 以下章节描述架构建立目标和约束，以及高层次系统整体概要。本节也描述后续章节从不同侧面检验系统架构的上下文环境。 2.2 架构约束 [本节需描述四方面的内容。1)本系统最受关注的前几个服务级别需求对架构的要求。(详细的服务级别需求可以在服务级别需求部分表述)2)是否是基于外购系统。(全部基于或部分基于外购系统或全部自主研发)3)本系统的架构适用范围。(只适用本系统还是可以适用于其余系统或者部分可适用于其余系统。如果是部分可适用于其余系统，则需要描述架构模式) 4)本系统的技术约束(需依赖的技术)，对团队成员的约束(如成员需要掌握的技能)，软硬件约束等。] 2.3 整体概要 [提供一个架构的整体性说明。因为在后续的章节中，都是按层(layer)来组织该层(layer)的视图，本概述章节就更适合把所有层(layer)作为一个整体来考虑，而不是分层(layer)来描述。通常，划分层(tier)是很有用的，突出(加亮)每级的关键点，这些关键点包括主要的外部实体(如终止用户访问的节点和遗留系统)。主要的架构特征列表，如:独立供应商、一致的行业 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 、产物的构思等。同一类架构特征应该放进整体说明中描述。] 第 6 页 共 15 页 秘密 2.3.1 系统上下文 [描述本系统与参与者(内部、外部)的关联关系] 整体架构 2.3.2 [描述系统整体架构] 3. 应用层 [本节在均衡考虑架构统一原则的基础上,通过分解对应用层的功能进行讨论。从概要地描述应用层 各独立视图开始，例如:分别对比静态和动态的结构视图，分别对比静态和动态的配置视图。] 3.1 设计思路 [整体描述应用层整体的设计思路,例如使用Pafa3架构作为基础框架代码;cache缓存在app Server及其原因等.] 3.2 结构视图 [当需要进行开发时，描述架构上重要的包和它们之间编译时的静态依赖关系。选择的分解应该详 细阐述每条定义明确的分解规则，例如:分层、分类、概括等。一旦包括各等级的小节，就可以用 一个等级分层的概要图表作为开始，然后用更加详细的图表描述架构上比较重要的部分。所有的图 表中对每个包的描述，应该包括它们的职责和资源(自定义的、可重用的、成本等)的描述。] [本小节可以放到本节开头部分，但是要先于各小节提出。无论是放在此处还是其他地方，推荐保 留次级标题，即使内容是空的，也要作为详尽阐述的占位符。] 3.2.1 包视图 3.2.1.1 XX包的描述 [描述xx模块的职责/功能范围] 3.2.1.1.1 类图 3.2.1.1.2 包内接口或服务 [声明用例中系统执行操作对应的服务，为其他模块提供的服务] 3.2.1.2 YY包的描述 [描述YY模块的职责/功能范围] 3.2.1.2.1 类图 3.2.1.2.2 包内接口或服务 [声明用例中系统执行操作对应的服务，为其他模块提供的服务] 3.2.2 外部服务 [描述调用的外部接口或对外提供的外部接口] 3.2.2.1 使用关联系统的服务 [描述使用关联系统的服务] 第 7 页 共 15 页 秘密 3.2.2.2 为关联系统提供的服务 [描述为关联提供提供的服务,可以参见接口文档的服务] 3.3 配置视图 [逐条描述各应用模块的配置，包括这些模块的物理位置、运行时的交互。为此，可以使用模块结构图覆盖展开图。为不同的配置提供适合的多样的图表，可能需要产品的例子、或配置于不同环境中的产品的例子、决定支持配置与交易配置不同之处的例子。当描述各种配置时，应当定义为每项配置所选的配置策略。] [注明底层的详细信息将在稍后的独立配置视图中获取，所以最好在此赘述一下相关的视图信息。] 3.3.1 配置视图 3.3.2 配置描述 [如果有需要，可以在视图后加入对配置的描述] 3.4 行为视图 [当某些架构设计对子系统的功能有影响，而不是影响子系统的划分时，本节描述对子系统的功能有影响的架构设计;这些设计不会影响子系统的划分。以下小节可以使用，也可以适当的删减。] [本节是下面小节的代表。推荐保留次级标题，即使内容是空的，也要作为详尽阐述的占位符。] 3.4.1 关键问题的技术解决方案 [描述架构上在各层的关键决定和架构设计方案在系统各层的考虑，以及架构重要用例涉及的技术解决方案,也包括可重用组件设计方案。下面是一个简单的格式例子。] 3.4.1.1 解决方案的分层描述 下表通过分层概述通用的设计方法，每行对应一个架构上的决定和在各层的解决方案。 关键问题/组件 表示层 业务层 资源层 DOM 表示 集合处理 查询API 导航API 完整性管理 事务控制 表 1 <系统> 关键问题技术解决方案 3.4.1.2 解决方案详述 [如果有需要，可以详细描述关键问题的解决方案和思路。对于可重用组件，需要描述详细解决方案。] 第 8 页 共 15 页 秘密 3.4.2 部署视图 3.4.2.1 部署逻辑图 3.4.2.2 部署注意事项 3.4.3 核心架构模式及设计模式 3.4.3.1 核心架构模式 [描述系统特有的架构模式(Pafa3架构不需要再描述)，例如使用AJAX架构等] 3.4.3.2 核心架构模式中使用到的设计模式 [描述架构模式中使用到的设计模式] 3.4.4 典型用例流程 [描述所有保留的典型的或比较有价值的系统里动态(基于时间)相互作用的例子的详细设计。 1. 典型用例的目的是让设计人员可以参考典型用例来对其他用例进行详细设计。例如抽取报表模 块中的一个典型的用例进行详细设计，其他报表详细设计可以参考此用例。 2. 架构重要用例必须在典型用例流程中有详细描述.] 3.5 进程视图 [说明贯穿系统的交互流程同步和异步的方式，焦点是影响质量上的(如:吞吐量、可靠性、实用 性等)宏命令。] [本节是小节中的典型。推荐保留次级标题，即使内容是空的，也要作为详尽阐述的占位符。] 3.6 升级注意事项 [描述系统升级时应用层的架构应该随之做出的改进。例如，可能预先增加一项参数或增加对另一 个系统的接口，将功能性从中分离出来。] 3.7 集成方案 [描述系统内部和外部需要集成的组件;集成的顺序;集成的工具等，标准pafa3架构可以参考<平 安通用系统架构.doc>,与标准不同之处需要单独描述] 4. 虚拟平台层 [如果存在为独立供应商访问应用基础架构层而提供的标准层，应当描述标准层。最好的例子使 J2EE，但也可以包括其他的标准，如基于SNMP、LDAP和XML的标准。(需要说明的是，应用 程序可能以任何格式提供服务器，但是这些应该放在应用层里进行描述，本节的焦点仅仅是应用程 序使用什么到达下一层。)] 选Java? 2 Platform, Enterprise Edition (J2EE)作<系统名称>的服务器平台。J2EE是开发 多级企业应用软件的工业标准平台。它提供一个位于中间层机制的顶端的虚拟平台，解开很多机制 的限制，同时简化和加快了整个开发过程。同时提供了对现有应用程序集成最强有力的支持，最大 化将来变更的选择权。 第 9 页 共 15 页 秘密 5. 应用基础层 [本章描述前面所述各层的基础层，但要注意是从前面没提到过的角度来描述。例如，供应商提供 的产品架构上的描述，可能更有价值。] 5.1 固化在平台中的机制 [描述系统要求的各种机制。包括一个关于机制的列表――机制的定义及为什么这些机制被合并到 应用程序中。对运行的机制、访问和管理应用程序接口的机制，如下的列表可以作为一个大致的轮 廓。] Tier层 容器 平台 接口(API) 管理接口(MI) 机制(Mechanism) 客户端 表示层 业务层 集成层 资源层 图5-1 列举所有机制 5.2 自定义机制 [如果有任何自定义的机制上一节中没有说到，就在本节描述。为此，可以使用静态和动态的UML 图描述各种机制，同时可以包含必要的改进注意事项。] 5.3 软件要求 [描述部署逻辑实体的软件版本信息,参考《平台软件版本清单表.xls》] 部署逻辑实体 软件版本信息 6. 企业服务层 [描述支持与本系统相关的或依赖的服务器环境。] 6.1 配置视图 [描述在应用层下，直接或间接支持应用层的配置。包括应用层整合不太明显的一些细节，如: DHCP服务器和使性能失效的底层平台。使用配置图，随意地描绘一下架构上的重要过程或行为视 图中的主线。] 6.2 升级注意事项 [描述架构预期到的改进,如何配合计算&存储层预的架构升级做调整。] 7. 计算&存储层 [列举计算设备和封装格式存储器等硬件/系统级的组件 注意事项:1. 评估指南参考《基础架构资源需求评估单.xls》 2.不在此表的资源需要与EA,CCO,基础架构讨论再确定。 3.在架构复审后如有变化需要更新。 第 10 页 共 15 页 秘密 4. 除明确说明外, 生产对应的灾备资源会由公式计算获得. 详细的公式参考《基础架构资 源需求评估单.xls》 5. 非平安标准的OS或软件版本需要特别说明，参考《平台软件版本清单表.xls》] 下表为系统运行的硬件/软件组件: 资源名称 适用范围 评估点 评估结果 评估依据 高端生产SAN存储普通OLTP或OLAP应用的1)业务数据量(GB) 生产: ,001 Oracle生产数据库 2)索引数据量(GB) 性能要求较高的OLTP数据库 应用，如CIF2、UMPRD、OID高端生产SAN存储1)业务数据量(GB) 等 生产: ,002 2)索引数据量(GB) 磁盘组的整体I/O压力处理 能力比HSAN-001高33, 1)需要评估生产和STAGING: 普通文件的存放，非关键系STAGING 2个环境 生产: 统 2)业务所需的存储空间数 中端SAN存储-001 量(GB) 业务所需的存储空间数量Oracle DB的Staging环境 STAGING: (GB) 对性能和可用性要求较高的1)需要评估生产和应用，如SQL Server DB、STAGING 2个环境 生产: 中端SAN存储-002 exchange应用等对I/O读写 2)业务所需的存储空间数STAGING: 要求和访问量比较高的量(GB) Windows/Linux平台应用 归档应用，如邮件归档、影1)需要评估生产和 像归档、日志归档、备份归STAGING 2个环境 生产: NAS存储-001 档等应用，配置SATA盘柜，2)业务所需的存储空间数STAGING: 对性能和可用性要求较低 量(GB) 通用的NAS文件共享服务需1)需要评估生产和 求，如保存、J2EE文件共STAGING 2个环境 生产: NAS存储-002 享、NAS虚拟机应用等，配2)业务所需的存储空间数STAGING: 置光纤盘柜 量(GB) 1)网络分区 生产Oracle DB小2)需要的CPU数量 Oracle生产数据库 生产: 型机 3)非平安标准的OS或DB版 本需要特别说明 1)网络分区 2)依据厂商针对平安的业 务规模提供的硬件配置要 生产: 求，和资源负责人讨论后非ORACLE DB小型所使用的应用软件需要运行 灾备: 决定CPU数量 机 在UNIX小型机平台 STAGING: 3)非平安标准的OS或DB版 本需要特别说明 4)需要评估生产,灾备和 STAGING 3个环境 1、应用以PAFA/J2EE架构开1)网络分区 发 2)Weblogic unit数 2、服务器不进行大量消耗3)Jboss/Tomcat unit或J2EE生产用虚拟机 生产: CPU、I/O资源的计算，系统其他中间件的unit数 主要资源需求为内存(Java 4)非平安标准的OS或中间 Heap) 件版本需要特别说明 第 11 页 共 15 页 秘密 1)网络分区 1、应用架构中有外购软件2)需要的OS UNIT数目 需要部署在PC Server 3)非平安标准的OS或软件非J2EE生产用虚拟2、应用架构自行开发部分版本需要特别说明注:1 生产: 机 有非标准架构、或不符合OS UNIT,1个CPU核+应用J2EE生产服务器规格条件的要求的MEM,只包含系统盘组件 空间 7.1 升级注意事项 [预期的改进明细表，例如:所选模块的扩展性或升级能力，或者系统在某些地方的设计更易于添 部分加可复制的节点等等。] 8. 网络基础层 8.1 配置视图 [描述物理上的配置，包括运算和存储资源，以及它们之间相互连接的网络。细分应包括路由器、 防火墙、子网、主要的/次级的服务器等等。本视图应该补充应用层/配置视图，以确保各组件在本 视图中描绘得更加详细。例如:用框图代替视图中的抽象概念。] 9. 设备 [论述设备要求，如:空间维度、马力、热量等环境要求，以及进入场地的安全要求(如身份技术 鉴定)等。] 10. 服务级别需求 [本节包含所有和服务级别需求相关的因素，可以增加副标题分别列举各项。本节以下是选取格式 的一个提纲。] 10.1 列举服务级别需求 [详细阐述各项重要的服务级别需求参数(像需求规格说明书中标识一样)。可以使用立体视图， 附加一些文字描述。以下是各个服务级别需求参数都应当提到的几项。] [直接需求和衍生需求。直接需求就是在需求规格说明书中列出的那些需求，在此只是对这些信息 必要的重复。衍生需求虽然没有在需求规格说明书中列出，但却是满足直接需求的技术上的必要条 件。例如，架构里使用一个遗留组件时，一个直接的吞吐量需求可能隐藏着一个衍生的吞吐量需 求。] [使用的策略。架构怎样提出这些系统性能,参考其他视图，并避免对已提出的性能进行考证所产 生的冗余。] [将来的变更。确定为了支持版本预期的升级而在架构里合并的内容。例如，可伸缩性对吞吐量。] 第 12 页 共 15 页 秘密 10.1.1 性能、吞吐量和可伸缩性 10.1.1.1 需求 10.1.1.2 架构解决方案 10.1.1.3 改进注意事项 10.1.2 可用性和可靠性 10.1.2.1 需求 10.1.2.2 架构解决方案 10.1.2.3 改进注意事项 10.1.3 安全性 10.1.3.1 需求 10.1.3.2 架构解决方案 10.1.3.3 改进注意事项 10.1.4 可管理性 10.1.4.1 需求 10.1.4.2 架构解决方案 10.1.4.3 改进注意事项 10.1.5 易用性 10.1.5.1 需求 10.1.5.2 架构解决方案 10.1.5.3 改进注意事项 10.1.6 可维护性 10.1.6.1 需求 10.1.6.2 架构解决方案 10.1.6.3 改进注意事项 10.1.7 扩展性和灵活性 10.1.7.1 需求 10.1.7.2 架构解决方案 10.1.7.3 改进注意事项 10.1.8 可重用性 第 13 页 共 15 页 秘密 10.1.8.1 需求 10.1.8.2 架构解决方案 10.1.8.3 改进注意事项 11. 容灾设计 [本节描述本系统的容灾目标和容灾方案，容灾方案需列出支持本系统容灾的各支持环节的容灾要 求，各环节容灾方案默认为J2EE平台容灾方案，不同于平台方案的地方要做说明。] 11.1 容灾目标值 数据恢复点目标RPO 恢复时间目标RTO 优先级 [数据恢复点目标，主要[恢复时间目标，主要指的是[表示业务系统的重要程度: 指的是业务系统最大能容最大能容忍的业务停止服务的1至关重要的(邮件，公告栏 忍的数据丢失量。] 时间 等) ] 2关键性的(公共平安，例如 UM，CIF2) 3重要的(核心业务系统) 4重要但是可以延缓的 5可以延缓的] 11.2 容灾环境 [描述本系统依赖的环境容灾方案要求，如果同J2EE平台容灾方案要求一样可以填写同标准，需说 明本系统不同于J2EE平台容灾方案的地方] 基础架构环境 容灾方案要求 网络环境 [描述使用的网段，各网段需要的IP数，及其他与网络相关补充] 防火墙策略 [描述本系统的防火墙策略，填写参考标准/无,或做方案说明] 域名服务DNS [填写参考标准/无,或做方案说明] 应用主机 [描述主机的配置要求以及主机参数情况，填写参考标准/无,或做方案 说明] 存储NAS [填写参考标准/无,或做方案说明] 负载F5 [描述哪些部署实体需要容灾F5，填写参考标准/无,或做方案说明] 应用软件平台 [描述本系统的软件平台，参数设置。填写参考标准/无,或做方案说明] 数据库 [填写参考标准/无,或做方案说明] 11.3 关联系统容灾要求 [列出需要做容灾的关联系统，说明本系统容灾对其他关联系统的容灾要求] 关联系统简称 关联系统中文名称 容灾要求 [在系统清单中的英文简[关联系统名称] [描述关联系统的容 第 14 页 共 15 页 秘密 称，例如UM] 灾要求，RPO值和RTO 值，以及优先级] 11.4 其他补充说明 [补充说明在容灾环境日常工作中和容灾恢复时不同于J2EE平台容灾标准方案的地方,如果没有不 同可以填写无] 12. 风险 12.1 技术风险列表 [描述从系统架构重要用例(参考需求规格说明书)中识别出来的与技术风险相关的用例，以及对应 的技术风险] 风险代码 风险描述 R01 R02 12.2 风险识别 [描述与风险相关的用例编号] 用例编号 R01 R02 R03 第 15 页 共 15 页