Microservices hay monolith cho một sản phẩm mới?

Lập luận thường gặp cho microservices là “mở rộng độc lập từng phần”. Nó đúng về lý thuyết và hiếm khi là ràng buộc thật: chạy thêm instance của cả monolith gần như luôn rẻ hơn chi phí kỹ sư của việc tách dịch vụ, cho tới khi một thành phần có hồ sơ tài nguyên KHÁC HẲN — ví dụ xử lý video ngốn CPU bên cạnh một API chủ yếu chờ I/O. Đó mới là lý do kỹ thuật hợp lệ để tách, và nó tách đúng một thứ chứ không tách tất cả.

Điều quan trọng là monolith không có nghĩa là code lộn xộn. Modular monolith giữ ranh giới rõ ràng trong cùng một tiến trình: mỗi module có API công khai riêng, không được truy cập bảng của module khác, và có thể có schema riêng trong cùng database. Làm được vậy thì việc tách thành dịch vụ sau này là một refactor có kế hoạch chứ không phải một cuộc viết lại — bạn đã trả trước phần khó là xác định ranh giới.

Về chi phí phân tán, con số đáng nhớ: một lời gọi hàm là nano giây, một lời gọi mạng trong cùng vùng là khoảng nửa mili giây. Chênh nhau sáu bậc. Một endpoint gọi qua năm dịch vụ đã tốn vài mili giây chỉ cho mạng, và mỗi bước là một chỗ có thể timeout. Đó là lý do một kiến trúc microservices thiết kế kém thường CHẬM hơn monolith nó thay thế.