技术方案文档模板

技术方案文档模板

一，现状

业务背景
业务背景就是你这个业务（项目）的基本介绍，包括但不限于：
项目名称
业务描述
技术背景
技术背景就是你这个业务是基于什么样的技术背景下来构建的，我们的技术方案可能是从 0 到 1 来构建，也能是基于现有的方案来优化，但是不管是什么场景，一定都会存在相关的技术背景，因此包括但不限于：
现有技术积淀
现有架构描述
现有系统的整体容量
需求
需求，就是你这个技术方案的起点，技术方案一切都是围绕需求来设计，当然，这个需求可以是当下的需求，也可以包含未来潜在的需求。
只有把需求介绍清楚之后，大家才能知道你方案设计里面的所有设计和对应的折中点是否可行，也才能比较好的去评审你的方案。
业务需求
业务需求就是你这个业务具体要做的事情，包括但不限于：
要改造的内容
要实现的新需求
业务痛点
涉及到的业务痛点有哪些
性能需求
我们做需求的时候，对于技术人员，不能只看业务需求，业务需求可能是项目管理人员，也可能是产品人员提出来的，他们只会重点关注业务的可行性，只会关注业务的逻辑。但是技术人员，要从这个业务需求里面考虑清楚我们满足这个业务之下的性能需求点，比如我做一个秒杀活动，如果你不考虑性能，可能活动一上来，服务就挂掉了。性能需求包括但不限于：
预估系统平均容量
预估系统峰值容量
可伸缩性
其他的一些性能要求点，比如安全性等

二，方案描述

前面把现状和需求说清楚后，终于到了我们的重头戏，方案描述这里了。一般我们做方案，可能会有几个可选的方案，但是你不清楚哪个方案最合适，因此你需要把相关可能的方案都描述清楚，然后给出你认为的最合适的方案，然后让大家来评审和决策，看是否同意你的意见或者有其他更好的意见。
如果没有方案对比，那么可以省略掉这一章节
方案1
概述
一句话概括方案的亮点，比如说：高性能、可扩展、双写、主从分离、分库分表、扩容等。
详细说明
详细说明这里需要图文结合，包括但不限于架构图、流程图等。把你整个方案的架构和模块、细节流程都描述清楚。
性能目标
性能一般来说可能包含以下部分：
日平均请求：一般来自产品人员的评估；
平均QPS：日平均请求 除以 4w秒得出，为什么是4w秒呢，24小时化为86400秒，取用户活跃时间为白天算，除2得4w秒；
峰值QPS：一般可以以QPS的2~4倍计算；
性能评估
给出方案的基准数据，并按性能需求评估需要使用的资源数量。
单机并发量
单机容量
按照预估性能需求，预估资源数量(应用服务器、缓存、存储、队列等)
方案优缺点
列出方案的优缺点，优缺点要具有确定性，最好是通过量化的指标来说明

方案2

方案对比
前面给出了多种可选的方案，那么这里就是进行一个简单的对比，然后给出你觉得最优的方案和原因，这就是你的决策。
有了你自己的决策（倾向）的方案后，接下来的设计就应该更多的偏向你倾向的方案去做设计和描述

三，线上方案

线上方案是对上面你更倾向的方案的更为细致的描述。
架构图
整体架构是如何，把架构图画上
关键设计点和设计折衷
把几个关键、重点的点的设计思想表述出来，用来确保你的方案的大体方向是 OK 的。因为没有一个方案设计是最完美，方案设计都是逐步演进和优化的，方案设计是要最符合当前的背景的。因此，一定会有你设计的关键点和折衷点，这也就是前面为何要把项目的各种业务背景和技术背景都说清楚的原因。
业务流程
整体流程是如何，弄一个整体流程图、核心流程图出来，然后分业务场景把各个业务场景的流程图也画出来，并且做好相关介绍
模块划分
有了业务流程，那么必然要针对这个业务流程的各个环节来划分模块，模块的划分需要考虑我们架构设计的一些原则，比如：架构分层、业务分模块、微服务化、高内聚低耦合 等。然后把每个模块的功能点都说清楚
异常边界【重要】
异常边界是比较重要的，一般情况下，大部分人都能考虑到正常的处理流程，对于异常的边界考虑的比较少，但是线上出问题，大部分都是异常情况导致，因此这里非常重要！！！
我们可以通过一个 xmind 格式去整理相关的异常边界，这样有助于自己在实现的时候有足够的把控度，也便于别人去 review 你的方案和具体实现（如 coding）异常边界需要考虑
涉及到了哪些模块
涉及到了哪些流程
每个模块、流程出现了各种可能情况的处理是？
系统底层原因导致的异常的处理是 ？
统计、监控
线上运行的项目，一定需要有各种监控，除了公司内部的基建的监控外，我们可能还需要从业务内部实现自定义的一些业务监控和相关技术统计

四，风险评估

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

五，工作量评估

工作量评估也是一个重要的环节，这里需要细化到每个模块、每个接口的设计分别需要多长时间，一定要同时包括开发时间、联调时间、测试时间。