c4 model 架构设计「C4架构」

大家好，c4 model 架构设计「C4架构」很多人还不知道，现在让我们一起来看看吧！

15分钟阅读.

一、前言

---

在日常工作中同一系统，不同人画出来的架构图是不一样的，但也不是说他们谁画错了，而是每个人的抽象层次不一样。抽象层次这种东西，说起来好像存在，但真要说清楚还挺难，于是作者类比地图，提出了缩放的概念。这便是“C4模型”。

关于作者：Simon Brown 是一位专门从事软件架构的独立顾问，也是“Software Architecture for Developers”（面向开发人员的软件架构、技术领导力和敏捷性平衡的指南）的作者。他还是 C4 软件架构模型的创建者，这是一种创建代码映射的简单方法。

二、为什么推荐C4模型

---

1）、由于向敏捷转型，软件架构图的使用规模已经大幅缩减。即使有在使用软件架构图，它们往往也混淆不清。软件架构图是一种非常好的表达方式，可以用它们来表达你将如何构建一个软件系统（预先设计）或者现有的软件系统是如何工作的（回顾文档、知识分享和学习）。

然而，我们所看到的大多数软件架构图很可能只是由混乱的框和线组成。敏捷软件开发宣言的一个副作用就是让很多团队停止或缩减了他们的架构图和文档工作，包括使用UML。

敏捷软件开发宣言

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

现在，这些团队倾向于依靠他们在白板上绘制的临时架构图，或者使用通用的图表工具（如微软的Visio）。Ionut Balosin 在去年写了一篇叫作“软件架构图的艺术”的文章，他在文章中描述了一些常见问题，这些问题与不可理解的符号和不明确的语义有关。

如上图含糊不清的软件架构图容易导致误解，这可能会拖慢一个优秀团队的前进步伐。

2）、C4 模型由一系列分层的软件架构图组成，这些架构图用于描述上下文、容器、组件和代码。C4 图的层次结构提供了不同的抽象级别，每种抽象级别都与不同的受众有关。

3）、为了避免出现含糊不清的情况，通过可视化的方式展示，可以在图中包含足够数量的文本和关键的图例。

三、什么是C4模型，怎么来画

---

1、地图缩放来类比C4

C4是一种以各种细节级别创建代码映射的方法，就像使用Google Maps之类的工具来放大或缩小感兴趣的区域一样。

道路级：像源代码一样，街景视图提供了一个非常底层且准确的位置视图。

城市级别，省级

国家级：不同的缩放级别可让您向不同的受众讲述不同的故事。

2、C4模型

上面的四张地图就是想说明，当我们看待真实世界的“架构图”的时候，也是要不停的缩放，在每一个层次刻意忽略一些细节才能表达好当前抽象层次的信息。所以他类比着把架构也提出了四个抽象层次：

从上到下依次是系统System、容器Container、组件Component和代码Code。（那为什么叫C4呢，因为系统的图叫System Context，系统上下文图。为了凑四个C也是够拼的。）

C4 代表上下文（Context）、容器（Container）、组件（Component）和代码（Code）一系列分层的图表，可以用这些图表来描述不同缩放级别的软件架构，每种图表都适用于不同的受众。

基于这四个层次的抽象，C4模型由4张核心图和3张附属图组成，分别用于描述不同的场景，下面我们一一介绍一下。

3、四张核心图

4.1 系统上下文图(级别1)

tips：这是一个虚构的Internet银行系统的示例系统上下文图。它显示了使用它的人员以及与Internet Banking System相关的其他软件系统。银行的个人客户使用Internet银行系统查看有关其银行帐户的信息并进行付款。互联网银行系统本身使用银行现有的大型机银行系统来执行此操作，并使用银行现有的电子邮件系统向客户发送电子邮件。

系统上下文图是用于绘制和记录软件系统的一个很好的起点，使您可以退后一步查看全局。通过系统上下文图将你的系统显示为一个处于中心的盒子，周围环绕着用户和与之交互的其他系统。

这里的细节并不重要，因为这是缩小视图，显示了系统概况。重点应该放在人员和软件系统上，而不是技术，协议和其他低级细节上。

范围：单个软件系统。

主要元素：范围内的软件系统。支持元素：在范围内直接连接到软件系统的人员（例如，用户，角色）和软件系统（外部依存关系）。通常，这些其他软件系统不在您自己的软件系统的范围或边界之内，因此您不承担任何责任或所有权。

目标读者：软件开发团队内部和外部的所有人，包括技术人员和非技术人员。

4.2 容器图（级别2）

tip：这是一个虚构的Internet银行系统的示例容器图。它显示了Internet银行系统（虚线框）由五个容器组成：服务器端Web应用程序，单页应用程序，移动应用程序，服务器端API应用程序和数据库。该Web应用程序是Java / Spring MVC Web应用程序，它仅提供静态内容（HTML，CSS和JavaScript），包括构成单页应用程序的内容。单页应用程序是一个Angular应用程序，可在客户的Web浏览器中运行，提供所有Internet银行功能。或者，客户可以使用跨平台的Xamarin移动应用程序来访问Internet银行功能的子集。

单页应用程序和移动应用程序都使用JSON / HTTPS API，该API由服务器上运行的另一个Java / Spring MVC应用程序提供。API应用程序从数据库（关系数据库模式）获取用户信息。API应用程序还使用专有的XML / HTTPS接口与现有的大型机银行系统通信，以获取有关银行帐户的信息或进行交易。如果需要将电子邮件发送给客户，API应用程序还将使用现有的电子邮件系统。

当我们放大一个系统，就会看到容器，如上图所示，C4模型认为系统是由容器组成的。容器是我个人认为，C4模型最大的创举，尤其是在这个单体架构快速崩塌的时代。这里的容器，既不是Docker的容器，也不是JavaEE里的容器，而是借用了进程模型，每一个容器都是指有自己独立的进程空间的一种存在。不管是在服务器上的单独进程空间，还是在浏览器里的单独进程空间，只要是单独的进程空间就可以看作一个容器。当然如果你容器化做得好，Docker的Container和这个Container可以一一对应。有了这个概念的存在我们就可以更清晰的去表达我们的架构，而不是总是用一些模糊的东西。

容器图显示了软件体系结构的高层结构以及如何在其间分配职责。它还显示了主要的技术选择以及容器之间的通信方式。

范围：单个软件系统。

主要元素：范围内软件系统内的容器。支持元素：直接连接到容器的人员和软件系统。

目标受众：软件开发团队内部和外部的技术人员；包括软件架构师，开发人员和运营/支持人员。

注意：此图未说明部署方案，集群，复制，故障转移等。

4.3 组件图（级别3）

tip：这是一个虚构的Internet银行系统的示例组件图，显示了API应用程序中的某些（而非全部）组件。这里，有三个Spring MVC Rest控制器为JSON / HTTPS API提供访问点，每个控制器随后都使用其他组件来访问数据库和大型机银行系统中的数据，或者发送电子邮件。

接下来，可以放大并进一步分解每个容器，以识别主要的结构构件及其相互作用。

组件图显示了容器如何由多个“组件”组成，每个组件是什么，它们的职责以及技术/实现细节。

范围：单个容器。

主要元素：范围内容器中的组件。支持元素：容器（在范围内的软件系统内）以及直接连接到组件的人员和软件系统。

目标受众：软件架构师和开发人员。

4.4 代码图（级别4）

tips：这是一个虚构的Internet银行系统的示例（部分）UML类图，显示了构成MainframeBankingSystemFacade组件的代码元素（接口和类）。它显示了该组件由许多类组成，实现细节直接反映了代码。

代码图没什么可说的，就是UML里的类图之类很细节的图。一般是不画的，都是代码生成出来。除非非常重要的且还没有写出代码的组件才画代码图。

范围：单个组件。

主要元素：作用域内组件内的代码元素（例如，类，接口，对象，函数，数据库表等）。

目标受众：软件架构师和开发人员。

4、四张核心图的关系

类比地图缩放，把架构也提出了四个抽象层次，分别适用于不同的受众。C4模型是一种“抽象至上”的方法，用于表示软件体系结构，该方法基于反映软件架构师和开发人员如何思考和构建软件的抽象。C4模型是为了帮助软件开发团队在前期设计会议和回顾性文档化现有代码库的过程中描述和交流软件体系结构。

5、三张扩展图

架构设计设计要考虑的维度很多，仅四张核心图是不够的，所以作者又提供了三张扩展图，可以让我们关注更多的维度。

5.1 全景图

C4模型提供了单个软件系统的静态视图，但是在现实世界中，软件系统永远不会孤立存在。因此，尤其是在您负责一组软件系统时，了解所有这些软件系统如何在企业范围内融合在一起通常很有用。为此，只需添加另一个C4图“顶部”的图，以从IT角度显示系统格局。像系统上下文图一样，此图可以显示组织边界，内部/外部用户和内部/外部系统。

本质上，这是企业级软件系统的高级映射，其中每个感兴趣的软件系统都有C4向下钻取。从实践的角度来看，系统格局图实际上只是系统上下文图，而没有特别关注特定的软件系统。

适用范围：企业。

主要元素：范围内与企业相关的人员和软件系统。

目标受众：软件开发团队内部和外部的技术人员和非技术人员。

这个图有什么用呢？在我们分析一个企业的时候，我们需要一个工具帮助我们把一家公司给挖个底掉，做到完全穷尽，才能看到企业的全景图从而理解局部的正确定位以做好局部设计为全局优化服务。

5.2 动态图

动态图不同于其他图（表达静态关系的），它是用来表达动态关系的，也就是不同的元素之间是如何调用来完成一个业务的。所以动态图不仅仅在一个层面上可以工作，它在系统级、容器级和组件级都可以画，表达的目标是不一样的。

5.3 部署图

前面的几张图都是站在开发的角度思考，但是一个没有充分思考过部署的架构很容易变成一个运维的灾难。所以作者提供了一个部署图。考虑到DevOps运动如火如荼，这个图可以变成很好的Dev和Ops之间沟通的桥梁。我们在实操中发现，Dev和Ops关注点的不同、语言的不一致，在这张图上表现得非常清楚。

图上最大的的实线框不同于虚线框，它表达的是数据中心，当你开始考虑异地灾备的时候它就有了意义。数据的同步、实例的数量都会影响你部署图的内容。部署图基本都是容器级的，它会很好的表达出来容器到底部署了几个实例，部署在什么样的操作系统上，一个节点部署了几个容器之类，我们在实际使用中，发现需要考虑的信息太多，自己就抽象出了类似于亚马逊上实例规格的Small、Large之类的术语来表达机器配置，增进了开发和运维之间的交流准确性。

6、C4模型里的符号

C4说穿了就是几个要素：

1）、元素——方块和角色、

2）、关系——带箭头的线、

3）、元素的描述——方块和角色里的文字、

4）、关系描述——线上的文字、

5）、元素的标记——方块和角色的颜色、虚线框

通过在不同的抽象层次上，重新定义方块和虚线框的含义来限制我们只能在一个抽象层次上表达，从而避免在表达的时候产生抽象层次混乱的问题。

即使符号是显而易见的，仍然要确保为这些符号提供图例。图例中应该包括颜色、形状、首字母缩略词、线条样式、边框、尺寸等。理想情况下，符号应该在每个细节层次上保持一致。下面是前面显示的容器图的图例。

四、小结

---

C4 模型是一种在不同抽象层次上交流软件架构的简单方法，可以向不同的受众讲述不同的故事。这也是向软件开发团队介绍（通常是重新引入）严谨和轻量级建模的一种方式。有关 C4 模型的更多信息，以及补充图（运行时和部署）的示例、符号清单、常见问题解答、会议讲座视频和工具选项，请参阅 c4model.com 。

关注「架构那些事儿」公众号！

你的关注就是我的动力！