本文阐述了Netflix是如何基于六边形架构去开发一款全新应用的。

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

1 从开始就高度集成

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

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

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

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

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

2 可切换数据源

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

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

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

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

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

3 利用六边形架构

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

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

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

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

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

4 定义核心概念

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

实体（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 系统的更改做好准备，并且当需要迈出这一步时，我们很容易就能完成切换数据源的任务。

5 切换数据源

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

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

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

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

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

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

6 隐藏数据源细节

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

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

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

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

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

7 测试策略

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

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

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

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

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