How Netflix Scales its API with GraphQL Federation (Part 1)

Netflix · 2020 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

Mảng Studio (sản xuất nội dung) có hàng trăm ứng dụng; dữ liệu và quan hệ nằm rải trong vô số microservice.
Hai cách các đội tự xoay xở: lớp gộp dùng một lần (BFF hoặc mid-tier) lặp lại code lấy dữ liệu; và materialized view dữ liệu của đội khác, nhanh nhưng lệch. Dữ liệu không nhất quán giữa các ứng dụng Studio là vấn đề hỗ trợ số một năm 2018.

Studio API: một graph GraphQL tập trung, mỗi field resolve bởi đúng một đoạn code nên ít lệch dữ liệu. Thành công lớn, rồi lộ nút thắt: đội Studio API xa domain nên schema kém; nối backend mới vào graph làm tay; một đội nhỏ gánh vận hành cho graph ngày càng lớn.
Đầu 2019 Apollo công bố đặc tả GraphQL Federation; Netflix thử và cộng tác với Apollo. Kiến trúc mới "Studio Edge":
- Domain Graph Service (DGS): service GraphQL do đội domain sở hữu, định nghĩa phần schema của mình (chuyển service cũ hoặc dựng mới).
- Schema Registry: lưu schema và thay đổi; kiểm schema hợp lệ, ghép được với các DGS khác, tương thích ngược; ghép thành schema thống nhất cho gateway. Dùng trong công cụ dev và CI/CD.
- Gateway: tách query của client thành query plan gồm các sub-query (tuần tự hoặc song song) tới DGS rồi gộp kết quả; overhead xấu nhất khoảng 10 ms.
- Type được "mở rộng" qua nhiều DGS (ví dụ Movie) nhờ @key (khoá chung như movieId) và resolver _entities mà mỗi DGS phải cài.
Sau một năm: 70 DGS, hàng trăm developer đóng góp và dùng (2020).

Muốn giữ một graph thống nhất cho người dùng API nhưng trả quyền sở hữu resolver về đội domain, như cách tách monolith trước đây.

API gộp tập trung giải quyết nhất quán nhưng biến đội sở hữu thành nút thắt khi số domain tăng.
Federation chuyển việc kiểm soát chất lượng schema sang registry tự động (hợp lệ, ghép được, tương thích ngược) thay vì một đội gác cổng.
Materialized view dữ liệu của đội khác đánh đổi nhất quán lấy tốc độ; không chấp nhận được cho luồng quan trọng.