Khi nào nên và không nên dùng microservices

Có một giai đoạn mình từng nghĩ microservices là chuẩn mực mặc định cho bất kỳ hệ thống nghiêm túc nào. Sau vài năm làm việc với cả hai kiểu kiến trúc, mình nghĩ khác: microservices là câu trả lời cho một vấn đề tổ chức, không phải vấn đề kỹ thuật.

Vấn đề thực sự mà microservices giải quyết

Khi một đội ngũ kỹ sư lớn lên đến vài chục người cùng làm trên một codebase duy nhất, việc triển khai bị nghẽn: một service lỗi kéo theo toàn bộ hệ thống không deploy được, một thay đổi nhỏ cần review từ nhiều nhóm không liên quan. Microservices tách hệ thống theo ranh giới đội ngũ, để mỗi nhóm có thể deploy độc lập. Đó là bài toán về con người và quy trình, được giải bằng kiến trúc.

Cái giá phải trả

Đổi lại, hệ thống có thêm độ trễ mạng giữa các service, cần cơ chế retry và circuit breaker, cần observability để debug một request đi qua năm service khác nhau, và cần một đội hạ tầng đủ mạnh để vận hành tất cả. Với một đội năm người, chi phí này thường lớn hơn lợi ích.

Một quy tắc thực dụng

Nếu một service duy nhất (monolith) đang khiến việc deploy chậm vì lý do tổ chức, kỹ thuật, chứ không phải vì thiếu kỷ luật trong code, đó là lúc nên cân nhắc tách nhỏ. Nếu vấn đề chỉ là code lộn xộn, tách thành microservices không giải quyết được gì, chỉ nhân bản sự lộn xộn đó ra thành nhiều service khó theo dõi hơn.

Bắt đầu với một monolith có ranh giới module rõ ràng bên trong. Tách ra khi có lý do tổ chức cụ thể, không phải vì đó là xu hướng.