架构图是软件设计的基本要素，也是软件开发过程中沟通和协作的基本工具。Spotify 拥有一个非常复杂的软件系统网络，数百个团队开发的数千个相互关联的软件系统组成了这个复杂的网络，所以我们需要一个简单的方法来让这些连接可视化。从技术层面上来看，我们可以用一个大型的图表来捕捉所有系统，但这样很难理解和浏览。我们需要一些在不同的抽象层次上观察架构的工具，从而做出好的设计决策，可持续地开发软件。
我们利用标准化的软件元数据模型创建了传达软件架构的通用语言，这是我们的解决方案的一部分。
Spotify 系统模式
为了围绕复杂的软件和目录进行推理和交流，我们引入了一种共享的语言和概念定义——系统模型 。Spotify 系统模型包含了一套核心实体和抽象，工程师可以使用这些实体和抽象来合成有关软件健康状况、所有权和依赖关系的数据。
我们认为，在软件和资源方面建立共识和术语可以增强沟通和协作，这对于 Spotify 这种规模的公司尤为重要。
Spotify 系统模型由下列三个核心实体组成：
-
API ：不同组件之间的边界，定义了这些组件之间的接口；
-
组件 ：单个软件块（例如，后端服务、网站、数据管道、库）；
-
资源 ：在运行时操作组件所需的基础设施（例如，数据库、虚拟机、存储桶）。
图 1.核心实体之间的关系
在目录中映射和跟踪软件组件的能力对我们至关重要，能让我们更好地了解软件的规模和发展。但是，随着单个组件目录的规模越来越大，组件会变得越来越难以理解、审查和相互关联。因此，我们引入了一些额外的抽象，来帮助我们理解更大范围的软件生态系统：
-
系统 ：合作来执行某种功能的实体的集合；
-
领域 ：与部分业务相关的实体和系统。
通过将这个模型表达为元数据，我们能够创建软件目录，从而跟踪生态系统中的组件、所有权、依赖关系和生命周期。
图 2. 与核心实体相关的域和系统。
克服软件可视化的挑战
Spotify 的员工喜欢使用白板!在实行远程办公之前，我们办公室的白板上经常画满“方框和箭头”。你如果好奇白板上的内容，就需要请教白板旁边的员工，这些方框代表什么？它们指的是同一件事吗？箭头表示的是依赖还是信息流？白板图乍一看很简单，但如果没有上下文或相关解释就很难理解。
对于小团队来说，在白板上画图表可能就够了，例如，参加头脑风暴会议、或是在会议室里绘制现有系统的交互。但在白板上画图不可扩展，随身携带白板来传播知识也不现实，所以白板是有物理空间限制的。对于像 Spotify 这样偏好分布式方法的公司来说，只使用白板是不够的。即使我们把图表转换为数字工具，如果没有约定好软件可视化的方法，问题就依然存在。软件可视化并不是新问题，它有很多解决方案，其中最著名的是统一建模语言（UML）。
我们需要一种轻量级的可视化软件架构的方法，从而优化人与人之间的交流。我们想要一种只需很少的上下文就能理解软件的图表。在查看了工程师目前正在使用的软件后，我们发现解决方案就在眼皮底下：C4 模型。
利用 C4 模型来创建 Spotify 图表
C4 模型是一种轻量级的、简单的软件架构可视化方法。除了概述了一些抽象概念之外，C4 还定义了绘制软件系统图的标准符号和最佳实践。总的来说，它为大家提供了不错的指导，确保软件图表易于理解，并且能够在没有额外上下文的情况下独立存在。C4 中和了“点对点”的“方框和箭头”的优点，又没有过于正式，正好符合我们的需求。
C4 附带了一组软件抽象，那么如何在 Spotify 系统模型中把 C4 和我们自己的抽象一起应用呢？因为不想从零开始，所以我们保留了 C4 符号和最佳实践，并将抽象层替换为 Spotify 系统模型。因此，我们必须重新定义这套用于记录架构和系统设计的核心图表：
-
系统全景图 ：描述一组相关的系统如何连接，以及依赖于哪些外部系统（例如，一个团队拥有的所有系统或一个域中的所有系统）；
-
系统上下文图 ：描述系统如何适应更大的上下文的依赖关系、依赖项和用户；
-
系统组件图 ：描述如何从单个组件构建系统（在 C4 中为容器图）。
图 3. Spotify 图与 C4 图的对比，基于 c4model.com 的一张图片。C4model.com 由Simon Brown 所有，点击 这里可查看网站许可信息。
在 Backstage 中自动化架构图
有了软件的目录以及软件元数据和组件的详细信息，我们就可以在图表中应用软件生态系统的自动渲染和交互式浏览。这样，我们就可以使用同一种语言和模型来传达和可视化整个架构。
自动化架构图的一大好处是，它们会始终与元数据中表达的有意设计保持同步；不用随着系统的发展更新这些图，也不需要担心可视化是否过时。
Backstage 中的可扩展插件系统可以让我们轻松在系统页面上添加架构选项卡 ，该选项卡渲染系统的 Spotify 组件图。这些图表是用软件元数据自动生成的。外部系统从图表链接，可以轻松浏览不同的系统图。
C4 的优点
在 Backstage 中提供系统模型非常有利于发现问题、了解生命周期、所有权和软件组件之间的关系以及自动生成软件可视化图。系统模型及其可视化能够让我们使用通用语言来生成系统设计——既适用于新系统，也适用于现有系统的演变——这非常有利于沟通，也能改善跨团队合作。
此外，使用 C4 可视化软件提供了一个高级概述，可用于生成关于重复模式、技术债务和其他学习的见解。这非常有利于团队新成员和外部的利益相关者了解软件系统。因为自动化图表能让我们以交互方式穿越生态系统，所以我们可以轻松理解系统间的相互联系。
应用 C4
如果你觉得软件太复杂，难以理解，那么用图表将其可视化会很有帮助。拥有抽象模型对大规模理解软件架构至关重要，因此你可以使用现有模型，如 C4 或 Spotify 系统模型，或者创建一个适合特定需求的模型。
软件图表的标准符号也很重要，它可以确保图表被理解；C4 模型非常好用，如果你不想完全采用 C4 模型，可以以此为灵感。如果你打算采取下一步行动并自动生成图表，一定要确保获取软件的元数据并构建自己的软件目录。拥有这样的目录也能提高洞察力，从而帮助大家更好地规划软件操作和发展。
总结
随着 Spotify 的发展，软件的规模在变大，复杂性也在增加。我们需要工具来更好地理解和传输软件，而拥有标准的核心实体和抽象概念是基础要求。通过从 C4 模型中获得灵感并利用符号和最佳实践，我们能够利用 Spotify 系统模型构建易于理解且上下文最少的软件可视化。这种结合创造了一种能在整个组织内使用的共享语言，从而促进交流和决策并支持软件的发展。
原文作者：Renato Kalman、Johan Wallin
原文链接：Software Visualization — Challenge, Accepted - Spotify Engineering : Spotify Engineering
good