系统架构图是为了表达传递想法，如果一个表达方式能表达你的想法，就可以选择使用
很多人之所以画不好架构图，最大的痛点就是不好把握到底要画哪些内容，画得太少担心没有展现关键信息，画得太多又觉得把握不住重点。

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

用不同的方式去划分系统，就会得到不同类型的架构，分别对应不同类型的架构图。常见的类型整理如下：

常见的系统架构

业务架构图 ： 描述系统对用户提供了什么业务功能。用户视角或业务视角
【画图技巧】
通过不同颜色来标识业务状态：比如说哪些业务发展状态好，哪些问题比较多，哪些比较稳定，哪些竞争比较激烈等。
业务分组管理：将类似的业务放在一个分组里面展现，用虚线框或者相同背景将其标识出来。
区块对齐：为了美观，可以改变不同区块的长短大小进行对齐，让整体看起来更美观。

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

一个业务架构图

系统架构图
描述后端的逻辑架构，又叫“后端架构”或“技术架构”，不管是业务系统、中间件系统，还是基础的操作系统、数据库系统等，系统架构都是软件系统架构的核心。
系统架构核心部分就是在后端；
系统就是系统，业务就是业务，系统是来实现业务的
【使用场景】
整体架构设计。
架构培训。
【画图技巧】
通过不同颜色来标识不同角色。通过连接线来表示关系。逻辑分组。
【参考案例】
如果系统比较简单，可以参考 MongoDB Sharding 的系统架构图，
如下所示：

系统架构图

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

系统架构图-Role

系统架构图-Relation

4. 应用架构图【定义】描述后端系统由哪些应用组成，一个应用就是一个可部署发布运行的程序，它是项目开发过程中，开发测试运维团队协作的基础。【使用场景】项目开发、测试。运维部署发布。子域架构设计。【画图技巧】通过不同颜色来标识不同角色。通过连接线来表示关系。复杂系统分域来画。
   【参考案例】如果系统比较简单，那么基本上应用架构和系统架构是等价的，可以参考 MongoDB Sharding 的应用架构图，如下所示：

   
   
   image.png
   
   

   我们可以看到，这张图中的 Router（mongos）、Config Servers 和 Shard（replica set），既包含了系统架构的角色信息（Router、Config Servers 和 Shard），又包含了应用信息（mongos、Config Servers 和 Shard）。如果系统比较复杂，按照架构分层的角度来看，应用架构已经到了可执行程序这一层，例如支付中台这一类的系统，包含的应用可能有几百上千个，如果把整个支付中台所有的应用都在一张图里面展示出来，信息太多太密，可能会导致架构图都看不清。这种情况下，应用架构一般都是按照子域来画应用架构图，可以参考支付中台的会员域的应用架构图，如下所示：

   
   
   image.png

5. 部署架构图【定义】描述后端系统具体是如何部署的，主要包含机房信息、网络信息和硬件信息等。【使用场景】总体架构设计。运维规划和优化。【画图技巧】用图标代替区块，这样看起来更加美观和容易理解。【参考案例】一个简单的支付系统的部署架构图如下所示：

   
   
   image.png

6. 系统序列图【定义】描述某个业务场景下，系统各个角色如何配合起来完成业务功能。【使用场景】结合“系统架构、应用架构和部署架构”来使用。【画图技巧】使用 UML 的序列图来画。【参考案例】“扫码支付”这个支付核心场景的系统序列图如下所示：

   
   
   系统序列图
   
   

   补充说明如果你曾经研究过架构图的标准，那么除了 4+1 视图以外，你可能还看到过 TOGAF 的“业务架构（跟这一讲的业务架构名字相同，但是意义不同）、数据架构（不是指大数据平台架构，而是指数据资产的架构）、应用架构和技术架构”这种说法，或者还看到过 C4 架构模型（Context、Container、Component 和 Code）等等。但其实目前业界并没有就架构图标准达成共识，刚才提到的 TOGAF 是企业级的架构，基本上要到 CTO 这个级别才能接触的，而 C4 模型的表达能力又不够。所以，我并没有直接套用这些内容，而是根据个人经验，将我认为最有效果的架构图整理出来。这些架构图，都是我在不同类型不同规模不同业务的公司（华为、UC、阿里和蚂蚁等）里面验证过的，你可以放心地使用。

架构图小结

https://time.geekbang.org/column/article/482815