Netflix 的六边形架构实践

随着 Netflix 原创内容的逐年增长，我们要构建一些可提升整个创作过程效率的应用。我们的一个大型部门，Studio 工程团队已经构建众多应用，去帮助从剧本制作到内容播出的全套流程，涉及的环节涵盖剧本内容获取、交易谈判和供应商管理，以及日程安排、简化生产流程等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

借鉴六边形架构，定义我们业务逻辑的三大概念分别是实体、存储库和交互器。

实体（Entities）指的是域对象（例如一部影片或一个拍摄地点），它们不知道自身的存储位置（不像是 Ruby on Rails 中的 Active Record 或者 Java Persistence API 那样）。

存储库（Repositories）是获取实体及创建和更改实体的接口。它们保存一系列方法，用来与数据源通信并返回单个实体或实体列表。（例如 UserRepository）

交互器（Interactors）是用来编排和执行域动作（domain action）的类——可以考虑服务对象或用例对象。它们实现复杂的业务规则和针对特定域动作（例如上线一部节目）的验证逻辑。

有了这三大类对象，我们就可以在定义业务逻辑时无需知晓或者关心数据的存储位置，也不用理会业务逻辑是怎样触发的。业务逻辑之外是数据源和传输层：

数据源（Data Sources）是针对不同存储实现的适配器（Adaptor）。数据源可能是 SQL 数据库的适配器（Rails 中的 Active Record 类或 Java 中的 JPA）、弹性搜索适配器、REST API，甚至是诸如 CSV 文件或 Hash 之类的简单适配器。数据源实现在存储库上定义的方法，并存储获取和推送数据的实现。

传输层（Transport Layer）可以触发交互器来执行业务逻辑。我们将其视为系统的输入。微服务最常见的传输层是 HTTP API 层和一组用来处理请求的控制器（Controller）。将业务逻辑提取到交互器后，我们就不会耦合到特定的传输层或控制器实现上。交互器不仅可以由控制器触发，还能由事件、cron 作业或从命令行触发。

六边形架构的依赖图向内收缩

在传统的分层架构中，我们所有的依赖项都会指向一个方向，上面的每一层都会依赖自己下面的层。传输层会依赖交互器，而交互器会依赖持久存储层。

在六边形架构中，所有依赖项都指向中心方向。我们的核心业务逻辑对传输层或数据源一无所知。但传输层仍然知道如何使用交互器，数据源也知道如何对接存储库接口。

这样，我们就可以为将来切换到其他 Studio 系统的更改做好准备，并且当需要迈出这一步时，我们很容易就能完成切换数据源的任务。

切换数据源的需求比我们预期来得更早一些——我们的单体架构突然遇到一个读取瓶颈，并且需要将某个实体的特定读取切换到一个在 GraphQL 聚合层上公开的新版微服务上。这个微服务和单体保持同步，数据相同，并且它们从各个服务中读取时产生的结果也是一致。

我们设法在 2 小时内就将数据读取从一个 JSON API 切换到一个 GraphQL 数据源上。

我们之所以能如此快地完成这一操作，主要归功于六边形架构。我们没有让任何持久存储细节泄漏到业务逻辑中。我们创建了一个实现存储库接口的 GraphQL 数据源。因此，只需要做简单的一行代码更改，即可开始从新的数据源读取数据。

通过适当的抽象，很容易更改数据源

到这个时候，我们就知道使用六边形架构没错了。

单行代码更改有一大优势，那就是它可以减小发布风险。如果下游微服务在初始部署时失败，回滚也会非常容易。这也让我们能解耦部署和激活作业，因为可以通过配置来决定使用哪个数据源。

这种架构的一大优势是让我们能封装数据源的实现细节。

我们遇到这样一种情况：有一次，我们需要一个尚不存在的 API 调用——有一个服务用一个 API 来获取单个资源，但没有实现批量获取。与提供该 API 的团队交流后，我们得知这个批量获取端点需要一些时间才能交付。因此，我们决定在这个端点构建的同时，使用另一种方案来解决这个问题。

我们定义了一个存储库方法，该方法可以在给定多个记录标识符的情况下获取多个资源——并且该方法在数据源的初始实现会向下游服务发送多个并发调用。我们知道这是一个临时的解决方案，数据源实现的下一步改进是在批量 API 构建完毕后切换到新 API 上。

我们的业务逻辑不需要了解特定的数据源限制

这样的设计让我们能继续开发以满足业务需求，同时不会积累太多技术债，也无需事后更改任何业务逻辑。

当我们开始尝试六边形架构时，就知道需要提出一种测试策略。要提升开发速度的先决条件就是拥有可靠且非常快的测试套件。我们不认为这是锦上添花，而是必要条件。

我们决定在三个不同的层上测试应用：

我们测试了交互器，业务逻辑的核心存在于此，但与任何类型的持久层或传输层无关。我们用上了依赖注入，并 mock 任意类型的存储库交互。在这里我们详细测试业务逻辑，大部分测试都位于此处。

我们测试数据源，以确定它们是否与其他服务正确集成，它们是否对接上存储库接口，并检查它们在出现错误时的行为。我们试着尽量减少这些测试的数量。

我们具有遍及整个栈的集成规范，从我们的 Transport/API 层到交互器、存储库、数据源以及重要的下游服务全部包含在内。这些规范测试的是我们是否正确“布线”了一切。如果一个数据源是一个外部 API，我们将命中该端点并记录响应（并将其存储在 git 中），从而让我们的测试套件可以在每次后续调用时快速运行。我们不会在这一层进行广泛测试，通常每个域动作只有一个成功场景和一个失败场景。

我们不会测试存储库，因为它们是数据源实现的简单接口；并且我们很少测试实体，因为它们是定义了属性的普通对象。我们会测试实体是否有其他方法（这里不涉及持久层）。

我们还有改进空间，比如我们将来可以不 ping 所依赖的任何服务，而是 100％依赖合同测试。有了上述方式编写的测试套件，我们可以 100 秒内在单个过程中运行大约 3000 个 specs。

能轻松在任何机器上运行的测试套件，它用起来非常棒，我们的开发团队可以在不中断的前提下做日常功能测试。

现在我们可以轻松将数据源切换到不同的微服务上。关键的一大好处是，我们能延迟一些关于是否以及如何存储应用程序内部数据的决策。根据功能用例，我们甚至可以灵活确定数据存储的类型——可以是关系型也可以是文档型。

当这个项目开始时，我们对正在构建的这个系统的了解是非常少的。我们不应该将自己锁定在一个会导致项目悖论和不明智决策的架构中。

我们现在做的决策符合我们需求，并且让我们能快速行动。六边形架构的最大优点在于，它可以让我们的应用程序灵活适应未来需求。

延展阅读：

https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749

点个在看少个 bug 👇