Chào các bạn, qua tiêu đề bài viết này, chúng ta sẽ cùng khám phá về mô hình API Composite Pattern, một pattern được áp dụng phổ biến trong kiến trúc Microservices. Những bạn nào chưa quen với thuật ngữ này, đừng lo lắng; rất có thể bạn đã gặp hoặc sử dụng nó mà lại không biết tên. Hãy cùng tìm hiểu chi tiết về API Composite Pattern nhé!
1. Bối Cảnh
Trong hệ thống microservices, mỗi service đảm nhiệm một chức năng riêng biệt. Khi client cần dữ liệu từ nhiều service khác nhau, thường thì client phải thực hiện nhiều yêu cầu riêng lẻ tới từng service.
Hãy tưởng tượng một hệ thống thương mại điện tử (e-commerce) đơn giản. Ta có kiến trúc như sau:
- Client: Giao diện người dùng (frontend).
- API Gateway: Nhận yêu cầu từ client và thực hiện xác thực người dùng qua token.
- Order Service: Cung cấp thông tin về đơn hàng.
- Customer Service: Cung cấp thông tin về khách hàng.
- Product Service: Cung cấp thông tin về sản phẩm.
Luồng Hoạt Động
Dưới đây là cách mà hệ thống làm việc khi client muốn lấy thông tin về đơn hàng:
- Client gửi yêu cầu đến API Gateway để lấy dữ liệu đơn hàng.
- API Gateway xác thực yêu cầu và chuyển tiếp đến Order Service.
- Order Service xử lý yêu cầu và gửi dữ liệu về cho API Gateway.
- Client gửi yêu cầu lấy thông tin khách hàng đến API Gateway.
- API Gateway xác thực yêu cầu và chuyển tiếp đến Customer Service.
- Customer Service gửi thông tin khách hàng về cho API Gateway.
- Client gửi yêu cầu về sản phẩm đến API Gateway.
- API Gateway chuyển tiếp đến Product Service.
- Product Service xử lý và gửi dữ liệu sản phẩm về cho API Gateway.
- Client nhận dữ liệu tổng hợp và hiển thị cho người dùng.
Như vậy, để thu thập thông tin cho một đơn hàng, server cần xử lý ba yêu cầu khác nhau! Nếu có nhiều user cùng lúc, server sẽ gặp phải tình trạng quá tải.
Các vấn đề được nêu ra:
- Tăng số lượng yêu cầu: Client cần gửi nhiều yêu cầu đến server, dẫn đến quá tải và phức tạp trong quản lý.
- Độ trễ cao: Thời gian xử lý cho mỗi yêu cầu tăng lên, ảnh hưởng tiêu cực đến thời gian phản hồi.
- Phức tạp hóa logic client: Client cần hoạt động để quản lý và kết hợp dữ liệu từ nhiều nguồn.
Giải pháp cho vấn đề này là API Composite Pattern.
2. Cách Hoạt Động Của API Composite Pattern
2.1. Nguyên Lý Hoạt Động
API Composite Pattern giúp giảm số lượng yêu cầu từ client qua hoạt động của một Composite API. Các bước hoạt động cơ bản:
- Client gửi yêu cầu duy nhất: Client chỉ cần gửi một yêu cầu đến Composite API.
- Composite API gửi yêu cầu đến các service liên quan: Composite API thực hiện gửi yêu cầu đến các microservices cần thiết.
- Tổng hợp kết quả: Composite API thu thập và tổng hợp dữ liệu từ các service.
- Trả về kết quả cho Client: Cuối cùng, Composite API trả về cho client một phản hồi duy nhất chứa đầy đủ thông tin.
2.2. Ví Dụ Cụ Thể
Với hệ thống thương mại điện tử trước đó, khi client muốn nhận thông tin chi tiết cho đơn hàng:
- Client gửi yêu cầu đến API Gateway.
- API Gateway thực hiện xác thực và gửi yêu cầu đến Order Service.
- Order Service trả dữ liệu về đơn hàng.
- API Gateway gửi yêu cầu đến Customer Service cho thông tin khách hàng.
- Tương tự cho Product Service.
- Cuối cùng, API Gateway tổng hợp và trả về cho Client.
Có thể có ý kiến cho rằng cách này gây trở ngại cho frontend. Tuy nhiên, backend hiện đại có thể xử lý đa luồng, cho phép gửi các yêu cầu cùng lúc để giảm thiểu độ chậm trễ.
3. Ưu và Nhược Điểm
3.1. Ưu Điểm
- Giảm số lượng yêu cầu: Client chỉ cần gửi một yêu cầu duy nhất.
- Tối ưu hóa hiệu suất: Giảm thời gian chờ đợi nhờ gửi yêu cầu song song.
- Đơn giản hóa client logic: Client không phải lo về các service backend.
- Tính linh hoạt cao: Composite API có thể định dạng và xử lý kết quả phù hợp với nhu cầu của client.
- Xử lý lỗi tốt hơn: Composite API có thể quản lý lỗi từ các service một cách đồng nhất.
3.2. Nhược Điểm
- Phức tạp trong triển khai: Đặc biệt khi có nhiều service.
- Độ trễ: Nếu một service có vấn đề, cả quá trình sẽ bị ảnh hưởng.
- Khó bảo trì: Nâng cấp hệ thống yêu cầu cập nhật Composite API.
- Không đảm bảo tính nhất quán ngay lập tức: Dữ liệu có thể không đồng bộ liên tục giữa các service.
3.3. Khi Nào Nên Sử Dụng
- Khi client cần dữ liệu từ nhiều nguồn khác nhau.
- Khi cần giảm số lượng yêu cầu từ client.
- Khi cần tối ưu hóa độ trễ.
4. Các Cách Triển Khai Phổ Biến
Ngoài việc triển khai trong API Gateway, còn các phương án như:
- Tạo một service riêng cho API Composite.
- Sử dụng GraphQL.
- Sử dụng Message Broker.
| Cách triển khai | Ưu điểm | Nhược điểm | Khi nào nên sử dụng |
|---|---|---|---|
| Composite API tại API Gateway | Tối ưu cho hệ thống đơn giản. | Tăng tải cho API Gateway. | Hệ thống nhỏ, yêu cầu đơn giản. |
| Composite API service riêng | Tối ưu cho logic phức tạp. | Tăng số lượng service. | Hệ thống lớn cần logic tùy chỉnh. |
| GraphQL | Linh hoạt cho client. | Phức tạp trong bảo mật. | Khi cần sự linh hoạt trong truy vấn. |
| Message Broker | Tính phi đồng bộ. | Độ trễ có thể cao hơn. | Khi cần xử lý không đồng bộ. |
Kết Luận
Bài viết đã giới thiệu về API Composite Pattern, một công cụ hữu ích trong kiến trúc Microservices. Hi vọng qua bài viết, bạn có thêm kiến thức và có thể áp dụng pattern này vào dự án của mình. Nếu có thắc mắc hoặc góp ý, đừng ngần ngại bình luận bên dưới nhé. Cảm ơn bạn đã đọc bài!
source: viblo
