Netflix 的六边形架构应用

1. 从开始就高度集成

大约一年前，我们的 Studio 流程团队开始开发一款跨多个业务领域的全新应用。

当时，我们面临一项有意思的挑战：

一方面我们需要从头开始构建应用的核心，另一方面我们所需的数据分布在众多不同的系统之中。

我们所需要的一些数据，比如有关影片信息、制作日期、员工和拍摄地点的数据，分布于许多服务中。并且，它们使用的协议也各有不同，包括 gRPC、JSON API、GraphQL 等等。

对我们应用程序的行为和业务逻辑而言，已有数据非常重要。我们从一开始就需要高度集成。

早期的一款应用程序用来为我们的产品引入可见性，它被设计为单体架构。在领域知识体系尚未建立的情况下，单体架构可以实现快速开发和快速变更。后来，使用它的开发人员超过 30 人，有超过 300 个数据库表。

随着时间流逝，应用程序从涉及面广泛的服务演变成高度专业化的产品。在这样的背景下，团队决定将单体架构解构为一系列专用服务。

做出这一决策并非性能问题，而是要对所有这些领域设置界限，并让各个专属团队能独立开发针对每个特定领域的服务。

我们的新应用所需的大量数据依旧是之前的单体提供的，但我们知道这个单体将在某一天分解开来。我们不能确定具体时间，但知道这一时刻不可避免，所以需要做好准备。

这样的话，我们能在一开始利用某些来自单体的数据，因为它们仍然是可信来源；但我们也要做好准备，在新的微服务上线后立刻切换到这些数据源上。

我们需要有在不影响业务逻辑的前提下切换数据源的能力，因此我们需要让它们保持解耦状态。

我们决定基于六边形架构的原则来构建应用。

六边形架构的思想是将输入和输出都放在设计的边缘部分。不管我们公开的是 REST 还是 GraphQL API，也不管我们从何处获取数据——是通过数据库、通过 gRPC 还是 REST 公开的微服务 API，或者仅仅是一个简单的 CSV 文件——都不应该影响业务逻辑。

这种模式让我们能将应用程序的核心逻辑与外部的关注点隔离开来。核心逻辑隔离后，意味着我们可以轻松更改数据源的细节，而不会造成重大影响或需要在代码库重写大量代码。

我们还看到，在应用中具有清晰边界的另一大优势就是测试策略——我们的大多数测试在验证业务逻辑时，都不需要依赖那些很容易变化的协议。