如何画技术架构图？
如何画技术架构图？
在软件开发和系统设计中，技术架构图是传达设计思路和方案的重要工具。本文将详细介绍各种类型的技术架构图及其绘制方法，帮助读者更好地理解和应用这些图表。
简介
在我们做系统架构设计时，如何快速地向外界传达我们的设计思路？4+1试图（场景视图、逻辑视图、物理视图、处理流程视图和开发视图）适合我们厘清思路、表达自己的想法。在我们汇报，争取领导层的认同支持更适合用架构图来表述我们的观点。架构图包括总体架构、逻辑架构、应用架构、技术架构、数据架构、功能架构、网络架构、运行架构等等。
架构图总类
整体架构图
总体架构基本上把下面所有的架构都体现了。下面所有的架构也都是要与总体架构保持一致。
总体架构需要说明几件事情：
- 整个系统的硬件设置是怎么回事？
- 数据大概是从哪里来，怎么采集、存储、处理、交换的？
- 做了哪些功能抽象，以便于支撑上层的应用？
- 提供哪些业务应用？管理、控制等功能有哪些？
- 终端用户怎么访问和使用这些应用？
- 该系统与外部系统是怎么进行对接的？
- 如何保障整个系统的安全、可靠、高质量的建设？
逻辑架构
逻辑架构就是整体架构去掉各种保障、底层的硬件基础等非软件开发逻辑核心的内容。所以有很多简单的项目压根就不写逻辑架构，直接用总体架构就行了。复杂的，就要把上面总体架构中间分层的逻辑给写清楚一些。
关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描述，逻辑架构更偏向我们日常所理解的“分层”，把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。
逻辑架构设计的目的就是为了告诉读者，整个系统是怎么产生左右的。所谓的系统架构，主要说的就是这部分。早期的单体架构、后面的各种分层架构、微服务、服务网格等，说的都是在这里进行设计。
在设计的时候，会用到很多种设计模式，比如你看到有一个应用支撑层/服务层之类的，这就是做了一个 MVC，把业务逻辑和用户前端分离。而所有的逻辑架构都有数据层，这是最早的 MVP，即数据、用户视图和处理逻辑分离。当然，系统越复杂，架构图就越复杂。
业务架构
企业架构框架白皮书中把架构分为了四个层次，分别是业务、应用、数据、技术。只有梳理清楚了业务，才能指导应用、数据和技术架构。业务架构的分析过程是复杂的，最终的产出可能也不仅仅只是一张架构图。还有更细节的流程、建模等产出物。一张好的架构图大概是：分层次、分模块讲清楚了各个产品模块之间的关系。
应用架构
就是应用太丰富了，需要整理整理。内部有哪些应用，怎么对外部提供服务。很多项目都没有这个，因为应用比较少，不值得多废点人工单独写。用以阐述细化逻辑架构。
技术架构
技术架构要干啥也就很清楚了，就是每一层，我们都用什么组件、什么技术解决什么问题。要求是：精准、明确、简练。但大体上的结构是类似的，从最底层的存储，到最上层的接口。右边是一些通用的运维体系或者支撑服务。体现出来依赖的 SDK、第三方类库、中间件。
现在更多的情况，是多个系统模块，组成一个大的分布式系统，或者现存多个系统的情况下，需要进行集成开发一个产品。
这样的话，技术架构，就是高层级的技术架构了，不仅仅体现的是技术组件了，而是更高层级的一些模块，甚至规范。
数据架构
数据架构其实就是从数据侧描述数据怎么来、怎么存、怎么加工、怎么使用。从数据源开始，数据通过哪些方式集成过来；集成到数仓之后，都存在哪里，数仓怎么分层，每一层都干啥；在数据集市中又怎么存、怎么管；到数据应用层又提供哪些应用。上面所有的一切，都用什么技术，什么组件，解决什么问题。系统需要什么样的数据、如何存储、如何进行数据架构设计。
部署架构
部署架构也叫网络架构，就是底层服务器、网路的设计，提供网络安全、服务可靠性的设计。再简单一些理解，就是你这些应用、数据库都放在那台服务器上，这些服务器都在哪个 ip 端，怎么进行访问。要具体体现：机房；服务器个数、配置；网络分区关系；体现数据库、高可用；体现负载均衡；
功能架构
就是前台页面的功能菜单的目录结构。你怎么组织系统的所有功能，给用户提供相应的服务。
运行架构
运行架构其实就是软件内部，这些系统内部是怎么运转的，一般会画很多时序图、状态图、活动图。一般不单独画一个运行架构，而是在概要和详细设计里画。
4+1 视图
4+1 架构视图，也称为 4+1 视图模型，是一种软件架构设计方法，通常用于描述大型复杂软件系统的不同视角。它由 Philippe Kruchten 于 1995 年提出，并在 Rational Software Corporation（现在是 IBM 公司）的 Rational Unified Process（RUP）中得到广泛应用。
4+1 架构视图包括以下五个视图：
逻辑视图（Logical View）：描述系统的功能、组件和它们之间的关系。它主要关注系统的静态结构，包括类、接口、包、模块等，并用于表示系统的组织结构、模块划分和关系。
进程视图（Process View）：描述系统的并发性和分布性。它关注系统在运行时的行为，包括系统的运行时进程、线程、节点、通信方式等，并用于表示系统的并发性、分布性、通信和同步方式。
物理视图（Physical View）：描述系统的部署和配置。它关注系统在物理计算资源上的部署，包括硬件、网络、服务器、存储等，并用于表示系统的部署拓扑、配置和资源分配。
开发视图（Development View）：描述系统的软件开发过程。它关注软件的开发、构建和部署过程，包括开发环境、版本控制、构建工具、编译器等，并用于表示系统的开发工程、构建过程和开发环境。
场景视图（Scenarios View）：描述系统在不同情景下的使用场景。它关注系统的用例、用户交互和系统行为，包括用户界面、用例场景、用户需求等，并用于表示系统的功能需求、用户交互和系统行为。
逻辑视图
用于描述系统的功能需求，即系统给用户提供哪些服务；以及描述系统软件功能拆解后的组件关系、组件约束和边界，反映系统整体组成与系统如何构建的过程。在 UML 中由类图来表示（关于什么是类图，这里有一篇通俗易懂的介绍）。
下面 SpringCloud 微服务的逻辑视图示例（仅部分），就描述了 SpringCloud 中各个功能组件。从这个图中，基本可以对 springcloud 有一个大颗粒度的了解。
物理视图
开发出的软件系统，最终是要运行在物理或软件环境上。物理环境可能是服务器、PC 机、移动终端等物理设备；软件环境可以是虚拟机、容器、进程或线程。部署视图就是对这个部署信息进行描述。在 UML 中通常由部署图表示。
处理视图
处理视图，又称过程视图、运行视图。用于描述系统软件组件之间的通信时序，数据的输入输出。在 UML 中通常由时序图和流程图表示，如下图所示：
开发视图
开发视图关注软件开发环境下实际模块的组织，反映系统开发实施过程。
一个设计良好的开发视图，应该能够满足以下要求：
- 通过逻辑架构元素，能够找到它所有代码和所有的二进制交付件
- 每一个代码源文件，都能够找到它所属的逻辑架构元素
- 每一个二进制交付件，都能够找到它集成了哪些逻辑架构元素
场景视图
场景视图，即 4+1 中的 1。从前面的图可以看到，4+1 中的 4 个视图都是围绕着场景视图为核心的。它用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计。在 UML 中通常由用例图表示：
总结来说，以上5种架构视图，是从不同角度表示一个软件系统的不同特征，组合到一起作为架构蓝图描述系统架构。
总结
- 逻辑视图（Logical View）
- 进程视图（Process View）
- 物理视图（Physical View）
- 开发视图（Development View）
- 场景视图（Scenarios View）
- 运行架构