Netflix的六边形架构实践

2020 年 3 月 26 日

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。


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


延迟决策


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


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


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


英文原文:


Ready for changes with Hexagonal Architecture


2020 年 3 月 26 日 07:004059
用户头像

发布了 490 篇内容, 共 175.3 次阅读, 收获喜欢 1010 次。

关注

评论 3 条评论

发布
用户头像
很好的设计!
2020 年 03 月 29 日 08:52
回复
用户头像
与干净架构类似,都是以业务逻辑核心,但干净架构更加完善和清晰。
干净架构最佳实践 https://blog.jaggerwang.net/clean-architecture-in-practice/
2020 年 03 月 26 日 09:44
回复
用户头像
方法论不错
2020 年 03 月 26 日 09:01
回复
没有更多评论了
发现更多内容

第三代人工智能基础设施背后,是一次技术应用的常识普及运动

脑极体

阿里三面惨遭被虐,spring,jvm,mybatis,并发编程等一窍不通

Java架构之路

Java 程序员 架构 面试 编程语言

互联网新规鼓励保险与大数据、区块链等新技术融合!业内呼吁配套产品管理制度尽快出炉

CECBC区块链专委会

互联网金融

期权代持的“坑”里,加拿大人也在 | 法庭上的CTO(11)

赵新龙

CTO 法庭上的CTO

生产环境全链路压测建设历程之十 淘宝网2013年的建设过程

数列科技杨德华

有了Git这个功能,再也不需要依赖IDE了!

云流

编程 架构

没弄懂这些Java基础,简历上千万别写熟悉:异常+反射+注解+泛型

小Q

Java 学习 编程 面试 基础

赶紧看!阿里架构师必备“绝杀版”Tomact架构笔记堪称绝技

比伯

Java tomcat 编程 架构 程序人生

Java并发编程:多线程如何实现阻塞与唤醒

码农架构

Java并发

盘点 2020 | 坚持写技术博客一年能有多少收获!

小傅哥

Java 小傅哥 技术人 盘点2020

BAT等大厂面试复习资料文档整理:ActiveMQ+redis+Spring+高并发多线程+JVM

Java架构之路

Java 程序员 架构 面试 编程语言

SSO的通用标准OpenID Connect

程序那些事

OAuth 2.0 程序那些事 授权框架 安全框架 openid

1428万的Adobe采购纠纷 | 法庭上的CTO(10)

赵新龙

CTO 法庭上的CTO

如何在软件发布计划中自动化语义化版本与变更日志

华为云开发者社区

自动化 工具 发布

C语言服务器编程必备常识

MySQL从删库到跑路

c

JVM从概述到调优图文详解,含思维脑图深度剖析!

Java架构师迁哥

架构作业--大数据

Nick~毓

架构师训练营 Week8 - 课后作业

极客大学架构师训练营

数据类型第2篇「字典和集合的原理和应用」

清菡

测试开发

【小菜学网络】数据链路层概述

fasionchan

网络编程 计算机网络 网络协议 TCP/IP

即构SDK12月迭代:新增多项质量回调,互动白板、云录制SDK同步更新

ZEGO即构

SpringBoot魔法堂:应用热部署实践与原理浅析

云流

设计原则 框架 spring Boot Starter

架构之书:雄伟与《Domain Driven Design》

lidaobing

架构 领域驱动设计

LeetCode题解:429. N叉树的层序遍历,BFS,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

手把手教你免费获取正版 Jetbrains 全家桶 License

郭旭东

ide JetBrains

甲方日常 68

句子

工作 随笔杂谈 日常

Spring Boot 集成 Redis

噜噜猫

Spring Boot

BATJ面试常被问到的100+题:Spring+微服务+SpringMVC+MyBatis

Java架构之路

Java 程序员 架构 面试 编程语言

探营苏州数字人民币试点

CECBC区块链专委会

数字人民币

旷工三天被开除,公司赔偿十万五 | 法庭上的CTO(9)

赵新龙

CTO 法庭上的CTO

从零开始学习Java8 Stream,看这篇就够了

Silently9527

Java stream java8

Netflix的六边形架构实践-InfoQ