如何画架构图？

今天再讲下如何画架构图。

架构图素材和软件架构构图逻辑概述

而对于软件架构设计分层逻辑在前面我也专门分享了一篇文章进行说明，这篇文章给出了核心的架构图制作思路，可以参考。

软件架构设计分层模型和构图思考

要完成一个完整的架构图构图，可以先拆分为两边+中间。两边一般是放具体的标准，规范等，比如安全管理，质量管理，技术标准规范，开发运维规范等。

中间即是重点需要考虑进行分层构建的地方。

在前面也谈到了中间部分重点参考云计算和SOA的架构分层逻辑。一般来说核心的还是资源层，平台层，应用层，门户层。而对于应用层本身又可以考虑业务域进一步拆分，或者根据价值链或业务生命周期拆分为多个阶段域再展开描述。

在云和SOA下，更加强调平台+应用构建的模式。而两者之间一般是服务层，通过SOA平台或API能力开放平台来统一接入和发布服务，以形成一个完整的资源+服务+应用的松耦合架构。

当然对于领域设计架构分层实际也是传统的三层架构模型和SOA架构思想的一种融合，同时独立出单独的服务层和应用层的概念。

再谈分层逻辑

一个完整的架构本身就是多视角的，如下

功能架构往往可以给具体用户和业务人员看，而对于技术架构往往更多是内部团队开发人员研讨使用。而设计到资源和平台的架构图往往又是运维工程人员进行部署架构搭建的重要参考。因此不同维度的架构分层属性本身不能随意融合使用，而导致架构图混乱。

云计算分层逻辑

云平台的分层逻辑，即标准的IaaS-PaaS-SaaS三层

• IaaS层：资源层，计算，存储，网络
• PaaS层：各种平台可以放到这层，包括技术平台，集成平台，数据平台等
• SaaS层：对应到应用即服务

当然在构图的时候往往会进一步做些扩展。

比如构建物联网应用的架构，一般会在底层扩展网络和感知层。如果要体现平台+应用的服务化开发思路，一般会增加一个独立的服务层或能力开放层。

云计算架构分层模型一般用在最顶层的整体架构规划设计，这类架构图重点体现出云架构分层，体现平台+应用化构建，体现出各个应用域和具体应用。

要明白在这类架构图里面，各个应用一般只会是一个小方框而不会展开。但是从整个大架构规划里面又能够看到基于云平台构建了哪些具体的应用。

类似一个智慧城市的架构图参考如下：

这类架构图在智慧城市，智慧政务，企业整体IT架构规划中都会应用，一般属于顶层架构设计，体现云平台分层，体现技术平台能力和各个IT应用即可。而不做展开。

应用技术架构

注意常说的类似Java开发里面的三层架构，数据访问层，业务逻辑层，展现层。或者类似领域模型中的领域服务层，应用层，界面接口层分层方法。

这些本质是偏应用技术架构的描述。

技术架构描述的重点不是讲清楚应用有哪些功能，而是要说清楚应用中的每一个功能是如何通过技术分层来实现的。比如你需要先定义数据库结构，开发数据访问接口，然后编写业务规则逻辑，最好实现前端界面展现设计，再将所有分层内容连接起来。

所以应用技术架构更多是应用实现技术层面的内容，而不是去关心应用实现用的底层IT基础设施资源。在应用技术架构里面一般不会涉及到底层具体的资源或平台，如果应用技术架构在底层增加了类似IT基础设施，存储等内容，就显得不伦不类了。

类似上图，实际就完全没有必要体现出最底层的基础层内容。

应用功能架构

简单来说应用功能架构需要的是体现出应用有哪些业务模块，有哪些具体的业务功能点，而不是关心应用实现的技术架构分层等内容。

但是应用功能架构最好也体现分层。

简单方式就是最下层全部抽象到基础技术支撑层里面，这里面包括了具体的和业务无关的基础技术支撑功能。中间就是应用功能层，最上层是门户层。

在应用功能层的描述中可以分具体的业务域再到业务功能逐层展开，如果业务应用本身有一个完整的生命周期或阶段线条，那么还可以按阶段来排列具体的功能模块。而底层一般放具体的基础数据管理，元数据管理等功能模块。

当然在应用功能架构的构图中，有时候还需要体现出当前应用和外部应用之间的集成，因此可以在纵向再单独增加了一个接口集成的模块。如下：

集成架构的构图

由于我自己经常做SOA规划咨询类项目，因此做整个企业IT应用间集成架构和做接口关系梳理的时候比较多。一个集成架构不仅仅体现出各个IT系统，更加重要的是需要体现出各个IT系统至今的集成关系和关键的集成点，在集成点上又要体现核心基础的数据流。

对于这类图整体可以理解为传统软件工程里面的数据流图的一个演进。

构图的难点是在于整体IT系统的布局，各个系统间接口连接线的设计，如果设计得不好那么集成架构图就会显得很凌乱。

这本身就是一个不断优化调整的过程，没有统一的方法可以遵循。

部署架构-物理架构还是逻辑架构

我们先看一个常见的网络布线和拓扑架构图。

这个图体现了IT基础设施架构的一个关键内容，即应用层，接入层，汇聚层。汇聚后统一进入到核心网。核心网通过DMZ区再连接到互联网。

如果你做一个IT系统的部署架构，一般不会体现最终的应用层内容。

而是体现你核心系统里面的各个IT基础设施情况，如数据库服务器，中间件服务器，缓存服务器等。但是所有的资源配置最终仍然是经过汇聚层交换机后进入到核心网。

类似如下：

因此在部署架构中不会去体现云平台的分层架构，也不会去体现应用分层架构，只需要列清楚具体的物理资源或逻辑资源，以及资源本身接入和汇聚的情况即可。

应用层拆分-前台应用和中台能力层

最近几年谈中台和微服务比较多，注意中台本身是一个业务概念。

实际中台层本身是原来应用层可共享的共性业务能力的下沉，中台层能力在原来是属于应用层能力的。因此在中台架构下，应用层进一步拆分为前台应用和中台能力。

类似一个电商的中台架构如下：

也就是中台架构下的分层应该是：前台应用+中台能力+后台

这个后台有人会理解为技术平台或技术中台，但是更好地理解是后台本身也是原来的应用层内容，也是业务能力的实现。类似在我前面文章中提到过的，企业传统的ERP系统就下沉为后台应用层能力。同时基于后台能力构建了一个抽象服务适配层，这个抽象的共享服务适配层即是中台能力。在这种场景下中台更类似一个服务层。

SOA架构分层，体现独立的服务层

对于SOA架构分层，重点要体现的就是服务，对于组件本身是属于逻辑资源层的概念，而对于服务则是资源对外暴露的能力抽象。

SOA架构分层重点就是要体现出独立的服务层，注意不是画服务总线，这里可以单独画出具体提供哪些业务服务能力，技术服务能力。在采用SOA架构进行开发的时候，整体业务系统拆分为4个组件，10类服务域，5类流程，那么在构建的时候重点就是将上述组件，服务域和流程类体现出来。

这里的数据层最好改为标准的组件层，更加贴近SOA架构模型。在图中的服务层已经可以看到一个个独立的API服务接口。如果服务接口数据大，一般只会划分到服务域，比如用户中心服务，采购类服务等。

多种分层思路的一个糅合

在前面谈到SOA架构分层，云平台分层，应用技术架构分层等多个分层方法，但是各种分层思路一般不混用，各有各的应用场景。

当然有时候也需要多个分层架构的思想融合。

比如需要在一个分层架构中既体现出技术架构分层，又体现出类似SOA和云的平台+应用架构思想，那么就需要多种分层架构融合。

比如前面谈到云平台是一种横向资源-平台-应用的分层方式。而对于技术架构分层仅仅是应用的进一步展开。那么我们在构图的时候就可以横向+纵向结合的方式来进行构图，同时体现出两种分层内容，参考如下：

参考上图，可以将技术架构的分层转变为纵向方式进行描述。而横向重点还是体现云和SOA的架构分层，整体思路就更加清晰。

个人原创的架构图构图案例参考如下：

对于PPT源文件，请关注个人微信公众号 人月聊IT 并留言获取。感谢支持。

在我们做系统架构设计时，如何快速的向外界传达我们的设计思路。4+1试图适合我们厘清思路、表达自己的想法。在我们汇报，争取领导层的认同支持更适合用架构图来表述我们的观点。架构图包括总体架构、逻辑架构、应用架构、技术架构、数据架构、功能架构、网络架构、运行架构等等。

一、整体架构图

总体架构基本上把下面所有的架构都体现了。下面所有的架构也都是要与总体架构保持一致。

总体架构需要说明几件事情：

• 整个系统的硬件设置是怎么回事？
• 数据大概是从哪里来，怎么采集、存储、处理、交换的？
• 做了哪些功能抽象，以便于支撑上层的应用？
• 提供哪些业务应用？管理、控制等功能有哪些？
• 终端用户怎么访问和使用这些应用？
• 该系统与外部系统是怎么进行对接的？
• 如何保障整个系统的安全、可靠、高质量的建设？

二、逻辑架构

逻辑架构就是整体架构去掉各种保障、底层的硬件基础等非软件开发逻辑核心的内容。所以有很多简单的项目压根就不写逻辑架构，直接用总体架构就行了。复杂的，就要把上面总体架构中间分层的逻辑给写清楚一些。

关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描述，逻辑架构更偏向我们日常所理解的“分层”，把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。

逻辑架构设计的目的就是为了告诉读者，整个系统是怎么产生左右的。所谓的系统架构，主要说的就是这部分。早期的单体架构、后面的各种分层架构、微服务、服务网格等，说的都是在这里进行设计。

在设计的时候，会用到很多种设计模式，比如你看到有一个应用支撑层/服务层之类的，这就是做了一个MVC，把业务逻辑和用户前端分离。而所有的逻辑架构都有数据层，这是最早的MVP，即数据、用户视图和处理逻辑分离。当然，系统越复杂，架构图就越复杂。

三、业务架构

企业架构框架白皮书中把架构分为了四个层次，分别是业务、应用、数据、技术。只有梳理清楚了业务，才能指导应用、数据和技术架构。业务架构的分析过程是复杂的，最终的产出可能也不仅仅只是一张架构图。还有更细节的流程、建模等产出物。一张好的架构图大概是：分层次、分模块讲清楚了各个产品模块之间的关系。

四、应用架构

就是应用太丰富了，需要整理整理。内部有哪些应用，怎么对外部提供服务。很多项目都没有这个，因为应用比较少，不值得多废点人工单独写。用以阐述细化逻辑架构。

五、技术架构

技术架构要干啥也就很清楚了，就是每一层，我们都用什么组件、什么技术解决什么问题。要求是：精准、明确、简练。但大体上的结构是类似的，从最底层的存储，到最上层的接口。右边是一些通用的运维体系或者支撑服务。体现出来依赖的SDK、第三方类库、中间件。

现在更多的情况，是多个系统模块，组成一个大的分布式系统，或者现存多个系统的情况下，需要进行集成开发一个产品。

这样的话，技术架构，就是高层级的技术架构了，不仅仅体现的是技术组件了，而是更高层级的一些模块，甚至规范。

六、数据架构

数据架构其实就是从数据侧描述数据怎么来、怎么存、怎么加工、怎么使用。从数据源开始，数据通过哪些方式集成过来；集成到数仓之后，都存在哪里，数仓怎么分层，每一层都干啥；在数据集市中又怎么存、怎么管；到数据应用层又提供哪些应用。上面所有的一切，都用什么技术，什么组件，解决什么问题。系统需要什么样的数据、如何存储、如何进行数据架构设计。

七、部署架构

部署架构也叫网络架构，就是底层服务器、网路的设计，提供网络安全、服务可靠性的设计。再简单一些理解，就是你这些应用、数据库都放在那台服务器上，这些服务器都在哪个ip端，怎么进行访问。要具体体现：机房；服务器个数、配置；网络分区关系；体现数据库、高可用；体现负载均衡；

八、功能架构

就是前台页面的功能菜单的目录结构。你怎么组织系统的所有功能，给用户提供相应的服务。

九、运行架构

运行架构其实就是软件内部，这些系统内部是怎么运转的，一般会画很多时序图、状态图、活动图。一般不单独画一个运行架构，而是在概要和详细设计里画。

架构图可以说是一个程序员的必备技能。做为一个在从业十多年中，画过无数的架构图的IT老司机，我来分享一下如何去画架构图？

当我们想用一张或几张图来描述我们的系统时，是不是经常遇到以下情况：

对着画布无从下手、删了又来？
如何用一张图描述我的系统，并且让产品、运营、开发都能看明白？
画了一半的图还不清楚受众是谁？
画出来的图到底是产品图功能图还是技术图又或是大杂烩？
图上的框框有点少是不是要找点儿框框加进来？
布局怎么画都不满意……

如果有同样的困惑，本文将介绍一种画图的方法论，来让架构图更清晰。

先厘清一些基础概念

1、什么是架构？

架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策。

架构是结构和愿景。

系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。

做好架构是个复杂的任务，也是个很大的话题，本篇就不做深入了。有了架构之后，就需要让干系人理解、遵循相关决策。

2、什么是架构图？

系统架构图是为了抽象地表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。

3、架构图的作用

一图胜千言。要让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体。那么，画架构图是为了：

• 解决沟通障碍
• 达成共识
• 减少歧义

4、架构图分类

搜集了很多资料，分类有很多，有一种比较流行的是4+1视图，分别为场景视图、逻辑视图、物理视图、处理流程视图和开发视图。

★ 场景视图

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

★ 逻辑视图

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

★ 物理视图

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

★ 处理流程视图

处理流程视图用于描述系统软件组件之间的通信时序，数据的输入输出，反映系统的功能流程与数据流程,通常由时序图和流程图表示。

★ 开发视图

开发视图用于描述系统的模块划分和组成，以及细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。

以上 5 种架构视图从不同角度表示一个软件系统的不同特征，组合到一起作为架构蓝图描述系统架构。

怎样的架构图是好的架构图

上面的分类是前人的经验总结，图也是从网上摘来的，那么这些图画的好不好呢？是不是我们要依葫芦画瓢去画这样一些图？

先不去管这些图好不好，我们通过对这些图的分类以及作用，思考了一下，总结下来，我们认为，在画出一个好的架构图之前， 首先应该要明确其受众，再想清楚要给他们传递什么信息 ，所以，不要为了画一个物理视图去画物理视图，为了画一个逻辑视图去画逻辑视图，而应该根据受众的不同，传递的信息的不同，用图准确地表达出来，最后的图可能就是在这样一些分类里。那么，画出的图好不好的一个直接标准就是：受众有没有准确接收到想传递的信息。

明确这两点之后，从受众角度来说，一个好的架构图是不需要解释的，它应该是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。

画架构图遇到的常见问题

1、方框代表什么？

为什么适用方框而不是圆形，它有什么特殊的含义吗？随意使用方框或者其它形状可能会引起混淆。

2、虚线、实线什么意思？箭头什么意思？颜色什么意思？

随意使用线条或者箭头可能会引起误会。

3、运行时与编译时冲突？层级冲突？

架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱。

本文推荐的画图方法

C4 模型使用容器（应用程序、数据存储、微服务等）、组件和代码来描述一个软件系统的静态结构。这几种图比较容易画，也给出了画图要点，但最关键的是，我们认为，它明确指出了每种图可能的受众以及意义。

下面的案例来自C4官网，然后加上了一些我们的理解，来看看如何更好的表达软件架构

1、语境图(System Context Diagram)

这是一个想象的待建设的互联网银行系统，它使用外部的大型机银行系统存取客户账户、交易信息，通过外部电邮系统给客户发邮件。可以看到，非常简单、清晰，相信不需要解释，都看的明白，里面包含了需要建设的系统本身，系统的客户，和这个系统有交互的周边系统。

★ 用途

这样一个简单的图，可以告诉我们，要构建的系统是什么；它的用户是谁，谁会用它，它要如何融入已有的IT环境。这个图的受众可以是开发团队的内部人员、外部的技术或非技术人员。即：

• 构建的系统是什么
• 谁会用它
• 如何融入已有的IT环境

★ 怎么画

中间是自己的系统，周围是用户和其它与之相互作用的系统。这个图的关键就是梳理清楚待建设系统的用户和高层次的依赖，梳理清楚了画下来只需要几分钟时间。

2、容器图(Container Diagram)

容器图是把语境图里待建设的系统做了一个展开。

上图中，除了用户和外围系统，要建设的系统包括一个基于java\spring mvc的web应用提供系统的功能入口，基于xamarin架构的手机app提供手机端的功能入口，一个基于java的api应用提供服务，一个mysql数据库用于存储，各个应用之间的交互都在箭头线上写明了。

看这张图的时候，不会去关注到图中是直角方框还是圆角方框，不会关注是实线箭头还是虚线箭头，甚至箭头的指向也没有引起太多注意。

我们有许多的画图方式，都对框、线的含义做了定义，这就需要画图的人和看图的人都清晰的理解这些定义，才能读全图里的信息，而现实是，这往往是非常高的一个要求，所以，很多图只能看个大概的含义。

★ 用途

这个图的受众可以是团队内部或外部的开发人员，也可以是运维人员。用途可以罗列为：

• 展现了软件系统的整体形态
• 体现了高层次的技术决策
• 系统中的职责是如何分布的，容器间的是如何交互的
• 告诉开发者在哪里写代码

★ 怎么画

用一个框图来表示，内部可能包括名称、技术选择、职责，以及这些框图之间的交互，如果涉及外部系统，最好明确边界。

3、组件图(Component Diagram)

组件图是把某个容器进行展开，描述其内部的模块。

★ 用途

这个图主要是给内部开发人员看的，怎么去做代码的组织和构建。其用途有：

• 描述了系统由哪些组件/服务组成
• 厘清了组件之间的关系和依赖
• 为软件开发如何分解交付提供了框架

4、类图(Code/Class Diagram)

这个图很显然是给技术人员看的，比较常见，就不详细介绍了。

案例分享

下面是内部的一个实时数据工具的架构图。作为一个应该自描述的架构图，这里不多做解释了。如果有看不明白的，那肯定是还画的不够好。

画好架构图可能有许多方法论，本篇主要介绍了C4这种方法，C4的理论也是不断进化的。但不论是哪种画图方法论，我们回到画图初衷，更好的交流，我们在画的过程中不必被条条框框所限制。简而言之，画之前想好：画图给谁看，看什么，怎么样不解释就看懂。

补充：画图的工具有Keynote、Xmind、EdrawMax、Visio、OmniGraffle、Process On……

文中物理视图Download地址：Win（ http://t.cn/EXAGBDW）、Mac（ http://t.cn/EXAqtxI）

作者：三画，阿里巴巴技术专家，梓敬、鹏升和余乐对此文亦有贡献。三画曾多年从事工作流引擎研发工作，现专注于高并发移动互联网应用的架构和开发。
来源：阿里技术

参考：

• C4官网： https://c4model.com/
• 为什么需要软件架构图：
• https://www.infoq.cn/article/GhprrUlOYyOqS8*FR1pH
• 书籍：《程序员必读之软件架构》

平时做过一些系统设计，也写过一些系统分析文章，从组件、关系、交互等方面提供一些建议，并用我之前写文章画的一些图举些例子。

构成系统的组件

通过形状、颜色、名称来逼近其概念。

如上面 LevelDB 的 架构图，包含的主要组件有：

1. memtable：红色，内存可变数据，较热
2. immutable memtable：绿色，不可变数据，相对较冷
3. sstable：深蓝，外存数据，最冷
4. WAL log

上图是分布式系统中一种常见的架构模式： Master-Workers 架构。主要组件有：

1. Master：红色，表示相对较重要
2. Worker：绿色，都是绿色，表示地位等同
3. Client：

上图是 Zookeeper 论文解析中架构图：

1. 预处理模块和原子广播模块用框框。
2. 持久化的多副本状态机模块用圆柱：存储、数据库等持久化组件的多用柱形。

组件间的关系

通过分割线、分割框来表达是否在同一层级、是否有包含关系。

如前面 LevelDB 的图，是分了内存和外存（文件系统）两个层次，因此中间用虚线隔开。

如前面 Master-Workers 架构图，是分了系统内和系统外，用方框隔开。

上图来自 LevelDB 源码解析之 LRUCache， 在 LRU 算法中，需要用以两种形式组织数据条目，以达到缓存达到阈值时驱逐最老的数据：

1. 以字典维护键值映射：图中 list_，本质上是一个 HashTable。
2. 以链表维护访问顺序：图中 lru_ （LRU 算法只作用于驱逐表上，即 refs=1）和 in_use_（还在使用的数据 refs > 1）。

因此任意一个数据条目 LRUHandle 都同时归属于字典和链表，但字典的表头和链表的表头是各自独立的。另外使用不同颜色的框表达了如下的嵌套结构：

class HandleTable {
  LRUHandle** list_;
};

class LRUCache {
  LRUHandle lru_ GUARDED_BY(mutex_);
  LRUHandle in_use_ GUARDED_BY(mutex_);

  HandleTable table_ GUARDED_BY(mutex_);
}

组件间的交互

通过线条来表达组件的数据流向、依赖关系。

上图来自 Golang Context 源码剖析，图中通过：

1. 虚线表达由嵌入（embedded）而构成的回溯链。
2. 实线表达由 cancelCtx children 数组而保存的父子关系。

最后，想必你也感受到了，一个好的架构图离不开一个好的配色。上述架构图都是用 drawio 画的，配色模板在 这里（用的 draveness 的某版配色）。

后续

我正在探索用 Procreate 画类似的图：

感兴趣的可以关注 github repo：

我是青藤木鸟，一个喜欢摄影的分布式系统程序员，欢迎关注我的公众号：“木鸟杂记”。里面有更多的有配图的关于架构的文章。

先说答案，画架构图分四步走：

第一，搞清楚要画的架构图的类型；

第二，确认架构图中的关键要素（比如产品、技术、服务）；

第三，梳理关键要素之间的关联：包含、支撑、同级并列等；

第四，输出关联关系清晰的架构图。

接下来，我们作进一步解读：

一、架构图的定义及作用

什么是架构图？维基百科、百度百科其实都没有关于它的直接定义。不过我们可以进行拆分理解：

• 架构图=架构+图

这样问题就转化成，什么是架构，以及什么是图？

关于架构，百度百科上是这样定义的：

架构，又名软件架构，是有关软件整体结构与组件的抽象描述，于指导型软件系统各个方面的设计。

ISO/IEC 42010:20072 中对架构则有如下定义：

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.（系统架构，体现在它的组成部分、它们之间的相互关系和环境中，以及控制其设计和演化的原则。）

也就是说，架构是由系统组件，以及组件间相互关系共同构成的集合体。

而架构图，则是用来表达这种集合的载体。

它的作用也很简单，两个：

• 划分目标系统边界
• 将目标系统的结构可视化

进而减少沟通障碍，提升协作效率。

二、架构的分类及画法

架构大致可以分为4类：业务架构、应用架构、数据架构和技术架构，整体逻辑关系如下：

业务架构：使用一套方法论/逻辑对产品（项目）所涉及到的业务进行边界划分。所以熟悉业务是关键。

比如做一个团购网站，你需要把商品类目、商品、订单、订单服务、支付、退款等进行清晰划分，而业务架构不需要考虑诸如我用什么技术开发、我的并发大怎么办、我选择什么样的硬件等等。

应用架构：它是对整个系统实现的总体上的架构，需要指出系统的层次、系统开发的原则、系统各个层次的应用服务。

例如，下图就将系统分为数据层、服务层、通讯层、展现层，并细分写明每个层次的应用服务。

数据架构：是一套对存储数据的架构逻辑，它会根据各个系统应用场景、不同时间段的应用场景 ，对数据进行诸如数据异构、读写分离、缓存使用、分布式数据策略等划分。

数据架构主要解决三个问题：第一，系统需要什么样的数据；第二，如何存储这些数据；第三，如何进行数据架构设计。

技术架构：应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构则是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。

技术架构解决的问题包括：纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。

三、适合画架构图的工具

大家可能会好奇，前面那些精美的架构图配图是用什么工具做的。

现在正式揭晓答案：亿图图示，一款专业的综合类办公绘图软件。全拖拽式操作，即学即用，不论背景，轻松上手。

高效绘制架构图 | 亿图图示15天会员免费领取

高效绘制架构图 | 免费下载亿图图示

亿图图示提供了210种绘图类型，能实现流程图、架构图、工程图、思维导图、UML、时间线、甘特图、信息图、户型图、电路图、网络图、市场分析图等数专业领域图形图表的绘制。

而且自带26000+个矢量图形，能大大省去了你绘制单个组件所需的时间。

软件还内含3000+专业模板和UGC作品，涉及商业、教育、平面、软件、工程等多个领域，可以全面提升你的绘图效率。找到心仪的模板，选择一键“使用”即可变成自己的作品。

另外，亿图图示支持多端运行，同时兼容Windows、Mac、Linux，以及网页在线版。

值得一提的是，它还支持Visio文件的导入导出、支持云文档以及社交分享功能，能够很好地解决国内用户的办公协同问题。

高效绘制架构图 | 亿图图示15天会员免费领取

大家感兴趣的话，可以用起来呀~

很多同学技术能力很强，架构设计也做得很好，但是在给别人讲解的时候，总感觉像是“茶壶里煮饺子，有货倒不出”。

其实，在为新员工培训系统架构、给领导汇报技术规划、上技术大会做演讲或者向晋升评委介绍工作贡献的时候，如果你能画出一张优秀的软件系统架构图，就可以大大提升自己的讲解效果，让对方轻松地理解你想表达的关键点。

在这儿为你分享软件系统架构图的画图技巧。

4+1 视图

说起软件系统架构图，你可能会想到**4+1视图**，毕竟很多学习资料上都说它是架构图的标准。那么，到底什么是4+1视图呢？是不是只要按照4+1视图的标准去画，就没有问题呢？

我们还是从它的由来说起。1995年，Philippe Kruchten在[论文]中指出了过去用单一视图描述软件系统架构的问题，并提出了4+1视图作为解决方案。

有时，软件架构的问题来源于系统设计者过早地划分软件或者过分地强调软件开发的某一个方面，比如数据工程、运行时效率、开发策略或团队组织。此外，软件架构往往不能解决它的所有“用户”的问题。……作为补救措施，我们建议使用几个并发视图来组织对软件架构的描述，其中每个视图分别解决一组特定的问题。

不同视图之间的关系如下图所示：

4+1视图的核心理念是从不同的角度去剖析系统，看看系统的结构是什么样的，具体每个视图的含义是：

1. 逻辑视图：从终端用户角度看系统提供给用户的功能，对应 UML的 class 和 state diagrams。

2. 处理视图：从动态的角度看系统的处理过程，对应 UML 的 sequence 和 activity diagrams。

3. 开发视图：从程序员角度看系统的逻辑组成，对应 UML 的 package diagrams。

4. 物理视图：从系统工程师角度看系统的物理组成，对应 UML 的 deployment diagrams。

5. 场景视图：从用户角度看系统需要实现的需求，对应 UML 的 use case diagrams。

（备注：逻辑视图看到的“功能”和场景视图看到的“需求”是一回事吗？答案是否定的。一个需求可能涉及多个功能，例如“取款”这个场景涉及“插卡”“密码验证”“出钞”等功能；而多个需求可能涉及同一个功能，例如“取款”和“转账”是两个不同的需求，但是都涉及“密码验证”这个功能。）

我们可以看到，4+1视图本身很全面也很规范，但是为什么在实际工作中，真正按照这个标准来画架构图的公司和团队并不多呢？

我认为原因主要有三点：

1. 架构复杂度增加：1995年的时候，系统大部分还是单体系统，而现在分布式系统越来越多。如果我们用4+1视图来表示分布式系统的话，就会遇到困难，比如微服务架构下有那么多的微服务，Development view 就不好表示。

2. 绑定 UML 图：UML 图画架构图存在问题，主要问题是不美观，表达能力弱。

（备注：左图是用UML工具画的，右图是用Visio画的，对比之下，UML图的缺点十分明显。）

3. 理解困难：逻辑视图、开发视图和处理视图比较容易混淆。比如说，有人把逻辑视图理解为软件开发的类结构图，也有人把处理视图和开发视图等同，还有人认为逻辑视图就是开发视图。

这些原因导致4+1视图在目前的实际工作中并不是很实用。那么，我们到底要怎么画软件系统架构图呢？

核心指导思想：4R架构定义

其实，很多人之所以画不好架构图，最大的痛点就是不好把握到底要画哪些内容，画得太少担心没有展现关键信息，画得太多又觉得把握不住重点。

所以现在的问题变成了：应该按照什么样的标准来明确架构图要展现的内容呢？

答案就是我在[第1讲]( 01 | 架构到底是指什么？-极客时间)中介绍的4R架构定义。

软件架构指软件系统的顶层（Rank）结构，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）。

4R是指4个关键词：Rank，Role，Relation和Rule。既然可以通过4R来定义软件系统的架构，那么按照4R架构定义的思路来画架构图也是很合情合理的，具体步骤如下：

• 第一步，明确Rank：也就是说，不要事无巨细地把一个大系统的方方面面都在一张架构图中展现出来，而应该明确你要阐述的系统所属的级别（L0～L4），然后只描述这个级别的架构信息。
• 第二步，画出Role：从不同的角度来分解系统，看看系统包含哪些角色，角色对应架构图中的区块、图标和节点等。
• 第三步，画出Relation：有了角色后，画出角色之间的关系，对应架构图中角色之间的连接线，不同的连接线可以代表不同的关系。
• 第四步，最后画出Rule：挑选核心场景，画出系统角色之间如何协作来完成某项具体的业务功能，对应系统序列图。

我把描述Role和Relation的架构图称为静态架构图，描述Rule的系统序列图称为动态架构图。

从某一个角度去看，静态架构图的数量跟系统复杂度有关，一般是1～2张，如果比较简单，用一张图就够了，如果比较复杂，就要分别用两张图来展现；而动态架构图是一般是多张，因为核心场景数量不止一个，对应的系统序列图有多张。

本内容选自前阿里P9李运华专栏 《从0开始学架构》。
李运华：前阿里资深技术专家。在阿里时带领多个研发团队，承担架构设计、架构重构、技术团队管理、技术培训等职责，曾就职于华为和 UCWeb，写过《面向对象葵花宝典》一书。
华仔从 2006 年开始接触架构设计，花费 8 年时间掌握架构设计的精髓，走过了从程序员到架构师的蜕变之路，也踩过了这条路上的很多坑。后来他带了团队，特别是做了职业等级晋升评委后，看到了一大批优秀程序员的晋升卡在架构设计上，也越来越能体会架构设计特性所导致的学习和实战方面的问题。
在本专栏中，华仔会从架构基础、三大架构模式和实战的角度分享他一整套的架构设计方法论，希望你学习后不仅能够快速理解陌生的架构设计，自己也能对架构设计游刃有余，并且可以给身边正在迷惘的同学指点迷津，实践所学，分享所学。

常见架构图

刚才介绍4+1视图的时候，我提到过，从不同的角度去剖析系统，就会得到不同的视图。其实按照4R架构定义来画架构图也是这样，用不同的方式去划分系统，就会得到不同类型的架构，分别对应不同类型的架构图。常见的类型整理如下：

接下来，我就为你详细地讲解每一类架构图的特点。

1. 业务架构图

【定义】

描述系统对用户提供了什么业务功能，类似于 4+1 视图的场景视图。

【使用场景】

1. 产品人员规划业务：比如说我们经常在产品规划和汇报会议上看到产品人员会用业务架构图来展现业务全局状态。

2. 给高 P 汇报业务：对于P7+以上级别的技术人员，在汇报的时候不能光讲技术，也要讲业务的发展情况，用业务架构图就比较容易的展现业务整体情况。

3. 给新员工培训业务。

【画图技巧】

1. 通过不同颜色来标识业务状态：比如说哪些业务发展状态好，哪些问题比较多，哪些比较稳定，哪些竞争比较激烈等。

2. 业务分组管理：将类似的业务放在一个分组里面展现，用虚线框或者相同背景将其标识出来。

3. 区块对齐：为了美观，可以改变不同区块的长短大小进行对齐，让整体看起来更美观。

【参考案例】

AlipayHK的一个业务架构图如下所示：

这张业务架构图有三点关键信息：

1. “MTR”区块是浅红色的，“人传人”区块是绿色的，浅红色代表正在进行的，绿色代表明年规划的。

2. 分了4组：钱包业务、第三方业务、商家服务和用户管理。

3. “转账”和“社交红包”等区块比较长，只是为了对齐后更美观，不代表业务本身的量级或者重要程度，如果要表示这样的信息，那么可以用颜色来表示。

注意，千万不要画得五颜六色，一般一张图的颜色数量控制在3种以内是比较好的。所以在画图的时候你要想清楚，到底哪些信息是要放在业务架构图中重点展示的关键信息，哪些信息顺带讲一下就可以了。

2. 客户端和前端架构图

【定义】

描述客户端和前端的领域逻辑架构，关注的是从逻辑的角度如何分解客户端或者前端应用。

【使用场景】

1. 整体架构设计：由客户端或者前端架构师完成本领域的架构设计。

2. 架构培训。

【画图技巧】

1. 通过不同颜色来标识不同角色。

2. 通过连接线来表示关系，如果有多种关系，例如有的是直接调用，有的是事件通知，那么可以用不同形状的线条来表示。

3. 分层或分组：将类似的角色分层或者分组管理。

【参考案例】

微信客户端架构3.x的架构图如下所示：

这张客户端架构图有三点关键信息：

1. 图中用了灰色（app:UI等）、蓝色（Net Scene等）、深灰色（Storage）、浅蓝色（Network）来表示不同类型的模块。

2. 图中有两类连接线：双向的（WebViewUI和app:UI），单向的（app:UI和Net Scene等）。

3. 整体上分为4组，对应图中背景色不同的四个大的区块。

3. 系统架构图

【定义】

描述后端的逻辑架构，又叫“后端架构”或“技术架构”，不管是业务系统、中间件系统，还是基础的操作系统、数据库系统等，系统架构都是软件系统架构的核心。

【使用场景】

1. 整体架构设计。

2. 架构培训。

【画图技巧】

1. 通过不同颜色来标识不同角色。

2. 通过连接线来表示关系。

3. 逻辑分组。

【参考案例】

如果系统比较简单，可以参考MongoDB Sharding的系统架构图，如下所示：

如果系统相对复杂，建议首先用一张图来展示系统架构里面的角色（Role）以及每个角色的核心功能；然后再用一张图来展示角色之间的关系（Relation），可以参考一个支付中台的系统架构图，如下所示：

（备注：完整的支付中台关系图太大了，这张关系图只是摘取其中一部分作为示意图，供你参考。）

4. 应用架构图

【定义】

描述后端系统由哪些应用组成，一个应用就是一个可部署发布运行的程序，它是项目开发过程中，开发测试运维团队协作的基础。

【使用场景】

1. 项目开发、测试。

2. 运维部署发布。

3. 子域架构设计。

【画图技巧】

1. 通过不同颜色来标识不同角色。

2. 通过连接线来表示关系。

3. 复杂系统分域来画。

【参考案例】

如果系统比较简单，那么基本上应用架构和系统架构是等价的，可以参考MongoDB Sharding的应用架构图，如下所示：

我们可以看到，这张图中的Router（mongos）、Config Servers 和 Shard（replica set），既包含了系统架构的角色信息（Router、Config Servers 和 Shard），又包含了应用信息（mongos、Config Servers 和 Shard）。

如果系统比较复杂，按照架构分层的角度来看，应用架构已经到了可执行程序这一层，例如支付中台这一类的系统，包含的应用可能有几百上千个，如果把整个支付中台所有的应用都在一张图里面展示出来，信息太多太密，可能会导致架构图都看不清。

这种情况下，应用架构一般都是按照子域来画应用架构图，可以参考支付中台的会员域的应用架构图，如下所示：

5. 部署架构图

【定义】

描述后端系统具体是如何部署的，主要包含机房信息、网络信息和硬件信息等。

【使用场景】

1. 总体架构设计。

2. 运维规划和优化。

【画图技巧】

用图标代替区块，这样看起来更加美观和容易理解。

【参考案例】

一个简单的支付系统的部署架构图如下所示：

6. 系统序列图

【定义】

描述某个业务场景下，系统各个角色如何配合起来完成业务功能。

【使用场景】

结合“系统架构、应用架构和部署架构”来使用。

【画图技巧】

使用UML的序列图来画。

【参考案例】

“扫码支付”这个支付核心场景的系统序列图如下所示：

（备注：这张序列图的角色对应前面“系统架构”这一小节的支付中台系统的关系图。）

补充说明

如果你曾经研究过架构图的标准，那么除了4+1视图以外，你可能还看到过TOGAF的“业务架构（跟这一讲的业务架构名字相同，但是意义不同）、数据架构（不是指大数据平台架构，而是指数据资产的架构）、应用架构和技术架构”这种说法，或者还看到过C4架构模型（Context、Container、Component和Code）等等。

但其实目前业界并没有就架构图标准达成共识，刚才提到的TOGAF是企业级的架构，基本上要到CTO这个级别才能接触的，而C4模型的表达能力又不够。

所以，我并没有直接套用这些内容，而是根据个人经验，将我认为最有效果的架构图整理出来。这些架构图，都是我在不同类型不同规模不同业务的公司（华为、UC、阿里和蚂蚁等）里面验证过的，你可以放心地使用。

如果对你有帮助，别忘记给个三连呀，这对小极非常重要！

@极客时间

画架构图建议最好分四步走，更有利于厘清思路：

第一，搞清楚要画的 架构图类型，明确画架构图的核心目的；

第二，确认架构图中的关键要素（比如产品、技术、服务）；

第三，梳理关键要素之间的关联：包含、支撑、同级并列等；

第四，输出关联关系清晰的架构图。

一、架构图的定义及作用

什么是架构图？架构图=架构+图

也就是说，架构是由系统组件，以及组件间相互关系共同构成的集合体。

而架构图，则是用来表达这种集合的载体。

它的作用也很简单，两个：

• 划分目标系统边界
• 将目标系统的结构可视化

进而减少沟通障碍，提升协作效率。

二、架构的分类及画法

架构大致可以分为4类：业务架构、应用架构、数据架构和技术架构。

1、业务架构：使用一套方法论/逻辑对产品（项目）所涉及到的业务进行边界划分。所以熟悉业务是关键。

比如做一个团购网站，你需要把商品类目、商品、订单、订单服务、支付、退款等进行清晰划分，而业务架构不需要考虑诸如我用什么技术开发、我的并发大怎么办、我选择什么样的硬件等等。

2、应用架构：它是对整个系统实现的总体上的架构，需要指出系统的层次、系统开发的原则、系统各个层次的应用服务。

例如，下图就将系统分为数据层、服务层、通讯层、展现层，并细分写明每个层次的应用服务。

3、数据架构：是一套对存储数据的架构逻辑，它会根据各个系统应用场景、不同时间段的应用场景 ，对数据进行诸如数据异构、读写分离、缓存使用、分布式数据策略等划分。

数据架构主要解决三个问题：第一，系统需要什么样的数据；第二，如何存储这些数据；第三，如何进行数据架构设计。

4、技术架构：应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构则是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。

技术架构解决的问题包括：纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。

三、适合画架构图的工具

1、ProcessOn

https://www.processon.com/diagrams

里面有收费及免费的模板可供使用，免费和VIP会有使用权限的不一致，详情见官网啦。我一般就用这个，很好用，充了好几年的年费。

2、 http://draw.io

http://www.draw.io

大家一定会喜欢这个，因为免费！！！这个连接的是 GitHub 和 微软的OneDrive，不连接的话就是个离线版本。而且有 vscode 的插件可用。所以我身边用这个的大佬颇多。

3、visual-paradigm

地址--- https://online.visual-paradigm.com/cn/

这个模板也很多，提供桌面版本和在线版本，就是收费。收费的好处就是非常的全，只有你想不到的。打开速度对于一个前端工程师来说零容忍。

4、excalidraw

https://excalidraw.com/

这个就是拼脑洞的，很好看

比如我们的脑洞架构师画的flex的讲解，灰常的棒！

以上就是画架构图的具体思路和步骤，希望对大家有帮助。如果有对物联网架构图感兴趣的，这边推荐下全球化IoT开发平台服务商--涂鸦智能，上面有很多帮助开发智能产品的软硬件工具。也可以自己学着画架构图，涂鸦这边提供开发者论坛，有任何问题都能在上面进行咨询。

————————————————

1、版权声明：本文为CSDN博主「亿图图示」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接： 如何画架构图？_亿图图示的博客-CSDN博客_画架构图

2、本文架构图工具部分来源于CSDN技术社区：

很多答主一顿猛贴图，我简单点回答，顺便举一个实战的栗子，让大家更容易看懂。

先说结论：画架构图要分四步走：

第一，弄清楚业务产品的全流程；

第二，拆解全业务流程

第三，确认架构图中的关键要素（比如技术、领域、服务）；

第四，整理清楚关键要素之间的关联：并列、包含、支撑、等；

第五，输出关联关系清晰的架构图。

曾经在一家独角兽公司担任技术VP，上任的第一件事就是重构整个公司的架构，深入了解了下，我首先把公司当时的架构画出来了，简单点说就是个大泥球架构（没有架构）：

这家公司的数据库是单库模式，一张表就有几百个字段，简直搞死人！绝绝子！

当时公司已经惨到只要改一个功能就得测试2周的悲惨境地，线上出一个故障技术团队更是惶惶不可终日。

耗时2周我才完成第一步：深入了解了这个大泥球和对应支撑的业务。

感谢大家耐心阅读，另外我把大学和工作中用的经典电子书库（包含数据结构、操作系统、C++/C、网络经典、前端编程经典、Java相关、程序员认知、职场发展）、面试找工作的资料汇总都打包放在这了，点击下方可以直达：

看看这套资源的目录，非常经典：

这套资源可不是一般那种网上找的资源，是伴随我从学生一路成长为腾讯高级开发工程师，360技术经理、360技术总监、中小公司CTO的打包全套！非常宝贵！

接下来耗时1个月，采用ddd领域设计：

在充分了解业务之后，基于领域模型，我们做了对业务的拆解：

以上，完成了第二步。

接下来我们最终确定了新架构的六大关键元素：

• 前端业务模块
• 支撑业务模块
• 核心业务模块
• 中台服务模块
• 平台服务模块
• 基础架构模块

这是第三步,done。

基于领域模型的拆解，我们还确定了六大关键元素之间的并列、包含、支撑关系，第四步，done。

然后我们开始画架构图：

以上，是我们确定的公司的新的技术架构图，紧接着我带领团队攻坚3个月，按照架构图的设想重构了公司的技术框架。

重构完成后，公司的程序员们再也不用为了一个bug拔光自己的胡子了。

C4 Model - 教你如何画架构图

什么是C4 Model？

C4 Model 是Simon Brown提出的一种软件架构的可视化模型，简单来说，也就是如何描述软件架构，如何画架构图，而不是如何设计软件架构。

为什么画架构图还需要一个模型呢？当我们看一个软件系统时，不同的人或角色会有不同的视角，所看到的也会是不同的方面。BA/PO所看到的软件系统可能是业务面，架构师所看到的可能是技术架构，而开发者可能看到的是实现细节。而在不同的场合，对不同的受众应该展示的方面应该是不同的，这样更便于描述和沟通软件架构。

所谓C4指的是Context, Containers, Components, Code， 指代不同Level的架构图，就像官网中所举的Map的例子，可以通过放大/缩小来呈现不同Level的内容。

Level 1: 系统上下文图

Context即系统上下文，这是最高Level的架构图，不暴露系统的内部细节，所展现的是：

• 本系统的用户是谁
• 与哪些外部系统有交互

系统上下文图可以说是一个系统的外观，不是站在系统内部，而是抽离出来，将本系统看作一个黑盒，站在系统外部来看，来展现与用户、外部系统间的关系。

细节在这里并不重要，因为这是显示系统全景图的缩小视图。重点应该放在用户和软件系统上，而不是技术和其他实现细节。这是可以向所有人展示的架构图， 包括技术人员与非技术人员。

Level 2: 容器图

这里容器的概念，有别于Docker容器，指的是在一个软件系统中可独立部署/独立运行的单元。可以是服务器端 Web 应用、单页应用、桌面应用、移动应用、数据库等。

如果说系统上下文图将本系统看作一个黑盒，那么容器图则是把这个黑盒打开，这个时候看到的是系统内部的所有容器，及各个容器盘根错节的交互关系，可以展现容器的主要技术栈，容器间如何通信。这是一个以技术为重点的简单图表，对软件开发人员、支持和运维人员都很有用。

Level 3: 组件图

组件图则是放大和分解每个容器，显示了容器是如何由多个“组件”组成的，每个组件是什么，它们的职责以及技术/实现细节。

Level 4: 代码结构图

代码层则是放大每个组件以显示它是如何作为代码实现的；使用 UML 类图、实体关系图等。 理想情况下，该图将使用工具（例如 IDE 或 UML 建模工具）自动生成，您应该考虑仅显示那些想要展示的属性和方法。

符号

C4 模型没有规定任何特定的符号。使用的任何符号都应尽可能具有自描述性，但所有图表都应有一图例，以使符号明确。这也适用于使用 UML、ArchiMate 和 SysML 等符号创建的图表，因为不是每个人都知道所使用的符号。适用于白板、纸张、便签和各种绘图工具的简单符号如下：

然后可以使用颜色和形状来补充图表，以添加其他信息或只是使图表更美观。

思考

• 对于一个系统，并不一定必须有这几个Level的架构图，而是当想要去画一个架构图时，需要回答几个问题：
• 受众是谁？
• 需要哪个Level的图？
• 重点关注在哪一块？
• 与其他系统/组件之间的交互有哪些？是否在同一Level展现？
• 对于一个系统的各个Level的架构图，个人认为系统上下文图和容器图的意义要高于组件图和代码结构图，原因是后者更关注实现细节，受众仅限于开发人员，而且稳定性更差，参考价值低于代码本身。
• C4 Model的价值更多在于如何认识系统，从哪个角度去剖析系统，而不拘泥于用什么线条、形状画出来。

参考

• https://c4model.com/

二次转载一篇好文，来回答这个问题~

本文源于极客帮-创未来组分享

写在前面

当我们想用一张或几张图来描述一下我们的系统时，是不是许多时候对着画布无从下手、删了又来？我想用一张图描述我的系统，又想让产品、运营、开发都能看明白？甚至画了一半的图还不清楚受众是谁？画出来的图到底是产品图功能图还是技术图又或是大杂烩？图上的框框有点少是不是要找点儿框框加进来？布局怎么画都不满意……如果有同样的困惑，本文将介绍一种画图的方法论，来让架构图更清晰。

定义

什么是架构

架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策。

架构是结构和愿景。

系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。

做好架构是个复杂的任务，也是个很大的话题，本篇就不做深入了。有了架构之后，就需要让干系人理解、遵循相关决策。

什么是架构图

系统架构图是为了抽象的表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。

架构图的作用

一图胜千言。要让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体。那么，画架构图是为了：

• 解决沟通障碍
• 达成共识
• 减少歧义

架构图分类

搜集了很多资料，分类有很多，有一种比较流行的是4+1视图，分别为场景视图、逻辑视图、物理视图、处理流程视图和开发视图。

场景视图

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

逻辑视图

逻辑视图用于描述系统软件功能拆解后的组件关系,组件约束和边界,反映系统整体组成与系统如何构建的过程,通常由UML的组件图和类图来表示。

物理视图

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

处理流程视图

处理流程视图用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。

开发视图

开发视图用于描述系统的模块划分和组成,以及细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。

5 种架构视图从不同角度表示一个软件系统的不同特征，组合到一起作为架构蓝图描述系统架构。

好的架构图

上面的分类是前人的经验总结，图也是从网上摘来的，那么这些图画的好不好呢？是不是我们要依葫芦画瓢去画这样一些图？

先不去管这些图好不好，我们通过对这些图的分类以及作用，思考了一下，总结下来，我们认为，在画出一个好的架构图之前， 首先应该要明确其受众，再想清楚要给他们传递什么信息 ，所以，不要为了画一个物理视图去画物理视图，为了画一个逻辑视图去画逻辑视图，而应该根据受众的不同，传递的信息的不同，用图准确地表达出来，最后的图可能就是在这样一些分类里。那么，画出的图好不好的一个直接标准就是：受众有没有准确接收到想传递的信息。

明确这两点之后，从受众角度来说，一个好的架构图是不需要解释的，它应该是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。

常见问题

• 方框代表什么？

为什么适用方框而不是圆形，它有什么特殊的含义吗？随意使用方框或者其它形状可能会引起混淆。

• 虚线、实线什么意思？箭头什么意思？颜色什么意思？

随意使用线条或者箭头可能会引起误会。

• 运行时与编译时冲突？层级冲突？

架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱。

C4

C4 模型使用容器（应用程序、数据存储、微服务等）、组件和代码来描述一个软件系统的静态结构。这几种图比较容易画，也给出了画图要点，但最关键的是，我们认为，它明确指出了每种图可能的受众以及意义。

如何更好的表达软件架构

下面的案例来自C4官网，然后加上了一些我们的理解。

语境图(System Context Diagram)

这是一个想象的待建设的互联网银行系统，它使用外部的大型机银行系统存取客户账户、交易信息，通过外部电邮系统给客户发邮件。可以看到，非常简单、清晰，相信不需要解释，都看的明白，里面包含了需要建设的系统本身，系统的客户，和这个系统有交互的周边系统。

用途

这样一个简单的图，可以告诉我们，要构建的系统是什么；它的用户是谁，谁会用它，它要如何融入已有的IT环境。这个图的受众可以是开发团队的内部人员、外部的技术或非技术人员。即：

• 构建的系统是什么
• 谁会用它
• 如何融入已有的IT环境

怎么画

中间是自己的系统，周围是用户和其它与之相互作用的系统。这个图的关键就是梳理清楚待建设系统的用户和高层次的依赖，梳理清楚了画下来只需要几分钟时间。

容器图(Container Diagram)

容器图是把语境图里待建设的系统做了一个展开。

上图中，除了用户和外围系统，要建设的系统包括一个基于java\spring mvc的web应用提供系统的功能入口，基于xamarin架构的手机app提供手机端的功能入口，一个基于java的api应用提供服务，一个mysql数据库用于存储，
各个应用之间的交互都在箭头线上写明了。

看这张图的时候，不会去关注到图中是直角方框还是圆角方框，不会关注是实线箭头还是虚线箭头，甚至箭头的指向也没有引起太多注意。

我们有许多的画图方式，都对框、线的含义做了定义，这就需要画图的人和看图的人都清晰的理解这些定义，才能读全图里的信息，而现实是，这往往是非常高的一个要求，所以，很多图只能看个大概的含义。

用途

这个图的受众可以是团队内部或外部的开发人员，也可以是运维人员。用途可以罗列为：

• 展现了软件系统的整体形态
• 体现了高层次的技术决策
• 系统中的职责是如何分布的，容器间的是如何交互的
• 告诉开发者在哪里写代码

怎么画

用一个框图来表示，内部可能包括名称、技术选择、职责，以及这些框图之间的交互，如果涉及外部系统，最好明确边界

组件图(Component Diagram)

组件图是把某个容器进行展开，描述其内部的模块。

用途

这个图主要是给内部开发人员看的，怎么去做代码的组织和构建。其用途有

• 描述了系统由哪些组件/服务组成
• 厘清了组件之间的关系和依赖
• 为软件开发如何分解交付提供了框架

类图(Code/Class Diagram)

这个图很显然是给技术人员看的，比较常见，就不详细介绍了。

案例分享

下面是 城市运营态势 工具的一个架构图。作为一个应该自描述的架构图，这里不多做解释了。如果有看不明白的，那肯定是还画的不够好。

写在最后

画好架构图可能有许多方法论，本篇主要介绍了C4这种方法，C4的理论也是不断进化的。但不论是哪种画图方法论，我们回到画图初衷，更好的交流，我们在画的过程中不必被条条框框所限制。简而言之，画之前想好：画图给谁看，看什么，怎么样不解释就看懂。

让我们一起画出好的架构图！

文章转载自公众号：“程序员的后花园”
原文作者：极客帮-创未来
原文链接： https://mp.weixin.qq.com/s/S3qo-73mUrsVo6F3v-NnXg

许多的小伙伴坦言画不好架构图，因为有很多困难阻碍了他们的进阶之路。

当你想用一张或几张图来描述你的系统时，经常对着画布无从下手、删了又画；不知道如何用一张图描述你的系统，让各部门同事一目了然；图画一半发现不清楚给谁看；布局怎么画都不满意···

当然你可能还面临更多细碎的问题，让你画架构之路举步维艰。如果你有以上诸多困惑，本周小编的分享也许能够让你的架构图更清晰。

一、什么是架构图

系统架构图是为了抽象地表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。

二、架构图的作用

要让各部门的同事理解、遵循架构决策，就需要把架构信息传递出去，架构图就是一个很好的载体。一图胜千言，使用架构图的好处就是能解决沟通障碍，达成共识，让相关同事通过图一目了然领悟作图者的信息。

架构图是提升工作效率、优化产品性能、改善用户体验等方面的体现，也是作图者专业能力的表现。

接下来，小编分享一些ProcessOn优秀架构图。

三、优秀架构图模板

先来看一下，网站上优秀的架构图长什么样子，不过这只是海量图中的几张，这些中有发布很久的，也有刚刚发布的，我们一起来学习一下吧。

1、微服务架构图 | 浏览3.33W，克隆5.5K

2、技术架构图 | 浏览3.7W，克隆5.4K

3、支付系统功能架构图 | 浏览量2.51WK，克隆量4.09K

4、数据中台全景架构图 | 浏览3.03K，克隆194

5、物联网架构图 | 浏览量9.47K，克隆量1.9K

如何判断一个架构图是好的架构图？最直接的标准是架构图要具备一致性和准确性，能够与代码相呼应；受众能准确接收到作图人想传递的信息。

四、如何做架构图？

画架构图分四步走：

1、搞清楚要画的 架构图的类型；

2、确认架构图中的关键要素（比如产品、技术、服务）；

3、梳理关键要素之间的关联：包含、支撑、同级并列等；

4、输出关联关系清晰的架构图。

在ProcessOn绘制一张架构图有以下两种方法：自己制作和使用模板。

第1种：新建流程图自己制作

操作步骤：

Step1：新建【流程图】

Step2：在【更多图形】中添加更多架构图相关图形【网络拓扑图】、【UI界面原型图】

Step3：拖拽图形到编辑区使用即可

第2种：从模板区克隆使用别人模板制作

操作步骤：

Step1：新建【流程图】-从模板新建

Step2：进入模板区后在搜索【架构图】或进入架构图专题中直接选用架构图模板

Step3：克隆使用模板

Step4：编辑克隆后的模板为我所用，下载或协作、分享使用即可

新手做有困难的小伙伴，推荐先克隆使用别人的优质模板，按图索骥学会架构图，先模仿别人，再超越别人！

软件架构是一种无法以简单的一维方式进行说明的复杂实体。
－Paul Clements 《软件架构编档》

正如上面提到的，不同的受众，比如用户、客户、开发人员、测试人员、运维人员，需要从各自工作的角度去理解和使用架构。所以回答这个问题，需要首先了解这幅架构图画出来是给谁看，你想从那个维度去入手。

确定了这个问题之后，再来了解架构视图有哪些维度和组成要素：

1. 架构视图

最经典的当属4+1视图：

• 逻辑视图
  
• 开发视图
  
• 过程视图
  
• 物理视图
  
• 场景视图
  

4+1视图提出后，业界也有其它的观点提出，诸如SEI(模块视图、组建和连接件视图、分配视图)、西门子4种视图（概念、模块、代码、执行视图）、以及RM-ODP(企业视图、信息视图、计算视图、工程师图）等。

常见的视图除了上述4+1视图外还包括：数据视图、安全视图、实现视图等。

2. 了解架构视图的四要素

• 图示化主要元素和元素之间的关系
  
• 具有明确的图例、定义和说明元素
  
• 每个元素具备明确的接口和行为规范
  
• 设计原理和设计决策的信息
  

3. 简单说一下几个视图针对的角色和维度：

逻辑视图一般针对客户、用户、业务人员、开发组织，主要从系统的功能元素、以及它们的接口、职责、交互维度入手。主要元素包括系统、子系统、功能模块、子功能模块、接口等。

开发视图一般针对开发和测试相关人员，主要描述系统如何开发实现；主要元素包括描述系统的分层、分区、框架、系统通用服务、业务通用服务、类和接口、系统平台和大基础框架。用途是知道开发设计和实现。

物理视图一般针对系统运维人员、集成人员，它是系统逻辑组件到物理节点的映射，节点与节点间的物理网络配置等，主要关注非功能性需求，诸如性能（吞吐量）、可伸缩性、可靠性，可用性等，从而得出相关的物理部署结构图。

4. 写在最后

了解这些，确定了你的受众和切入的维度后，你就可以决定你要用什么样的视图和视图组合来表达你的内容，挑选一个你得心应手的工具去实施就可以了。

在我看来，用白板和团队一起画出来是一件极美的好玩的事情。

个人观点，仅供参考。

在说如何画架构图之前，我们不妨先来了解一下什么是架构图，在对架构图有初步的了解之后，才能更好地讨论「如何画架构图」。

架构图是什么？

架构图是用于可视化呈现系统架构的图形表示。架构图的目的是为了提供系统的视图，这些视图可以从不同的角度（如逻辑、物理、功能、数据等）来展示系统的不同部分。

这里的「架构」是由系统组件，以及组件间相互关系共同构成的集合体，由于架构的不同，架构图也会区分出不同的类型，包含：

• 系统架构图：描述整个系统的高级视图，包括系统内部的主要组件以及这些组件之间的交互方式。这种图通常用于给出系统的大概概述，而不会涉及太多细节。
• 组件架构图：展示系统中各个组件（如软件模块或硬件设备）之间的关系。这种图包括了系统的各个组件，以及它们之间的相互连接和交互。
• 软件架构图：描述软件应用或系统的内部架构，包括软件组件、数据存储、外部系统、用户界面等。
• 硬件架构图：描述硬件设备和系统的物理布局和连接，包括服务器、网络设备、存储设备等。
• 网络架构图：描述网络的物理和逻辑布局，包括网络设备、连接、IP地址、网络协议等。
• 数据架构图：描述数据的结构和组织方式，包括数据库表、字段、关系，以及数据流和数据转换等。

单纯看概念可能会觉得比较抽象，我们可以来看一个架构图案例，如下图所示，这是一个某品牌的A.I.P.L架构，整个架构图由 3 个模块组成：

• 云底座（底层）
• 数据中台
• 应用（前端应用）

每个模块之间既相互独立又彼此依存，单个模块内部会细分出不同的子模块，模块与模块之间带有方向的箭头，代表了模块间的信息或者数据流动的方向：

• 单向箭头：表示信息或数据只能沿箭头指示的方向流动。例如，如果模块A向模块B有一条箭头指向，那么表示A会传送数据给B，但是B不会传送数据给A。
• 双向箭头：表示信息或数据可以在两个方向上流动。例如，如果模块A和模块B之间有一条双向箭头，那么表示A和B可以相互传送数据。

使用 boardmix博思白板在线绘制架构图

在初步了解什么是架构图之后，我们就可以着手绘制架构图了！这里推荐使用专业的在线绘图软件【boardmix博思白板】来绘制架构图。

打开在线绘图软件 boardmix白板的首页 boardmix.cn，点击页面中间的「免费使用」按钮，进入 boardmix博思白板工作台。

在 boardmix白板的工作台，点击左侧的「模板中心」，打开 boardmix内置的模板库，在右侧可以看到 boardmix白板提供的「架构图」模板。

将鼠标指针移动到架构图模板上方，点击「使用」按钮，会创建一个带有此架构图模板的白板文件。

进入刚创建的白板文件，如下图所示，可以看到，boardmix的架构图模板提供了两个架构图，一个是作为示例的A.I.P.L模型，另一个则是空的架构图模板，供我们自行修改或填充内容。

右侧的空的架构图模板，本质上也是由一些基本的元素组合而成，譬如：

• 文本
• 圆角矩形
• 箭头
• 批注（图形）
• 单向箭头
• 双向箭头

双击模板中的文本，激活文本的编辑状态，就可以直接修改架构图模板的文本或占位文字。

对于没有占位文本的圆角矩形，如果想在其中输入内容，只要双击矩形，就可以直接在其中输入文本内容。

架构图模板中每个形状都设置了颜色样式，如果你不喜欢默认的配色方案，可以选中一个或多个形状，点击上方工具栏的「填充颜色」和「边框」，更改形状的背景色和轮廓色。

此外，架构图模板最上面和中间的模块，使用的是单向箭头，如果你想把它更改为双向箭头，boardmix博思白板也提供了更改箭头类型的选项：

选中单向箭头，点击上方工具栏的第一个选项「切换形状」，在弹出的浮窗，单击选择双向箭头，就可以把单向箭头快速更改为双向箭头。

在架构图模板的最右侧，提供了一个用于标识模块名称的「批注」占位符，我们可以将默认的批注文本替换为模块的名称。

除了在架构图的右侧添加批注图形标识模块名称，我们同样也可以在左侧添加：

点击 boardmix白板左侧菜单栏的「图形」工具，打开「图形库」面板，在「流程图」类别中可以看到另一个方向的批注图形，选中将其拖拽到架构图的左侧，根据模块大小调整一下批注图形的高度即可~

软件架构图模板，尽在 boardmix模板社区

前面基于 boardmix博思白板内置的【架构图】模板，简要介绍了在 boardmix博思白板中使用和编辑架构图模板的技巧。

使用 boardmix博思白板绘制架构图，除了使用【模板中心】内置的模板，我们还可以试着从 boardmix模板社区寻找更多的架构图模板，基于社区中已有的模板进行修改，节省花费在绘图上的时间~

在浏览器打开 boardmix模板社区首页 boardmix.cn/community，在社区中搜索【架构图】，可以快速筛选出社区中所有的软件架构图模板：

• 消费金融系统架构图
• 支付系统架构图
• 政务系统管理架构图
• 美团AB股股权架构图及分析
• 产品质量管理体系架构图
• QMS质量体系架构
• 产品设计框架
• 金融科技产业生态架构
• 智慧工地监控系统架构
• 敏捷项目管理架构
• 智慧园区建设架构
• 三层敏捷能力架构
• 金融机构管理架构
• 蚂蚁金服股权架构图

写在最后

软件架构图，简单来说，就是一种用来描绘事物结构的工具。无论是哪个领域，我们都可以通过软件架构图来具象地展示其内在的结构和关系。绘制软件架构图并不复杂，关键在于如何将其融入到我们的实际工作中。

如果你想要快速地绘制出一份逻辑清晰、易于理解、形象生动的架构图，那么选择一款强大的在线绘图工具就显得尤为重要，譬如我们这里介绍的 boardmix博思白板，它的功能非常齐全，旗下的 boardmix模板社区拥有丰富的模板库，可以应对各种业务场景，帮助你绘制出各种可视化图表。更重要的是，它支持多人协作，让你可以和你的团队成员一起创作，分享你们的想法。这样的工具不仅可以帮助你在思维和视觉上提升一个层次，还可以让你的工作变得更加高效！

看到这里，不妨点击下面的卡片，打开boardmix博思白板，开启你的软件架构图绘图之旅吧！

✅ 阅读更多

码字不易，如果对你有帮助的话，请别忘了赏个【三连】或是【关注】小博哦，关注不迷路！

我是小博 @boardmix博思白板，那我们下次再见咯。

在回答这个问题之前，我们先了解一下什么是架构图。

首先架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策。

架构是结构和愿景。系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。

系统架构图是为了抽象地表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。

架构图的作用

一图胜千言。要让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体。那么，画架构图是为了：

• 解决沟通障碍
• 达成共识
• 减少歧义

架构图是提升工作效率、优化产品性能、改善用户体验等方面的体现，也是作图者专业能力的表现。

架构图的分类

场景视图、逻辑视图、物理视图、处理流程视图、开发视图等等。

在画架构图的时候，用一个框图来表示，内部可能包括名称、技术选择、职责，以及这些框图之间的交互，如果涉及外部系统，最好明确边界。

其实，小白也可以画架构图，因为ProcessOn 会为你提供很多模板，轻松容易上手。

Step1：新建【流程图】-从模板新建

Step2：进入模板区后在搜索【架构图】或进入架构图专题中直接选用架构图模板

Step3：克隆使用模板

Step4：编辑克隆后的模板为我所用，下载或协作、分享使用即可

分享几个优秀的架构模板

SpringCloud微服务分布式系统架构图

产品能力架构图

微服务架构图

技术架构图

支付系统功能架构图

数据中台全景架构图

产品架构图