Kiến trúc của FAANG 2 - Netflix Architect

Tiếp tục phần 1, bài này tiếp tục giới thiệu về kiến trúc của Netflix

Netflix là công ty đầu tiên thành công trong việc migrate từ monolithic sang microservices. Họ phải mất hơn 2 năm để thực hiện việc migrate này. Trong quá trình xây dựng hệ thống, các kĩ sư của Netflix phát triển rất nhiều platform như Hystrix, Mantis, Genie… Netflix thành lập Netflix OSSC, nơi các platform này được open sources, giới thiệu tới cộng đồng. Đây là cách làm khá phổ biến của các big tech đến từ Silicon Valley, như Linkedin với Kafka, hay Google với Kubernetes

Microserice Architect

Netflix backend sử dụng kiến trúc microservice, mỗi service làm những tác vụ riêng từ login, signup, billing đến video transcoding, recommendation…

Nếu nhìn overview, thì Netflix vẫn follow theo best practice của Microservice, các service được expose qua API, được manage bởi API Gatewat Service.

Request từ client đến AWS ELB rồi forward tới API Gateway. Netflix API đóng vai trò là front door của hệ thống, hỗ trợ hơn 1000 device types và handler 50K+ requests/s. Tuy nhiên Netflix không sử API Gateway built-in của AWS hay những platform API Gateway thông dụng như Kong API, họ tự phát triển một API Gateway riêng gọi là Zuul làm nhiệm vụ dynamic routing, monitoring, resiliency, security. Cơ bản tính năng của Zuul cũng giống như các platform API Gateway khác, nhưng nó được thiết kế đặc thù cho nền tảng online streaming

Hãy bắt đầu bằng scenarios sau để hiểu được cách hoạt động của Netflix

Khi user search một phim ví dụ Spider Man, user có được những thông tin như Tên, Diễn viên, thể loại… rồi bấm nút Play

Request này được qua API Gateway Zuul rồi forward tới Application API (Search API, Discovery API, Play API…) Các application API này sử dụng Graph API, dùng GrapQL để query dữ liệu từ các microserivce, hoạt động giống như Orchestration layer

Bởi vì 1 thông tin mà user query ở trên là dữ liệu cấu trúc cây, Movie data owner bới serivice movie, production owner bởi service production. Application API sử dụng GraphQL để tổng hợp info từ tất cả các service liên quan để trả về cho người dùng

Nói sơ qua về GraphQL, technique đằng sau Netflix application API (lên google đầy) nhưng giải thích đơn giản kiểu giaosucan’s blog như sau

A e thiên địa hội rất quan tâm đến các JAV Idol, ví dụ như Emi Fukada, thông tin về em ý có thể query từ các trang như R18 , DMM, Tokyo Hot bằng API.

ví dụ

https://api.dmm.xx/affiliate/v3?code=MIMK-101

Nó sẽ trả về thông tin dạng json tá lả như tên diễn viên, tên phim, năm sản xuất, hãng sxx.. Và có nhiều thông tin thừa, khiến dev phải thêm 1 bước xử lý để lấy những thông tin cần thiết. Thế nên kĩ sư của Facebook đã phát triển GrapQL cho phép developer có thể lấy chỉ những thông tin họ cần trong query

Ví dụ

jav {

 code

 actress

 year

}

Thì GraphQL trả về đơn giản gọn nhẹ

jav {

 code: MIMK-101

 actress: Emi fukada

 year: 2022

}

Nhờ đó Netflix Application API có thể dễ dàng extract được thông tin cần thiết từ nhiều service khác nhau để trả về cho người dùng

Stateless microservice

Sau khi request được gửi tới các services, svc này sẽ access vào data store để lấy dữ liệu trả về cho Application API để tổng hợp. Phần lớn Netflix services là stateless và có thể call lẫn nhau. Vì dụ service Movie call tới service Production, service Production gọi tới service Talents .. Như vậy nếu như một service bị lỗi dẫn tới cascading failure . Ví dụ như service talents (get info diễn viên) bị lỗi, dẫn tới service production không lấy được data khiến service movie cũng đi theo. Trên GUI, user sẽ thấy loading quay quay liên tục không thấy kết quả –> bad user experiences

Do đó, Netflix đã phát triển Hystrix, Latency and Fault Tolerance for Distributed Systems, mục đích là quản lý communication giữa các service, isolate những service lỗi.

Hystrix implement một microservice pattern rất thông dụng gọi là Circuit Breaker. Đọc giải thích về pattern này trên GG xcmnd là mụ hết đầu óc

Hiểu theo kiểu giaosucan’s blog là như thế này

Giữa 2 service Movie và Production sẽ nhét vào 1 cái cầu chì, cái cầu chì này sẽ healcheck service Production độ xx giây check 1 lần. Nếu health check OK, thì sẽ cho Movie call Production thoải mái. Còn không OK tức là service Production ngỏm, thì ngắt kết nối luôn (như sập aptomat), đem thằng Production đi cách ly luôn, rồi dán cái biển “Đã cách ly vì Covid” trước nhà, service Movies nhìn thấy biển thì sẽ không bấm chuông chờ mở cửa nữa, return “Production not available luôn”, nhờ đó user sẽ biết ngay kết quả mà không phải ngồi loading cả tiếng nữa. Tuy nhiên cách ly thì cũng chỉ 14 ngày thôi, cho nên cần có state "Half Open", kiểu như sau 14 ngày, lôi ra chọc mũi healthcheck một cái xem hết bệnh chưa, nếu ok thì mở để em nó hoạt động lại, không thì xích tiếp

Microservice DataStore

Datastore của netflix sử dụng Hadoop, ElasticSearch , Cassandra, được phát triển bởi Facebook , NoSQL database dùng trong hệ thống phân tán.Cụ thể datastore của Netflix được sử dụng thế nào, cách query ra sao đón đọc những phần sau