系统架构

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

1 怎么画好架构图

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

2 架构方案的受众分析

架构方案，也要 千人千面，在画出一个好的架构图之前， 首先应该要明确其受众，再想清楚要给他们传递什么信息 ，一个方案，面向不同的受众，需要有不同的视图，不是为了画图而画图，而是应该差异化分析

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

3 视图的分析维度

针对不同的受众，有不同的分析图，但是，也是层层深入的；
大概有下面的 8个维度

3.1 场景视图

用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计，通常由用例图表示；

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

image.png

3.2 系统架构分析

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

image.png

3.3 系统依赖分析

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

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

image.png

3.4 子系统依赖分析

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

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

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

image.png

3.5 组件架构图

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

组件架构图受众：主要是给内部开发人员看的。
组件架构图的作用：为代码的组织和模块架构，提供支撑

image.png

3.6 模块架构图

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

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

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

image.png

3.7 逻辑架构视图

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

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

image.png

3.8 部署架构分析

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

image.png

对于程序员来说，最常用的是这三种架构图，
3.2 系统架构分析：通常用于整体描述系统所包含的组件
3.5 组件架构图：通常用于模块设计
3.7 逻辑架构视图 ：通常用于开发小组内部讨论具体的复杂的开发流程；

4 案例

上面根据不同的受众划分了8中类型的架构图，但是实际应用中，不需要那么死板，架构说到底是为了达成交流共识的实现方案演示，并不一定非得拘泥于某种形式，只要你能画的清楚，讲的明白就最合适不过了。

以下是三个案例

案例1：架构选型图

image.png

作用：通常在新项目开发初期，都要做一些技术选型工作。在负载、网关、架构、治理、框架、服务、数据以及环境和支撑服务上，要选择适合当前开发的技术。

案例2：微服务架构

image.png

作用：技术选型完毕后，接下来就是对于这些技术的运用。这个过程有点像搭积木一样，把每一个区域用适合此位置的积木填充进去。如果是团队初建或者是技术升级，那么这个过程还是比较复杂的，需要大量的验证。不过其实互联网的技术分层和使用已经相对稳定，搭建一个这样的微服务并不会耗费太长的时间。

案例3：技术架构图

image.png

作用：技术架构图主要是对于研发层面做技术实现指导的，它可以把系统分层和实现结构划分清楚。另外一般也会把案例工程的结构拿出来一起讲解，这样可以让团队伙伴快速的进入开发。

技术方案

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

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

1 精简版-技术方案设计模板

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

image.png

2 详细版-技术方案设计模板

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

image.png

3 现状

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

3.1 业务背景

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

• 项目名称
• 业务描述

3.2 技术背景

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

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

4 需求

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

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

4.1 业务需求

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

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

4.2 业务痛点

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

4.3 性能需求

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

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

5 方案描述

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

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

5.1 方案1

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

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

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

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

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

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

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

5.2 方案2

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

5.3 方案对比

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

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

6 线上方案

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

6.1 架构图

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

6.2 关键设计点 和 设计折衷

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

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

6.3 业务流程

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

6.4 模块划分

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

6.5 异常边界【重要】

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

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

异常边界需要考虑:

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

6.6 统计、监控

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

6.7 灰度、回滚策略

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

6.8 容灾方案

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

7 部署拓扑

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

8 风险评估

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

潜在风险

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

9 阶段规划【架构演进规划】

• 架构怎么演进

• 阶段如何规划

• 每个阶段该达成什么目标

  • 第一阶段
  • 第二阶段
  • 第三阶段

10 工作量评估

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