Netflix Conductor: A microservices orchestrator
Bài tóm tắt Netflix 2016 3. Quy mô lớn Độ khó: Trung bình
Netflix · 2016 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc
Bài công bố mã nguồn mở Conductor.
Bối cảnh
- Content Platform Engineering chạy các quy trình nghiệp vụ bất đồng bộ trải qua nhiều microservice, có cái kéo dài nhiều ngày: nhận nội dung từ studio, ingest IMF, dựng title mới, encode và đẩy lên CDN.
- Trước đó các quy trình được điều phối tuỳ biến: pub/sub, gọi REST trực tiếp, và một database giữ trạng thái. Khi số service và độ phức tạp tăng thì không còn nhìn thấy quy trình.
Thay đổi chính
- Bỏ choreography ngang hàng, dùng orchestrator trung tâm. Theo Netflix, pub/sub chỉ ổn cho luồng đơn giản: luồng nghiệp vụ nằm rải trong code của nhiều app, các bên ngầm giả định về input/output và SLA của nhau, và gần như không trả lời được "phim này còn thiếu bước nào để setup xong".
- Workflow khai báo bằng JSON DSL có version (task worker và task điều khiển: fork, join, decision, sub-workflow); task definition giữ timeout, số lần retry, kiểu retry, chính sách khi hết giờ.
- Decider là state machine: mỗi sự kiện (task xong, task lỗi) thì ghép blueprint với trạng thái hiện tại để lên lịch task tiếp theo. Hàng đợi task là dyno-queues trên Dynomite; lưu trữ Dynomite, index thực thi trên Elasticsearch để tìm kiếm theo input/output.
- Worker là hàm stateless, idempotent, tự poll lấy việc. Poll cho phép worker tự điều tiết (backpressure) và autoscale theo độ sâu hàng đợi; Conductor có API xem lượng việc chờ của từng loại worker.
- UI hiện từng workflow: đường đã đi, thời điểm lên lịch/nhận/xong của mỗi task, lý do lỗi, số lần retry, host chạy.
- Bỏ Amazon SWF vì cần blueprint khai báo thay cho decider viết bằng code, cần UI, API đồng bộ khi cần, index để tìm workflow. Step Functions mới ra có vài tính năng tương tự.
- Số liệu: dùng gần một năm, đã điều phối hơn 2,6 triệu process flow (2016).
Vì sao
- Câu hỏi "quy trình đang ở đâu" cần một nơi giữ trạng thái; khi trạng thái nằm rải trong nhiều service, không ai trả lời được.
Bài học cho SWE
- Choreography bằng sự kiện giảm coupling lúc đầu nhưng làm luồng nghiệp vụ vô hình; orchestration tập trung đổi lại một thành phần trung tâm phải sẵn sàng cao, nhưng có trạng thái, retry, timeout và UI ở một chỗ.
- Worker kéo việc (pull) thay vì bị đẩy (push) là cách rẻ để có backpressure và autoscale theo hàng đợi.
- Retry ở orchestrator chỉ an toàn khi task idempotent.
Liên quan
- Event-driven, message queue và Kafka · Monolith và microservices — đi và quay lại
- Quan sát workflow bất đồng bộ ở Netflix 2021: Netflix 2021
- Hàng đợi ưu tiên cho workflow media ở Netflix 2022: Netflix 2022
#orchestration vs choreography#workflow engine#JSON DSL#Decider#state machine#dyno-queues#Dynomite#Elasticsearch#worker polling#idempotent#Amazon SWF#Step Functions
Được nhắc tới trong
Công ty (1)