Netflix 的六边形架构实践.docxVIP

Netflix 的六边形架构实践 大约一年前，我们的 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 系统的更改做好预备，并且当需要迈出这一步时，我们很简约就能完成切换数据源的任务。 切换数据源 切换数据源的需求比我们预期来得更早一些——我们的单体架构突然遇到一个读取瓶颈，并且需要将某个实体的特定读取切换