吃透8图1模板，人人可以做架构

前言

在40岁老架构师尼恩的读者交流群(50+)中，很多小伙伴问尼恩：

大佬，我们写架构方案，需要从哪些方面展开

大佬，我们写总体设计方案需要一些技术亮点，可否发一些给我参考下

诸如此类，问法很多，但是不知道架构图长成啥样？架构方案怎么写。

40岁老架构师尼恩，不知道做过多少架构方案。也不知道指导了多少开发，完成了架构师的华丽转身。

现在，给大家提供一份如何画好架构图，和如何做好架构方案，核心的要点，展示给大家。

使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让你的主管、同事爱到 “不能自已、口水直流”。

也一并把这个题目以及参考答案，收入咱们的《尼恩Java面试宝典》V53版本，供后面的小伙伴参考，提升大家的 3高架构、设计、开发水平。

注：本文以 PDF 持续更新，最新尼恩架构笔记、面试题的PDF文件，请从这里获取：码云

系统架构图是为了抽象的表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。好的架构图可以让干系人理解、遵循架构决策，就需要把架构信息传递出去。那么，画架构图是为了：解决沟通障碍/达成共识/减少歧义。比较流行的是4+1视图和C4视图。

一：怎么画好架构图

一个好的架构图是不需要解释的，它应该是自描述的，并且要具备一致性和足够的准确性，前瞻性，能够与后面的设计相呼应。

架构方案的受众分析

架构方案，也要千人千面

在画出一个好的架构图之前， 首先应该要明确其受众，再想清楚要给他们传递什么信息 ，

一个方案，面向不同的受众，需要有不同的视图

不是为了画图而画图，而是应该差异化分析

要进行受众分析，应该根据受众的不同，传递的信息的不同，用图准确地表达出来，最后的图可能就是在这样一些分类里。

视图的分析维度

针对不同的受众，有不同的分析图

但是，也是层层深入的

大概有下面的 8个维度

架构图1：场景视图

用于描述系统的参与者与功能用例间的关系,

反映系统的最终需求和交互设计，通常由用例图表示;

场景分析图的受众：外部的技术或非技术人员，包括团队内部或外部的开发人员或运维人员，

架构图2：系统架构分析

系统架构分析用于描述系统软件功能拆解后的组件关系，组件约束和边界，反映系统整体组成与系统如何构建的过程，通常子系统的线框图表示。

架构图3：系统依赖分析(System Context Diagram)

系统依赖分析(System Context Diagram)用于描述要我们要构建的系统是什么，子系统直接的依赖关系是什么，用户是谁，需要如何融入已有的IT环境。

系统依赖分析图的受众：外部的技术或非技术人员，包括团队内部或外部的开发人员或运维人员，

架构图4：子系统依赖分析(Container Diagram)

子系统依赖是系统依赖图里，对待建设的子系统做了一个内部依赖关系展开分析，

子系统依赖分析主要用来描述子软件系统的内部的依赖关系，分析系统中的职责是如何分布的，子系统是如何交互的。

子系统依赖分析的受众：外部的技术或非技术人员，包括团队内部或外部的开发人员或运维人员，

架构图5：组件架构图(Component Diagram)

组件架构图是把针对某个子系统进行组件设计、模块设计，

组件架构图用于子系统的模块关系，介绍子系统由哪些组件/服务组成，了组件之间的关系和依赖，为软件开发如何分解交付提供了框架。

组件架构图受众：主要是给内部开发人员看的。

组件架构图的作用：为代码的组织和模块架构，提供支撑

架构图6：模块架构图

从编码的维度来说，组件内部，很多模块。模块架构分析，是对组件的进一步深入分析。

模块架构分析用于描述模块划分和组成,

模块架构分析可以细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。

架构图7：逻辑架构视图

逻辑架构视图用于描述系统模块内部的的通信时序,数据的输入输出,反映系统的功能流程与数据流程,、

通常由时序图和流程图表示。

架构图8：部署架构分析

用于描述系统软件到物理硬件的映射关系,反映出系统的组件是如何部署到一组可计算机器节点上，用于指导软件系统的部署实施过程。

二：怎么做好架构方案？

光有图是不够的，还要有方案

下面是一份P8 级专家的架构方案

提纲如下：

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

2.1、现状

现状，主要是用来描述当前这个业务(项目)的一些基本情况介绍和相关的背景。

方案设计出来之后，是需要给你的 leader 或者团队其他成员进行评审或者查看，

一般来说，由技术委员会来评审

但是别人不可能都和你一样清楚你的项目，

因此首先，你要把你项目的基本情况和背景都说清楚，让大家达成一个共识，

大家站在同一个起点上，才能进行后面的方案评审和讨论。

业务背景

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

项目名称
业务描述
业务难点

技术背景

技术背景就是项目是基于什么样的技术背景下来构建的，

可以是从 0 到 1 来构建，也能是基于现有的方案来优化，

但是不管是什么场景，一定都会存在相关的技术背景，因此包括但不限于：

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

2.2、需求

需求，很重要！

不管你的技术有多牛逼，都一定为需求服务的，

不管这个需求是技术需求，还是业务需求，一定都是要为需求服务。

注意：需求，这个需求可以是当下的需求，尽可能包含未来潜在的需求。

需求越完善，后面会少走弯路。

业务需求

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

业务的功能点
要提升改造的功能

业务痛点

涉及到的业务痛点有哪些

性能需求

除了业务需求，还要从这个业务需求里面考虑清楚我们满足这个业务之下的性能需求点，

如果一个系统不考虑性能，可能流量一上来，服务就挂掉了。

性能需求包括但不限于：

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

2.3、方案描述

前面把现状和需求说清楚后，终于到了我们的重头戏，方案描述这里了。

一般，需要会有几个可选的方案，

也就是说，尽可能把相关可能的方案都描述清楚，

然后给出你认为的最合适的方案，然后让大家来评审和决策，看是否同意你的意见或者有其他更好的意见。

除非万不得已，最好，不要一只有个方案。

方案1

概述

说明一下方案的核心亮点、核心特色，核心目标，核心优势

比如说：高性能、可扩展、双写、主从分离、分库分表、扩容等。

详细说明

详细说明这里需要图文结合，

包括但不限于架构图、流程图等。

把你整个方案的架构和模块、细节流程都描述清楚

性能目标

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

DAU：
日活跃用户数量。一般用于反映网站、互联网应用等运营情况。
平均QPS：
可以参考淘宝的平均QPS 估算公式，进行估算。
峰值QPS：
一般可以以QPS的2~4倍计算；

资源评估

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

按照预估性能需求，预估资源数量

单节点并发量
单节点容量
应用服务器的单节点资源配置、节点数
缓存的单节点资源配置、节点数
数据存储的单节点资源配置、节点数
消息队列的单节点资源配置、节点数
反向代理的单节点资源配置、节点数
搜索引擎的单节点资源配置、节点数
伸缩方式
高可用方式
监控预警的方式

方案优缺点

列出方案的优缺点，

这个需要通过量化的指标来支撑

方案2

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

方案对比

前面给出了多种可选的方案，那么这里就是进行一个简单的对比，

然后，给出自己的觉得最优的方案，并且给出支撑的数据、理由。

有了你自己的决策（倾向）的方案后，

当然，对于最优的方案，就应该提供更有支撑力的细化的方案和数据

2.4、线上方案

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

架构图

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

关键设计点和设计折衷

把核心的关键点，用自己的名词系统表达出来

这里有一个要求：整体是完备的、自洽的

用来确保你的方案的大体方向是 OK 的。

因为没有一个方案设计是最完美，方案设计都是逐步演进和优化的，

但是，一定是完整的、系统的、没有大漏洞的

还有，方案设计是要最符合当前的背景的。

业务流程

对于业务的核心场景，弄一个整体流程图、核心流程图出来，

然后分业务场景把各个业务场景的流程图也画出来，并且做好相关介绍

模块划分

模块的划分需要考虑我们架构设计的一些原则，

比如：架构分层、业务分模块、微服务化、高内聚低耦合等。

然后把每个模块的功能点都说清楚

异常边界【重要】

异常边界是比较重要的，一般情况下，

大部分人都能考虑到正常的处理流程，对于异常的边界考虑的比较少，

但是线上出问题，大部分都是异常情况导致，因此这里非常重要！！！

我们可以通过一个思维导图去整理相关的异常边界，

这样有助于自己在实现的时候有足够的把控度，也便于别人去 review 你的方案和具体实现（如 coding）

异常边界需要考虑:

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

监控、预警、统计

线上运行的项目，一定需要有各种监控，预警、指标统计

可以使用公司内部的基建的监控外，

还需要从业务内部，实现自定义的一些业务监控和相关技术统计

最终的目标、保证系统的高可用、支撑系统的高可用

灰度、回滚策略

如何灰度？
如何回滚？

容灾方案

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

2.5、部署架构

可以按照下面的方向，去做拓展：

线上部署拓扑什么，
各层的部署架构是什么
多活的部署架构是什么
公有云部署架构是什么

2.6、风险评估

标识所选方案的风险，提出解决此风险发生时候的应对策略，

比如：上线失败时的回滚策略。

潜在风险

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

2.7、阶段规划【架构演进规划】

架构怎么演进

阶段如何规划

每个阶段该达成什么目标

第一阶段

目标 XXXX

第二阶段

目标 XXXX

第三阶段

目标 XXXX

2.8、投入评估

最后，需要做投入的评估，作为投资回报分析的支撑，包括：

物理设备、云设备投入评估
工作量评估，

这里需要细化到每个模块、

工作量评估一般按照时间进行，一定要同时包括开发时间、联调时间、测试时间。

最好比较细化，不要太粗，

比如开发时间可以细化到接口的维度，每个接口的设计分别需要多长时间，

老马识途，找老架构取经

只要是成功走上架构师岗位的都指导，架构之路，充满了坎坷

这个和高级开发不一样，架构的问题，是open的，开发式的，没有答案的

在架构设计的过程中，会遇到无数的挫折，很多小伙伴，就没有跨过去

其实，如果真的遇到架构难题，找有经验的人帮帮忙，这道坎，就过去了

所以，如果遇到复杂的场景，确实不知道怎么做架构方案，怎么办？

可以来尼恩的技术自由圈（疯狂创客圈圈）中求助.

咱们圈聚焦架构研究，这里有上1000位架构人脉，10年多架构经验的老架构师，在100位以上。

大家什么架构方案都做过，可以给遇到困难的小伙伴，提供设计帮助、架构帮助。