Netflix tiết lộ hệ thống ánh xạ hàng nghìn microservices theo thời gian thực

Phần mềm05 tháng 6, 2026·5 phút đọc

Netflix đã công bố chi tiết về hệ thống nội bộ có tên Service Topology, giúp tạo và cập nhật biểu đồ phụ thuộc trực tiếp cho hàng nghìn microservices. Hệ thống này kết hợp ba nguồn dữ liệu khác nhau để cung cấp cái nhìn toàn diện, giúp các kỹ sư giải quyết sự cố nhanh chóng và hiểu rõ hơn về cách các dịch vụ kết nối với nhau.

Netflix tiết lộ hệ thống ánh xạ hàng nghìn microservices theo thời gian thực

Netflix tiết lộ hệ thống ánh xạ hàng nghìn microservices theo thời gian thực

Netflix đã chia sẻ chi tiết về hệ thống nội bộ có tên Service Topology. Hệ thống này tạo và cập nhật biểu đồ phụ thuộc trực tiếp cho hàng nghìn microservices, giúp các kỹ sư nhìn thấy cách các dịch vụ kết nối và giải quyết vấn đề nhanh hơn. Hệ thống hợp nhất ba nguồn dữ liệu riêng biệt thành một biểu đồ duy nhất có thể truy vấn, cập nhật gần như theo thời gian thực khi các mẫu lưu lượng truy cập thay đổi.

Thách thức về khả năng quan sát trong hệ thống phân tán

Động lực phát triển hệ thống này xuất phát từ một mô hình nhất quán trong các yêu cầu hỗ trợ kỹ thuật trong bốn năm qua. Các kỹ sư sửa chữa hệ thống phân tán thường xuyên đối mặt với những câu hỏi giống nhau: dịch vụ nào phụ thuộc vào dịch vụ nào, phạm vi ảnh hưởng của một thay đổi hoặc sự cố là bao nhiêu, và vấn đề bắt nguồn từ cục bộ hay từ một phụ thuộc ngược dòng (upstream dependency).

Các công cụ quan sát hiện có như số liệu (metrics), nhật ký (logs) và dấu vết (traces) đều ghi lại một phần bức tranh nhưng không cung cấp cái nhìn thống nhất về cách các dịch vụ kết nối tại thời điểm chạy (runtime).

Kiến trúc hệ thống Service Topology của NetflixKiến trúc hệ thống Service Topology của Netflix

Kết hợp ba nguồn dữ liệu để tạo ra sự thật duy nhất

Hệ thống Service Topology tiêu thụ dữ liệu từ ba nguồn, mỗi nguồn được lưu trữ trong một phân vùng đồ thị riêng biệt:

  • Nhật ký luồng mạng eBPF: Thu thập dữ liệu ở mức hạt nhân (kernel level), mang lại cái nhìn hoàn chỉnh ngay cả khi các dịch vụ không được đo lường. Tuy nhiên, chúng thiếu ngữ cảnh cấp ứng dụng như API endpoint nào đang được gọi.
  • Số liệu IPC (Inter-Process Communication): Được phát ra bởi các dịch vụ đã được đo lường, cung cấp chi tiết về endpoint và giao thức, nhưng chỉ áp dụng cho các dịch vụ chủ động phát ra chúng.
  • Dấu vết phân tán tổng hợp (Distributed Traces): Tiết lộ các đường dẫn yêu cầu thực tế, bao gồm cả các nhánh có điều kiện, mặc dù chịu hạn chế về lấy mẫu (sampling).

Mỗi lớp này bù đắp cho các khoảng trống của lớp kia, và các truy vấn có thể nhắm vào một lớp duy nhất hoặc hợp nhất cả ba song song.

Xử lý dữ liệu và lưu trữ đồ thị

Một đường ống tổng hợp ba giai đoạn giải quyết vấn đề chính với các luồng mạng thô. Nhật ký theo dõi các bước nhảy riêng lẻ thông qua các trung gian như bộ cân bằng tải (load balancers) và cổng NAT, nhưng chúng không hiển thị kết nối ứng dụng-đến-ứng dụng trực tiếp mà các kỹ sư cần. Giai đoạn thứ hai thực hiện giải quyết trung gian, thu gọn các đường dẫn nhiều bước thành các cạnh trực tiếp. Phương pháp graduated này giúp phân tải tải và ngăn chặn các điểm nóng (hot spots) khi một số trung gian xử lý quá nhiều lưu lượng.

Đường ống xử lý chạy trên Apache Pekko Streams trên nhiều người tiêu dùng Kafka đa khu vực. Lưu trữ đồ thị được xây dựng trên hệ thống khóa-giá trị phân tán nội bộ của Netflix, sử dụng lớp cơ sở dữ liệu đồ thị được thiết kế để duyệt nhanh. Một API gRPC hiển thị cấu trúc liên kết với hỗ trợ cho các truy vấn nhiều bước, lọc theo tầng sẵn sàng và lĩnh vực kinh doanh, với thời gian phản hồi dưới giây là yêu cầu bắt buộc.

Truy vấn lịch sử và bài học kinh nghiệm

Các truy vấn lịch sử sử dụng tổng hợp cửa sổ thời gian thay vì giữ các bản ảnh chụp nhanh (snapshots) riêng biệt. Điều này cho phép các kỹ sư nhìn thấy cấu trúc liên kết tại một thời điểm nhất định trong quá khứ mà không tốn nhiều chi phí lưu trữ. Nhóm mô tả tính năng này rất hữu ích để tương quan các thay đổi phụ thuộc với sự khởi đầu của một sự cố.

Nhóm Netflix lưu ý rằng một số quyết định thiết kế xuất phát từ những nỗ lực thất bại trước đó. Các biểu đồ phụ thuộc tĩnh hoặc bị trì hoãn đã được chứng minh là vô dụng trong môi trường mà các dịch vụ được triển khai nhiều lần mỗi ngày. Các giải pháp hoạt động ở quy mô nhỏ hơn sẽ gặp trở ngại tại quy mô dịch vụ và lưu lượng truy cập khổng lồ của Netflix. Hơn nữa, dữ liệu phụ thuộc không đầy đủ hoặc không chính xác còn tồi tệ hơn là không có dữ liệu nào cả vì nó dẫn các kỹ sư đến kết luận sai lầm trong các sự cố.

Công việc trong tương lai sẽ bao gồm thêm các sự kiện thay đổi triển khai và cấu hình vào biểu đồ liên kết. Về lâu dài, nhóm nhằm mục đích sử dụng biểu đồ này làm cơ sở cho phân tích nguyên nhân gốc rễ tự động.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗