Trả lời nhanh: Microservices (kiến trúc vi dịch vụ) là cách xây dựng ứng dụng thành nhiều dịch vụ nhỏ chạy độc lập. Mỗi dịch vụ lo một nghiệp vụ, giữ dữ liệu riêng, giao tiếp qua API hoặc hàng đợi sự kiện, và được triển khai, mở rộng riêng.
Điểm chính
- Đối lập với microservices là monolithic (nguyên khối): mọi chức năng nằm trong một ứng dụng, triển khai cùng lúc. Monolithic không lạc hậu, chỉ hợp với bối cảnh khác.
- Microservices đổi sự phức tạp trong mã nguồn lấy sự phức tạp của hệ thống phân tán: mạng, dữ liệu, giám sát, bảo mật.
- Nên cân nhắc khi nghiệp vụ đã rõ, nhiều đội cùng phát triển và đã có nền tảng tự động hoá. Dự án mới, đội nhỏ nên bắt đầu bằng monolith chia module.
- Cần các mẫu thiết kế (API gateway, saga, circuit breaker) và khả năng quan sát hệ thống ngay từ đầu.
- Cách chuyển đổi an toàn là tách dần theo mẫu Strangler Fig, không viết lại toàn bộ một lần.
Mục lục
- Microservices là gì?
- Kiến trúc microservices gồm những thành phần nào?
- Microservices và monolithic khác nhau thế nào?
- Ưu nhược điểm microservices là gì?
- Khi nào nên và không nên dùng microservices?
- Doanh nghiệp đi trước học được gì?
- Các mẫu thiết kế microservices phổ biến là gì?
- Các dịch vụ giao tiếp với nhau như thế nào?
- Container và Kubernetes liên quan gì đến microservices?
- Làm sao quan sát và giám sát hệ thống microservices?
- Bảo mật microservices cần chú ý gì?
- Lộ trình chuyển từ monolithic sang microservices
- Những sai lầm phổ biến khi làm microservices
- Câu hỏi thường gặp
Microservices là gì?
Microservices, còn gọi là kiến trúc vi dịch vụ (microservice architecture), là một phong cách thiết kế phần mềm. Thay vì gom mọi chức năng vào một chương trình lớn, bạn chia ứng dụng thành nhiều dịch vụ nhỏ. Mỗi dịch vụ chạy trong tiến trình riêng, phụ trách một năng lực nghiệp vụ (đơn hàng, thanh toán, kho) và nói chuyện với dịch vụ khác qua HTTP API hoặc hàng đợi thông điệp.
Định nghĩa được trích dẫn nhiều nhất đến từ bài “Microservices” của James Lewis và Martin Fowler (03/2014): ứng dụng là tập các dịch vụ nhỏ xoay quanh năng lực nghiệp vụ, triển khai độc lập bằng công cụ tự động, quản lý tập trung ở mức tối thiểu, mỗi dịch vụ có thể dùng ngôn ngữ và công nghệ lưu trữ khác nhau. Hai tác giả thừa nhận không có định nghĩa hình thức chính xác. Cũng theo bài này, thuật ngữ được bàn tại một hội thảo kiến trúc sư phần mềm gần Venice (Ý) tháng 5/2011 và được chọn làm tên gọi chính thức tháng 5/2012.
Lewis và Fowler nêu 9 đặc điểm thường gặp, đáng nhớ nhất là: tổ chức theo năng lực nghiệp vụ, đội xây cũng là đội vận hành, mỗi dịch vụ tự quản dữ liệu, tự động hoá hạ tầng và thiết kế để chịu lỗi.
Một ví dụ dễ hình dung
Ví dụ minh hoạ. Một chuỗi bán lẻ có website gồm danh mục sản phẩm, giỏ hàng, đơn hàng, thanh toán, kho, khách hàng thân thiết.
- Kiểu monolithic: tất cả nằm trong một ứng dụng, một cơ sở dữ liệu. Sửa một dòng ở phần khách hàng thân thiết cũng phải triển khai lại cả website. Mùa khuyến mãi, giỏ hàng quá tải thì phải nhân bản cả ứng dụng.
- Kiểu microservices: mỗi chức năng là một dịch vụ do một đội phụ trách. Đội thanh toán phát hành bản mới mà không chờ đội kho. Mùa khuyến mãi, chỉ dịch vụ giỏ hàng và đơn hàng được thêm máy. Dịch vụ gợi ý sản phẩm lỗi thì khách vẫn đặt hàng được.
Cái giá phải trả: đội kỹ thuật giờ vận hành hàng chục chương trình nói chuyện với nhau qua mạng.
Kiến trúc microservices gồm những thành phần nào?
Ngoài các dịch vụ nghiệp vụ, một hệ thống microservices thực tế cần một lớp hạ tầng giúp các dịch vụ tìm thấy nhau, nói chuyện an toàn và được giám sát.
| Thành phần | Vai trò |
|---|---|
| Dịch vụ nghiệp vụ | Mỗi dịch vụ xử lý một nghiệp vụ, có mã nguồn, quy trình build và dữ liệu riêng |
| API gateway | Cửa vào duy nhất cho web, mobile, đối tác; định tuyến, xác thực, giới hạn tần suất gọi |
| Service discovery | “Danh bạ” ghi địa chỉ hiện tại của từng dịch vụ, vì địa chỉ đổi liên tục khi tăng giảm máy |
| Message broker | Hàng đợi trung chuyển sự kiện giữa các dịch vụ theo kiểu bất đồng bộ |
| Cơ sở dữ liệu riêng | Dịch vụ khác chỉ truy cập dữ liệu qua API hoặc sự kiện, không đọc thẳng bảng |
| Container và điều phối | Đóng gói dịch vụ, tự khởi động lại khi lỗi, tự tăng giảm số bản chạy |
| CI/CD | Đường ống build, kiểm thử, triển khai tự động cho từng dịch vụ |
| Observability | Thu log, metric, trace để biết hệ thống khoẻ hay ốm, lỗi nằm ở đâu |
Microservices và monolithic khác nhau thế nào?
Monolithic là kiến trúc mà toàn bộ ứng dụng được build thành một khối triển khai duy nhất, thường dùng chung một cơ sở dữ liệu. Phần lớn phần mềm khởi đầu theo cách này, và nhiều hệ thống lớn vẫn chạy tốt với nó.
| Tiêu chí | Monolithic | Microservices |
|---|---|---|
| Đơn vị triển khai | Một khối duy nhất | Nhiều dịch vụ, triển khai độc lập |
| Dữ liệu | Thường một cơ sở dữ liệu chung, giao dịch đơn giản | Mỗi dịch vụ một kho; giao dịch xuyên dịch vụ cần mẫu như saga |
| Tốc độ khởi đầu | Nhanh, ít hạ tầng | Chậm hơn vì phải dựng nền tảng, CI/CD, giám sát |
| Khi đội lớn lên | Chậm dần: nhiều người sửa chung, phải xếp hàng phát hành | Nhanh hơn nếu ranh giới đúng: mỗi đội phát hành theo nhịp riêng |
| Mở rộng | Nhân bản cả ứng dụng | Chỉ mở rộng dịch vụ đang chịu tải |
| Cô lập lỗi | Một lỗi nặng có thể kéo sập cả ứng dụng | Khoanh vùng được, nhưng lỗi có thể lan theo chuỗi nếu thiếu timeout |
| Gỡ lỗi | Một log, một stack trace | Phải lần theo yêu cầu qua nhiều dịch vụ |
| Chi phí vận hành | Thấp ở quy mô nhỏ | Cao hơn: nhiều tiến trình, công cụ, kỹ năng vận hành |
Modular monolith (nguyên khối chia module) là con đường ở giữa: vẫn triển khai một khối, nhưng bên trong chia module theo nghiệp vụ, module này không đọc thẳng dữ liệu của module kia. Bạn có phần lớn sự gọn gàng của microservices mà chưa phải trả chi phí hệ thống phân tán.
Distributed monolith (nguyên khối phân tán) là kết quả tệ nhất: tách thành nhiều dịch vụ nhưng vẫn dùng chung cơ sở dữ liệu, gọi nhau dày đặc và phải phát hành cùng lúc. Uber gọi hiện tượng này là “networked monoliths” trong bài viết năm 2020.
Ưu nhược điểm microservices là gì?
Ưu điểm
- Triển khai độc lập: mỗi đội phát hành khi sẵn sàng, tính năng đến tay người dùng nhanh hơn.
- Mở rộng có chọn lọc: chỉ tăng tài nguyên cho phần đang chịu tải.
- Khoanh vùng sự cố: nếu thiết kế tốt, dịch vụ phụ lỗi không làm dừng chức năng cốt lõi.
- Đội nhỏ tự chủ: mỗi đội sở hữu trọn một nghiệp vụ. Điều này khớp với định luật Conway (Melvin Conway, 1968): thiết kế hệ thống phản chiếu cấu trúc giao tiếp của tổ chức.
Nhược điểm
- Phức tạp của hệ thống phân tán: lời gọi qua mạng có thể chậm, mất, trùng lặp; mã nào gọi dịch vụ khác cũng phải tính đến.
- Dữ liệu khó nhất quán: không còn một giao dịch bao trọn; dữ liệu thường chỉ nhất quán sau một khoảng thời gian (eventual consistency).
- Gỡ lỗi khó: Uber kể có lần điều tra một sự cố phải đi qua khoảng 50 dịch vụ của 12 đội.
- Chi phí phụ trội: nền tảng, công cụ, nhân sự vận hành. Martin Fowler gọi đây là “microservice premium”.
- Rủi ro chia sai ranh giới: chuyển chức năng giữa hai dịch vụ khó hơn nhiều so với giữa hai module.
- Bề mặt tấn công rộng hơn: nhiều điểm cuối mạng, nhiều thông tin xác thực cần quản lý.
Khi nào nên và không nên dùng microservices?
Trong bài “Monolith First” (06/2015), Martin Fowler khuyên không nên bắt đầu dự án mới bằng microservices. Giai đoạn đầu, tốc độ quan trọng nhất, và đội gần như không thể vẽ đúng ranh giới dịch vụ khi chưa hiểu sâu nghiệp vụ. Xây monolith trước giúp tìm ra ranh giới đúng rồi mới tách. Bảng dưới giúp bạn tự đánh giá; nếu phần lớn câu trả lời rơi vào cột phải, hãy hoãn microservices.
| Câu hỏi | Nên cân nhắc microservices | Nên giữ monolith chia module |
|---|---|---|
| Nghiệp vụ ổn định chưa? | Đã chạy thật nhiều năm, ranh giới các mảng rõ | Sản phẩm mới, còn thay đổi liên tục |
| Quy mô đội? | Nhiều đội cùng sửa một hệ thống, thường giẫm chân nhau | Một hoặc hai đội nhỏ |
| Nhu cầu mở rộng? | Các phần chịu tải rất khác nhau | Tải đều, vài máy chủ là đủ |
| Năng lực vận hành? | Đã có CI/CD, giám sát, người trực sự cố | Triển khai còn thủ công |
| Yêu cầu nhất quán? | Chấp nhận dữ liệu đồng bộ chậm vài giây ở nhiều chỗ | Hầu hết nghiệp vụ cần nhất quán tức thì |
Lưu ý: “Công ty lớn dùng microservices” không phải lý do đủ. Họ chuyển khi đã có hàng trăm, hàng nghìn kỹ sư và tải rất lớn. Với doanh nghiệp vừa và nhỏ, monolith chia module chạy trên đám mây thường hiệu quả hơn trong vài năm đầu.
Doanh nghiệp đi trước học được gì?
Bốn câu chuyện dưới đây do chính các công ty công bố.
| Doanh nghiệp | Điều đã xảy ra | Bài học |
|---|---|---|
| Netflix | Sau sự cố hỏng cơ sở dữ liệu tháng 8/2008 khiến không gửi được DVD trong 3 ngày, Netflix chuyển dần lên đám mây và từ ứng dụng nguyên khối sang hàng trăm microservices; hoàn tất đầu năm 2016, sau khoảng 7 năm (theo bài Netflix đăng 12/02/2016) | Chuyển đổi lớn là việc nhiều năm, làm từng phần |
| Uber | Bài 23/07/2020 cho biết Uber có khoảng 2.200 microservices quan trọng, phải gom thành khoảng 70 miền (domain) theo mô hình DOMA, mỗi miền một cổng vào | Quá nhiều dịch vụ nhỏ cũng là vấn đề; cần nhóm theo miền nghiệp vụ |
| Segment | Bài “Goodbye Microservices” (10/07/2018): hệ thống tăng lên hơn 140 dịch vụ, ba kỹ sư toàn thời gian chủ yếu chỉ giữ hệ thống chạy; họ gộp lại thành một dịch vụ | Dịch vụ gần giống nhau, đội nhỏ thì gộp có thể tốt hơn |
| Amazon Prime Video | Năm 2023, đội làm dịch vụ giám sát chất lượng luồng video gộp các thành phần phân tán (AWS Step Functions, Lambda) vào một tiến trình, giảm hơn 90% chi phí hạ tầng của dịch vụ đó | Chỉ là một dịch vụ, không phải cả Prime Video; chính đội này kết luận phải xét từng trường hợp |
Các mẫu thiết kế microservices phổ biến là gì?
Mỗi nhược điểm nêu trên đều có mẫu thiết kế (design pattern) để giảm thiểu.
| Mẫu | Giải quyết vấn đề gì | Lưu ý |
|---|---|---|
| API gateway | Một cửa vào cho client; gom xác thực, định tuyến | Không nhồi logic nghiệp vụ vào gateway |
| Database per service | Mỗi dịch vụ sở hữu dữ liệu, đổi cấu trúc không ảnh hưởng bên khác | Mất JOIN xuyên dịch vụ |
| Saga | Nghiệp vụ trải qua nhiều dịch vụ mà không có giao dịch phân tán | Phải tự viết bước bù trừ |
| Transactional outbox | Vừa ghi dữ liệu vừa phát sự kiện một cách tin cậy | Ghi sự kiện vào bảng outbox trong cùng giao dịch |
| CQRS | Tách mô hình ghi và đọc; dựng bảng đọc tổng hợp từ nhiều dịch vụ | Bảng đọc trễ hơn bảng ghi |
| Circuit breaker | Ngắt gọi tạm thời khi dịch vụ đích lỗi liên tục | Luôn đi cùng timeout và phương án dự phòng |
| Strangler Fig | Thay dần hệ thống cũ bằng dịch vụ mới | Xem phần lộ trình bên dưới |
Saga: giao dịch trải qua nhiều dịch vụ
Theo mô tả trên microservices.io của Chris Richardson, saga là chuỗi giao dịch cục bộ: mỗi bước cập nhật dữ liệu của một dịch vụ rồi phát sự kiện kích hoạt bước tiếp theo. Bước nào thất bại, saga chạy giao dịch bù trừ (compensating transaction) để đảo ngược các bước trước. Ví dụ minh hoạ khi đặt hàng: dịch vụ đơn hàng tạo đơn “chờ xử lý”, dịch vụ kho giữ hàng, dịch vụ thanh toán trừ tiền. Nếu thẻ bị từ chối, kho nhả hàng đã giữ và đơn chuyển sang “đã huỷ”.
Có hai cách điều phối. Choreography (biên đạo): không có trung tâm, mỗi dịch vụ nghe sự kiện và tự làm phần mình, gọn với quy trình ngắn. Orchestration (điều phối): một bộ điều phối ra lệnh cho từng bước, dễ theo dõi khi quy trình dài, nhiều nhánh.
Timeout, retry và circuit breaker
Khi dịch vụ A gọi B mà B treo, A sẽ chờ, cạn tài nguyên và treo theo, rồi tới các dịch vụ gọi A. Đây là lỗi dây chuyền (cascading failure). Ba lớp phòng vệ cơ bản:
- Timeout: mọi lời gọi mạng phải có thời gian chờ tối đa.
- Retry có giới hạn: thử lại vài lần, khoảng nghỉ tăng dần. Thao tác được thử lại phải idempotent (gọi nhiều lần cho cùng kết quả), ví dụ dùng mã yêu cầu duy nhất để không trừ tiền hai lần.
- Circuit breaker (cầu dao): khi tỉ lệ lỗi vượt ngưỡng, cầu dao ngắt và trả lỗi hoặc kết quả dự phòng ngay; sau một lúc mới cho thử lại vài lời gọi.
Các dịch vụ giao tiếp với nhau như thế nào?
| Tiêu chí | Đồng bộ (synchronous) | Bất đồng bộ (asynchronous) |
|---|---|---|
| Cách làm | Gọi và chờ trả lời: REST qua HTTP, gRPC | Gửi sự kiện vào hàng đợi, không chờ |
| Hợp khi | Cần trả lời ngay: kiểm tra tồn kho khi khách xem hàng | Báo nhiều bên biết việc đã xảy ra: “đơn hàng đã tạo” |
| Rủi ro | Chuỗi gọi dài cộng dồn độ trễ và lỗi | Thông điệp có thể trễ, trùng, sai thứ tự |
Giao tiếp đồng bộ dựa trên API, thường là REST với JSON, hoặc gRPC cho giao tiếp nội bộ cần nhanh. Bài API là gì và REST API hoạt động ra sao giải thích chi tiết phần này. Với microservices, cần nhớ ba nguyên tắc:
- API là hợp đồng giữa các đội: có tài liệu, có phiên bản, không âm thầm đổi định dạng. Kiểm thử hợp đồng (contract testing) bắt thay đổi phá vỡ trước khi lên môi trường thật.
- Hạn chế chuỗi gọi đồng bộ dài: xác suất cả chuỗi thành công là tích xác suất từng mắt xích, chuỗi càng dài càng mong manh.
- Sự kiện mô tả điều đã xảy ra, không ra lệnh: “đơn hàng đã thanh toán” tốt hơn “hãy giao đơn hàng”; bên phát không cần biết ai phản ứng.
Container và Kubernetes liên quan gì đến microservices?
Microservices không bắt buộc chạy trong container, nhưng hai thứ thường đi cùng nhau. Container đóng gói mỗi dịch vụ cùng thư viện cần thiết, chạy giống nhau ở mọi môi trường. Khi số dịch vụ tăng, cần hệ thống điều phối (orchestration) để xếp container lên máy chủ, khởi động lại khi lỗi, tăng giảm số bản theo tải. Kubernetes, dự án mã nguồn mở thuộc Cloud Native Computing Foundation (CNCF), là nền tảng điều phối phổ biến nhất.
Theo khảo sát thường niên của CNCF công bố ngày 20/01/2026, 82% tổ chức dùng container đã chạy Kubernetes trong môi trường thật năm 2025, tăng từ 66% năm 2023. Thách thức hàng đầu không phải công nghệ mà là thay đổi văn hoá trong đội phát triển (47% người trả lời).
Hạ tầng cho microservices thường đặt trên đám mây, nơi có sẵn Kubernetes được quản lý, hàng đợi và cơ sở dữ liệu theo nhu cầu; xem thêm bài điện toán đám mây, hoặc hybrid cloud nếu một phần dữ liệu phải nằm tại chỗ. Quy trình build, kiểm thử, phát hành tự động cho hàng chục dịch vụ thuộc phạm vi DevOps và CI/CD. Không có CI/CD, lợi ích “triển khai độc lập” gần như biến mất.
Làm sao quan sát và giám sát hệ thống microservices?
Một cú bấm “đặt hàng” có thể đi qua gateway, dịch vụ đơn hàng, kho, thanh toán, thông báo. Khi khách báo “chậm”, bạn cần biết chậm ở đâu. Đó là việc của observability (khả năng quan sát), dựa trên ba loại tín hiệu: log (nhật ký sự kiện, nên ghi có cấu trúc và gom về một chỗ), metric (số đo theo thời gian như số yêu cầu, tỉ lệ lỗi, độ trễ) và trace (hành trình của một yêu cầu qua nhiều dịch vụ, kèm thời gian từng chặng).
- Mã tương quan (trace ID): gắn một mã cho mỗi yêu cầu ngay tại gateway, truyền qua mọi dịch vụ và in vào mọi dòng log. Thiếu nó, ghép log từ nhiều dịch vụ gần như bất khả thi.
- Chuẩn mở OpenTelemetry: theo trang chính thức, đây là bộ công cụ mã nguồn mở thuộc CNCF để tạo, xuất, thu thập trace, metric, log, hình thành từ việc hợp nhất OpenTracing và OpenCensus. Nó không lưu trữ dữ liệu, nên bạn tự chọn công cụ phân tích, tránh bị khoá vào một nhà cung cấp.
- Bốn tín hiệu vàng: sách Site Reliability Engineering của Google khuyến nghị đo độ trễ (latency), lưu lượng (traffic), lỗi (errors) và mức bão hoà (saturation) cho mỗi dịch vụ, tách độ trễ của yêu cầu lỗi khỏi yêu cầu thành công.
Bảo mật microservices cần chú ý gì?
Khi giao tiếp nội bộ cũng đi qua mạng, đừng giả định “trong mạng nội bộ là an toàn”. Hãy áp dụng mô hình zero trust: mọi lời gọi đều được xác thực và cấp quyền, kể cả giữa hai dịch vụ của cùng công ty.
- Xác thực người dùng tại gateway, truyền danh tính bằng token có thời hạn ngắn; mỗi dịch vụ vẫn kiểm tra quyền với dữ liệu mình sở hữu.
- Mã hoá giao tiếp giữa các dịch vụ bằng TLS hai chiều (mTLS) để hai bên xác thực lẫn nhau.
- Quyền tối thiểu: dịch vụ thông báo không cần quyền đọc dữ liệu thanh toán.
- Lưu mật khẩu, khoá API trong kho bí mật, không ghi cứng trong mã hay ảnh container; quét lỗ hổng ngay trong CI/CD.
Lộ trình chuyển từ monolithic sang microservices
Viết lại toàn bộ một lần (big bang rewrite) là cách rủi ro nhất: nhiều tháng không ra tính năng mới trong khi hệ thống cũ vẫn phải chạy. Cách được khuyến nghị rộng rãi là mẫu Strangler Fig. Martin Fowler đặt tên theo loài cây đa bóp cổ ở rừng mưa Queensland (Úc), mọc bám cây chủ rồi thay thế dần. Với phần mềm, bạn xây thành phần mới bên cạnh hệ thống cũ và chuyển dần từng chức năng sang.
- Làm rõ lý do và thước đo: phát hành nhanh hơn, mở rộng tốt hơn hay giảm sự cố? Ghi lại số liệu hiện tại để so sánh sau.
- Dựng nền móng trước: CI/CD, giám sát tập trung có trace, quản lý bí mật, môi trường container.
- Chia module ngay trong monolith: tìm ranh giới theo nghiệp vụ (bounded context trong Domain-Driven Design), dọn các chỗ module này đọc thẳng dữ liệu module kia.
- Đặt lớp định tuyến phía trước, lúc đầu chuyển hết yêu cầu vào hệ thống cũ.
- Tách chức năng đầu tiên cùng dữ liệu của nó: chọn phần ít phụ thuộc như thông báo, tìm kiếm; tránh bắt đầu bằng phần lõi như thanh toán.
- Chuyển lưu lượng từng phần, theo dõi chỉ số, luôn có đường quay lại; xoá phần cũ tương ứng khi đã chuyển xong.
- Đánh giá lại sau mỗi lần tách. Không bắt buộc tách hết; một monolith nhỏ hơn cộng vài dịch vụ cũng là kết quả tốt.
Thời gian chuyển đổi phụ thuộc quy mô và năng lực đội; Netflix mất khoảng 7 năm với hệ thống rất lớn. Nếu đang làm sản phẩm mới, hãy theo tinh thần Agile: ra bản dùng được sớm trên một monolith gọn, học từ người dùng rồi mới quyết định tách gì.
Những sai lầm phổ biến khi làm microservices
- Chia quá nhỏ: mỗi bảng một dịch vụ, việc nhỏ cũng phải sửa nhiều nơi và lời gọi mạng tăng vọt.
- Dùng chung cơ sở dữ liệu: con đường ngắn nhất tới distributed monolith. Nếu cần nền tảng về DBMS, SQL, NoSQL, xem bài cơ sở dữ liệu là gì.
- Chia theo tầng kỹ thuật: “dịch vụ giao diện”, “dịch vụ xử lý”, “dịch vụ dữ liệu” khiến tính năng nào cũng phải sửa cả ba.
- Không đổi cách tổ chức đội: kiến trúc chia theo nghiệp vụ nhưng đội vẫn chia theo chuyên môn; theo định luật Conway, hệ thống sẽ dần quay về hình dạng tổ chức.
Câu hỏi thường gặp
Microservices và SOA khác nhau thế nào?
Cả hai đều chia hệ thống thành dịch vụ. SOA (kiến trúc hướng dịch vụ) thường xoay quanh trục tích hợp trung tâm như Enterprise Service Bus (ESB), chứa cả logic định tuyến và chuyển đổi dữ liệu. Microservices để logic trong dịch vụ, đường truyền chỉ chuyển tin, dịch vụ nhỏ hơn và tự quản dữ liệu.
Một microservice nên lớn cỡ nào?
Không có con số chung. Một dịch vụ nên khớp với một năng lực nghiệp vụ, do một đội nhỏ sở hữu, phát hành được mà không cần phối hợp đội khác. Nếu hai dịch vụ luôn phải phát hành cùng nhau, có lẽ chúng nên là một.
Mỗi microservice có bắt buộc có cơ sở dữ liệu riêng không?
Nguyên tắc là mỗi dịch vụ sở hữu dữ liệu của mình, dịch vụ khác không đọc ghi trực tiếp. Không nhất thiết là máy chủ riêng: schema riêng trên cùng máy chủ cũng được, miễn quyền truy cập tách biệt.
Có phải dùng Kubernetes mới làm được microservices?
Không. Với vài dịch vụ, máy ảo, dịch vụ container được quản lý hoặc PaaS là đủ. Kubernetes đáng giá khi số dịch vụ và số bản chạy đã lớn.
Serverless có phải là microservices?
Không hẳn. Microservices nói về cách chia hệ thống, serverless nói về cách chạy mã mà không quản lý máy chủ, tính tiền theo lần chạy. Trường hợp Prime Video năm 2023 cho thấy với khối lượng xử lý lớn và liên tục, tính tiền theo lần gọi có thể đắt hơn một tiến trình chạy thường trực.
Doanh nghiệp vừa và nhỏ ở Việt Nam có nên dùng microservices?
Phần lớn trường hợp chưa nên ở giai đoạn đầu. Nếu đội kỹ thuật nhỏ và sản phẩm còn thay đổi nhiều, một monolith chia module tốt, chạy trên đám mây với CI/CD và giám sát cơ bản thường hiệu quả hơn. Hãy cân nhắc microservices khi gặp đúng vấn đề nó giải quyết: nhiều đội giẫm chân nhau hoặc một phần hệ thống cần mở rộng khác hẳn phần còn lại.
Microservices có giúp tiết kiệm chi phí không?
Không mặc định. Bạn tiết kiệm nhờ chỉ mở rộng phần cần thiết, nhưng tốn thêm cho nền tảng, giám sát, lưu lượng mạng và nhân sự vận hành. Lợi ích chính thường là tốc độ phát hành và khả năng nhiều đội làm song song, không phải hoá đơn hạ tầng thấp hơn.