Business-Driven Upgrade of Alibaba Group: The Evolution of Dubbo 3.0

Alibaba · 2021 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bài trên blog Alibaba Cloud, giọng giới thiệu kế hoạch; phần lớn là thiết kế và lộ trình, ít số liệu đo. Kết quả hai năm sau (Dubbo3 thay hẳn HSF2) ở Alibaba 2023. Mọi số liệu theo Alibaba.

Bối cảnh

• Cuối 2020 Alibaba đặt mục tiêu hợp nhất công nghệ nội bộ, mã nguồn mở và sản phẩm thương mại. Bên trong dùng framework RPC HSF (đã qua nhiều mùa Double 11), bên ngoài là Dubbo mã nguồn mở. Dubbo 3.0 là bản hợp nhất hai bên, đã chạy lớn ở Kaola (2021).
• Dubbo 2.7 trở về trước đăng ký và khám phá service theo từng interface: mỗi interface là một bản ghi trên registry, mỗi máy đăng ký metadata riêng (serialization, timeout, data center). Một gateway phụ thuộc 30 interface của một ứng dụng upstream thì mỗi lần upstream release có 30 danh sách địa chỉ lên xuống.
• Giao thức Dubbo 2 là nhị phân riêng: gateway, mesh, client mobile phải chuyển đổi giao thức; chỉ có request/response, không stream.

Thay đổi chính

• Khám phá service theo ứng dụng (thử từ 2.7.6): ứng dụng có 100 interface và 100 máy, mỗi lần release client thấy 10.000 thay đổi theo interface, nay chỉ còn 100; theo Alibaba bộ nhớ giảm ít nhất một nửa, cụm lên được hàng triệu instance.
• Để nâng cấp không hỏng lời gọi đang chạy, thêm metadata center giữ hai thứ: ánh xạ interface → ứng dụng (client tự quyết có dùng chế độ mới không, không đổi code nghiệp vụ) và metadata snapshot theo mỗi lần release (cấu hình mọi interface, ID snapshot nằm trong URL). Client cũ và mới cùng chạy được.
• Giao thức Triple trên HTTP/2, tương thích gRPC, thêm stream và hai chiều, giữ request ID để tránh head-of-line blocking; vẫn hỗ trợ serialization cũ để chuyển dần sang Protobuf.
• Hai cách vào service mesh dưới một control plane: Thin SDK (sidecar, SDK chỉ giữ lõi RPC) và Proxyless (SDK tự nói với control plane, không sidecar) cho nơi không chịu được chi phí chặn traffic của sidecar; hai kiểu được trộn trong cùng cụm.
• Lộ trình: 3.1 (11/2021) cho mesh, 3.2 (3/2022) điều phối traffic theo năng lực thực của từng node.

Vì sao

• Khi tách monolith thành microservice đã xong, mỗi interface thường chỉ do một ứng dụng cung cấp, và cấu hình trên URL hầu như không đổi; đơn vị đăng ký theo interface trở thành dư thừa và làm phình registry khi số máy tăng.
• Nhiều kiểu triển khai (VM, container, sidecar, không sidecar) sẽ cùng tồn tại lâu, nên cần một bộ quy tắc quản trị chung thay vì mỗi kiểu một bộ.

Bài học cho SWE

• Đơn vị đăng ký trong service discovery quyết định số thay đổi mỗi lần deploy; khi tách service đã ổn định, gộp về đơn vị thô hơn giảm tải registry cấp bậc độ lớn.
• Nâng cấp cơ chế lõi trong một hệ có hàng nghìn ứng dụng phải có lớp tương thích để client cũ và mới cùng chạy (ở đây là metadata center), không bắt mọi team đổi cùng lúc.
• Không có một kiểu mesh cho mọi nơi: sidecar cho phần rìa, proxyless cho đường nóng.

Liên quan

• Nền tảng nội bộ cho service (đường ray chung) · Migration không downtime
• Phần tiếp: Alibaba 2023