+2

Microservices Design Patterns – Hướng dẫn & Ứng dụng Thực Tế

Tìm hiểu về các pattern phổ biến của Microservices.

image.png

From : https://www.linkedin.com/posts/sina-riyahi_microservices-design-patterns-microservices-activity-7326863427832823808-wC7i?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAABcd9xkB6w57Mmsqti43xtrqxUIgxeAfmT8

Tác giả hình ảnh: Sina Riyahi


1. API Gateway Pattern

🧩 Mô tả:

API Gateway đóng vai trò như một điểm vào duy nhất cho tất cả các request từ client. Nó định tuyến request tới các microservice phù hợp.

✅ Ưu điểm:

  • Ẩn kiến trúc bên trong khỏi client
  • Cho phép xử lý bảo mật, logging, throttling tập trung
  • Tối ưu hiệu năng với caching, aggregation

❌ Nhược điểm:

  • Là một Single Point of Failure (SPoF)
  • Phức tạp khi tích hợp nhiều policy khác nhau

📦 Use case:

  • Netflix dùng API Gateway để điều hướng lưu lượng người dùng đến hàng trăm microservice khác nhau.
  • Ứng dụng mobile/web cần đồng bộ hóa điểm vào duy nhất.

2. Service Discovery Pattern

🧩 Mô tả:

Cho phép các microservice tự động đăng ký và tìm kiếm nhau thông qua Service Registry.

✅ Ưu điểm:

  • Giảm cấu hình thủ công giữa các service
  • Tự động scale up/down mà không cần cấu hình lại client

❌ Nhược điểm:

  • Cần thêm service registry (Eureka, Consul, etcd)
  • Có thể bị lỗi khi service registry không sẵn sàng

📦 Use case:

  • Kubernetes: tự động gán DNS cho mỗi pod
  • Hệ thống backend với hàng trăm service cần scale linh hoạt

3. CQRS (Command Query Responsibility Segregation)

🧩 Mô tả:

Tách riêng logic ghi (Command) và đọc (Query) ra hai mô hình khác nhau.

✅ Ưu điểm:

  • Tối ưu hóa hiệu suất đọc và ghi
  • Cho phép scale độc lập từng phần
  • Phù hợp với kiến trúc Event Sourcing

❌ Nhược điểm:

  • Phức tạp hơn mô hình CRUD thông thường
  • Cần đồng bộ hóa trạng thái giữa các model

📦 Use case:

  • Hệ thống đặt vé máy bay (ghi nhiều nhưng đọc thường xuyên)
  • Hệ thống quản lý đơn hàng lớn như Amazon

4. Backends for Frontends (BFF)

🧩 Mô tả:

Mỗi frontend (mobile, web) có một backend riêng biệt phù hợp với nhu cầu của nó.

✅ Ưu điểm:

  • Tối ưu dữ liệu trả về theo nhu cầu frontend
  • Tăng tốc độ phản hồi cho từng nền tảng

❌ Nhược điểm:

  • Tốn công bảo trì nhiều backend
  • Dễ trùng lặp logic giữa các BFF

📦 Use case:

  • Spotify sử dụng BFF cho desktop, mobile, web client
  • Hệ thống đa nền tảng cần tùy biến UI riêng

5. Event-Driven Pattern

🧩 Mô tả:

Các service giao tiếp với nhau thông qua các sự kiện (event), sử dụng message broker (Kafka, RabbitMQ, etc).

✅ Ưu điểm:

  • Giảm độ phụ thuộc giữa các service
  • Dễ dàng scale và xử lý bất đồng bộ
  • Tăng tính phản ứng (reactive)

❌ Nhược điểm:

  • Khó debug do không có luồng tuần tự rõ ràng
  • Phức tạp trong việc đảm bảo tính đúng đắn của dữ liệu

📦 Use case:

  • Hệ thống thanh toán, gửi email (event: đơn hàng thành công)
  • Uber dùng để xử lý việc điều phối xe theo thời gian thực

6. Database per Service Pattern

🧩 Mô tả:

Mỗi service có database riêng, không chia sẻ trực tiếp schema với service khác.

✅ Ưu điểm:

  • Tăng tính độc lập, dễ scale
  • Giảm coupling giữa các team/service

❌ Nhược điểm:

  • Khó khăn khi cần join dữ liệu giữa nhiều service
  • Cần đồng bộ dữ liệu trong các workflow phức tạp

📦 Use case:

  • Hệ thống lớn như Shopify, mỗi domain như orders, users, inventory có DB riêng
  • Hệ thống đa quốc gia cần tách vùng lưu trữ theo quốc gia

🔚 Kết luận

Pattern Ưu điểm nổi bật Điểm cần cân nhắc
API Gateway Tập trung điều phối & bảo mật SPoF nếu không dùng High Availability
Service Discovery Tự động scale, tránh cấu hình thủ công Cần service registry và health check
CQRS Scale riêng đọc/ghi Đồng bộ dữ liệu phức tạp
BFF Tối ưu frontend Dễ trùng lặp logic giữa các BFF
Event Driven Không đồng bộ, mở rộng linh hoạt Debug khó, cần chiến lược xử lý thất bại
Database per Service Độc lập cao, scale riêng Thiếu join trực tiếp, phức tạp đồng bộ


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí