C4 模型 - 可视化架构设计

 　　前言

　　世界上最难的两件事是：

　　1. 把我的思想放进你的脑袋

　　2. 把你的钱放进我的口袋　　

　　第二点我们不探讨，因为这是众所周知的，不信？过来试试：）　　

　　对于第一点，对我们程序员来说，其实也是我个人一直强调的，很多事情的成败，其实就在于掌舵人的思想层面是否认知是一致的，当我们对于一个事物的认知不在同一层面，就好比我们的划桨是不统一的，这是不能发挥最大的生产力。

　　你碰到过吗？

　　当我们进入一家新公司的时候，每个人都需要对公司的业务系统进行了解，当你不得不向别人解释系统是如何工作的，业务模块是如何串联的，子系统是如何各司其职的，特别是对于非技术人员来说，你会从代码开始解释吗？

　　如果是这样的话，这将是最低效且会让人陷入无穷无尽的技术细节里面，如何清晰描述系统让不同人找到自己的关注点，将成为难题。

　　通常我们会从宏观的架构设计上进行讲解，然而当我们在探讨架构设计的时候，每个人对架构的抽象层次理解都不一样，抽象这种东西，说起来好像存在，但是要具体描述乃至落笔下来，还是非常有难度的。

　　所以我们需要的是：让程序员和业务人员在讨论系统时候，能有统一的维度和统一标准，这就像是领域驱动设计里面所提倡的统一语言，让所有人在统一的认识中有效的沟通。

　　鉴于这样的背景，C4 model提出这样的概念来解决这个问题。

　　C4 模型

　　C4的理念是，具体把系统分为：System Context（上下文）, Container（容器）, Component（部件）, Code（代码）这四层，每层代表着不同的视图架构，关注点也会不同，所以每层适用于不同的人员，我们会针对当前的人员的角色，找到共同的关注点（合适的层级）来统一认识，然后拓展话题。

　　当我们使用C4模型来描述自己的软件架构时，可以通过不停的放大，把架构从宏观到细节具体地描述出来。就好比我们看地图一样，总览（System Context）关注的是国家层面，然后到省（Container）的层面，由多个省来构成国家，再下一层，到市（Component）,再到市是如何建设起来的（Code）。这四种不同的抽象层次的定义会让我们更容易固定住我们讨论的层次以及共同认识。

 

 

 

　　我们来看一下每一层的具体含义。

　　第一层 -  System Context

　　在这一层，我们将不会关注细节，这里提供的是系统级别的总览关系图，这层的关注点应该是用户和系统的交互，而不是协议，技术点等一些具体的体现。所以它的使用人群是非技术人员，这里面描述的是系统级别的交互，谁使用。

 

　　在这里，我们可以理解这是一个可供终端用户使用的完整系统（或者多个系统）的描述和专注于该层的使用人员，这里的一个系统可由一个或者多个服务（进程）组成，能完成我们业务的服务组合。所以看到我们用户直接面对的是可用的系统，而一些邮件和权限系统，则属于子系统。

　　在这里的一些特定技术术语需要澄清一下：一个系统可由多个服务（微服务）组成，也可只有一个服务组成（邮件系统很可能只有一个邮件的收发服务）。

　　需要特别注意的是，在跟别人探讨这层的时候，尽可能不要引入技术术语，因为这层更多的是使用人员关注的，大家的认知应该是在对系统的正常理解。

　　第二层 - Container

　　这一层是上一层Context的继续（我们这里选择的是用业务系统这个系统作为例子），是我们将各个System Context放大(Zoom in)的效果，我们将会看到一个技术栈以及各模块的一个职责和依赖。

   

　　这层是给具有技术背景的人员看，这里面描述的是进程级别的应用，这是可直接部署和运行的，通过这层，我们将可以看清软件整体形态以及职责描述。

　　这里的Container也可以简单地理解为容器，前提是这个Container只有一个服务，当Container具备多个服务组成时，那么这个Container就包含一系列的服务了，不能简单的对等于容器。

　　第三层 - Component

　　 这一层是Container层的继续放大，这里将看到服务的具体组成，如我们的订单服务包含哪些职责的类

　　我们可以看到，这一层是给开发人员看，这里描述的是系统组成部件、部件之间的层级关系和依赖。

　　这层的Component，可以理解为java里面的包或者c#里面的程序集，这里描述的是内部的包/程序集相互引用（调用）关系以及包对外部系统的程序的依赖

　　第四层 - Code

　　这一层是持续将Component放大的效果（借用一下官网的类图：））。

 

　　这一层的使用对象是开发人员，这里描述的是基于UML等图形来描述实现的技术细节，直接反映了代码层面。

　　找到共同语言

　　好了，当我们把整个系统通过通过C4 模型设计把不同层次的抽象软件架构描述了出来，我们可以找到各自所关心的层次进行快乐的交流了。

　　什么？你想给刚来的产品经理讲Component级别的架构？不，你不想，你也不能想，因为他并不关心这个，你能讲的，就是基于Context级别，讲述我们公司的整个产品体系是如何运行以及关联依赖的。

　　所以，回到我们的前言：让所有人在统一的认识中有效的沟通。这让我们在探讨之前，先找好各自关心的层次，然后再进行交流。这也是C4 模型给我们带来的巨大价值。

　　我们如何落地？

　　说了那么多概念，可以来点干货了，如何动手把脑袋中的架构展示出来？

　　PlantUML

　　什么是PlantUML? PlantUml是一个支持快速绘制的开源项目，其定义了一套完整的语言，通过文字、代码等工具用于实现UML关系图的描述。

　　通过PlantUML，我们可以轻松通过代码形式画出自己想要的图形。　

　　这里采用一个流程图作为例子：　

@startuml
用户 -> 认证中心: 登录操作
认证中心 -> 缓存: 存放(key=token+ip,value=token)token

用户 <- 认证中心 : 认证成功返回token
用户 -> 认证中心: 下次访问头部携带token认证
认证中心 <- 缓存: key=token+ip获取token
其他服务 <- 认证中心: 存在且校验成功则跳转到用户请求的其他服务
其他服务 -> 用户: 信息
@enduml

　　

　　PlantUML不仅仅能画出C4 模型架构，还能轻松画出常用的UML图，以及通过安装插件，实现draw.io ，xmind等插件的图形绘画。

　　使用PlantUML刻画C4

 　　在VSCode中下载PlantUML插件，然后在GitHub上搜索一些好用的PlantUML开源库，直接代码形式画图吧。

 

 　　补充个人上面图形的PlantUML源码：）

 　　总结

　　软件架构图是一种非常好的表达方式，可以用它们来表达你将如何构建一个软件系统或者现有的软件系统是如何工作的，而C4 模型则能很好的解决这个问题，它是由一系列分层的软件架构图组成，这些架构图用于描述不同层次的不同的抽象，每层的抽象都会有不同的适用人群。

　　当我们拥有了C4 模型的方法论之后，面对不同角色人员，我们将清楚的知道，应该宣讲哪层以及该把关注点放在哪层，这样我们将会在统一的意识层面上探讨，做到意识上的统一。