Chi Phí Ẩn Của Microservices: Tại Sao Monolith Vẫn Thắng Thế

Giới thiệu

Đây là một sự thật khó chấp nhận: hầu hết các hệ thống quy mô lớn đều không bắt đầu bằng microservices. Netflix, Uber, Amazon—tất cả đều bắt đầu là các khối độc lập (monoliths) và phát triển dần dần. Tuy nhiên, ngày nay, các startup có dưới 100.000 người dùng lại kiến trúc hệ thống như thể họ là Netflix, thường chỉ vì một lý do đơn giản: nó trông đẹp trên hồ sơ xin việc (resume).

Thực tế khắc nghiệt là microservices đi kèm với một cái giá quá đắt mà nhiều đội ngũ không thể chi trả.

Những gì bạn sẽ học:

Chi phí hiệu năng thực tế của các hệ thống phân tán
Tại sao độ phức tạp giao dịch tăng vọt với microservices
Cơn ác mộng gỡ lỗi (debugging) làm giảm năng suất
Khi nào nên chọn kiến trúc khối độc lập module hóa (modular monolith)

Những Chi Phí Tiềm Ẩn

1. Chi Phí Hiệu Năng Phụ Trội: Thuế Mạng Lưới

Microservices không làm hệ thống của bạn nhanh hơn—chúng làm hệ thống trở nên linh hoạt hơn (resilient). Nhưng sự linh hoạt đó phải trả giá.

Vấn đề:

Gọi nội bộ (In-process calls): nanoseconds
Gọi qua mạng (Network calls): hàng chục đến hàng trăm milliseconds
Chi phí phụ trội về tuần tự hóa dữ liệu (JSON, protobuf)
Nhiều bước nhảy mạng (network hops) cho các thao tác đơn giản

Một yêu cầu người dùng đơn giản mất 10ms trong kiến trúc monolith có thể dễ dàng tăng lên 200ms+ khi qua nhiều dịch vụ. Bạn đang đánh đổi tốc độ để lấy sự phân tán.

2. Độ Phức Tạp Giao Dịch: Cơn Ác Mộng Saga

Với monolith, giao dịch rất đơn giản:

// Giao dịch ACID đơn giản
using var transaction = _dbContext.Database.BeginTransaction();
try
{
    await UpdateInventory(productId, quantity);
    await CreateOrder(order);
    await ProcessPayment(orderId);
    transaction.Commit();
}
catch
{
    transaction.Rollback();
}

Với microservices, bạn cần các giao dịch phân tán:

Triển khai mẫu Saga (Saga pattern)
Phối hợp cam kết hai pha (Two-phase commit coordination)
Logic bù trừ (Compensation logic) cho việc hoàn tác (rollbacks)
Xử lý lỗi qua các ranh giới dịch vụ

Kết quả: Logic nghiệp vụ của bạn chỉ chiếm 30% mã. 70% còn lại? Xử lý lỗi, thử lại (retries), và hoàn tác.

3. Địa Ngục Gỡ Lỗi: Cuộc Săn Lùng Log

Gỡ lỗi Monolith:

Một cơ sở mã
Một file log
Stack traces rõ ràng
Dễ dàng tái tạo cục bộ

Gỡ lỗi Microservices:

Lỗi xảy ra tại Dịch vụ D
Nguyên nhân gốc rễ: dữ liệu xấu từ Dịch vụ A
Dữ liệu đã đi qua Dịch vụ B và C
Logs nằm rải rác trên 10+ containers
Mất hàng giờ để tìm ra nơi yêu cầu bị chết

Kiểm thử end-to-end yêu cầu chạy đồng thời hơn 20 dịch vụ—tốn kém, chậm, và thường bị bỏ qua. Các nhà phát triển cuối cùng chỉ kiểm tra cục bộ bằng mock, bỏ sót các vấn đề tích hợp thực tế.

4. Chi Phí Phụ Trội Hạ Tầng: Đốt Tiền

Mỗi microservice cần:

Hệ điều hành/image cơ sở riêng
Các dependencies riêng biệt
Chi phí bộ nhớ riêng lẻ
Cấu hình mạng
Thiết lập giám sát và ghi log

Bạn đang trả tiền cho hạ tầng gấp 10 lần cho cùng một chức năng. Chi phí Cloud tăng vọt.

5. Monolith Phân Tán: Điều Tệ Nhất Của Cả Hai Thế Giới

Microservices được thiết kế kém tạo ra một khối độc lập phân tán—tất cả sự phức tạp của microservices mà không có bất kỳ lợi ích nào. Các dịch vụ liên kết chặt chẽ, dùng chung cơ sở dữ liệu và không thể mở rộng độc lập.

Điều này xảy ra khi đội ngũ thiếu:

Kiến thức chuyên sâu về nghiệp vụ (domain knowledge)
Hiểu rõ ranh giới ngữ cảnh (boundary context)
Kỹ năng phân tách dịch vụ đúng đắn

Con Đường Tốt Hơn: Monolith Module Hóa

Hãy bắt đầu với một modular monolith:

Một cơ sở mã duy nhất (dễ phát triển hơn)
Một lần triển khai duy nhất (hoạt động đơn giản hơn)
Ranh giới module rõ ràng (Thiết kế Hướng Miền - Domain-Driven Design)
Cơ sở dữ liệu dùng chung (giao dịch đơn giản hơn)

Khi nào nên tách: Chỉ trích xuất một dịch vụ khi:

Một module thực sự cần mở rộng độc lập
Bạn có chuyên môn DevOps thực sự
Bạn có ngân sách cho hạ tầng
Bạn có nhu cầu người dùng thực tế

Các công ty như Netflix đã tạo ra các tiêu chuẩn và công cụ microservices vì họ cần chúng ở quy mô lớn—chứ không phải vì bạn nên sao chép chúng một cách mù quáng.

Câu Hỏi Thực Sự

Trước khi chọn microservices, hãy hỏi:

Chúng ta có 100k+ người dùng đồng thời không? (Có lẽ là không)
Chúng ta có kỹ sư DevOps chuyên nghiệp không? (Thường là không)
Chúng ta có ngân sách hạ tầng không? (Hiếm khi)
Chúng ta có thực sự cần mở rộng độc lập không? (Thường là không)

Một monolith được thiết kế tốt với khả năng mở rộng ngang (horizontal scaling), bộ nhớ đệm thông minh (smart caching) và thiết kế cơ sở dữ liệu phù hợp có thể xử lý lưu lượng truy cập khổng lồ. Bạn không cần microservices để mở rộng.

Kết Luận

Kiến trúc tốt là kiến trúc giải quyết các vấn đề hiện tại với chi phí thấp nhất—chứ không phải kiến trúc trông giống Netflix nhất.

Quy tắc: Đừng xây dựng microservices trừ khi bạn có:

✅ Chuyên môn DevOps thực tế
✅ Ngân sách hạ tầng
✅ Nhu cầu mở rộng thực tế
✅ Độ trưởng thành của đội ngũ

Hãy bắt đầu với một monolith module hóa. Chỉ trích xuất dịch vụ khi bạn có nhu cầu thực tế, có thể đo lường được. Tương lai của bạn (và ngân sách startup của bạn) sẽ biết ơn điều đó.

Hãy nhớ: Hầu hết các hệ thống bắt đầu là monolith vẫn là monolith—và chúng vẫn hoạt động tốt.