Kiến trúc Microservice Định hướng Domain của Uber

DOMA là cách Uber, với 2.200 microservice, đã áp dụng để giảm độ phức tạp trong khi vẫn giữ được tính linh hoạt của MSA

• Được thiết kế cho hệ thống phân tán quy mô lớn của một tổ chức lớn, bằng cách kết hợp các ý tưởng từ DDD, SOA, OO, CA, v.v.

• Bài viết cô đọng kinh nghiệm lâu năm của Uber sau một thời gian dài vận hành MSA

Các nguyên tắc cơ bản của DOMA

1. Gom microservice thành các collection theo từng domain

2. Tạo các collection domain gọi là Layer, cho phép có phụ thuộc bên trong từng layer → Layer Design

3. Tạo Gateway cung cấp giao diện gọn gàng như một điểm vào duy nhất cho từng collection

4. Mỗi domain nên độc lập với các domain khác. Tuy nhiên, vì thường cần bao gồm logic của domain khác, nên cung cấp kiến trúc Extension để hỗ trợ tốt việc này

** Cách Uber triển khai

• Domains

→ Tập hợp một hoặc nhiều microservice được nhóm lại một cách logic.

→ Mỗi domain có thể có hơn 10 service, hoặc cũng có thể chỉ có một service duy nhất

→ Ví dụ: tìm kiếm bản đồ, giá cước, nền tảng ghép cặp (rider và tài xế) đều là một domain

→ Không đi theo cấu trúc tổ chức của công ty, nên tổ chức liên quan đến bản đồ của Uber được chia thành 3 domain, 80 microservice và 3 gateway

• Layer Design

→ Câu trả lời cho câu hỏi: "Service nào có thể gọi service nào khác?"

→ "separation of concerns at scale" hoặc "dependency management at scale"

→ Uber gồm 5 layer

1. Infrastructure : Các chức năng mà mọi tổ chức đều có thể dùng. Ví dụ storage/networking

2. Business : Các chức năng dùng ở cấp độ nghiệp vụ. Không giới hạn trong một danh mục sản phẩm cụ thể hay một LOB (Line Of Business) như Rides, Eats, Freight

3. Product : Chức năng liên quan đến một danh mục sản phẩm hoặc LOB cụ thể, nhưng cũng có thể là thứ được nhiều app cùng dùng như "Request a ride"

4. Presentation : Các chức năng liên quan đến ứng dụng hướng tới người dùng (mobile / web)

5. Edge : Cách công bố dịch vụ Uber ra bên ngoài một cách an toàn. Cũng liên kết với ứng dụng mobile

• Gateways

→ Không quá khác với API Gateway của microservice. Tuy nhiên, có thể hiểu đây là điểm vào duy nhất (Single Entry-point) kết nối tới Domain

→ Vì bên trong chỉ còn một phụ thuộc duy nhất với bên ngoài, nên migration, discovery và độ phức tạp hệ thống nói chung đều giảm xuống

• Extensions

→ Cơ chế mở rộng domain mà không thay đổi phần triển khai của service hoặc ảnh hưởng đến độ ổn định

1. Mở rộng Logic : Mở rộng logic service bằng pattern Provider hoặc Plugin

2. Mở rộng Data : Cơ chế gắn thêm dữ liệu tùy ý để tránh việc dữ liệu lõi bị phình to. Sử dụng kiểu Any của Protobuf

3. Mở rộng Custom : Mỗi team mở rộng bằng pattern phù hợp với domain của mình

Hiệu quả là thời gian onboarding giảm 25~50%

2.200 microservice đã được tách thành 70 domain.

Uber tính toán rằng vòng đời bán rã của microservice là 1,5 năm. Tức là cứ mỗi 1,5 năm thì 50% microservice biến mất

Nếu không có gateway, mỗi lần như vậy sẽ là địa ngục migration.

Tại Uber, các nền tảng được thiết kế bằng DOMA đã chứng minh là dễ mở rộng hơn nhiều và dễ bảo trì hơn.

Lời khuyên thực tế cho các công ty khác

• Startup :

→ Những câu hỏi quan trọng là: "Khi nào nên áp dụng MSA?" và "Nó có phù hợp với tổ chức của chúng ta không?"

→ MSA có lợi thế vận hành với tổ chức có nhiều kỹ sư, nhưng cũng làm tăng độ phức tạp và có thể khiến việc phát triển tính năng khó hơn

→ Với tổ chức nhỏ, nó có thể chỉ mang lại sự gia tăng độ phức tạp kiến trúc mà không có lợi ích vận hành tương xứng, và còn có thể tốn kém hơn.

→ Áp dụng từ từ cũng hoàn toàn ổn; nếu đã quyết định đi theo MSA thì cần xem nó như một "chương trình phân tán quy mô lớn" và tách biệt giữa các microservice

→ Những microservice đầu tiên sẽ rất quan trọng khi mô tả các chức năng cốt lõi của doanh nghiệp và sẽ tồn tại lâu dài

• Công ty quy mô trung bình :

→ Khi công ty bắt đầu chia thành nhiều team và xuất hiện sự phân nhánh mối quan tâm giữa các platform, MSA trở nên hữu ích hơn

→ Ở giai đoạn này có thể bắt đầu cân nhắc cấu trúc phân tầng giữa các microservice, và khi nhiều service cùng được sử dụng hơn thì việc quản lý phụ thuộc trở nên quan trọng

→ Số lượng microservice vẫn chưa nhiều nên clustering có thể chưa có nhiều ý nghĩa, nhưng tư duy theo hướng domain vẫn rất hữu ích

• Công ty lớn :

→ Với tổ chức kỹ thuật quy mô lớn, có hàng trăm kỹ sư, microservice và phụ thuộc, DOMA phát huy tác dụng rất rõ rệt

→ Có thể dễ dàng nhóm theo domain có gateway, và gateway cũng hữu ích khi refactor hoặc viết lại hệ thống legacy

Ngay tại Uber, ngày càng có nhiều team đang dần áp dụng DOMA. (Nghe nói khoảng 60 người từ các tổ chức khác nhau trong Uber đã cùng tham gia xây dựng nó suốt 2 năm)

[algedian]

https://eng.uber.com/microservice-architecture/

Bây giờ có vẻ vẫn xem được.. nhưng hình như hình ảnh trên bản trong Wayback Machine hơi khác một chút.

[xguru]

À, lại hoạt động rồi nhé haha tôi đã hoàn nguyên lại rồi.

Có vẻ vấn đề là ở hình có hiển thị tên dịch vụ chi tiết.

[jaeyeonling]

Có vẻ bài viết đã bị xóa rồi T.T

[xguru]

Ồ, đúng là vậy nhỉ. Trước mắt vẫn có thể xem trên Wayback Machine.

https://web.archive.org/web/20200803012939/…

[jaeyeonling]

Cảm ơn bạn :)