webdev microservices programming backenddevelopment

Bạn Có Nên Quay Lại Với "Monolith" Trong Năm 2025? (Không Phải Cái Monolith "Mì Tôm" Ngày Xưa Đâu Nha!)

Lê Lân

08/07/2025

Kiến Trúc Modular Monolith và Microservices: Lựa Chọn Tối Ưu Cho Hệ Thống Phần Mềm Quy Mô Lớn 2025

Mở Đầu

Trong thập kỷ vừa qua, microservices đã trở thành mô hình kiến trúc được săn đón hàng đầu cho các hệ thống phần mềm có quy mô lớn. Các nhà lãnh đạo kỹ thuật, CTO và kiến trúc sư tập trung tách rời những ứng dụng đơn khối (monolith) thành các dịch vụ phân tán, có thể triển khai độc lập. Lý do khả quan cho xu hướng này là khả năng đem lại tính đàn hồi, tự chủ và hiệu năng ở quy mô lớn.

Tuy nhiên, bước sang năm 2025, câu chuyện bắt đầu chuyển dịch. Nhiều nhóm kỹ sư bắt đầu đánh giá lại sự phức tạp và chi phí phát sinh của microservices, đồng thời tái khám phá giá trị của kiến trúc monolith — không phải là monolith phức tạp, khó bảo trì thời trước mà là modular monolith, một kiến trúc có cấu trúc rõ ràng, gắn kết giữa sự đơn giản và khả năng mở rộng.

Bài viết này sẽ khám phá:

Modular monolith và microservices là gì và không phải là gì

Những đánh đổi quan trọng giữa hai mô hình này

Khi nào nên chọn mô hình nào cho dự án của bạn

Cách thiết kế modular monolith một cách chuyên nghiệp

📦 What Is a Modular Monolith? (Modular Monolith Là Gì?)

Định nghĩa

Modular monolith là kiến trúc phần mềm trong đó toàn bộ ứng dụng được triển khai dưới dạng một đơn vị duy nhất (monolith), nhưng được chia thành các module độc lập về mặt logic, với ranh giới, chức năng và giao diện rõ ràng.

Có thể hiểu nó giống như một bình nguyên khối về mặt triển khai, nhưng mang tinh thần phân tách và tách biệt như microservices.

Đặc điểm chính

Triển khai dưới dạng một đơn vị duy nhất (ví dụ: một file nhị phân, một container hoặc một process)

Cấu trúc nội bộ theo mô hình phân module, thường dựa trên Domain-Driven Design (DDD)

Mỗi module giữ được sự đóng gói mạnh đối với logic nghiệp vụ (ví dụ: User, Billing, Inventory)

Các giao diện nội bộ (API) được định nghĩa rõ ràng giữa các module

Cơ sở dữ liệu có thể dùng chung nhưng quyền truy cập được giới hạn theo module, đôi khi sử dụng ràng buộc từ code

🧩 Microservices Recap (Tổng Quan Microservices)

Đặc điểm chính

Dịch vụ được triển khai và vận hành độc lập

Giao tiếp qua mạng (REST, gRPC, messaging)

Mỗi microservice sở hữu một cơ sở dữ liệu riêng biệt

Mỗi dịch vụ có thể có đội ngũ phát triển riêng (đặc biệt ở các doanh nghiệp lớn)

Yêu cầu vận hành hạ tầng phức tạp: orchestration, service discovery, CI/CD riêng cho từng dịch vụ

⚔️ Modular Monolith vs Microservices: Những Đánh Đổi

Khía cạnh	Modular Monolith	Microservices
Deployment	Một file nhị phân hoặc container duy nhất	Dịch vụ độc lập, triển khai riêng lẻ
Quyền tự chủ đội nhóm	Chia sẻ codebase, sở hữu nội bộ module	Sở hữu hoàn toàn, repo riêng biệt
Giao tiếp	Gọi hàm nội bộ (in-process)	Giao tiếp qua mạng, API hoặc message queue
Hiệu năng	Nhanh, không có độ trễ mạng	Chậm hơn do gọi mạng nhiều lần
Khả năng mở rộng	Mở rộng toàn bộ ứng dụng	Mở rộng theo từng dịch vụ riêng biệt
Trải nghiệm phát triển	Dễ dàng debug, test, onboard	Môi trường phát triển phức tạp
Tooling & Overhead	CI/CD đơn giản, build nhanh	Phức tạp, cần Kubernetes, orchestration
Phân tách lỗi	Lỗi làm sập toàn bộ	Lỗi bị giới hạn trong dịch vụ riêng

Lưu ý: Modular monolith thường phù hợp với nhóm nhỏ, quy mô vừa và khi cần sự đơn giản để nhanh chóng phát triển, trong khi microservices phù hợp cho các tổ chức lớn với nhu cầu mở rộng, phân luồng và fault-tolerance phức tạp hơn.

🧠 Tại Sao Modular Monolith Đang Trở Lại?

Trong nhiều trường hợp, các team đã chuyển đổi sang microservices quá sớm hoặc chưa đủ sự sẵn sàng về kiến trúc, dẫn đến các hệ quả:

Số lượng dịch vụ quá nhiều, mỗi dịch vụ quá nhỏ

Logic trùng lặp và đa dạng công nghệ trong cùng hệ thống

Khó debug các lỗi phân tán

Triển khai phức tạp, DevOps trở nên lắt nhắt

Độ trễ và chi phí không cần thiết

Modular monolith tạo ra sự cân bằng: ✅ Giữ được sự đơn giản ✅ Tránh được các vấn đề phức tạp liên quan tới hệ phân tán ✅ Cấu trúc code dựa trên domain rõ ràng

📐 Thiết Kế Modular Monolith Chuyên Nghiệp

1. Tổ chức code theo domain (Domain-Driven Design)

/src
  /modules
    /users
      user.controller.js
      user.service.js
      user.model.js
    /billing
      billing.controller.js
      billing.service.js
      ...

Mỗi module:

Nội bộ liên kết chặt chẽ (cohesive)

Chỉ lộ ra giao diện công cộng (public interface)

Không được phép truy cập trực tiếp vào phần bên trong module khác

2. Sử dụng Internal APIs (Giao diện nội bộ)

Thay vì gọi hàm trực tiếp qua module khác, hãy cung cấp các lớp dịch vụ để gọi:

// billing.module.ts
export class BillingService {
  chargeUser(userId, amount) { ... }
}

// user.module.ts
import { BillingService } from '../billing'
BillingService.chargeUser(user.id, 100)

Điều này giúp hợp đồng giữa các module rõ ràng, dễ thay thế.

3. Bắt buộc ranh giới thông qua công cụ linting và build

Sử dụng Nx hoặc Lerna cho monorepo phân module

Viết rules ESLint tùy chỉnh hạn chế nhập khẩu code chéo giữa module

Phân tích tĩnh code để giảm tight coupling

4. Chuẩn bị khả năng chuyển đổi sang microservices

Trừu tượng truy cập database qua service interface

Tránh trạng thái toàn cục hoặc phụ thuộc cross-module

Ưu tiên mô hình pub/sub nội bộ

Điều này giữ khả năng extract module thành microservice sau này.

🚦 Khi Nào Nên Chọn Mô Hình Nào?

🟢 Chọn Modular Monolith Khi:

Bạn đang xây dựng sản phẩm hoặc MVP mới

Đội phát triển dưới 30 người

Muốn đẩy nhanh tốc độ iteration mà không thêm phức tạp hạ tầng

Chưa cần scale khổng lồ hoặc routing phức tạp toàn cầu

Muốn thiết kế module rõ ràng mà không phân tán sớm

🟡 Chọn Microservices Khi:

Tổ chức có nhóm lớn cần làm việc độc lập

Gặp yêu cầu scale từng domain riêng biệt

Cần hỗ trợ đa ngôn ngữ hoặc công nghệ khác nhau

Cần tính fault isolation cao cho các dịch vụ quan trọng

Đã vượt qua giới hạn của monolith và có kế hoạch rõ ràng để tách dịch vụ

🧱 Ví Dụ Thành Công Thực Tế

Nhiều công ty lớn từng bắt đầu với monolith và dần tách ra khi cần:

Basecamp: Modular monolith với Rails nhiều năm

Shopify: “Componentized monolith” dùng Rails Engines

GitHub: Vẫn chủ yếu monolith nhưng tuân thủ modular chặt

Amazon: Khởi đầu monolith rồi chuyển dần sang microservices

Điều quan trọng là: hệ thống lớn không bắt đầu là một hệ thống phân tán mà phát triển thành như vậy theo thời gian.

✅ Kết Luận

Modular monolith không phải bước lùi, mà là bước tiến trong việc tối ưu sự rõ ràng kiến trúc và tăng tốc độ phát triển

Giúp mở rộng phần mềm mà không bị ngập trong độ phức tạp của hệ phân tán

Cho phép code theo domain ngay từ đầu

Và chỉ chuyển đổi sang microservices khi thực sự cần thiết dựa trên nhu cầu kinh doanh

💬 Kêu Gọi Hành Động

Bạn đang mở rộng sản phẩm hoặc lên kế hoạch xây dựng lại hệ thống? 💡 Hãy trao đổi về kiến trúc! Tôi giúp các công ty thiết kế hệ thống full-stack có thể scale và dễ kiểm thử, đảm bảo tính linh hoạt khi phát triển. 👉 Theo dõi tôi trên Dev.to hoặc liên hệ qua educationgate.org để thảo luận về kiến trúc, scaling đội ngũ hoặc dự án tiếp theo.

Tham Khảo

Fowler, M. (2023). Monolith vs Microservices. martinfowler.com

Richardson, C. (2024). "Modular Monoliths: From Theory to Practice"

Bass, L., Weber, I., Zhu, L. (2020). DevOps and Microservices Architecture

Basecamp Engineering Blog

Shopify Engineering Blog

GitHub Engineering Updates

Amazon Technical Documents and Migration Stories June 1, 2025