Spotify是如何表达软件架构设计？

Spotify是如何表达软件架构设计？
架构图是软件设计的基础，也是软件开发沟通和协作的基础工具。在 Spotify，我们拥有一个极其复杂的网络，由数百个团队拥有的数千个相互关联的软件系统组成，因此有一种简单的方法来可视化这些连接是必不可少的。

虽然在一张大图中捕获我们所有的软件在技术上是可行的，但很难理解和导航。​​我们需要工具来查看不同抽象级别的架构，以便做出良好的设计决策并以可持续的方式发展我们的软件。

作为我们解决方案的一部分，我们利用标准化的软件元数据模型来创建用于通信软件架构的通用语言。 

Spotify 系统模型
为了能够围绕我们复杂的软件和目录进行推理和交流，我们引入了一种共享语言和概念定义——系统模型。Spotify 系统模型提供了一组核心实体和抽象，我们可以使用它们来合成有关我们的软件健康、所有权和依赖关系的数据。
在 Spotify，我们相信围绕软件和资源的稳固的共同理解和术语能够促进沟通和协作，这对于我们规模的公司的成功至关重要。
我们的软件使用三个核心实体建模：

• APIs：不同组件之间的边界，定义了这些组件之间的接口
• 组件：单个软件（例如，后端服务、网站、数据管道、库）
• 资源：在运行时操作组件所需的基础设施（例如，数据库、虚拟机、存储桶）

图 1. 核心实体之间的关系。

在目录中映射和跟踪软件组件的能力对我们来说非常有价值——它使我们能够更好地了解我们软件的规模和开发。但随着我们单个组件目录的规模不断扩大，这些组件变得越来越难以理解、审查和相互关联。出于这个原因，我们引入了一些额外的抽象来帮助我们理解更广泛的软件生态系统：

• 系统：合作执行某些功能的实体的集合
• 领域：与部分业务相关的实体和系统

通过将此模型表示为元数据，我们已经能够创建一个软件目录来跟踪我们生态系统中的组件、所有权、依赖关系和生命周期。

图 2. 与核心实体相关的域和系统。

解决软件可视化挑战
Spotifiers 喜欢使用白板！在我们采用Work From Anywhere之前，在办公室走动时经常会看到充满“方框和箭头”的白板。如果您好奇并想了解白板上的内容，您可能需要请坐在白板上的团队中的某个人向您解释这些方框和箭头。方框代表什么？它们都是同一个意思吗？箭头表示依赖还是信息流？白板图乍一看可能很简单，但如果没有上下文或解释，它们可能很难掌握。

尽管白板上的图表在较小的小组环境中可能就足够了，例如，头脑风暴会议或在会议室中绘制现有系统交互，但这不是一种可扩展的方法。随身携带白板来传播知识是不切实际的，因此它们被限制在物理空间中。对于像 Spotify 这样采用分布式优先方法的公司来说，白板并不总是足够的。即使我们将图表转换为数字工具，没有关于如何可视化我们的软件的约定，挑战仍然存在。软件可视化并
不是一个新问题，并且有很多解决方案——最著名的是统一建模语言 (UML)。

我们需要一种轻量级的方式来可视化软件架构，并针对人与人之间的交流进行优化。我们想要能够让我们以最少的上下文理解我们的软件的图表。我们查看了我们的工程师目前正在使用什么，并意识到解决方案就在我们的眼皮底下：C4 模型。

利用 C4 模型创建 Spotify 图表 
C4 模型是一种用于可视化软件架构的轻量级且直接的方法。除了概述一些抽象之外，C4 还定义了用于绘制软件系统图的标准符号和最佳实践。总体而言，它提供了良好的指导方针，以确保软件图表易于理解并且能够在没有额外上下文的情况下独立存在。C4 在临时的“盒子和箭头”和过于正式的标准之间取得了很好的平衡，就像手套一样适合我们的需求。
C4 带有一组软件抽象。那么我们如何在 Spotify 系统模型中将它与我们自己的抽象一起应用呢？我们不想重新发明轮子，所以我们保留了 C4 符号和最佳实践，并将其抽象层替换为 Spotify 系统模型。因此，我们不得不重新定义用于记录架构和系统设计的核心图集：

• 系统格局图：描述一组相关系统、它们如何连接以及它们依赖的外部系统——例如，一个小队拥有的所有系统或域中的所有系统
• 系统上下文图：描述系统如何适应更大的依赖关系、依赖项和用户上下文
• 系统组件图：描述如何从单个组件构建一个系统（在 C4 中称为容器图）

图 3. Spotify 图与 C4 图的比较，基于来自 c4model.com 的图像。

在 Backstage 中自动化架构图 
拥有我们软件的目录以及其元数据和组件的详细信息，使我们能够在图表中应用我们的软件生态系统的自动渲染和交互式浏览。这使我们能够使用通用语言和模型来交流和可视化我们的整个架构。
自动化架构图的一大好处是它们将始终与元数据中表达的有意设计保持同步；随着系统的发展，无需更新这些，也无需质疑可视化是否已过时。
Backstage 中的可扩展插件系统使我们能够轻松地将架构选项卡添加到系统页面，该选项卡呈现系统的 Spotify 组件图。这些图表是使用软件元数据自动生成的。外部系统从图表链接，可以在不同系统图表之间轻松导航。

C4的好处
在 Backstage 中提供系统模型对于发现、了解生命周期、所有权和软件组件之间的关系以及自动生成软件可视化图表非常有帮助。系统模型及其可视化还允许我们使用通用语言生成系统设计——既适用于新系统，也适用于现有系统的演变——这有助于沟通并改善跨团队协作。
此外，使用 C4 可视化软件提供了一个高级概述，可用于生成有关重复模式、技术债务和其他学习的见解。这对于入职目的非常有价值，无论是对于团队中的新加入者还是外部利益相关者。由于自动化图表允许我们以交互方式遍历生态系统，它也使理解系统如何互连变得容易。

应用 C4
如果您因为太复杂而难以理解您的软件，那么用图表将其可视化会很有帮助。由于拥有抽象模型对于大规模理解软件架构至关重要，因此您可以使用现有模型，如 C4 或 Spotify 系统模型，或创建一个适合您特定需求的模型。软件图的标准符号也很重要，以确保它们是可理解的；C4 模型做得非常好，如果你不想完全采用它，它可以作为灵感。如果您要采取下一步并自动生成图表，请确保您捕获有关您的软件的元数据并构建您的软件目录。拥有这样的目录还将帮助您获得洞察力并更好地规划如何操作和发展您的软件。

结论
随着 Spotify 的发展，我们软件的规模和复杂性也在增长。我们需要工具来更好地理解和交流我们的软件，而拥有标准的核心实体和抽象是基础。通过从 C4 模型中获取灵感并利用符号和最佳实践，我们能够利用 Spotify 系统模型创建易于理解且上下文最少的软件可视化。这种组合创造了一种在整个组织中使用的共享语言，以帮助进行沟通、帮助决策并支持我们软件的发展。