每天几分钟，解决工作生活问题。大家好？我是程序猿助理KK。
我有一个朋友，是非著名互联网公司的程序猿。公司新项目上马，需要做前期的架构设计等工作。他绞尽脑汁，勉强在画图软件上画出了一张图。
当他把辛辛苦苦画出的图作为资料汇报给老板的时候，结果得到的却是被老板痛骂。他很痛苦，也很委屈：加班熬夜画出的图，老板不理解，怎么办？
要解决这个“怎么办”的问题，我们首先要理解它的本质。再好的产品，只有设计规划被人理解才有机会做出来，怎么才能让人懂、让人理解呢？人的身份经验各不相同，例如，有懂技术的和不懂技术的。怎么才能让这些人能理解你的意图，是最关键的。
我们都使用过地图相关产品吧？例如手机端的百度地图、高德地图，电脑端的互联网地图等。地图产品都有一个共性：越缩小，就越能展示全局；越放大，就越能展示细节。我们首先看到的应该就是国家省份的大体轮廓，放大再是区县，再次是街道。这样是不是更能让人清楚的知道一个街道的具体方位呢？例如我们想去成都的青羊宫逛逛，打开地图导航，应该是展示成都市的全景，点击搜索青羊宫后就会逐渐放大到街道。这就是一个从全局到局部的一个过程。
今天给大家介绍一款辅助理解的工具，叫做C4 Model。为什么我们要介绍这个工具呢？它主要解决什么问题呢？C4架构模型主要解决我们需要为哪些用户提供什么服务？完成这个系统使用了哪些服务？每一个服务都由哪些部件组成？这些部件都需要完成什么？这种层层深入的是不是有点像地图缩放。
当我们看待真实世界“架构图”的时候，也需要不停缩放。不同角色不同时机需要了解不同层次的架构。不同层次特意的忽略一些细节才能突出架构意图。与地图的类比，C4模型把系统抽象成四个层次：
从上到下依次是系统（System）、容器（Container）、组件（Component）和代码（Code）。到这里有点同学就纳闷了，为啥叫C4呢？因为系统图叫System Context ——系统上下文图，也称为语境图。后面统一用语境图指代。
上图所示，从左到右依次是语境图（Context），容器图（Container），组件图（Components），代码图（Code），首字母是不是C。我们先看看语境图：
语境图
如上图我们可以看到，这个图向我们展示了软件系统是什么、它的用户以及是如何融入现有系统中的。从图中我们可以看到，蓝色方块表示我们需要开发的互联网系统，他可以接收个人银行客户来进行访问支付等操作，它也可以调用大型银行系统和电子邮件系统来继续支付和发送邮件操作。
划重点：语境图明确的对我们展示了需要向已有软件环境中加入什么，进一步帮助我们找到需要沟通协调的接口人，并以此作为技术和非技术人员沟通的桥梁。
容器图
放大语境图中我们的互联网银行系统后，就会看到系统和容器，如下图所示，系统是由容器组成的。是提供给软件开发团队内外的技术人员；包括软件架构师、开发人员和操作/支持人员提供指导的图示工具。 讲到这里，同学们可能会问，什么是容器呢？我个人认为，容器既不特定指代docker容器，也不指代java虚拟机。而是指代有独立进程空间的一种存在。通俗点就是可以独立部署东西。可以是微服务、数据库、应用程序等。
如图中所示，互联网银行系统容器图。它显示了互联网银行系统（虚线框）由五个容器组成：服务器端 Web 应用程序、客户端前端应用程序、移动应用程序、服务器端 API 应用程序和数据库。
WEB 应用程序是一个 Java/Spring MVC Web 应用程序，它仅提供静态内容（HTML、CSS 和 JavaScript），包括组成前端应用程序的内容。前端应用程序是一个运行在客户网络浏览器中的 VUE 应用程序，提供所有的网上银行功能。或者，客户可以使用Flutter开发的移动应用程序访问互联网银行的部分功能。前端应用程序和移动应用程序都采用 JSON/HTTPS 协议调用 API接口，这是由服务器端运行的另一个 Java/Spring MVC 的API应用程序提供的。API 应用程序从数据库中获取用户信息（关系数据库模式）。API 应用程序还使用专有的 XML/HTTPS 协议接口与现有的大型机银行系统进行通信，以获取有关银行账户或交易的信息。如果需要向客户发送电子邮件，API 应用程序还会调用现有的电子邮件系统。
划重点：容器图为了让我们了解软件系统的整体形态，更深层次的技术决策，系统职责如何分布，容器之间如何交流，以及我们需要在哪里写代码。不过这个图没有提到部署场景、集群、复制、故障转移等。
组件图
再把容器中的API应用放大，就可以看到容器是由哪些组件构成的，组件的功能职责及技术细节具体是什么，组件之间是如何进行交互的。这些就构成了一张供软件架构师和开发人员参考的组件图。例如上图中的登录控制器，采用了Spring MVC REST的技术以 JSON/HTTPS协议对外提供接口，每个控制器随后使用其他组件访问数据库和大型机银行系统中的数据。我们日常工作中会用到比如Service、Controller、Repository之类也可以用组件图来表达。例如下图所示。
划重点：组件图为了让我们了解容器是由哪些组件构成，组件的功能职责及技术细节是什么，组件之间是如何进行交互的。
代码图
把大型银行组件再次放大，可以显示出其组件的内部实现方式。例如图中是一个虚拟的网上银行系统的 UML 类图示例（部分），显示了组成 MainframeBankingSystemFacade 组件的代码元素（接口和类）。一般情况下，我们是不需要代码图的，一般IDE工具能根据代码生成。
以上就是C4架构的核心图，我们可以看到四种不同的抽象层次的定义会让我们更容易固定住我们讨论的层次，这点上我觉得C4是非常有价值的。
到这里了，同学们应该会感到疑惑。对于我们后面的研发，还是不够细怎么办？这就要用到几张扩展图了。
系统全景图
如图所示，系统全景图是比语境图更丰富的系统级别的表达。不像语境图只关注聚焦系统和它的直接关系，连一些间接相关的系统都会标示出来，那些系统的用户以及用户之间的关系也会标示出来，只是内部用户会用灰色标记。这样全景的展示企业相关系统，可以帮助我们理解聚焦系统的正确定位，以便根据全局环境对其进行优化。就像我们能知道青羊宫在成都的哪个方位，哪条街，怎么到达才能不堵车一样。
功能动态图
如图所示，功能动态图，你可以理解为这个就是具体业务操作的逻辑图。图中展示了登录操作的流程及逻辑，调用的具体方法等。这里可以再进一步细化到各组件内部，详细描述出登录操作的各操作逻辑，例如登录控制器接收到请求，先进行数据正确性校验，然后转发请求到其他组件，其他组件内部也会有一些逻辑处理。研发人员可以根据图中设计到的技术、逻辑提前做一些相关的预演。思考逻辑是否合适等。
系统部署图
前面几张图都是站在开发者的角度思考，没有提到部署场景、集群、复制、故障转移这些部署架构，这就很容易变成一个运维灾难。系统部署图就是为了解决此类问题的。它详细描述了个容器部件具体怎样部署，采用什么软件，做不做集群，出故障了怎么处理等。
从上面图中可以看到几个关键图形，如下图所示
蓝色方块表示我们聚焦的系统，也是我们需要开发的系统，也可能是需要分析的系统，这取决于目前我们处在的状态、位置。灰色方块表示我们依赖的系统，是已经存在且不需要做额外大量修改的系统。虚线方块表示系统的边界。带箭头虚线表示系统之间是怎样的关系，怎样进行依赖。
到这里我们的C4架构模型就讲解完毕了，相信架构图从此以后讲不再是你们的难点了。只要做到了先总后分的分析方法，就能做出简单易懂的架构图。期待您的成长。部分图示来源于 c4model.com
我是程序猿助理～KK，
后面会出一些关于辅助程序猿工作生活相关的文章，力求帮助到程序猿们。
记得关注我哦
网友评论