使用 C4 模型绘制分布式架构图

“我读到过 C4 最适合单体架构，不太适合分布式架构”……这种说法我经常看到，但事实并非如此。C4模型是基于一小部分抽象概念的分层图表集合。它与 UML、ArchiMate 或临时白板草图相比，并没有什么特别之处，使其更适合或更不适合分布式架构。问题实际上在于工具，以及我们无法超越静态 PNG 文件进行思考。

如果您遵循康威定律，并且分布式架构的不同部分由不同的团队负责，那么这篇文章可能不适合您。这篇文章真正针对的是构建分布式单体架构的团队——一个团队，大量可单独部署的微服务和/或lambda表达式，步调一致的部署等等。这些架构在C4模型容器级别往往包含大量元素和关系，因此很难创建一个清晰易懂、全面的容器图。这条推文很好地总结了这种情况。

“通过无服务器，您可以部署您的 UML 协作图！”

任何包含 20 个以上（甚至更少）元素的图表都会很快变得复杂，难以清晰地表达你想要表达的内容。复杂的架构必然会导致图表的复杂性。

一个例子

这是一个过于简化的例子（请不要创建一个实际上只是脆弱的同步服务相互通信链的分布式架构！），但我想用这个例子来说明一些关于绘制图表的要点。许多团队最初会通过绘制一张展示其架构整体的图表来解决这个问题——也许会展示构成软件系统的所有容器及其外部依赖项。

当然，这张图还不错，而且这种方法对于较小的软件系统来说也很好用。但一旦服务数量达到 10 个、20 个甚至 100 个，它就会很快失效。虽然我们理想情况下希望创建一个图表来展示所有内容，但在很多情况下这并不可行。这种图表绘制方法不具备可扩展性。不过，你还是有一些选择的。

选项 1：创建多个较小的图表

其中一个选项是创建多个图表来展示整体故事的子集。您可以创建图表来展示单个域、有界上下文、业务能力、特性等等。或者，您可以创建图表来关注单个服务及其直接的传入/传出耦合。以下示例仅关注“服务 1”，而不是展示所有容器。

这样做确实会丢失一些“全局”，但这张图更容易理解，因为它的范围更窄。这种方法的问题与我在“图表即代码 2.0”中概述的问题相同……我们需要在多个图表中重复元素/关系，并且需要一种策略来在情况发生变化时保持它们同步。

这就引出了工具、图表与建模的争论。我之前就说过：我们需要停止使用通用的图表工具（例如 Visio 等）来绘制软件架构图，并且在使用 PlantUML、C4-PlantUML、Mermaid 等工具手工绘制图表之前也应该仔细考虑。

使用任何“模型 + 视图”工具都可以轻松创建上图，该图重点关注“服务 1”。例如，使用 Structurizr DSL，一旦定义了整体模型，就可以像这样创建上图：

views {
  container softwareSystem {
    include user ->service1->
  }
}

这表示“创建一个容器视图，显示用户、服务 1 以及与服务 1 直接相关的所有内容”。它还通过Structurizr CLI 的导出命令兼容多种图表格式。以下是上述图表的 PlantUML 版本，由相同的 Structurizr DSL 代码创建。

“模型 + 视图”工具提供了一种快速简便的方法，可以从模型中讲述不同的故事，同时保持所有生成的图表同步。Structurizr DSL 和 CLI 是免费开源的，而且过去 20 多年来任何优秀的 UML 工具都应该提供此功能，尽管用户体验截然不同。建模并非新鲜事物，我们真的不应该为了追求“敏捷”而将其抛弃。

选项 2：使用不同的可视化格式

尽管我们拥有如此强大的计算能力，但有些团队“只想把 PNG 图像嵌入到 Confluence 中”，这仍然让我感到惊讶。当然，还有其他文档工具可用。

传统的静态图表非常适合沟通，但它们不应该成为你工具箱里唯一的工具。一旦你放弃对静态 PNG 图像的执念，跨越鸿沟，你可能会发现其他更适合讲述故事的可视化格式。

例如，交互式力导向图更适合展示和探索大量数据。像D3.js这样的工具虽然学习起来比较困难，但相对来说比较简单。

（是的，发布交互式图表的静态截图的讽刺意味我并没有忽视，所以这里是交互式版本的链接）

另外，还有像Ilograph这样的工具，它提供了一种使用交互式 UI 导航模型的方法。

（如果您不喜欢手动编写 Ilograph 的 YAML 定义，可以使用 Structurizr DSL 到 Ilograph 导出）

概括

总而言之，C4 模型适用于绘制分布式架构图，其适用性丝毫不逊于其他任何替代方案。绘制大型单体应用程序内部的组件图时，您也会遇到同样的问题。这些问题与图的大小和复杂性有关。如果一个包含十几个方框的图难以理解，那就不要画一个包含十几个方框的图！

相反，应该从图表转向建模，思考你想要讲述的故事是什么，并探索技术如何帮助你实现这一目标。如果你愿意跨越图表的鸿沟，那么“图表即代码 2.0”将是一个非常强大的方法。