为什么netflix从大单体演进到联合网关了

Netflix 以其庞大的原创内容库而闻名。你是否曾想过支撑其运营的技术?

今天,我们将探讨 Netflix Studio API 架构的演进历程。下图展示了其 4 个阶段。

图片[1]-为什么netflix从大单体演进到联合网关了-编程社

1、大单体

早期,Netflix Studio 采用的是单体架构。

想象一下一个庞大的互联系统,所有组件都是一个统一代码库的一部分。

2、直接访问

随着 Netflix 的发展以及与更多的电影公司合作创作原创内容,这块巨石开始成为路障。

那么,下一步该怎么办?Netflix的工程师们将单体分割成微服务。

这种转变提高效率和自主性,它将其架构变成了一个服务网。

3、网关聚合层

但直接访问的效果却远非理想,为了克服这一难题,他们引入了网关聚合层。

他们构建了一个 API 网关,将所有服务绑定在一起为客户提供统一的前台。

这种设置非常适用于跨多个服务的用例。

试想一下,Studio 服务需要 3 个 API(如电影、制作和人才)来渲染前端用户界面,网关聚合层使之成为可能。

4、联合网关

网关聚合层本应带来秩序,但随着团队的壮大,服务的增多和领域复杂性的增加,开发网关聚合层变得越来越困难。为了解决这个问题,Netflix 使用 GraphQL 并引入了联合网关(Federated Gateway)。

这一策略允许领域专家管理自己的 “图”,同时为各种 Studio 应用程序提供统一、高效的访问点。

GraphQL 是 Federated Gateway 的核心。这种强大的查询语言使用户界面能在一次往返中准确获取所需内容。GraphQL 联合允许 Netflix 建立一个单一的 GraphQL 网关,从所有其他 API 获取数据。

从单体到联合网关的过程说明,系统架构应适应不断动态增长的业务需求。

我们也不应该单纯地去复制 Netflix 和 Google 等巨头的基础设施,因为这些需求我们可能永远也遇不到。无需过度优化我们不存在的问题。

© 版权声明
THE END
喜欢就支持一下吧
点赞97赞赏 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片

    暂无评论内容