Netflix 的六边形架构实践

本文阐述了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 作业或从命令行触发。

Netflix 的六边形架构实践

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

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

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

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

5. 切换数据源

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

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

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

Netflix 的六边形架构实践

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

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

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

6. 隐藏数据源细节

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

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

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

Netflix 的六边形架构实践

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

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

7. 测试策略

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

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

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

Netflix 的六边形架构实践

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

Netflix 的六边形架构实践

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

Netflix 的六边形架构实践

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

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

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

8. 延迟决策

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

相关推荐