Microservices vs Monolith: Khi nào nên 'đập đi xây lại'?

Trong thế giới phát triển phần mềm hiện đại, Microservices (kiến trúc vi dịch vụ) đã trở thành một từ khóa “thần thánh”. Nó được ví như liều thuốc tiên cho mọi vấn đề về khả năng mở rộng (scalability) của các hệ thống Monolith (kiến trúc nguyên khối) cũ kỹ.

Tuy nhiên, thực tế không phải lúc nào cũng màu hồng. Việc chuyển đổi từ Monolith sang Microservices sai thời điểm hoặc sai cách có thể biến hệ thống của bạn thành một “Distributed Monolith” (nguyên khối phân tán) - cơn ác mộng tồi tệ nhất của mọi kỹ sư DevOps.

Hôm nay, hãy cùng mổ xẻ vấn đề này dưới góc nhìn System Design thực chiến.

1. Monolith không “tệ” như bạn nghĩ

Trước khi nói về Microservices, hãy công bằng với Monolith. Các công ty tỷ đô như Stack Overflow hay Shopify vẫn vận hành phần lớn trên kiến trúc Monolith trong nhiều năm.

Ưu điểm của Monolith:

• Đơn giản để phát triển (Develop): Mọi thứ nằm trong một codebase. IDE hỗ trợ refactoring, navigating code cực tốt.
• Dễ dàng triển khai (Deploy): Chỉ cần build một file artifact (JAR, Docker Image) và chạy.
• Debug & Trace: Log nằm chung một chỗ, không cần distributed tracing phức tạp.
• Hiệu năng: Gọi hàm (function call) trong cùng process luôn nhanh hơn gọi qua mạng (network call/RPC).

Khi nào nên giữ Monolith?

• Team size nhỏ (< 20 kỹ sư).
• Domain nghiệp vụ chưa quá phức tạp.
• Traffic chưa đạt ngưỡng “hyper-scale”.

2. Cái giá của Microservices

Microservices không phải là “miễn phí”. Bạn đánh đổi sự đơn giản để lấy sự linh hoạt.

Độ phức tạp về vận hành (Operational Complexity)

Khi bạn tách một cục to thành 100 cục nhỏ:

• Bạn cần giám sát (monitoring) 100 services thay vì 1.
• Bạn cần quản lý cấu hình (config), log tập trung (centralized logging).
• Việc deploy cần orchestration tool như Kubernetes (K8s).

Vấn đề về dữ liệu (Data Consistency)

Trong Monolith, bạn có ACID transactions của Database bảo kê. Trong Microservices, mỗi service sở hữu một DB riêng. Làm sao để đảm bảo dữ liệu nhất quán giữa Service Order và Service Inventory?

• Bạn phải làm quen với Eventual Consistency.
• Phải xử lý Saga Pattern hoặc Two-Phase Commit (2PC) - những thứ cực kỳ đau đầu.

Độ trễ (Latency) & Lỗi mạng (Network Failure)

“The network is reliable” là một trong những sai lầm kinh điển của lập trình toán phân tán.

• Gọi qua mạng luôn có độ trễ.
• Service B chết thì Service A xử lý sao? (Circuit Breaker, Retries, Fallback).

3. Khi nào nên “đập đi xây lại”?

Đừng chuyển sang Microservices chỉ vì Netflix hay Uber làm thế. Hãy chuyển đổi khi bạn gặp các vấn đề sau (Pain points):

1. Scaling từng phần: Bạn cần scale module “Thanh toán” gấp 10 lần vào dịp Black Friday, nhưng module “User Profile” thì không. Monolith bắt bạn scale cả cục.
2. Độc lập công nghệ: Team AI muốn dùng Python, Team Backend muốn dùng Go, Team Web muốn dùng Node.js. Monolith (thường) trói bạn vào một stack.
3. Tốc độ deploy & Team autonomy: Khi team quá lớn (50-100+ người), việc merge code vào một repo chung trở thành nút thắt cổ chai. Bạn muốn Team A deploy tính năng mới mà không cần đợi Team B fix bug.
4. Fault Isolation: Một lỗi memory leak ở module “Xuất báo cáo” có thể làm crash cả hệ thống Monolith. Với Microservices, chỉ service báo cáo chết, web bán hàng vẫn sống.

4. Chiến lược chuyển đổi (Strangler Fig Pattern)

Đừng bao giờ “Rewrite from scratch” (Viết lại từ đầu). Đó là con đường dẫn đến thất bại. Hãy dùng chiến lược Strangler Fig (Cây đa bóp cổ):

1. Giữ nguyên Monolith đang chạy.
2. Xác định một module con cần tách (ví dụ: Notification Service).
3. Xây dựng Microservice mới cho module đó.
4. Dùng API Gateway hoặc Load Balancer để định tuyến traffic dần dần sang service mới.
5. Lặp lại cho đến khi Monolith chỉ còn là cái vỏ rỗng hoặc đủ nhỏ.

Kết luận

Kiến trúc phần mềm là nghệ thuật của sự đánh đổi (Trade-off).

“Nếu bạn không thể xây dựng một Monolith tốt, bạn cũng sẽ tạo ra một mớ hỗn độn Microservices.”

Hãy bắt đầu với Modular Monolith (Monolith được tổ chức tốt theo module). Khi hệ thống thực sự “đau”, lúc đó liều thuốc Microservices mới phát huy tác dụng.

Bạn đang ở giai đoạn nào? Monolith bền vững hay Microservices sành điệu? Chia sẻ dưới comment nhé!