团队的技术方案设计模板

不管我们是做业务开发，还是做基础建设，虽然产品诉求千差万别，但是我们必然需要做好方案设计，然后还需要进行方案设计评审。

之前我们团队的一些成员，甚至有些 T9 级别的同学，竟然都写不好一个技术方案设计文档。究其根本，主要还是没有形成自己的方法论，从我个人工作这么多年的经验来看，技术方案设计是可以总结出一套方法论或者说框架套路来的。为此，我总结出了一套通用的技术方案设计模板（提纲），然后在我们团队内部进行了统一，后面还推广到了整个中心，大家按照这个模板来写方案设计，绝对让你的领导满意。

大家参考我这个方案设计模板(提纲)和相关介绍来做自己的方案设计的时候，可以根据自己的实际业务情况和背景做相关目录的删减，最后得出自己最终的方案设计，然后再去进行方案评审。

精简版-技术方案设计模板（提纲）

精简版的模板如下，一般的方案设计，大家都可以参考这个提纲来写：

详细版-技术方案设计模板（提纲）

相对详细和复杂的版本如下：

下面是技术方案设计模板在每一章节的简单说明，用来帮助你理清每个章节大概要写什么内容

一，现状

现状，主要是用来描述当前这个业务(项目)的一些基本情况介绍和相关的背景。你的方案设计出来之后，是需要给你的 leader 或者团队其他成员进行评审或者查看，甚至是要给更高级别的人来评审。但是别人不可能都和你一样清楚你的项目，因此首先，你要把你项目的基本情况和背景都说清楚，让大家达成一个共识，站在同一个起点上，才能进行后面的方案评审和讨论。

业务背景

业务背景就是你这个业务（项目）的基本介绍，包括但不限于：

• • 项目名称
  
• • 业务描述
  

技术背景

技术背景就是你这个业务是基于什么样的技术背景下来构建的，我们的技术方案可能是从 0 到 1 来构建，也能是基于现有的方案来优化，但是不管是什么场景，一定都会存在相关的技术背景，因此包括但不限于：

• • 现有技术积淀
  
• • 现有架构描述
  
• • 现有系统的整体容量
  

二，需求

需求，很重要！技术人员千万不要忽略需求，因为不管你的技术有多牛逼，都一定为需求服务的，不管这个需求是技术需求，还是业务需求，一定都是要为需求服务。而需求，就是你这个技术方案的起点，技术方案一切都是围绕需求来设计，当然，这个需求可以是当下的需求，也可以包含未来潜在的需求。

只有把需求介绍清楚之后，大家才能知道你方案设计里面的所有设计和对应的折中点是否可行，也才能比较好的去评审你的方案。

业务需求

业务需求就是你这个业务具体要做的事情，包括但不限于：

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

业务痛点

• • 涉及到的业务痛点有哪些
  

性能需求

我们做需求的时候，对于技术人员，不能只看业务需求，业务需求可能是项目管理人员，也可能是产品人员提出来的，他们只会重点关注业务的可行性，只会关注业务的逻辑。但是技术人员，要从这个业务需求里面考虑清楚我们满足这个业务之下的性能需求点，比如我做一个秒杀活动，如果你不考虑性能，可能活动一上来，服务就挂掉了。性能需求包括但不限于：

• • 预估系统平均容量
  
• • 预估系统峰值容量
  
• • 可伸缩性
  
• • 其他的一些性能要求点，比如安全性等
  

三，方案描述

前面把现状和需求说清楚后，终于到了我们的重头戏，方案描述这里了。一般我们做方案，可能会有几个可选的方案，但是你不清楚哪个方案最合适，因此你需要把相关可能的方案都描述清楚，然后给出你认为的最合适的方案，然后让大家来评审和决策，看是否同意你的意见或者有其他更好的意见。

如果没有方案对比，那么可以省略掉这一章节

方案1

概述

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

详细说明

详细说明这里需要图文结合，包括但不限于架构图、流程图 等。把你整个方案的架构和模块、细节流程都描述清楚

性能目标

性能一般来说可能包含以下部分：

• • 日平均请求：一般来自产品人员的评估；
  
• • 平均QPS：日平均请求 除以 4w秒得出，为什么是4w秒呢，24小时化为86400秒，取用户活跃时间为白天算，除2得4w秒；
  
• • 峰值QPS：一般可以以QPS的2~4倍计算；
  

性能评估

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

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

方案优缺点

列出方案的优缺点，优缺点要具有确定性，最好是通过量化的指标来说明

方案2

可选的另外一种方案，模板和上面一样。

方案对比

前面给出了多种可选的方案，那么这里就是进行一个简单的对比，然后给出你觉得最优的方案和原因，这就是你的决策。

有了你自己的决策（倾向）的方案后，接下来的设计就应该更多的偏向你倾向的方案去做设计和描述

四，线上方案

线上方案是对上面你更倾向的方案的更为细致的描述。

架构图

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

关键设计点 和 设计折衷

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

因为没有一个方案设计是最完美，方案设计都是逐步演进和优化的，方案设计是要最符合当前的背景的。因此，一定会有你设计的关键点和折衷点，这也就是前面为何要把项目的各种业务背景和技术背景都说清楚的原因。

业务流程

整体流程是如何，弄一个整体流程图、核心流程图出来，然后分业务场景把各个业务场景的流程图也画出来，并且做好相关介绍

模块划分

有了业务流程，那么必然要针对这个业务流程的各个环节来划分模块，模块的划分需要考虑我们架构设计的一些原则，比如：架构分层、业务分模块、微服务化、高内聚低耦合 等。然后把每个模块的功能点都说清楚

异常边界【重要】

异常边界是比较重要的，一般情况下，大部分人都能考虑到正常的处理流程，对于异常的边界考虑的比较少，但是线上出问题，大部分都是异常情况导致，因此这里非常重要！！！

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

异常边界需要考虑:

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

统计、监控

线上运行的项目，一定需要有各种监控，除了公司内部的基建的监控外，我们可能还需要从业务内部实现自定义的一些业务监控和相关技术统计

灰度、回滚策略

• • 如何灰度？
  
• • 如何回滚？
  

容灾方案

容灾就是当出现 IDC 异常的情况下，怎么容灾，这个可以根据实际情况去考虑。

五，部署拓扑

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

六，风险评估

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

潜在风险

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

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

架构怎么演进

阶段如何规划

每个阶段该达成什么目标

第一阶段

第二阶段

第三阶段

八，工作量评估

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

~~~~~~~~ 本文完 ~~~~~~~~