用户您好!请先登录!

六边形架构

六边形架构

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

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

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

1. 定义核心概念

借鉴六边形架构,可以定义业务逻辑的三大概念分别是实体存储库交互器

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

2. 切换数据源

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

例如可以在 2 小时内就将数据读取从一个 JSON API 切换到一个 GraphQL 数据源上。

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

Netflix 的六边形架构实践

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

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

3. 隐藏数据源细节

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

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

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

Netflix 的六边形架构实践

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

4. 测试策略

开始尝试六边形架构时,就知道需要提出一种测试策略。要提升开发速度的先决条件就是拥有可靠且非常快的测试套件。

可以在三个不同的层上测试应用:

  • 交互器,业务逻辑的核心存在于此,但与任何类型的持久层或传输层无关。我们用上了依赖注入,并 mock 任意类型的存储库交互。在这里我们详细测试业务逻辑,大部分测试都位于此处。
Netflix 的六边形架构实践
  • 数据源,以确定它们是否与其他服务正确集成,它们是否对接上存储库接口,并检查它们在出现错误时的行为。我们试着尽量减少这些测试的数量。
Netflix 的六边形架构实践
  • 具有遍及整个栈的集成规范,从 Transport/API 层到交互器、存储库、数据源以及重要的下游服务全部包含在内。这些规范测试的是我们是否正确“布线”了一切。如果一个数据源是一个外部 API,我们将命中该端点并记录响应(并将其存储在 git 中),从而让我们的测试套件可以在每次后续调用时快速运行。我们不会在这一层进行广泛测试,通常每个域动作只有一个成功场景和一个失败场景。
Netflix 的六边形架构实践

不用测试存储库,因为它们是数据源实现的简单接口;较少测试实体,因为它们是定义了属性的普通对象。

5. 延迟决策

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

六边形架构的最大优点在于,它可以让我们的应用程序灵活适应未来需求。

行走的code
行走的code

要发表评论,您必须先登录