EP4. When should you pick Microservices Architecture?

1. Pros of microservice architecture

No Single Points of Failure

Do microservices là kiến trúc liên kết lỏng lẻo, nên không tồn tại điểm lỗi đơn.
Ngay cả khi một vài service gặp sự cố, toàn bộ ứng dụng vẫn có thể tiếp tục hoạt động.


Leverage Heterogeneous Technologies

  • Các microservice giao tiếp với nhau thông qua giao diện REST API, thường thông qua API Gateway.
  • Hệ thống microservices có thể áp dụng kiến trúc lưu trữ đa ngôn ngữ (polyglot persistence) và tận dụng nhiều công nghệ dị thể như:
    • Java
    • Python
    • Ruby
    • Node.js
    • v.v.
  • Polyglot persistence là việc sử dụng đồng thời nhiều loại cơ sở dữ liệu khác nhau trong cùng một kiến trúc, chẳng hạn như SQL và NoSQL.
    Phần này sẽ được trình bày chi tiết hơn trong bài học về cơ sở dữ liệu.

Triển khai độc lập và liên tục (Independent and Continuous Deployments)

  • Việc triển khai (deployment) có thể được thực hiện độc lập và liên tục.
  • Chúng ta có thể có các team riêng phụ trách từng microservice.
  • Mỗi service có thể được mở rộng độc lập, không ảnh hưởng đến các service khác.

2. Cons of microservices architecture

Management Complexity

Microservices là một môi trường phân tán, gồm nhiều service chạy trên các cluster máy chủ.
Điều này khiến việc quản lý và giám sát hệ thống trở nên phức tạp.

Chúng ta cần thiết lập thêm nhiều thành phần bổ trợ để quản lý microservices, chẳng hạn như:

  • Node manager (ví dụ: Apache ZooKeeper)
  • Dịch vụ theo dõi phân tán (distributed tracing) để giám sát các node
  • Và các thành phần hạ tầng khác

Ngoài ra, hệ thống microservices đòi hỏi nguồn nhân lực có kỹ năng cao, thậm chí cần một đội ngũ chuyên trách riêng chỉ để vận hành và quản lý các service này.


Strong Consistency

Trong môi trường phân tán, việc đảm bảo tính nhất quán mạnh đôi khi rất khó, đặc biệt khi cần duy trì một trạng thái nhất quán duy nhất trên nhiều microservice khác nhau.

Trong thực tế, dữ liệu giữa các node thường chỉ đạt tính nhất quán sau cùng (eventual consistency).
Đây là hạn chế tất yếu xuất phát từ bản chất thiết kế phân tán của hệ thống.

Trong chương cơ sở dữ liệu, chúng ta sẽ thảo luận chi tiết hơn về strong consistencyeventual consistency.


3. When should you pick a microservices architecture?

Kiến trúc microservices phù hợp nhất với các use case phức tạp, đặc biệt là những ứng dụng cần mở rộng nhanh về mặt tính năng.

Một ứng dụng mạng xã hội là ví dụ điển hình cho loại use case này.

Một ứng dụng mạng xã hội thông thường bao gồm rất nhiều thành phần, chẳng hạn như:

  • Nhắn tin (messaging)
  • Chat thời gian thực (real-time chat)
  • Phát video trực tiếp (LIVE video streaming)
  • Tải ảnh lên (photo uploads)
  • Tính năng thích (like) và chia sẻ bài viết (share)
  • Và nhiều tính năng khác

Những use case như vậy rất phù hợp với kiến trúc microservices.


Tăng tốc độ phát triển cho doanh nghiệp

Kiến trúc microservices cho phép doanh nghiệp di chuyển nhanh hơn:

  • Các tính năng có thể được phát triển, kiểm thử và triển khai độc lập
  • Việc thay đổi một feature không ảnh hưởng đến các feature hiện có
  • Ít cần regression testing hơn so với kiến trúc nguyên khối

Nếu viết toàn bộ các tính năng này trong một codebase duy nhất, thì chẳng mấy chốc hệ thống sẽ trở nên rối rắm và khó bảo trì.


Ba cách tiếp cận khi thiết kế ứng dụng

Cho đến thời điểm này, chúng ta có ba hướng tiếp cận chính trong thiết kế hệ thống:

  1. Chọn kiến trúc Monolithic
  2. Chọn kiến trúc Microservices
  3. Bắt đầu với Monolithic, sau đó mở rộng dần sang Microservices

Việc lựa chọn monolithic hay microservices phụ thuộc rất nhiều vào use case cụ thể.

👉 Lời khuyên là: hãy giữ mọi thứ đơn giản, hiểu thật kỹ yêu cầu bài toán, rồi mới quyết định kiến trúc phù hợp.