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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  ：也就是说，不要事无巨细地把一个大系统的方方面面都在一张架构图中体现出来，而应该明确你要阐述的系统所属的级别（L0～L4），然后只描述这个级别的架构信息。

  ：从不同的角度来分解系统，看看系统包含哪些角色，角色对应架构图中的区块、图标和节点等。

  ：有了角色后，画出角色之间的关系，对应架构图中角色之间的连接线，不同的连接线能代表不同的关系。

  ：挑选核心场景，画出系统角色之间如何协作来完成某项具体的业务功能，对应系统序列图。

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

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

  李运华：前阿里资深技术专家。在阿里时带领多个研发团队，承担架构设计、架构重构、技术团队管理、技术培养和训练等职责，曾就职于华为和 UCWeb，写过《面向对象葵花宝典》一书。

  华仔从 2006 年开始接触架构设计，花费 8 年时间掌握架构设计的精髓，走过了从程序员到架构师的蜕变之路，也踩过了这条路上的很多坑。后来他带了团队，特别是做了职业等级晋升评委后，看到了一大批优秀程序员的晋升卡在架构设计上，也慢慢变得能体会架构设计特性所导致的学习和实战方面的问题。

  在本专栏中，华仔会从架构基础、三大架构模式和实战的角度分享他一整套的架构设计方法论，希望你学习后不仅仅可以快速理解陌生的架构设计，自己也能对架构设计游刃有余，并能给身边正在迷惘的同学指点迷津，实践所学，分享所学。

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

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

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

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

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

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

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

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

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

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

  2. 通过连接线来表示关系，如果有多种关系，例如有的是直接调用，有的是事件通知，那就能用不一样的形状的线. 分层或分组：将类似的角色分层或者分组管理。

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

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

  如果系统最简单，可以借鉴MongoDB Sharding的系统架构图，如下所示：

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

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

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

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

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