Wavi Books · System Design & Backend

Microservices Architecture là gì? Khi nào doanh nghiệp nên dùng?

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

Phân tích microservices, monolith, ranh giới dịch vụ, dữ liệu, event-driven và chi phí vận hành cho đội ngũ backend.

## Microservices Architecture là gì?

## Câu trả lời ngắn trước khi đi vào kiến trúc

Phân tích microservices, monolith, ranh giới dịch vụ, dữ liệu, event-driven và chi phí vận hành cho đội ngũ backend. Hãy bắt đầu từ yêu cầu, điểm hỏng và hậu quả nghiệp vụ rồi mới chọn thành phần kỹ thuật.

Một hệ thống có thể chạy rất ổn trong buổi demo nhưng bắt đầu lộ vấn đề khi lưu lượng tăng, mạng chập chờn hoặc một dịch vụ phía sau phản hồi chậm. Lúc đó, câu hỏi đáng giá không phải là thêm công nghệ nào cho sơ đồ đẹp hơn, mà là điểm hỏng thật sự nằm ở đâu và người dùng chịu hậu quả gì.

Microservices có thể giúp nhiều đội phát triển độc lập, nhưng cũng biến một lần gọi hàm thành cuộc trò chuyện qua mạng có thể thất bại. Đây là lựa chọn tổ chức lẫn kỹ thuật, không phải huy hiệu của hệ thống hiện đại.

Microservices là cách tổ chức hệ thống thành các dịch vụ có ranh giới rõ, có thể phát triển và triển khai tương đối độc lập. Mỗi dịch vụ thường sở hữu logic nghiệp vụ và dữ liệu của phạm vi mình phụ trách. Lợi ích chính là giảm phụ thuộc giữa đội ngũ, không phải làm hệ thống tự động nhanh hơn.

## Khi nào microservices có giá trị?

Microservices phù hợp khi sản phẩm đủ lớn, nhiều đội cần triển khai độc lập, ranh giới nghiệp vụ đã tương đối rõ và tổ chức có năng lực vận hành phân tán. Nếu một đội nhỏ đang tìm product-market fit, modular monolith thường đơn giản và kinh tế hơn.

## Chia nhỏ dịch vụ cũng chia nhỏ sự chắc chắn

Mỗi service sở hữu một năng lực nghiệp vụ và có thể triển khai riêng. Đổi lại, dữ liệu phân tán, quan sát, kiểm thử và xử lý lỗi đều khó hơn một ứng dụng nguyên khối.

## Chuyện gì xảy ra khi đem vào dự án thật?

Một đội nhỏ với sản phẩm còn đổi nhanh thường tiến tốt hơn bằng modular monolith. Tách sớm có thể khiến developer dành thời gian cho hạ tầng thay vì học từ người dùng.

## Nếu bắt đầu hôm nay, tôi sẽ làm thế này

Chỉ tách khi ranh giới nghiệp vụ đủ rõ và vấn đề triển khai độc lập đã thực sự xuất hiện. Kiến trúc tốt là kiến trúc phù hợp với đội ngũ hôm nay và còn đường phát triển ngày mai.

## Chi phí thường bị đánh giá thấp

Khi tách dịch vụ, lời gọi trong bộ nhớ trở thành giao tiếp qua mạng. Bạn phải xử lý timeout, retry, idempotency, quan sát phân tán, version API và dữ liệu không đồng bộ. CI/CD, logging, tracing và platform engineering trở thành phần bắt buộc thay vì tùy chọn.

## Dữ liệu và event-driven

Một microservice nên sở hữu dữ liệu của nó thay vì nhiều dịch vụ cùng sửa một database. Khi cần phối hợp, đội ngũ có thể dùng API hoặc sự kiện. Event-driven giúp giảm liên kết trực tiếp nhưng tạo thêm thách thức về schema, thứ tự, trùng lặp và khả năng replay.

## Lộ trình đọc

Building Microservices 2nd Edition giúp hiểu ranh giới dịch vụ, tổ chức và tiến hóa kiến trúc. Microservices: Up and Running trình bày hành trình triển khai từng bước. Building Event-Driven Microservices phù hợp khi hệ thống cần Kafka, event streaming và quyền sở hữu dữ liệu theo domain.

Với doanh nghiệp Việt Nam, quyết định nên xuất phát từ cấu trúc đội ngũ, tốc độ thay đổi và năng lực vận hành. Chọn microservices chỉ vì xu hướng có thể làm chậm sản phẩm và tăng chi phí đáng kể.

## Bài tập tìm ranh giới trước khi tách service

Chọn một ứng dụng bán hàng nguyên khối và xác định các năng lực nghiệp vụ như catalog, đặt hàng, thanh toán. Viết ra dữ liệu, người chịu trách nhiệm và nhịp thay đổi của từng phần. Sau đó chọn một phần để tách và liệt kê thêm chi phí về mạng, triển khai, quan sát và nhất quán. Nếu lợi ích chưa vượt chi phí, giữ modular monolith là một quyết định trưởng thành.

## Ví dụ xuyên suốt để nối kiến thức

Một nền tảng thương mại có catalog thay đổi thường xuyên, thanh toán cần kiểm soát chặt và tìm kiếm có tải riêng. Đây có thể là ranh giới dịch vụ hợp lý khi mỗi phần có team và nhịp triển khai khác. Nếu cùng một nhóm sửa cả ba, tách service có thể chỉ thêm cuộc gọi mạng.

## Khung triển khai từ thử nghiệm đến thực tế

Lý do tốt để tách gồm quyền sở hữu rõ, nhu cầu scale khác biệt và khả năng triển khai độc lập mang lại giá trị. Lý do “công ty lớn đều dùng” không đủ vì bối cảnh tổ chức khác nhau.

### Bốn bước nên đi theo thứ tự

- Làm modular monolith với ranh giới domain và dependency rõ.

- Đo điểm nghẽn về đội ngũ, triển khai hoặc khả năng mở rộng.

- Tách một bounded context có dữ liệu và API được xác định.

- Đầu tư CI/CD, observability, security và platform trước khi nhân rộng.

## Trade-off cần nhìn thẳng

Microservices đổi gọi hàm thành mạng, transaction thành consistency phân tán và debug thành truy vết nhiều dịch vụ. Lợi ích tự chủ chỉ xuất hiện khi tổ chức cũng có khả năng sở hữu độc lập.

## Đánh giá bằng kết quả thay vì cảm giác

Theo dõi lead time, tần suất deploy, tỷ lệ lỗi thay đổi và thời gian phục hồi, bên cạnh latency và availability. Nếu mọi thay đổi vẫn phải phối hợp nhiều team, kiến trúc chưa tạo tự chủ.

## Giá trị đối với năng lực nghề nghiệp

Kỹ sư trưởng thành biết giữ hệ thống đơn giản cho đến khi có bằng chứng cần phức tạp hơn, đồng thời chuẩn bị ranh giới để có thể tách khi thời điểm đến.

## Góc nhìn dành cho developer Việt Nam

Với backend developer và kỹ sư phần mềm tại Việt Nam, kiến thức này đặc biệt hữu ích khi làm sản phẩm có thanh toán, đơn hàng, dữ liệu khách hàng hoặc chuẩn bị phỏng vấn System Design. Nhà tuyển dụng thường quan tâm cách bạn giải thích giả định và đánh đổi hơn là số lượng công nghệ bạn nhớ tên.

## Đọc tiếp trên Wavi Books

Nếu bạn muốn học chủ đề này theo một lộ trình có cấu trúc, có thể xem Building Microservices, 2nd Edition bản tiếng Việt tại [Wavi Books](/sach/building-microservices-sam-newman-2026). Sách liên quan được đặt sau phần kiến thức để bạn có thể đánh giá nội dung trước khi chọn mua.