怎样画一张人见人爱的系统架构图

作者：张馨予

　　在我们IT行业，经常要画系统架构图。这是和客户，上下游伙伴进行技术和商务沟通的有效工具。几乎任何一个复杂企业软件产品和方案都会把系统架构图作为商业表达的重点。

　　在技术研讨会上，这些架构图往往是幻灯片的主角，不仅出现在现场屏幕上，还是现场观众举起手机拍照的重点对象。所以，一副精确且大气漂亮的系统架构图能够同时体现公司产品的架构能力和品牌形象。

　　IT架构图看起来总是高大上，复杂的系统有时候不知道从何着手，但只要掌握几个关键步骤，你就能够做出惊艳的成果来，让读者赏心悦目的同时，增强研读的兴趣。

　　一、从具象到抽象

　　架构图表达的就是事物的结构，大多数领域都可以用具象的方式来呈现，比如下图中的人体器官系统图就显得一目了然。但是IT行业几乎没有具象表达的可能性。不像人体器官系统的直观视觉表达那么有效。所以，设计IT系统架构图，第一步就是要完成合理的“抽象”。

　　1.恰当的颗粒度

　　抽象最重要的目标就是决定用什么样的颗粒度来列出事物，而不是巨细无遗。这完全取决于架构图的受众和想要表达的系统的规模。越是非技术受众，越要降低颗粒度，越是大型系统，也要降低颗粒度。虽然我们可以在一个架构图中表达事物的层次，但是平面空间总是有限，就像人体器官分布图没办法呈现细胞组织一个道理。

　　IT系统架构图的受众通常包括客户和技术伙伴。两者都想要了解系统的基本原理，不想面对一个黑盒产品，但是非开发者型客户通常不需要了解过多的技术细节，所以适合使用较高抽象水平的表达。而参与产品生态的开发者、合作伙伴则希望了解更详细的系统信息，拓扑结构，因此需要一个颗粒度更高的表达版本。这一版本通常出现在产品技术白皮书中。

　　举个操作系统的例子。如果要用一个架构图呈现Windows的系统架构，对普通用户只需要切入到系统内核、内存管理、文件系统、GUI、设备管理这样的大模块就行。但对于Windows应用开发者，则需要继续延伸到DLL库、注册表、API等技术细节。对于后者，实践中可能要拆分成若干个子系统的架构解析才行，因为要把所有的技术细节都放到一张图中并不友好。如果搞错了受众，用过度技术化的细节架构会让一般读者无所适从。

怎样画一张人见人爱的系统架构图

最简单的操作系统架构图，只有四个抽象对象

相比较，一个更加详细的macOS操作系统架构图

　　2.通用和规范的命名

　　确定了抽象层级，在架构图上就要列出需要表达的事物对象。因为缺乏具象的参照，所有的对象表达唯一途径就是文字标签，最多加上符号图标。这就要求制作者必须使用规范或约定俗成的事物命名，否则读者将无法理解。比如，上例中的操作系统架构图，File System绝对不能写成Doc System，因为只有前者是一个规范名称。

　　很多IT产品设计中会有自己的独特命名组件，甚至这些命名没有任何的语义元素。这些命名在架构图中出现必须要附加实际含义的说明，否则没有读者会知道“海豚系统“是什么意思。当然IT行业中也会出现强势垄断产品，以自己的独特命名确定行业标准，以至于你不知道都不好意思，这种情况当然另当别论。

　　当使用图标和符号来表达事物对象时，要注意选择规范和识别性强的图形。在一些非常专业的领域，比如电子电气架构图，甚至有对各种组件规范的标准定义。即使有含义准确的符号图标，依然建议制作时附加上文本标签，可以让架构图的读者更明晰地理解。相反，没有图形，只有文字的架构图是完全可以接受的。

　　得益于该行业突出的模块化程度，电子电路也有抽象表达的架构图，但它有严谨的绘制规范。

　　3.明确抽象对象之间的关系

　　在进入正式的绘制之前，我们还要确定抽象对象之间的关系。这将决定我们用什么视觉形式来准确地表达架构。

　　在抽象系统架构中，各种对象之间的关系只有三种：包含、并列和联结。比如操作系统包含用户模式和内核模式，用户模式和内核模式是并列的，客户端和服务器是通过TCP/IP协议连接（联结）的。无论系统多么庞大和复杂，对象和对象之间的关系就这么几种。而且，在平面空间中，无论怎么演绎，也只能有效地表达这些有限的关系类型。

　　你只需要稍稍瞥一眼下图，就知道各个方块所代表的组件彼此之间的关系了。看罢这个参考，我们就可以开始动手绘制了。