简单的架构模板

大纲
1. 现状
  1. 业务背景
  2. 技术背景
2. 需求
  1. 业务需求
  2. 业务痛点
  3. 性能需求
3. 方案描述
  1. 方案1
    1. 概述
    2. 详细说明
    3. 性能目标
    4. 性能评估
    5. 方案优缺点
  2. 方案2
  3. 方案对比
4. 线上方案
  1. 架构图
  2. 关键设计点和设计折衷
  3. 业务流程
  4. 模块划分
  5. 异常边界（重要）
  6. 统计，监控
  7. 灰度，回滚策略
  8. 容灾方案
5. 部署拓扑
6. 风险评估
  1. 潜在风险
7. 阶段规划(架构演进规划)
  1. 第一阶段
  2. 第二阶段
  3. 第三阶段
8. 工作量评估
现状
1. 现状，
2. 主要是用来描述当前这个业务(项目)的一些基本情况介绍和相关的背景
3. 方案设计出来之后，是需要给你的 leader 或者团队其他成员进行评审或者查看
4. 一般来说，由技术委员会来评审
5. 但是别人不可能都和你一样清楚你的项目，
6. 因此首先，你要把你项目的基本情况和背景都说清楚，让大家达成一个共识
7. 大家站在同一个起点上，才能进行后面的方案评审和讨论。
8. 业务背景
9. 业务背景就是你这个业务的基本介绍，包括但不限于：
  1. 项目名称
  2. 业务描述
  3. 业务难点
10. 技术背景
11. 技术背景就是项目是基于什么样的技术背景下来构建的
12. 可以是从 0 到 1 来构建，也能是基于现有的方案来优化，
13. 但是不管是什么场景，一定都会存在相关的技术背景，因此包括但不限于
  1. 现有技术积淀
  2. 现有架构描述
  3. 现有系统的整体容量
需求
1. 需求
2. 不管这个需求是技术需求，还是业务需求，一定都是要为需求服务
3. 注意：需求，这个需求可以是当下的需求，尽可能包含未来潜在的需求
4. 需求越完善，后面会少走弯路。
5. 业务需求
6. 业务需求就是你这个业务具体要做的事情，包括但不限于：
  1. 业务的功能点
  2. 要提升改造的功能
7. 业务痛点
8. 涉及到的业务痛点有哪些
9. 性能需求
10. 除了业务需求，还要从这个业务需求里面考虑清楚我们满足这个业务之下的性能需求点
11. 如果一个系统不考虑性能，可能流量一上来，服务就挂掉了
12. 性能需求包括但不限于
  1. 预估系统平均容量
  2. 预估系统峰值容量
  3. 可伸缩性
  4. 其他的一些性能要求点，比如安全性等
方案描述
1. 方案描述
2. 一般，需要会有几个可选的方案
3. 也就是说，尽可能把相关可能的方案都描述清楚
4. 然后给出你认为的最合适的方案，然后让大家来评审和决策，看是否同意你的意见或者有其他更好的意见。
5. 除非万不得已，最好，不要一只有个方案
6. 方案1
  1. 概述
    1. 说明一下方案的核心亮点、核心特色，核心目标，核心优势
    2. 比如说：高性能、可扩展、双写、主从分离、分库分表、扩容等。
  2. 详细说明
    1. 详细说明这里需要图文结合
    2. 包括但不限于架构图、流程图等。
    3. 把你整个方案的架构和模块、细节流程都描述清楚
  3. 性能目标
    1. 性能一般来说可能包含以下部分：
      1. DAU：日活跃用户数量。一般用于反映网站、互联网应用等运营情况
      2. 平均QPS：可以参考淘宝的平均QPS 估算公式，进行估算
      3. 峰值QPS：一般可以以QPS的2~4倍计算
  4. 资源评估
    1. 给出方案的基准数据，并按性能需求评估需要使用的资源数量
    2. 按照预估性能需求，预估资源数量
      1. 单节点并发量
      2. 单节点容量
      3. 应用服务器的单节点资源配置、节点数
      4. 缓存的单节点资源配置、节点数
      5. 数据存储的单节点资源配置、节点数
      6. 消息队列的单节点资源配置、节点数
      7. 反向代理的单节点资源配置、节点数
      8. 搜索引擎的单节点资源配置、节点数
      9. 伸缩方式
      10. 高可用方式
      11. 监控预警的方式
  5. 方案优缺点
    1. 列出方案的优缺点，
    2. 这个需要通过量化的指标来支撑
7. 方案2
  1. 可选的另外一种方案，模板和上面一样
8. 方案对比
  1. 前面给出了多种可选的方案，那么这里就是进行一个简单的对比
  2. 然后，给出自己的觉得最优的方案，并且给出支撑的数据、理由
  3. 有了你自己的决策（倾向）的方案后
  4. 当然，对于最优的方案，就应该提供更有支撑力的细化的方案和数据
线上方案
1. 线上方案
  1. 线上方案是对上面你更倾向的方案的更为细致的描述
2. 架构图
  1. 整体架构是如何，把架构图画上
3. 关键设计点和设计折衷
  1. 把核心的关键点，用自己的名词系统表达出来
  2. 这里有一个要求：整体是完备的、自洽的
  3. 用来确保你的方案的大体方向是 OK 的。
  4. 因为没有一个方案设计是最完美，方案设计都是逐步演进和优化的
  5. 但是，一定是完整的、系统的、没有大漏洞的
  6. 还有，方案设计是要最符合当前的背景的
4. 业务流程
  1. 对于业务的核心场景，弄一个整体流程图、核心流程图出来
  2. 然后分业务场景把各个业务场景的流程图也画出来，并且做好相关介绍
5. 模块划分
  1. 模块的划分需要考虑我们架构设计的一些原则
  2. 比如：架构分层、业务分模块、微服务化、高内聚低耦合等。
  3. 然后把每个模块的功能点都说清楚
6. 异常边界【重要】
  1. 异常边界是比较重要的，一般情况下
  2. 大部分人都能考虑到正常的处理流程，对于异常的边界考虑的比较少
  3. 但是线上出问题，大部分都是异常情况导致，因此这里非常重要
  4. 我们可以通过一个思维导图去整理相关的异常边界
  5. 这样有助于自己在实现的时候有足够的把控度，也便于别人去 review 你的方案和具体实现（如coding）
  6. 异常边界需要考虑
    1. 涉及到了哪些模块
    2. 涉及到了哪些流程
    3. 每个模块、流程出现了各种可能情况的处理是？
    4. 系统底层原因导致的异常的处理是？
监控、预警、统计
1. 线上运行的项目，一定需要有各种监控，预警、指标统计
2. 可以使用公司内部的基建的监控外
3. 还需要从业务内部，实现自定义的一些业务监控和相关技术统计
4. 最终的目标、保证系统的高可用、支撑系统的高可用
灰度、回滚策略
1. 容灾方案
  1. 容灾就是当出现 IDC 异常的情况下，怎么容灾，这个可以根据实际情况去考虑。
部署拓扑
1. 可以按照下面的方向，去做拓展：
2. 线上部署拓扑什么，
3. 各层的部署架构是什么
4. 多活的部署架构是什么
5. 公有云部署架构是什么
风险评估
1. 风险评估
  1. 标识所选方案的风险，提出解决此风险发生时候的应对策略
  2. 比如：上线失败时的回滚策略
2. 潜在风险
  1. 相关的改动有哪些风险点
  2. 不兼容点？
  3. 当前设计方案目前存在哪些问题？
  4. 潜在有哪些问题
阶段规划【架构演进规划】
1. 架构怎么演进
2. 阶段如何规划
3. 每个阶段该达成什么目标
投入评估
1. 最后，需要做投入的评估，作为投资回报分析的支撑，包括：
  1. 物理设备、云设备投入评估
  2. 工作量评估
2. 这里需要细化到每个模块
3. 工作量评估一般按照时间进行，一定要同时包括开发时间、联调时间、测试时间
4. 最好比较细化，不要太粗
5. 比如开发时间可以细化到接口的维度，每个接口的设计分别需要多长时间