软件架构系列一：C4模型

本文要点预览：因为软件系统的分布式特点以及开发团队的分布性，了解软件架构的基础变得越来越重要。而在过度设计和毫无设计之间，我们应该把注意力放在对软件系统有重大影响的决策和权衡上。好的架构师应该是团队的活跃分子，不仅能够进行代码协作，还能为团队提供技术指导。软件架构中的沟通环节极具挑战性。C4 模型对软件架构中的沟通环节进行了结构化，从一个上下文图表开始，再逐步深入到系统的各个技术层面。实际上，可以多花一些时间实现好的架构，好的架构能够带来敏捷。

随着软件行业的发展，开发团队仍然面临着与软件架构有关的问题。这些问题比以往任何时候都要来得突出，因为我们现在构建的系统越来越趋于分布式化，开发团队也越来越分布式化。为了解开这些迷思，开发者需要了解以下五个与软件架构有关的事实。

     1. 软件架构不只是前期的“大设计”

传统的观点认为，软件架构就是在前期进行“大设计”，然后通过瀑布模型进行交付，架构团队要确保软件的每一个元素在进行编码之前都要考虑妥当。

2001 年，“敏捷开发宣言”建议我们“拥抱变化而不是遵循计划”，但这个观点后来却被误读成不应该制定任何计划。结果就是，有些开发团队直接从原先的“大设计”变成了零设计。

这两种极端的行为都愚蠢至极，实际上，在某个时候，你会发现前期的设计并非开发出完美软件的必要因素。前期的设计应该只是一个起点，或是作为团队前进方向的指引。

在进行软件设计时需要做出一些设计决策。在谈及软件架构和软件设计之间的区别这个问题时，Grady Booch 说，“架构代表了重要的决策，决策的重要程度通过变更成本来衡量”。
     换言之，就是看在后续进行变更时那个决策需要付出更大的成本。所以，好的前期设计就是要充分理解什么是“重要的决策”。这些决策通常与技术选型和结构（也就是分解策略、模块化、功能边界等）有关。

如果开发的是一个单体系统，那么选择何种编程语言可能就变得尤为重要。如果采用的是微服务架构，那么使用何种编程语言就变得不那么重要，但需要考虑其他方面的因素。类似的，如果采用了六边形架构，虽然可以将业务逻辑与技术选型解耦开来，但仍然需要做出其他方面的权衡。

所以说，前期设计就是要了解影响软件成型的重要决策，而不是具体的技术细节，比如数据库的某个列要设置多大的长度。在现实当中，我会让团队真正去了解他们将要做什么、如何去做以及他们已经设计好的东西是否可行。可以让他们识别出最高优先级的任务，如果有必要可以写出代码。总而言之，前期设计就是一个叠加成功几率的过程。

2. 每个开发团队都需要进行软件架构

上述的内容适用于每一个开发团队，从一个单人团队到数百人的分布式团队。设置起点和方向其实就是要建立技术领导力。如果做不到这一点，就可能出现混乱：结构混乱的代码库（典型的“大泥球”），难以理解，难以维护，质量不达标，如性能、伸缩性或安全性。简而言之，任何一个开发团队都需要技术领导力。

3. 软件架构师要会写代码、指导他人以及参与协作

在大部分人看来，软件架构师就是给开发团队下达指令的人，就像接力赛中跑第一棒的人。但事实不是这样的，现代的架构师喜欢编码、指导他人并参与协作。我所遇见的好架构师也都是好的开发者，他们仍然喜欢编码，最起码他们并不想放弃编码工作。

因为变化太快，人们很容易就与技术失之交臂。但我认为软件架构师应该是“建筑大师”，在必要的时候他们仍然可以写代码。作为团队的一份子，编码会让架构师的工作变得更容易一些，因为编码有助于架构师理解系统，而且团队的其他成员会真正把架构师当成是同事。

需要注意的是，软件架构师不一定要指定某个人来担任。刚开始可以这样做，但其实也可以由多个人共同承当这个角色。 但要注意，建立协作式的技术领导力并不是件轻而易举的事。软技能本来就不是很轻松就能获得的。

我曾经组建 2 到 5 个人的架构师小组，让他们来设计软件系统，但他们在与技术和设计决策方面无法达成共识。在极端情况下，个性冲突会导致小组解散。关键是要了解你的团队，并确保应用了恰到好处的技术领导力。

     4. 不一定非要用 UML
     传统的软件架构通常包含大量的 UML 模型图，试图充分展现软件系统的每一个细节。可惜的是，建模和 UML 在很大程度上与前期“大设计”相耦合，而这些技术在近几年已经过时了。现在完全不懂 UML 的软件开发团队比率在逐步上升。

现如今，大部分人只是“在白板上画几个方块和线条”，并将其作为沟通想法的手段。在过去几年，我参与过的软件架构小组画过大量这样的图表，我把它们拍成照片，有好几个 G。我敢说，从行业角度来讲，我们已经散失了软件架构的沟通能力。我见过不计其数的图表，它们有些是随机着色方块和线条的组合，模糊不清，难以辨认。如果一个团队无法就软件架构进行沟通，那么就无法设置起点和建立技术领导力。

我建议使用“C4 模型”来进行软件架构方面的沟通——上下文（Context）、容器（Containers）、组件（Components）和代码（Code）。其本质是创建一系列结构化、可伸缩的图表来描述软件系统。为每一个软件系统创建一个上下文图表，用于描述软件系统与真实世界之间的关系。然后放大系统边界，让内部的容器突显出来——容器就是可部署、可运行的实体，比如运行在浏览器上的单页应用、服务器端的 Web 应用、微服务、数据库实例，等等。如果有必要，可以再将每个容器放大，让容器内部的组件突显出来。最后，你也可以放大组件，让代码级别的元素（类、接口、函数、对象等）也突显出来。C4 模型独立于具体的表示方法，虽然我倾向于使用简单的“方块和线条”，但使用 UML 来表示也是可以的。

www.4model.com 提供了更多的信息、视频、示例图表和工具链接。如果你的团队正纠结于软件架构沟通方面的问题，那么可以看看这些资料。

5. 好的软件架构是敏捷的

现在仍然存在一种误解，认为“架构”和“敏捷”之间是一种竞争和冲突的关系。但其实不是的。相反，好的软件架构也是敏捷的，它有助于应对业务变更，不管是需求变更、业务流程变更还是混合变更。当然，什么才是“好的架构”仍然有待商榷，但我认为，好的架构与好的模块化息息相关。如果你曾经有过在“大泥球”上进行变更的痛苦经历，那么你就会知道，好的代码库结构（好的模块化）是多么的重要。

现如今，很多团队都存在一个很大的问题，他们采用了一种叫作“架构中立的设计”，George Fairbanks 在他的“Just Enough Software Architecture”一书中对此进行了描述。换句话说，他们采用了一种不需要考虑权衡因素的架构风格。在现实中，开发团队使用微服务架构代替单体代码库。但实际上，他们有可能是创建出了一种“分布式的大泥球”，可见软件设计和分解过程是多么的重要，不管是要构建一个单体还是一个微服务架构的系统。敏捷和好的软件架构不是那么容易就能实现的，它需要一些精巧的设计，也需要作出一些权衡。这也再次说明为什么设置起点和建立技术领导力是如此的重要。

关于 C4 模型的一些解释
     C4 模型是来自 software architecture for developers 一书的定义，指的是 Context 上下文场景、Container 容器、Component 组件和 Classes 类（或者 Code 代码），意思指一个软件架构是由这些模型呈树形结构组成。

关注代码仍然是大多数软件开发生命周期中关注的焦点，这是有一定道理，因为代码是最终交付。但如果你不得不向别人解释关于系统是如何工作的，你会从代码开始解释吗?

确实代码并不能讲述系统的整个故事，在缺乏文档的情况下，人们通常会开始在白板上或纸上用图框和线条解释系统的主要构建块是什么，它们是如何连接的。而使用 Microsoft Visio, Rational Software Architect 或 Sparx Enterprise Architect 等专业工具又比较复杂。

更好的办法是在不同的抽象层次创建不同的图 diagram，一个简单的图 diagram 比复杂的图能够更有效表达描述。下图是 C4 模型的示意图：

类 Class: 这是面向对象世界常用, 类是我们系统最小的构建模块。

组件 Component: 一个组件可以认为是由一个或多个类组成的逻辑组，比如一个审计 audit 组件或授权服务能够用于决定资源的访问是否被允许，组件典型地由许多协同类组成。微服务架构可以认为是一种组件。

容器 Container: 一个容器代表组件执行或驻留的地方，这可能是一个Web容器或应用服务器，也可以是富客户端应用或数据库，容器是做为系统一部分启动的，容器之间通讯是通过远程接口如 SOAP web service, RESTful interface, Java RMI, Microsoft WCF, messaging等进行， Docker 可以认为是一个这样的容器。

Context/系统System: 一个系统是一个高层次抽象和代表，一个系统由多个单独的容器组成，比如财务系统，银行系统或网站系统等。

以上解释来自 jdon.com。

相关文章链接：
    https://www.infoq.com/articles/brown-are-you-a-software-architect
    https://www.infoq.com/articles/architecture-five-things
    http://www.jdon.com/artichect/c4-model.html