51 | 如何画出优秀的软件系统架构图？

Jan 26, 2022

51 | 如何画出优秀的软件系统架构图？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

51 | 如何画出优秀的软件系统架构图？

2022-01-26 李运华来自北京

《从0开始学架构》

课程介绍



讲述：安晓辉

时长14:43大小13.44M



你好，我是华仔。
你现在看到的这篇文章，是我在 2022 年新写的。《从 0 开始学架构》这门课更新结束后，我又探索了很多和架构相关的事情。这期间新的经历和尝试，也让我有了更多的思考。
所以，有了今天这篇文章，把我在软件系统架构图上的实践分享给你。
很多同学技术能力很强，架构设计也做得很好，但是在给别人讲解的时候，总感觉像是“茶壶里煮饺子，有货倒不出”。
其实，在为新员工培训系统架构、给领导汇报技术规划、上技术大会做演讲或者向晋升评委介绍工作贡献的时候，如果你能画出一张优秀的软件系统架构图，就可以大大提升自己的讲解效果，让对方轻松地理解你想表达的关键点。
这一讲，我就会为你分享软件系统架构图的画图技巧。
4+1 视图说起软件系统架构图，你可能会想到 4+1 视图，毕竟很多学习资料上都说它是架构图的标准。那么，到底什么是 4+1 视图呢？是不是只要按照 4+1 视图的标准去画，就没有问题呢？
我们还是从它的由来说起。1995 年，Philippe Kruchten 在论文中指出了过去用单一视图描述软件系统架构的问题，并提出了 4+1 视图作为解决方案。
有时，软件架构的问题来源于系统设计者过早地划分软件或者过分地强调软件开发的某一个方面，比如数据工程、运行时效率、开发策略或团队组织。此外，软件架构往往不能解决它的所有“用户”的问题。……作为补救措施，我们建议使用几个并发视图来组织对软件架构的描述，其中每个视图分别解决一组特定的问题。
不同视图之间的关系如下图所示：
4+1 视图的核心理念是从不同的角度去剖析系统，看看系统的结构是什么样的，具体每个视图的含义是：
逻辑视图：从终端用户角度看系统提供给用户的功能，对应 UML 的 class 和 state diagrams。
处理视图：从动态的角度看系统的处理过程，对应 UML 的 sequence 和 activity diagrams。
开发视图：从程序员角度看系统的逻辑组成，对应 UML 的 package diagrams。
物理视图：从系统工程师角度看系统的物理组成，对应 UML 的 deployment diagrams。
场景视图：从用户角度看系统需要实现的需求，对应 UML 的 use case diagrams。
（备注：逻辑视图看到的“功能”和场景视图看到的“需求”是一回事吗？答案是否定的。一个需求可能涉及多个功能，例如“取款”这个场景涉及“插卡”“密码验证”“出钞”等功能；而多个需求可能涉及同一个功能，例如“取款”和“转账”是两个不同的需求，但是都涉及“密码验证”这个功能。）
我们可以看到，4+1 视图本身很全面也很规范，但是为什么在实际工作中，真正按照这个标准来画架构图的公司和团队并不多呢？
我认为原因主要有三点：
架构复杂度增加：1995 年的时候，系统大部分还是单体系统，而现在分布式系统越来越多。如果我们用 4+1 视图来表示分布式系统的话，就会遇到困难，比如微服务架构下有那么多的微服务，Development view 就不好表示。
绑定 UML 图：UML 图画架构图存在问题，主要问题是不美观，表达能力弱。
（备注：左图是用 UML 工具画的，右图是用 Visio 画的，对比之下，UML 图的缺点十分明显。）
理解困难：逻辑视图、开发视图和处理视图比较容易混淆。比如说，有人把逻辑视图理解为软件开发的类结构图，也有人把处理视图和开发视图等同，还有人认为逻辑视图就是开发视图。
这些原因导致 4+1 视图在目前的实际工作中并不是很实用。那么，我们到底要怎么画软件系统架构图呢？
核心指导思想：4R 架构定义其实，很多人之所以画不好架构图，最大的痛点就是不好把握到底要画哪些内容，画得太少担心没有展现关键信息，画得太多又觉得把握不住重点。
所以现在的问题变成了：应该按照什么样的标准来明确架构图要展现的内容呢？
答案就是我在第 1 讲中介绍的 4R 架构定义。
软件架构指软件系统的顶层（Rank）结构，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）。
4R 是指 4 个关键词：Rank，Role，Relation 和 Rule。既然可以通过 4R 来定义软件系统的架构，那么按照 4R 架构定义的思路来画架构图也是很合情合理的，具体步骤如下：
第一步，明确 Rank：也就是说，不要事无巨细地把一个大系统的方方面面都在一张架构图中展现出来，而应该明确你要阐述的系统所属的级别（L0～L4），然后只描述这个级别的架构信息。
第二步，画出 Role：从不同的角度来分解系统，看看系统包含哪些角色，角色对应架构图中的区块、图标和节点等。
第三步，画出 Relation：有了角色后，画出角色之间的关系，对应架构图中角色之间的连接线，不同的连接线可以代表不同的关系。
第四步，最后画出 Rule：挑选核心场景，画出系统角色之间如何协作来完成某项具体的业务功能，对应系统序列图。
我把描述 Role 和 Relation 的架构图称为静态架构图，描述 Rule 的系统序列图称为动态架构图。
从某一个角度去看，静态架构图的数量跟系统复杂度有关，一般是 1～2 张，如果比较简单，用一张图就够了，如果比较复杂，就要分别用两张图来展现；而动态架构图是一般是多张，因为核心场景数量不止一个，对应的系统序列图有多张。
常见架构图刚才介绍 4+1 视图的时候，我提到过，从不同的角度去剖析系统，就会得到不同的视图。其实按照 4R 架构定义来画架构图也是这样，用不同的方式去划分系统，就会得到不同类型的架构，分别对应不同类型的架构图。常见的类型整理如下：
接下来，我就为你详细地讲解每一类架构图的特点。
1. 业务架构图【定义】
描述系统对用户提供了什么业务功能，类似于 4+1 视图的场景视图。
【使用场景】
产品人员规划业务：比如说我们经常在产品规划和汇报会议上看到产品人员会用业务架构图来展现业务全局状态。
给高 P 汇报业务：对于 P7+ 以上级别的技术人员，在汇报的时候不能光讲技术，也要讲业务的发展情况，用业务架构图就比较容易的展现业务整体情况。
给新员工培训业务。
【画图技巧】
通过不同颜色来标识业务状态：比如说哪些业务发展状态好，哪些问题比较多，哪些比较稳定，哪些竞争比较激烈等。
业务分组管理：将类似的业务放在一个分组里面展现，用虚线框或者相同背景将其标识出来。
区块对齐：为了美观，可以改变不同区块的长短大小进行对齐，让整体看起来更美观。
【参考案例】
AlipayHK 的一个业务架构图如下所示：
这张业务架构图有三点关键信息：
“MTR”区块是浅红色的，“人传人”区块是绿色的，浅红色代表正在进行的，绿色代表明年规划的。
分了 4 组：钱包业务、第三方业务、商家服务和用户管理。
“转账”和“社交红包”等区块比较长，只是为了对齐后更美观，不代表业务本身的量级或者重要程度，如果要表示这样的信息，那么可以用颜色来表示。
注意，千万不要画得五颜六色，一般一张图的颜色数量控制在 3 种以内是比较好的。所以在画图的时候你要想清楚，到底哪些信息是要放在业务架构图中重点展示的关键信息，哪些信息顺带讲一下就可以了。
2. 客户端和前端架构图【定义】
描述客户端和前端的领域逻辑架构，关注的是从逻辑的角度如何分解客户端或者前端应用。
【使用场景】
整体架构设计：由客户端或者前端架构师完成本领域的架构设计。
架构培训。
【画图技巧】
通过不同颜色来标识不同角色。
通过连接线来表示关系，如果有多种关系，例如有的是直接调用，有的是事件通知，那么可以用不同形状的线条来表示。
分层或分组：将类似的角色分层或者分组管理。
【参考案例】
微信客户端架构 3.x 的架构图如下所示：
这张客户端架构图有三点关键信息：
图中用了灰色（app:UI 等）、蓝色（Net Scene 等）、深灰色（Storage）、浅蓝色（Network）来表示不同类型的模块。
图中有两类连接线：双向的（WebViewUI 和 app:UI），单向的（app:UI 和 Net Scene 等）。
整体上分为 4 组，对应图中背景色不同的四个大的区块。
3. 系统架构图【定义】
描述后端的逻辑架构，又叫“后端架构”或“技术架构”，不管是业务系统、中间件系统，还是基础的操作系统、数据库系统等，系统架构都是软件系统架构的核心。
【使用场景】
整体架构设计。
架构培训。
【画图技巧】
通过不同颜色来标识不同角色。
通过连接线来表示关系。
逻辑分组。
【参考案例】
如果系统比较简单，可以参考 MongoDB Sharding 的系统架构图，如下所示：
如果系统相对复杂，建议首先用一张图来展示系统架构里面的角色（Role）以及每个角色的核心功能；然后再用一张图来展示角色之间的关系（Relation），可以参考一个支付中台的系统架构图，如下所示：
（备注：完整的支付中台关系图太大了，这张关系图只是摘取其中一部分作为示意图，供你参考。）
4. 应用架构图【定义】
描述后端系统由哪些应用组成，一个应用就是一个可部署发布运行的程序，它是项目开发过程中，开发测试运维团队协作的基础。
【使用场景】
项目开发、测试。
运维部署发布。
子域架构设计。
【画图技巧】
通过不同颜色来标识不同角色。
通过连接线来表示关系。
复杂系统分域来画。
【参考案例】
如果系统比较简单，那么基本上应用架构和系统架构是等价的，可以参考 MongoDB Sharding 的应用架构图，如下所示：
我们可以看到，这张图中的 Router（mongos）、Config Servers 和 Shard（replica set），既包含了系统架构的角色信息（Router、Config Servers 和 Shard），又包含了应用信息（mongos、Config Servers 和 Shard）。
如果系统比较复杂，按照架构分层的角度来看，应用架构已经到了可执行程序这一层，例如支付中台这一类的系统，包含的应用可能有几百上千个，如果把整个支付中台所有的应用都在一张图里面展示出来，信息太多太密，可能会导致架构图都看不清。
这种情况下，应用架构一般都是按照子域来画应用架构图，可以参考支付中台的会员域的应用架构图，如下所示：
5. 部署架构图【定义】
描述后端系统具体是如何部署的，主要包含机房信息、网络信息和硬件信息等。
【使用场景】
总体架构设计。
运维规划和优化。
【画图技巧】
用图标代替区块，这样看起来更加美观和容易理解。
【参考案例】
一个简单的支付系统的部署架构图如下所示：
6. 系统序列图【定义】
描述某个业务场景下，系统各个角色如何配合起来完成业务功能。
【使用场景】
结合“系统架构、应用架构和部署架构”来使用。
【画图技巧】
使用 UML 的序列图来画。
【参考案例】
“扫码支付”这个支付核心场景的系统序列图如下所示：
（备注：这张序列图的角色对应前面“系统架构”这一小节的支付中台系统的关系图。）
补充说明如果你曾经研究过架构图的标准，那么除了 4+1 视图以外，你可能还看到过 TOGAF 的“业务架构（跟这一讲的业务架构名字相同，但是意义不同）、数据架构（不是指大数据平台架构，而是指数据资产的架构）、应用架构和技术架构”这种说法，或者还看到过 C4 架构模型（Context、Container、Component 和 Code）等等。
但其实目前业界并没有就架构图标准达成共识，刚才提到的 TOGAF 是企业级的架构，基本上要到 CTO 这个级别才能接触的，而 C4 模型的表达能力又不够。
所以，我并没有直接套用这些内容，而是根据个人经验，将我认为最有效果的架构图整理出来。这些架构图，都是我在不同类型不同规模不同业务的公司（华为、UC、阿里和蚂蚁等）里面验证过的，你可以放心地使用。
小结今天我为你介绍了画软件系统架构图的总体思路，以及常见架构图的应用场景和画图技巧，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧：为什么后端架构可以直接被称为“系统架构”，通常我们说的系统不是应该包含客户端和前端在内的一个整体吗？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 43

提建议

50 | 架构实战：架构设计文档模板

架构专栏特别放送 | “华仔，放学别走！”第1期

 写留言

精选留言(35)

quietwater
2022-02-02
这节课不应该是选学，应该是必学。对我帮助很大，太有指导意义了。老师对这门课太用心了，一直关注学员留言，这个必须点赞！学第二遍了，感觉收获比第一遍大，期待第三遍的学习🙂 客户端和前端的复杂度在于应用内部，而后端的复杂度在于应用间的协作，当然应用内的复杂度也很高，不比客户单和前端低，甚至更复杂。想要满足三高，必须是分布式的，这样后端就会涉及很多组件之间的协作，系统架构的权衡取舍也来自于此。所以后端架构的复杂度基本等同分布式的复杂度，也基本等同系统的复杂度。
展开
作者回复: 这一章是添加的正式章节，应该是必学的，你对课后习题的理解很到位，点赞
20
Aresx
2022-02-24
想复习架构知识，没想到2022年老师还在更新专栏，感谢，受用颇深！
作者回复: 哈哈，我自己也在迭代，一起学习：）
8
Thomas
2022-03-09
这篇文章中所列举的例子：AlipayHK业务架构图与中台系统架构图除颜色外，没看出有多大差别，实质是相同的？求解？
作者回复: 明显不同呀，比如说“扫码支付”和“付款码”两个业务，都会涉及到支付中台里面的“交易中心、支付中心、风控中心……”等，一个是从外部用户或者客户的角度来看系统，一个是从内部开发或者团队的角度来看系统
共 2 条评论
7
敏叔
2022-02-25
mac下一般用哪些软件画图
作者回复: 我就是用PPT来画，有学员推荐用draw.io
5
shawn
2022-01-27
我觉首先得在一个应用中后端架构更加复杂，其次前端架构和后端架构一起展示出来对于绝大部分人来说是没有意义的，因为各自所属领域不同。
作者回复: 1. 系统架构核心部分就是在后端； 2. 前端和后端一起展示出来还是有意义的，主要在高级别的汇报的时候
5
知行合一
2022-05-24
这节课好棒，解决了我画架构图的困惑，以前不知4R方法，不会分层，总想展示所有信息，学了4R,Rank,Role,Relation,Rule对系统分层分场景展示系统角色之间的关系。
作者回复: 赶紧画一画目前自己正在做的系统的架构，体会会更深：）
4
月光宫羽
2022-11-21 来自广东
1、4R是否可以理解成以下4个思考步骤？（1）分层（2）列出角色（3）表达角色间关系（4）表达角色间交互 2、业务和系统架构图，无论从功能还是从架构层级看，有时感觉有人画的差不多，没能突出这2者的区别？是否可以理解为：业务架构是站在用户角度，用户能够真切的感知与看到的（页面菜单或选项）。系统架构是站在开发者角度，通过编码实现用户所需要的功能（模块）。
展开
作者回复: 正解，理解到位
2
千锤百炼领悟之极限
2022-02-05
这个跟C4图有没有什么联系的?
作者回复: 请看文章最后一段话
2
G
2022-06-24
老师，画图对应模板图片。您是不是有一套，能分享出来吗。
作者回复: 链接: https://pan.baidu.com/s/1OdWLHuXS1cHn2lKfS1-4nQ 提取码: 1ttt
1
shark
2022-04-13
想问华哥一个问题，我们的业务场景和产品比较特殊，产品的核心其实是在前端（前端需要处理大量的业务逻辑，复杂度也相对更高），这样系统架构是不是得以前端为主？
作者回复: 正常来说不应该前端处理大量业务逻辑，因为前端的运算能力肯定没有后端强，不管是手机app还是web浏览器还是pc的应用程序，肯定都不如后端分布式，更不用说后端服务器的性能了
共 3 条评论
2
开心
2022-03-22
所以系统架构中的系统，指的是某一类业务/能力统称。应用架构中的应用，指的是组成这个系统的各个应用？这样理解对么~
作者回复: 系统就是实现某个业务的系统，比如说电商系统、IM系统、MongoDB等，应用就是如你理解的那样。
1
开心
2022-03-22
所以系统架构中的系统，指的是某一类业务。
作者回复: 系统就是系统，业务就是业务，系统是来实现业务的
1
Geek_b43e49
2022-03-07
老师您好，有哪些常用的画图软件也推荐一下吧，还有哪种类型的架构图用什么软件画好点，谢谢
作者回复: 我都是用PPT画
1
helloworld
2023-01-04 来自广东
“不要事无巨细地把一个大系统的方方面面都在一张架构图中展现出来，而应该明确你要阐述的系统所属的级别（L0～L4），然后只描述这个级别的架构信息。”，请教下老师，文章中的L0～L4，具体是指哪5个级别啊
作者回复: 这个不是说每个级别都有一个名称，而是说你自顶向下的分，顶层架构是L0，下一级是L1，再下一级是L2，以此类推
FuriousEric
2022-11-29 来自广东
1. 微信客户端架构图那张图感觉云里雾里，网上搜索了下，来源于《微信 Android 客户端架构演进之路》这个分享 https://www.infoq.cn/article/wechat-android-app-architecture 这样就能明白这个客户端架构图到底在讲什么了 2. 应用架构图种，会员中心系统的内部几个server，用线和箭头连起来，说实话，根本看不懂这个线和箭头到底在表达什么？感觉表达力比较弱，只能粗浅看出来这个会员中心内部使用了这些server，server之间可能存在某种形式的联系，至于是什么联系，图中看不出来 3. 支付系统的部署架构图太粗糙了啊，能否贴张现实场景中的部署架构图
展开
作者回复: 光看图就想了解全部信息肯定不行，图只是整体上的形象表达，细节还是要靠文字。支付系统部署架构图，如果是现实的，那就属于公司的机密信息了。
波
2022-11-25 来自广东
从不同的角度来分解系统，看看系统包含哪些角色划分系统的角度有哪些？分解出的角色，在架构图中是什么关系，如何取舍要不要展示？
作者回复: 从物理的角度划分为组价，从逻辑的角度划分为模块都是可以的，同级别的角色展示即可，不要在上层架构中展示下层的设计。
共 2 条评论
程序员小跃
2022-09-14 来自广东
我去，今年角色有点变化，领导会时不时地叫我们更新部门的系统架构图，正发愁去哪找资源呢。老师实在是太棒了
作者回复: 知行合一，学以致用，挺好：）
hello world
2022-09-08 来自广东
没有泳道图么
作者回复: 如果你觉得泳道图更适合表达你的想法，也可以用的
线条
2022-08-12 来自广东
一些个人的理解和疑问：业务架构：从系统要实现的业务角度来罗列业务和相应的业务功能，主要目的是告知客户系统所支持业务范围。系统的登录等算业务吗？是否存在一些共性的业务？功能架构【自己加的】：从业务架构中的业务视角转换成开发的视角，将某些业务功能抽象出来形成某些基础功能模块，同时将某些业务功能进行组合形成某些功能模块。系统架构：文章中说是描述后端的逻辑架构（又叫后端架构和技术架构），这么来说主要是描述实现功能的技术方案了？包括技术选型，实现策略等？应用架构：描述系统由哪些应用组成，对这个”应用“的概念不是那么清晰，可以是子系统、也可以是微服务里面的一个服务，总体来讲必须满足能独立部署的特点？或者说就是一个独立的进程？那么如果是单体系统，是不是这个应用架构就不存在了？部署架构：描述系统的各个组件的部署，包括各类中间件按什么方式部署、各个系统/子系统按什么方式部署、服务器配置、网络配置、机房信息等。在技术架构中也会涉及组件等，但更多是告诉用什么组件来干嘛，而在部署架构中需要细化到组件的部署方式，例如：单机还是集群、一个机房还是多个机房部署、配置几个副本、如何做数据同步、使用什么样的网络连接等总的疑问：不同的架构图里面应该/可以包含哪些元素，网上的很多架构图感觉元素混乱，自己也好难判断应不应该参考。
展开
作者回复: 1. 登录一般不算业务，算功能； 2. 功能架构一般用在微内核架构里面； 3. 是的，后端架构包括技术选型等决策； 4. 单体系统就没有应用架构了；应用就是指可以独立部署的单元；
永不放弃
2022-08-09 来自广东
老师有移动端架构的更多方向吗？
作者回复: 目前明确的是大前端架构，以后那就是虚拟技术了，目前看不太清

