Engineering Notes

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

6 min read

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:

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 đề:

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:

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:

Gỡ lỗi Microservices:

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:

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:

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

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

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

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:

  1. Chúng ta có 100k+ người dùng đồng thời không? (Có lẽ là không)
  2. Chúng ta có kỹ sư DevOps chuyên nghiệp không? (Thường là không)
  3. Chúng ta có ngân sách hạ tầng không? (Hiếm khi)
  4. 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ó:

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.

#microservices architecture backend monolith performance
← Back to Articles
Chi Phí Ẩn Của Microservices: Tại Sao Monolith Vẫn Thắng Thế - Ginbok