从0开始学架构_52_51_如何画出优秀的软件系统架构图
你好，我是华仔。
很多同学啊技术能力很强，架构设计也做的很好。
但是一到了给别人讲解的时候呢，就总感觉像是茶壶里煮饺子有货到不出。
其实，在为新员工培训系统架构，给领导汇报技术规划，给技术大会做演讲，或者向晋升评委介绍工作贡献的时候，如果你能画出一张优秀的软件系统架构图，就可以大大的提升自己的讲解效果，让对方轻松的理解你想表达的关键点。
这一讲，我就会告诉你怎么画好软件系统架构图。
说起软件系统架构图，你可能会想到四加一视图，毕竟很多学习资料上都说它是架构图的标准。
那么到底什么是四加一视图呢？是不是只要按照四加一视图的标准去画就没有问题呢？我们还是从它的由来说起吧。
一九九五年，克鲁奇顿在一篇论文当中指出了过去用单一视图描述软件系统架构的问题，并提出了四加一视图作为解决方案，不同视图之间的关系。
如文稿中图片所示，四加一视图的核心理念呢是从不同的角度去剖析系统，看看系统的结构是什么样的。
具体每个视图的含义是一逻辑视图。
从终端用户角度看，系统提供给用户的功能，对应UML的class和state diagrams.二、处理视图。
从动态的角度看，系统的处理过程，对应UML的sequence和activity diagrams.三、开发视图。
从程序员角度看，系统的逻辑组成，对应UML的package diagrams.四、物理视图。
从系统工程师角度看，系统的物理组成，对应UML的deployment diagrams.最后是场景视图，从用户角度看系统需要实现的需求。
对应UML的use case diagrams.我们可以看到四加一视图本身很全面，也很规范。
但是为什么在实际工作当中，真正按照这个标准来画架构图的公司和团队并不多呢？我认为原因主要有三点，第一，架构复杂度增加。
一九九五年的时候，系统大部分还是单体系统，而现在分布式系统越来越多。
如果我们用四加一视图来表示分布式系统的话，就会遇到困难。
比如微服务架构下有那么多的微服务development view就不好表示。
第二，绑定UML图UML图画架构图存在问题。
主要问题是不美观、表达能力弱。
第三，理解困难，逻辑视图、开发视图和处理视图比较容易混淆。
比如说，有人把逻辑视图理解为软件开发的类结构图，也有人把处理视图和开发视图等同。
还有人认为逻辑视图就是开发视图，正是这些原因导致四加一视图在目前的实际工作中并不是很实用。
那么我们到底要怎么画软件系统架构图呢？其实很多人之所以画不好架构图，最大的痛点就是不好把握到底要画哪些内容，画的太少，担心没有展现关键信息画的太多，又觉得把握不住重点。
所以现在的问题变成了应该按照什么样的标准来明确架构图要展现的内容呢？答案就是我们在第一讲中介绍的四r架构。
定义四r是指四个关键词，rank role、 relation和role.既然可以通过四r来定义软件系统的架构，那么按照四r架构定义的思路来画架构图，也是很合情合理的。
具体步骤是第一步，明确rank,也就是说不要事无巨细的把一个大系统的方方面面都在一张架构图中展现出来。
而应该明确你要阐述的系统所属的级别，然后只描述这个级别的架构信息。
第二步，画出role,从不同的角度来分解系统，看看系统包含哪些角色，角色对应架构图中的区块图标和节点等。
第三步，画出relation,有了角色后，画出角色之间的关系，对应架构图中角色之间的连接线，不同的连接线可以代表不同的关系。
第四步，最后画出role挑选核心场景，画出系统角色之间如何协作，来完成某项具体的业务功能，对应系统序列图。
我把描述role和relation的架构图称为静态架构图，描述role的系统序列图称为动态架构图。
从某一个角度去看，静态架构图的数量跟系统复杂度有关，一般是一到两张，如果比较简单，用一张图就够了。
如果比较复杂，就要分别用两张图来展现，而动态架构图一般是好多张，因为核心场景数量不止一个，对应的系统序列图有好多张。
刚才介绍四加一视图的时候，我提到过从不同的角度去剖析，系统就会得到不同的视图。
其实按照四r架构定义来画架构图也是这样。
用不同的方式去划分系统，就会得到不同类型的架构，分别对应不同类型的架构图。
我把常见的类型用图片的形式整理在文稿当中了。
接下来我就为你详细的讲解每一类架构图的特点。
第一类业务架构图，他描述的是系统对用户提供了什么业务功能，类似于四加一视图的场景。
视图使用场景主要有三种，一是产品人员、规划业务。
比如说我们经常在产品规划和汇报，会议上看到产品人员会用业务架构图来展现业务全局状态。
二是给高批汇报业务。
对于p七加及以上级别的技术人员，在汇报的时候，不能光讲技术，也要讲业务的发展情况，用业务架构图就比较容易的展现业务整体情况。
三是给新员工培训业务画图。
技巧主要有三条，一、通过不同颜色来标识业务状态，比如说哪些业务发展状态好，哪些问题比较多，哪些比较稳定，哪些竞争比较激烈等。
二、业务分组管理，将类似的业务放在一个分组里面，展现，用虚线框或者相同背景将其标识出来。
三、区块对齐为了美观，可以改变不同区块的长短大小，进行对齐，让整体看起来更美观。
你可以参考阿里pay HK的一个业务架构图，如文稿中所示，这张业务架构图有三点关键信息。
第一，MTR区块是浅红色的人传人。
区块是绿色的浅红色代表正在进行的绿色代表，明年规划的第二分了四组钱包业务、第三方业务、商家服务和用户管理。
第三，转账和社交红包等。
区块比较长，只是为了对齐后更美观，不代表业务本身的量级或者重要程度。
如果要表示这样的信息，那么可以用颜色来表示注意，千万不要画的五颜六色。
一般一张图的颜色数量控制在三种以内是比较好的。
所以在画图的时候，你要想清楚到底哪些信息是要放在业务架构图中重点展示的关键信息，哪些信息顺带讲一下就可以了。
第二类客户端和前端架构图，它描述的是客户端和前端的领域逻辑架构。
关注的是从逻辑的角度如何分解客户端或者前端应用使用场景。
主要有两种，一是整体架构设计，由客户端或者前端架构师完成本领域的架构设计。
二是架构培训画图。
技巧主要有三条，一、通过不同颜色来标识不同角色。
二、通过连接线来表示关系。
如果有多种关系，例如有的是直接调用，有的是事件通知，那么可以用不同形状的线条来表示三分层或分组，将类似的角色分层或者分组管理。
你可以参考微信客户端架构，三点x的架构图，如文稿中所示，这张客户端架构图有三点关键信息。
第一点，图中用了灰色、蓝色、深灰色和浅蓝色来表示不同类型的模块。
第二点，图中有两类连接线双向的和单向的。
第三点，整体上分为四组，对应图中背景色，不同的四个大的区块第三类系统架构图，它描述的是后端的逻辑架构，又叫后端架构或技术架构。
不管是业务系统、中间件系统还是基础的操作系统、数据库系统等系统架构，都是软件系统架构的核心使用场景主要有两种，一是整体架构设计，二是架构培训。
画图技巧主要有三条，一、通过不同颜色来标识不同角色，二、通过连接线来表示关系。
三逻辑分组。
如果系统比较简单，你可以参考mango DB sharling的系统架构图。
如果系统相对复杂，建议首先用一张图来展示系统架构里面的角色，以及每个角色的核心功能。
然后再用一张图来展示角色之间的关系。
你可以参考一个支付中台的系统架构图，这些图片我都整理在文稿当中了。
第四类应用架构图，它描述的是后端系统有哪些应用组成一个应用，就是一个可部署发布运行的程序。
它是项目开发过程中开发测试、运维团队协作的基础使用场景主要有三种，一是项目开发测试，二是运维部署发布。
三是子域架构设计画图技巧主要有三条，一、通过不同颜色来标识不同角色。
二、通过连接线来表示关系。
三、复杂系统分域来画。
如果系统比较简单，那么基本上应用架构和系统架构是等价的。
你可以参考mango DB sharding的应用架构图。
我们可以看到这张图中的rooter conflict、 servers和下的既包含了系统架构的角色信息，又包含了应用信息。
如果系统比较复杂，按照架构分层的角度来看，应用架构已经到了可执行程序这一层。
例如，支付中台这一类的系统包含的应用可能有几百上千个。
如果把整个支付中台所有的应用都在一张图里面展示出来，信息太多太密，可能会导致架构图都看不清。
这种情况下，应用架构一般都是按照子域来画应用架构图，你可以参考支付中台的会员域的应用架构图。
这些图片我都整理在文稿当中了。
第五类部署架构图，它描述的是后端系统，具体是如何部署的，主要包含机房、信息网络信息和硬件信息等。
使用场景主要有两种，一是总体架构设计，二是运维规划和优化画图。
技巧主要是用图标代替区块，因为这样看起来更加美观和容易理解。
你可以参考一个简单的支付系统的部署架构图，如文稿中所示，第六类系统序列图，它描述的是某个业务场景下系统各个角色如何配合起来完成业务功能，一般是结合系统架构、应用架构和部署架构来使用画图技巧，主要是使用UML的序列图来画。
你可以参考扫码支付这个支付核心场景的系统序列图。
如文稿中所示，最后是补充说明。
如果你曾经研究过架构图的标准，那么除了四加一视图以外，你可能还看到过toorgef的业务架构、数据架构、应用架构和技术架构这种说法，或者还看到过c四架构模型等等。
但其实目前业界并没有就架构图标准达成共识。
刚才提到的togef是企业级的架构，基本上要到CTO这个级别才能接触的。
而c四模型的表达能力又不够，所以我并没有直接套用这些内容，而是根据个人经验，将我认为最有效果的架构图整理出来。
这些架构图都是我在不同类型、不同规模、不同业务的公司里面验证过的。
你可以放心的使用。
今天我为你介绍了画软件系统架构图的总体思路，以及常见架构图的应用场景和画图技巧，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你为什么后端架构可以直接被称为系统架构。
通常我们说的系统不是应该包含客户端和前端在内的一个整体吗？欢迎你把答案写到留言区，和我一起讨论。
相信经过深度思考的回答，也会让你对知识的理解更加深刻。