Uber tự động hóa phân tích phụ thuộc trong lưới dịch vụ quy mô lớn

Uber vừa công bố một hệ thống phân tích phụ thuộc tự động, sử dụng middleware RPC và các số liệu thu thập từ môi trường vận hành thực tế để tương quan lỗi giữa bên gọi (caller) và các dịch vụ hạ nguồn (downstream). Hệ thống này phân loại các mối phụ thuộc thành ba nhóm: fail-close, fail-open và chưa xác định (unknown).

Cách tiếp cận mới được thiết kế nhằm giải quyết những hạn chế của phương pháp distributed tracing lấy mẫu (sampled tracing) — vốn thường bỏ sót các lỗi hiếm gặp trong một lưới dịch vụ có quy mô khổng lồ như của Uber. Đây là vấn đề đặc biệt nhức nhối với các kỹ sư vận hành hệ thống phân tán, khi chỉ một lỗi hiếm cũng có thể gây ảnh hưởng dây chuyền trên toàn bộ hệ thống.

Vì sao cần phân tích phụ thuộc tự động?

Trong một kiến trúc microservices với hàng nghìn dịch vụ liên kết chặt chẽ, việc hiểu rõ mối quan hệ phụ thuộc giữa các dịch vụ là bài toán sống còn. Khi một dịch vụ gặp sự cố, câu hỏi đặt ra luôn là: lỗi này bắt nguồn từ đâu, và nó lan truyền theo con đường nào?

Các công cụ distributed tracing truyền thống — như Jaeger hay Zipkin — dựa trên cơ chế lấy mẫu để giảm chi phí lưu trữ và xử lý. Tuy nhiên, chính cơ chế lấy mẫu này lại là điểm yếu chí mạng:

• Lỗi hiếm bị bỏ sót: nếu một lỗi chỉ xảy ra với tần suất 0,01%, việc lấy mẫu 1% trace gần như chắc chắn sẽ không ghi nhận được nó.
• Khó tái hiện: khi lỗi không xuất hiện trong trace, kỹ sư không có dữ liệu để điều tra nguyên nhân gốc.
• Chi phí lưu trữ toàn bộ trace là quá lớn: với lưu lượng của Uber, việc lưu mọi trace là bất khả thi về mặt kinh tế.

Middleware RPC kết hợp số liệu vận hành

Thay vì phụ thuộc vào trace, Uber chèn logic thu thập dữ liệu ngay trong middleware RPC — lớp trung gian xử lý mọi cuộc gọi giữa các dịch vụ. Mỗi khi một cuộc gọi RPC diễn ra, middleware ghi nhận kết quả thành công hay thất bại mà không cần lấy mẫu.

Dữ liệu này sau đó được đối chiếu với số liệu vận hành production để tìm ra tương quan:

• Khi dịch vụ A gọi dịch vụ B, và cả hai cùng tăng tỷ lệ lỗi trong một khoảng thời gian, hệ thống suy luận A phụ thuộc vào B.
• Nếu A lỗi nhưng B vẫn khỏe mạnh, mối phụ thuộc được đánh dấu là fail-open — nghĩa là A có thể chịu được sự cố từ B.
• Nếu A và B cùng lỗi theo tỷ lệ thuận, mối phụ thuộc là fail-close — A sẽ sập nếu B sập.

Việc phân loại fail-close và fail-open giúp các nhóm vận hành hiểu rõ dịch vụ nào là điểm yếu chí mạng cần bảo vệ trước, và dịch vụ nào có thể chịu lỗi mà không gây hậu quả nghiêm trọng.

Ý nghĩa với cộng đồng kỹ sư Việt Nam

Với các doanh nghiệp Việt Nam đang chuyển dịch mạnh sang kiến trúc microservices — từ các công ty fintech, thương mại điện tử đến các nền tảng gọi xe và giao đồ ăn — bài học từ Uber mang tính thực tiễn cao.

Nhiều đội ngũ kỹ sư trong nước vẫn phụ thuộc hoàn toàn vào distributed tracing và thường xuyên rơi vào tình trạng "không tìm thấy trace" khi có sự cố hiếm gặp. Việc tận dụng middleware RPC sẵn có và số liệu observability đã thu thập (qua Prometheus, Grafana, hoặc các nền tảng APM) để xây dựng phân tích phụ thuộc là hướng đi khả thi, chi phí thấp hơn so với đầu tư hạ tầng trace toàn phần.

Bên cạnh đó, việc phân loại rõ fail-close và fail-open cũng hỗ trợ trực tiếp cho công tác thiết kế circuit breaker, timeout và chiến lược retry — những thành phần cốt lõi của một hệ thống chịu lỗi tốt.

Kết luận

Giải pháp của Uber cho thấy một xu hướng đáng chú ý: thay vì chạy theo công cụ quan sát (observability) ngày càng phức tạp và tốn kém, các đội ngũ kỹ sư có thể khai thác dữ liệu sẵn có ngay trong luồng giao tiếp giữa các dịch vụ. Đây là bài học về sự cân bằng giữa chi phí, độ chính xác và khả năng vận hành thực tế — điều mà bất kỳ hệ thống phân tán quy mô lớn nào cũng phải đối mặt.