Netflix 的 API 架构演变历程

Netflix 以其松耦合和高度可扩展的微服务架构而闻名,Netflix API 的后端架构经历了 4 个主要阶段。

𝐌𝐨𝐧𝐨𝐥𝐢𝐭𝐡

Netflix 的 API 架构演变历程

𝐌𝐨𝐧𝐨𝐥𝐢𝐭𝐡 单体架构,各种各样的服务融合在一起,向外提供服务,大多数创业公司都是这么做的。

𝐃𝐢𝐫𝐞𝐜𝐭 𝐚𝐜𝐜𝐞𝐬𝐬

Netflix 的 API 架构演变历程

在这个架构中,客户端程序可以直接向不同的微服务发出请求。但是随着业务的发展,Netflix 拥有成百上千个微服务 ,加上服务与服务之间的相互调用,整个架构变得混乱和复杂。

𝐆𝐚𝐭𝐞𝐰𝐚𝐲 𝐚𝐠𝐠𝐫𝐞𝐠𝐚𝐭𝐢𝐨𝐧 𝐥𝐚𝐲𝐞𝐫

Netflix 的 API 架构演变历程

Netflix 开始引入网关聚合层,客户端应用展示的页面内容是很丰富的,想象一下,一个电影的页面,需要获取电影信息,制作人信息,以及演员信息,前端显示至少需要调用三个不同的 API。而使用网关来聚合不同后端服务的数据,只需要进行一次调用即可。

𝐅𝐞𝐝𝐞𝐫𝐚𝐭𝐞𝐝 𝐠𝐚𝐭𝐞𝐰𝐚𝐲

随着业务规模不断扩大,微服务越来越多,维护 API 聚合层变得越来越困难,另外一个问题是,不同后端服务的数据聚合逻辑不能够复用。

于是,Netflix 引入了灵活的联合架构 GraphQL Federation,它有三个主要组件。

  • DGS: 全称是 Domain Graph Service,一个独立的 GraphQL 服务,开发人员在 DGS 中定义 Schema,每个 DGS 服务由各个后端 API 团队自己管理,可以选择把现有的微服务对接到 DGS,或者直接转换成 DGS 服务。
  • Schema Registry:一个有状态的组件,保存每个 DGS 的全部的 Schema,并进行组合提供给网关。
  • GraphQL Gateway:主要负责为客户端提供 GraphQL 查询服务,把大的查询分解成更小的子查询,然后转发到对应的下游 DGS 服务,最后通过网关返回数据给客户端。

Netflix 的 API 架构演变历程

最终的架构图如下:

Netflix 的 API 架构演变历程

(0)
上一篇 2022年5月25日 上午12:56
下一篇 2022年5月27日 下午11:59

相关推荐

发表回复

您的电子邮箱地址不会被公开。

评论列表(1条)