Microservices là một phong cách kiến trúc phần mềm phát triển một ứng dụng thành tập hợp các dịch vụ nhỏ, độc lập, mỗi dịch vụ chạy trong tiến trình riêng và giao tiếp với nhau qua các API nhẹ thường là HTTP REST. Khái niệm này được James Lewis và Martin Fowler định nghĩa bài bản từ năm 2014, và đến nay đã trở thành kiến trúc tiêu chuẩn cho hầu hết các hệ thống phần mềm quy mô lớn.
Microservices là gì?
Trái ngược với kiến trúc monolithic (kiến trúc nguyên khối) — nơi toàn bộ ứng dụng được xây dựng trong một codebase và một executable duy nhất — microservices chia ứng dụng thành nhiều service nhỏ theo năng lực nghiệp vụ (business capability). Ví dụ, một hệ thống thương mại điện tử có thể có service riêng cho giỏ hàng, thanh toán, quản lý người dùng, gợi ý sản phẩm… Mỗi service tự quản lý database riêng, tự deploy độc lập và được phát triển bởi một đội ngũ riêng.
Thuật ngữ “microservices” chính thức ra đời vào năm 2012 tại một hội thảo kiến trúc sư gần Venice, sau đó được phổ biến rộng rãi nhờ bài viết kinh điển của Martin Fowler. Nguyên tắc cốt lõi có nguồn gốc từ Conway’s Law: một hệ thống phần mềm thường phản chiếu cấu trúc tổ chức tạo ra nó, vì vậy chia nhỏ dịch vụ theo nghiệp vụ giúp các đội ngũ cross-functional tự chủ hoàn toàn sản phẩm của mình.
Đặc trưng cốt lõi của microservices
- Component hóa qua services: Phần mềm được chia thành các component dạng service out-of-process, có thể thay thế và nâng cấp độc lập mà không ảnh hưởng đến toàn hệ thống.
- Decentralized data management: Mỗi service tự quản lý database riêng (polyglot persistence), có thể dùng các loại database khác nhau — SQL, NoSQL — tùy theo nhu cầu.
- Smart endpoints, dumb pipes: Logic nghiệp vụ nằm hoàn toàn trong service, giao tiếp qua HTTP API đơn giản thay vì nhồi nhét vào ESB như kiến trúc SOA cũ.
- Infrastructure automation: CI/CD tự động hóa toàn bộ quy trình build, test và deploy cho từng service riêng lẻ.
- Design for failure: Hệ thống được thiết kế để chịu lỗi — circuit breaker, timeout — vì khi có nhiều service, remote call luôn tiềm ẩn rủi ro thất bại.
Lợi ích của kiến trúc microservices
Theo tài liệu chính thức từ AWS, microservices mang lại 5 lợi ích chính:
- Agility (linh hoạt): Đội ngũ nhỏ độc lập phát triển service riêng, rút ngắn chu kỳ phát triển sản phẩm đáng kể.
- Flexible scaling (mở rộng linh hoạt): Chỉ scale service đang bị quá tải thay vì phải scale toàn bộ ứng dụng như monolith.
- Easy deployment: Triển khai độc lập từng service, rollback dễ dàng, chi phí thất bại thấp.
- Technological freedom: Mỗi đội tự chọn ngôn ngữ lập trình, framework và database phù hợp với bài toán của mình.
- Resilience: Service gặp sự cố chỉ ảnh hưởng đến một phần chức năng, không sập toàn bộ ứng dụng.
Thách thức và nhược điểm
Microservices không phải là giải pháp vạn năng. Martin Fowler cảnh báo rằng microservices luôn đi kèm một chi phí riêng gọi là “Microservice Premium”:
- Độ phức tạp của hệ phân tán: Remote call chậm hơn call nội bộ nhiều lần và luôn có nguy cơ thất bại. Gỡ lỗi, tracing trên nhiều service khó khăn hơn rất nhiều.
- Eventual consistency: Giữ tính nhất quán dữ liệu mạnh giữa nhiều database riêng lẻ gần như bất khả thi, phải chấp nhận mô hình nhất quán cuối cùng.
- Operational complexity: Cần đội vận hành (DevOps) trưởng thành để quản lý hàng chục, hàng trăm service deploy thường xuyên.
- Chi phí hạ tầng: Nhiều service đồng nghĩa với nhiều server, nhiều pipeline CI/CD, nhiều công cụ monitoring hơn.
Khi nào nên dùng microservices?
Khuyến nghị chung từ Fowler và các chuyên gia kiến trúc là chiến lược “Monolith First”: bắt đầu với kiến trúc nguyên khối, chỉ tách thành microservices khi thực sự cần thiết. Hãy cân nhắc microservices khi:
- Đội ngũ phát triển đủ lớn (nhiều nhóm làm việc song song cần tự chủ).
- Ứng dụng cần khả năng scale độc lập từng phần theo nhu cầu.
- Yêu cầu triển khai thường xuyên và độc lập cho từng module.
- Đã có hạ tầng DevOps và đội vận hành trưởng thành.
Ngược lại, với dự án nhỏ, sản phẩm mới khởi nghiệp hoặc đội ngũ còn non trẻ, monolithic vẫn là lựa chọn tối ưu hơn nhiều.
Ví dụ thực tế
Uber từng vận hành khoảng 2.200 microservices, sau đó phải gộp lại thành 70 domain lớn hơn qua kiến trúc DOMA (Domain-Oriented Microservice Architecture) vì độ phức tạp tăng vọt. Netflix là đơn vị tiên phong với kiến trúc fine-grained SOA trên quy mô web, nổi tiếng với bộ công cụ Simian Army chủ động gây lỗi hệ thống trong giờ làm việc để kiểm tra khả năng chịu lỗi. Amazon cũng là nguồn gốc của triết lý “you build, you run it” — đội phát triển phải tự vận hành dịch vụ mình tạo ra.
Các thành phần hỗ trợ microservices
- API Gateway: Điểm vào duy nhất cho client, xử lý authentication, logging, load balancing, rate limiting trước khi chuyển request tới service phù hợp.
- Service discovery: Cơ chế tìm địa chỉ service động khi IP thay đổi do scale hoặc restart. Kubernetes có built-in, AWS cung cấp qua Route 53 và ECS.
- Containerization: Docker đóng gói service cùng dependency, Kubernetes quản lý orchestration, autoscaling và phục hồi lỗi. Không bắt buộc nhưng gần như là tiêu chuẩn thực tế.
- Observability: Centralized logging, distributed tracing (OpenTelemetry, AWS X-Ray) và monitoring là bắt buộc vì một request có thể đi qua nhiều service.
- Messaging: Kafka, SQS, Azure Service Bus cho giao tiếp bất đồng bộ, giảm coupling giữa các service.
Tổng kết
Microservices là kiến trúc mạnh mẽ giúp các tổ chức lớn đạt được tốc độ phát triển, khả năng mở rộng và sự linh hoạt vượt trội. Tuy nhiên, đây là kiến trúc phức tạp đi kèm chi phí vận hành cao, không phù hợp cho mọi dự án. Nguyên tắc đúng đắn nhất là bắt đầu với monolith, và chỉ chuyển sang microservices khi lợi ích thực sự rõ ràng — đúng như khuyến nghị “Monolith First” từ chính tác giả khái niệm này.
Nếu bạn đang tìm hiểu để lựa chọn kiến trúc cho dự án mới, hãy bắt đầu từ bài viết gốc của Martin Fowler tại martinfowler.com, tài liệu kiến trúc microservices của AWS và hướng dẫn từ Microsoft Azure Architecture Center.
