Netflix 的 API 架构演变历程

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

 𝐌𝐨𝐧𝐨𝐥𝐢𝐭𝐡 

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

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

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

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

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 服务，最后通过网关返回数据给客户端。

最终的架构图如下：

  译：等天黑

 作者：Alex Xu   

 希望对您有用！