Introducing Domain-Oriented Microservice Architecture

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

Bối cảnh

Uber có khoảng 2.200 microservice quan trọng (2020).
Lý do tách năm 2012–2013 (hai monolith): rủi ro availability, deploy rủi ro và đắt, ranh giới kém, các team không làm việc độc lập được khi lên hàng trăm kỹ sư. Theo Uber, microservices đã mang lại độ tin cậy, quyền sở hữu rõ ràng, tốc độ ra tính năng.
Khi lên hàng nghìn kỹ sư thì độ phức tạp bùng nổ:
- Điều tra một sự cố phải đi qua ~50 service của 12 team.
- Một tính năng đơn giản cần ~10 điểm chạm (ví dụ năm 2018).
- Team viết code trong service của nhau, deploy hộ nhau, tạo ra những "monolith nối mạng".

Thay đổi chính

DOMA dựa trên ý tưởng: coi microservice là "thư viện có thêm chi phí I/O", và cả hệ thống là một chương trình phân tán lớn. Áp dụng các nguyên tắc đã có (DDD, Clean Architecture, thiết kế hướng interface).

Domain: nhóm service liên quan theo chức năng (ví dụ map search, fare, matching). Không quy định kích thước; có domain chỉ một service. Không nhất thiết theo sơ đồ tổ chức: org Maps có 80 service chia thành 3 domain.
Layer design: 5 tầng, mỗi tầng chỉ được gọi tầng bên dưới. Từ dưới lên: Infrastructure → Business → Product → Presentation → Edge. Tầng thấp thì nhiều phụ thuộc vào nó và phạm vi ảnh hưởng khi hỏng lớn hơn. Chức năng thường "trôi xuống" khi trở thành nền tảng chung.
Gateway: một điểm vào duy nhất cho mỗi domain, che service, bảng dữ liệu, ETL bên trong.
Extension: để team khác mở rộng domain mà không sửa code lõi.
- Logic extension: ví dụ khi tài xế "go online", mỗi team đăng ký một kiểm tra riêng qua interface định trước.
- Data extension: gắn dữ liệu tuỳ ý bằng Protobuf Any.

Kết quả (theo Uber, 2020)

Phân loại 2.200 service vào 70 domain, khoảng 50% đã triển khai.
Thời gian onboarding tính năng mới giảm 25–50%. Một nền tảng giảm thời gian tích hợp từ 3 ngày xuống 3 giờ. Chi phí hỗ trợ nền tảng giảm khoảng một bậc độ lớn.
"Chu kỳ bán rã" của microservice là 1,5 năm: cứ 1,5 năm thì 50% service thay đổi. Gateway giúp hai lần viết lại nền tảng lớn nhất trong năm diễn ra mà không bắt hàng trăm service phía trên phải migrate.

Vì sao

Theo Uber: không thể quay về monolith vì lợi ích vận hành quá quan trọng ("không sống được với nó, cũng không sống được thiếu nó"). Cần giảm độ phức tạp mà vẫn giữ sự linh hoạt.

Bài học cho SWE

Lời khuyên theo quy mô:
- Startup: hoãn microservices là hợp lý; các service đầu tiên sẽ tồn tại lâu nhất.
- Quy mô vừa: đầu tư sớm vào nền tảng không mang logic sản phẩm, dùng extension.
- Quy mô lớn: gom domain và đặt gateway.
Tiến hoá kiến trúc như "tỉa hàng rào": điều chỉnh dần, không có cuộc viết lại toàn bộ.
Gateway là công cụ chống "migration hell" khi service thay đổi liên tục.