你真的会画架构图？我花了一年的时间学会了（画图困难户的福音）
大家可能觉得画架构图不是挺简单的吗？或许大家经常会看到以下类似的架构图。
以前我对架构图的认识就如上面的图。这张图描述了
- 服务器的部署资源关系
- 应用服务器和组件之间的协作关系
- 链路关系
一本书《程序员必读之软件架构》让我对架构图的理解开始变的更广，也学会了如何画架构图。
当一个工程师想要快速了解一个系统如何在一个复杂的集成环境中融入其中进行工作的，大家觉得需要一个什么样的图？书中提到了C4模型，也是这C4模型也让我知道画架构图不是那么的简单（http://c4model.com/）。
C4模型中提到：上下文（Context）也叫做语境图、容器（Container）、组件（Component）和代码（Code）
上下文（Context）：
意图：
-
我们构建的软件系统是什么？
-
这个系统的用户有哪些？
-
如何融入已有的IT环境
作用：
-
使语境更加明确，这样就不需要假设。
-
从一个较高层次展示了正在向已有的IT环境中添加的是什么
-
技术和非技术的人员可以当作讨论起点的一种高层次图表
-
牵涉到理解系统间接口的问题时，为你识别可能需要沟通的的人提供了一个起点
以上的例子是一个简单的上下文图，而我们工作中经常用系统集成关系图来替代上下文（Context）。我想我们工作中的输出的系统集成关系要比以上的图要复杂的多。
这张图在我们做集成开发/讨论/集成设计/新人加入项目理解系统显得尤其重要。我们一眼就能看出我们系统是如何配合其他系统完成功能需求的。
我们从系统集成关系图中知道了自己的系统所处的环境和上下游，那么我们如何针对一个场景梳理系统间的流程呢？这时候就要请出我们的系统间流程图
上图我们简单的描绘了在订单推送过程中经历了哪些系统，系统之间传递了哪些参数，对我们进行集成开发很有指导意义，开发人员也能快速的熟悉端到端的链路信息。
我们从系统集成关系图和系统间流程图中知道了当前系统如何配合其他系统完成工作，一个场景的功能系统间是如何配合完成的。
那我们怎么去了解这个系统呢？
容器（Container）：
意图：
-
软件系统的整体形态是什么样的？
-
高层次的技术决策有哪些？
-
职责在系统中如何分布？
-
容器之间如何相互交流？
-
为了实现特性，作为一个开发者，我需要在哪里写代码？
作用：
-
让高层次的的技术决策更明确
-
展示了哪些容器之间有关联，以及他们如何沟通
-
提供了一个放置组件的框架
但实际情况我们团队的成员已经变的非常有默契了，在讨论的时候已经默认了一些技术细节。比如数据库使用MYSQL,Redis，微服务使用SpringBoot默认的Http协议传输Json数据，使用平台公共组件等等。
而我们平时沟通更加关注这个系统有几个微服务，这几个微服务之间是怎么相互协作的，当我们进行迭代的时候讨论代码应该写在哪个模块。
而输出的容器图和官方的有点差异
容器图让我们看清楚系统内每个进程是如何协作的，我们接着深入到一个JAVA进程去探索这个进程中有哪些组件
组件（Component）：
意图：
-
系统有哪些组件/服务组成？
-
在高层次上，系统如何工作是否清晰？
-
所有组件/服务都有一个家吗？
作用：
-
展示了在高层次上将你的软件系统分解为职责不同的组件
-
展示了组件之间的关系和依赖
-
为软件开发的高层次预估和如何分交付提供了一个框架
以上这个图对我们的项目中的开发人员比较适用，然而如果我们只是想了解这个系统我们并非关心那么多的细节。
随着时间的推移和项目逐渐变得复杂，这个图也会变的复杂。或许我们可以使用包名来替换其中的Controller，我们知道每个包大概做了哪些事情，不至于在看这个图的时候看的晕头转向。
代码（Code）：
哈，很不巧，书上并未给出解释，不过官网上给出了一张图：
这是一张类图，在我们敏捷和快速迭代的环境下，类图可能无时无刻在发生变化，如果确实需要建议针对核心功能输出该图。
在我们在使用设计模式对某些功能进行重构的时候，我们需要好好设计一下类，或许这个图非常有帮助。
以上是C4模型提出的四个图：上下文（Context）也叫做语境图、容器（Container）、组件（Component）和代码（Code），可以帮助我们快速的了解一个系统
C4的官网在四个图的基础上进行了扩展增加了以下几张图：System Landscape（企业语境图）、Dynamic（动态图）、Deployment（部署图）
System Landscape（企业语境图）：
上下文（Context）关注当前系统的上下集成关系，如果我们负责的系统比较多且相互之间的协作比较多，那么我们需要一张企业语境图来将系统/产品组织在一起来表达他们之间的协作。可以在这张图上表达出组织的边界、外部系统和内部系统。
Dynamic（动态图）：
这样动态图表达了一个JAVA服务内部的组件之间的配合协作，和我们上面提到的系统间流程图非常的相似，只不过对象不一样，一个是系统一个是内部的组件。
Deployment（部署图）：
当我们使用微服务和容器技术的时候，部署也变得简单。应用开发团队只需要告诉负责IT资源的人我们需要哪些资源（数据库，消息队列等），链路关系（网关入口，是否需要外网等），我们有几个微服务等信息。而那些监控，日志，Web容器等都已经在容器中默认集成。
看了这么多图有没有觉得对架构图有了新的认识？当我看完《程序员必读之软件架构》后感觉眼前一亮，豁然开朗。
当我们的系统身处一个复杂的集成环境中我们的：系统集成关系图，容器图，系统间流程图（时序图），部署图就显得尤其重要。当有一个新的小伙伴加入到我们团队，这些图就能给他一些指导作用，更快的熟悉我们的IT环境、技术环境和集成环境从而快速的了解我们的系统。
当我们希望更深入的了解这个系统中的某个微服务，那么我们可以提供一张类似于组件图的图，帮他快速的了解各功能和模块在哪里。
不同的角色看图的角度不一样，我们在画架构图的时候也要考虑到是谁看这个图。当我们拥有以上图纸的时候，无论在演示，团队沟通，软件设计的时候沟通变的简单和高效。
一图胜千言，我们的工作也因此变得愉快。
最后给大家献上常用画图工具：
在线工具：https://www.processon.com 可进行成员之间在线协作，直播画图。
本地工具：Visio，我经常用来画用例图，系统间流程图，时序图等等画起来比较快。
文章来自我的个人公众号，获取更多精彩内容关注公众号：
推荐MYSQL SQL优化实战文章推荐：
MYSQL-SQL优化之-复合索引巧用 充分降低数据库CPU提高QPS
MYSQL-SQL优化之-Left Join优化 11秒的SQL优化到20毫秒内，技巧参考