系统架构设计模板.doc

XXXXXXXX XXXXXX系统架构设计文档系统架构设计文档 1 简介简介 5 1 1 文档说明 5 1 2 定义 首字母缩写词和缩略语 5 1 3 参考资料 5 2 架构设计目标架构设计目标 6 2 1 关键功能需求 6 2 1 1 在线充值 6 2 1 2 YYY 功能 6 2 2 关键质量需求 6 2 2 1 安全性 6 2 2 2 高可用 7 2 2 3 可伸缩 7 2 2 4 高性能 7 3 逻辑架构逻辑架构 7 3 1 总体架构 8 3 1 1 Portal 客户门户 8 3 1 2 Admin 管理门户 9 3 2 集成架构 9 3 2 1 SCS 9 3 2 2 中国银行 9 4 开发架构开发架构 9 4 1 技术选型 9 4 2 PORTAL客户门户 10 4 2 1 目录结构 10 5 数据架构数据架构 11 5 1 数据模型 11 5 2 持久化方案 11 6 关键质量需求设计关键质量需求设计 12 6 1 安全性 12 6 1 1 服务器证书 12 6 2 高可用 12 6 3 可伸缩 12 6 4 高性能 13 7 部署架构部署架构 13 版本历史历史 日期日期版本版本描述描述作者作者 2012 5 40 1 创建模板陈书元 1 简介简介 1 1 文档说明文档说明 蓝色字为举例说明 视具体系统情况 架构师自行编写 紫色字为思路和方法 供架构师参考 正式文档在编写完成后 蓝色 紫色字都要删除 该文档描述了 XXX 产品的系统架构 对系统设计 开发 维护予以指导 1 2 定义 首字母缩写词和缩略语定义 首字母缩写词和缩略语 词汇词汇解释解释 1 3 参考资料参考资料 一线架构师实践指南 温昱著 企业应用架构模式 Martin Fowler 著 J2EE 设计模式 William Crawford 著 分布式 Java 应用 林昊著 构建高性能 Web 站点 郭欣著 前言 2012 年第二季度 金融产品中心要研发多个产品 供应链融资 储值卡 保险 支付网关等 公司发 展这么快 对于系统研发速度要求也越来越高 但系统并不像种菜那样 播了青菜的种子 长出来就 是青菜 以前 系统做架构 更多的是讨论一些方案 画画图 缺乏总结和提炼 虽然软件开发永远 不能和种菜一样 但总有一些固定的模式和方法论 所以 我把架构设计的经验总结出来 让架构简 单化 架构思想可以复制 系统才有可能繁殖 系统架构设计做什么 设计系统部分和整体的关系 以及让这种关系更加和谐 架构师的职责 我以前的理解 预见问题 发现问题 不顾一切解决问题 一个架构设计良好的系统 绝对不是仅仅靠架构师一个人设计出来的 2 架构设计目标架构设计目标 2 1 关键功能需求关键功能需求 关键功能决定架构设计 如何识别关键功能 核心功能 系统中重要组成部分 比如支付系统中的充值功能 优先级高 相比其他功能 该功能必须要在该产品中实现 一般客户功能优先级高于管理功能 使用量大 数据量大等等 2 1 1 在线充值在线充值 1 用户在充值页面选择银行 输入充值金额 点击充值按钮 2 页面跳转至银行支付网关 3 用户输入银行卡相关信息后 确认支付 4 银行验证信息 扣用户账户资金 5 跳转易付宝支付成功页面 通知支付成功 详见 xxx 需求文档 xxx 章节描述 2 1 2 YYY 功能功能 2 2 关键质量需求关键质量需求 关键质量需要考虑多方涉众 客户 管理者 开发 测试 运维等人员 关键质量需要着眼当下 也需要考虑未来 关键质量决定了系统的成败 这也是让架构师最为纠结的地方 我们不能过度设计 也不能考虑欠缺 需要在时间 成本 能力上作出平衡 产品经理更多的时间花在功能需求 质量需求需要架构师与产品经理沟通 最终达成一致意见 2 2 1 安全性安全性 1 用户在浏览器输入密码时 要防止木马盗取 2 用户提交的信息在互联网传输时 要防止信息窃取 2 2 2 高可用高可用 1 网站向用户提供 7 24 小时服务 2 定时监控系统的运行状况 2 2 3 可伸缩可伸缩 1 当前系统每天可以支撑 100 万 PV 1 年后达到 1000 万 PV 2 当前系统每天可以支撑 10 万订单 1 年后达到 100 万订单 3 对系统改动最小的前提下 未来可以支撑更大的量 2 2 4 高性能高性能 1 首页加载时间不超过 2 秒 2 订单处理时间不超过 1 秒 3 逻辑架构逻辑架构 逻辑架构是用来描述系统的组成 一个系统组成如下图 XXX 系统 子系统 1 子系统 2 模块 1 模块 1 组件 1 组件 2 包 1 包 2 类 1 类 2 把系统分成多少个子系统才算合理 考虑因素 1 参与者 把不同类参与者的功能分开 比如 一般我们会将客户门户和管理门户分开 2 产品分类 不同类产品可以做在不同的系统中 比如 虚拟产品系统和易付宝支付系统就是分开的 3 兼顾规模 功能很少的系统分成多个子系统做是过度设计 这是反模式 4 质量需求 为了保证系统高可用性 压力大的业务建议独立系统 比如 秒杀系统就是从易购主站拆出来的 划分不同子系统的原则 1 职责不同的单元 2 通用性不同的单元 3 需要不同开发技能的单元 4 兼顾工作量的相对平衡 进一步切分太大的子系统 对于访问量和使用量很高的网站 PV 从百万向千万迅速迈进的时期 我们不能用一个系统来解决所有 的问题 按业务或产品垂直拆分是非常有必要的 3 1 总体架构总体架构 总体描述系统有哪些子系统组成 通过一张图表现 以下对各系统介绍 3 1 1 Portal 客户门户客户门户 提供给供应商使用融资服务 以及银行对融资相关的操作 以下可对各模块进行描述 会员 供应商注册 登录等相关功能 合同 供应商融资合同的签订和查看等功能 3 1 2 Admin 管理门户管理门户 3 2 集成架构集成架构 描述该系统和依赖系统之间的关系 3 2 1 SCS 描述该系统和 SCS 的接口信息 接口名接口名调用方向调用方向采用技术采用技术数据格式数据格式 供应商信息查询SCF SCSESB WS对象 结算清单同步SCS SCFESB MQXML 详见 内部系统接口文档 3 2 2 中国银行中国银行 XXXXXXXXXXXXXXXXX 详见 中国银行系统接口文档 4 开发架构开发架构 4 1 技术选型技术选型 参考技术管理中心规范 类型类型可选技术可选技术 主机PC Server IBM 小型机 操作系统Linux Redhat AS IBM AIX 应用服务器开发 Jetty 生产 WAS Web 服务器IHS Nginx 负载均衡Web 软负载 IHS DMZ F5 内网 Citrix 消息中间件IBM MQ 数据库DB2 版本管理SVN 组件管理Maven IDEEclipse All in One Spring STS MVCSpring MVC 页面FreeMarker SiteMesh JSJquery Jquery UI 容器Spring 持久化MyBatis JdbcTemplate 服务Hessian CXF 调度Quartz 统一调度服务中心 缓存Redis 日志SLF4J Logback XMLDom4j Xstream 组件版本可参考 snf parent 最新版本 例外情况需要说明 参考以下原则选型 1 可控制 在短期时间内 架构师能够精通 开发人员能够掌握 2 可扩展 考虑非功能性需求 在特定的场景下便于扩展 推荐自身扩展性较好 轻量级框架 3 高可用 选择框架 定制化框架必须要保证质量 4 高效率 框架本身处理效率高 尽可能减少重复开发工作量 易于做性能调优 5 低成本 在满足以上原则前提下 尽可能降低采购成本 学习成本低 有较完善的手册文档 4 2 Portal 客户门户客户门户 参考 J2EE 系统搭建指南 4 2 1 目录结构目录结构 scf portal scf portal client 客户门户客户端工程 scf portal deploy 客户门户发布脚本 scf portal dmo 说明 scf portal war 说明 scf member 会员模块 service 会员模块服务工程 web scf contract scf xxx 5 数据架构数据架构 5 1 数据模型数据模型 实体关系图 实体实体说明说明 5 2 持久化方案持久化方案 1 DB Schema 规划 2 数据分布规则 分库 分表 分区 3 数据同步机制 4 数据归档方案 6 关键质量需求设计关键质量需求设计 描述关键质量需求的设计方案 每一项用新章节描述 6 1 安全性安全性 四防 防篡改 防抵赖 防窃取 防攻击 场景场景防防 XXX方案方案 用户输入脏数据输入过滤 防篡改签名 SQL 注入输入过滤 不要拼 SQL 脚本注入输入过滤 输出转译 Web 访问防窃取服务器证书 防抵赖个人证书 未授权访问控制 隐私数据防窃取加密 系统集成防篡改签名 防抵赖签名 防窃取加密 6 1 1 服务器证书服务器证书 两台对外的 Web 服务器上部署 的证书 6 2 高可用高可用 侧重考虑 Web 服务器 应用服务器高可用 方案 1 无单点设计 2 服务器采用集群 双节点 3 系统监控 及时得知系统异常 4 异常自动处理机制 5 流量控制 6 采用成熟的技术 7 故障可隔离 应用拆分 8 容灾方案 6 3 可可伸缩伸缩 在对架构改动最小的前提下 通过增加硬件的方式 达到更大系统吞吐量 方案 1 无单点设计 2 服务器采用集群 3 应用可垂直拆分 4 数据可水平拆分 6 4 高性能高性能 方案 1 静态资源分离 2 缓存 应用 Web C