[TOC]

技术概要设计评审提纲

业务产品千差万别，没有一个统一的方法论可完成架构设计和技术评审，架构设计只需要从某些关键点来表达系统即可。提纲就是用来帮助大家做架构评审的工具，帮助大家整理思路并形成可实施的方案，因此在做系统设计时，可有选择性地参考此提纲，根据业务特点来完成一个可实现的有效的架构设计。

根据需求规格说明书和项目技术调研报告，进行软件的概要设计，通过技术研讨、系统原型设计等方法，形成软件的设计思路和设计模型，绘制系统设计图表（包括系统总体架构图、系统结构划分图、动态交换关系图、系统流程图、系统运行设计图表、系统部署架构图、系统技术架构图），定义系统关键数据结构，设计系统关键接口。如果有必要的话，需要开发软件原型系统对设计思路进行验证，并作为后续系统开发的基础。

总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。

一，现状

业务背景

项目名称
业务描述

技术背景

架构描述
当前系统容量（系统调用量平均值）
当前系统调用量峰值
现有技术积淀

二，需求

业务需求

要改造的内容
要实现的新需求

业务痛点

涉及到的业务痛点有哪些

性能需求

预估系统容量（预估系统调用量平均值）
预估系统调用量峰值
其他非功能质量，例如：安全性、可伸缩等

三，方案描述

方案1

概述

一句话概括方案的亮点，比如说：双写、主从分离、分库分表、扩容、归档等。

详细说明

方案的具体描述，文字描述不清楚的话可以结合图（任何图：UML、概念图、框图等）的方式说明，如果是改造方案最好突出变动的地方，以下列举了几种描述的角度：

中间件架构（应用服务器、数据库、缓存、消息队列等）
逻辑架构（模块划分、模块通信、信息流、时序等）
数据架构（数据结构、数据分布、拆分策略、缓存策略、读写分离策略、查询策略、数据一致性策略）
异常处理，容灾策略，灰度发布

性能评估

给出方案的基准数据，并按性能需求评估需要使用的资源数量。

单机并发量
单机容量
按照预估性能需求，预估资源数量(应用服务器、缓存、存储、队列等)
伸缩方式

方案优缺点

列出方案的优缺点，优缺点要具有确定性，不要有“存在一定风险”这种描述，也就是要量化。

方案2

整个方案需要参考技术评审指标提出的各方面指标来考虑满足系统的非功能质量需求。

四，方案对比

对比可选方案，并给出选择这种方案的理由，选择倾向的方案。

五，线上方案

对上面倾向的方案的更为细致的描述

具体方案

具体方案设计是如何

架构图

整体架构是如何，把架构图画上

关键设计点

把几个关键、重点的点的设计思想表述出来，用户确保大的方向是 OK 的。

整体流程

整体流程是如何，弄一个整体流程图

关键系统的核心流程是如何

模块划分

1、模块描述：说明哪些模块实现了哪些功能； 2、模块层次结构：可以使用某个视角的软件框架图来表达； 3、模块间的关系：模块间依赖关系的描述，通信机制描述； 4、模块的核心接口：说明模块传递的信息、信息的结构； 5、处理方式设计：说一些满足功能和性能的算法；

异常边界【重要】

通过一个 xmind 格式去整理相关的异常边界，这样有助于自己在实现的时候有足够的把控度，也便于别人去 review 你的方案和具体实现（如 coding）

异常边界需要考虑:

涉及到了哪些模块
涉及到了哪些流程
每个模块、流程出现了各种可能情况的处理是？
系统底层原因导致的异常的处理是？

统计、监控

灰度、回滚策略

如何灰度？
如何回滚？

容灾方案

六，部署拓扑

线上部署拓扑如何，上下游是如何

七，风险评估

标识所选方案的风险，提出解决此风险发生时候的应对策略，比如：上线失败时的回滚策略。

潜在风险

相关的改动有哪些风险点
不兼容点？
当前设计方案目前存在哪些问题？
潜在有哪些问题

八，阶段规划【架构演进规划】

架构怎么演进

阶段如何规划

每个阶段该达成什么目标

第一阶段

第二阶段

第三阶段

九，工作量评估

描述使用所选方案需要做的具体工作，并评估开发、测试等细化任务需要的时间，形成可实施的任务计划表，任务计划表推荐采用简单的表格形式，减少工具使用和学习的成本。

【"欢迎关注我的微信公众号：Linux 服务端系统研发，后面会大力通过微信公众号发送优质文章"】