Microservices cho sàn TMĐT là cách chia hệ thống thành nhiều dịch vụ nhỏ theo nghiệp vụ — sản phẩm, giỏ hàng, đơn hàng, thanh toán, tồn kho, khuyến mãi — mỗi dịch vụ được triển khai, mở rộng và cập nhật độc lập, thường chạy trong container. Lợi ích lớn nhất với TMĐT: mùa sale chỉ cần scale riêng dịch vụ giỏ hàng và đơn hàng, đội ngũ có thể phát hành tính năng mà không phải triển khai lại toàn bộ hệ thống.
Nhưng microservices không miễn phí: hệ thống phân tán phức tạp hơn nhiều để vận hành. Bài viết giúp bạn quyết định có nên chuyển hay không, và nếu có, chuyển thế nào cho an toàn.
Tóm tắt nhanh
- Chuyển sang microservices khi đội kỹ thuật đông, phát hành chậm vì giẫm chân nhau, hoặc một phần hệ thống cần scale khác hẳn phần còn lại.
- Startup nhỏ thường nên bắt đầu bằng monolith được chia module rõ ràng.
- Chuyển dần theo mô hình “strangler fig”: tách từng dịch vụ một, không viết lại toàn bộ.
- Mỗi dịch vụ sở hữu dữ liệu của mình; giao tiếp qua API và sự kiện (Kafka).
Monolith và microservices khác nhau thế nào?
Monolith là một ứng dụng duy nhất chứa mọi chức năng, dùng chung một database và được triển khai cùng lúc. Microservices chia các chức năng thành dịch vụ riêng, mỗi dịch vụ có database và vòng đời triển khai riêng.
| Tiêu chí | Monolith | Microservices |
|---|---|---|
| Triển khai | Cả hệ thống cùng lúc | Từng dịch vụ độc lập |
| Mở rộng | Nhân bản toàn bộ ứng dụng | Scale riêng dịch vụ đang chịu tải |
| Ảnh hưởng khi lỗi | Một lỗi có thể kéo sập toàn bộ | Lỗi được khoanh vùng nếu thiết kế đúng |
| Dữ liệu | Một database chung | Mỗi dịch vụ một database |
| Độ phức tạp vận hành | Thấp | Cao: mạng, giám sát, dữ liệu phân tán |
| Phù hợp | Đội nhỏ, sản phẩm đang tìm hướng | Đội lớn, hệ thống quy mô, tải không đồng đều |
[ẢNH 1 — Từ monolith đến microservices]
Khi nào sàn TMĐT nên chuyển sang microservices?
Hãy cân nhắc chuyển khi có từ 2 dấu hiệu trở lên:
- Phát hành chậm: nhiều đội cùng sửa một codebase, mỗi lần triển khai phải chờ nhau và kiểm thử toàn bộ.
- Tải không đồng đều: giỏ hàng, thanh toán quá tải mùa sale trong khi trang quản trị, báo cáo gần như không có tải — nhưng phải scale cả khối.
- Một lỗi nhỏ làm sập cả hệ thống: ví dụ dịch vụ gửi email treo kéo theo trang thanh toán.
- Công nghệ bị khóa: muốn dùng ngôn ngữ, database khác cho tìm kiếm hay gợi ý sản phẩm nhưng không thể vì gắn chặt vào monolith.
- Đội kỹ thuật trên khoảng 15–20 người chia thành nhiều nhóm theo nghiệp vụ.
Khi nào chưa nên chuyển?
Nếu đội kỹ thuật dưới 10 người, sản phẩm còn thay đổi mô hình kinh doanh liên tục, hoặc chưa có giám sát và CI/CD cơ bản, hãy ở lại monolith và chia module rõ ràng bên trong (modular monolith). Khi cần, mỗi module có thể tách ra thành dịch vụ mà không phải viết lại. Vấn đề hiệu năng mùa sale thường giải quyết được bằng CDN, cache, read replica và auto-scale — xem auto-scale hạ tầng cloud mùa sale.
Container khác máy chủ ảo thế nào với e-commerce?
Container đóng gói ứng dụng cùng thư viện cần thiết, chia sẻ nhân hệ điều hành với máy chủ, nên khởi động trong vài giây và chạy được nhiều container trên một máy. Máy chủ ảo (VM) chứa cả hệ điều hành riêng, nặng hơn nhưng cách ly mạnh hơn.
| Tiêu chí | Máy chủ ảo (Sun VM) | Container (Sun Container, Sun Kubernetes) |
|---|---|---|
| Thời gian khởi động | Vài phút | Vài giây |
| Mật độ | Một vài ứng dụng mỗi VM | Hàng chục container mỗi node |
| Mở rộng mùa sale | Chậm hơn, cần image chuẩn bị sẵn | Nhanh, tự động theo tải |
| Phù hợp | Database tự quản, ứng dụng cũ, phần mềm cần hệ điều hành riêng | Microservices, API, worker xử lý sự kiện |
Với TMĐT, mô hình phổ biến là chạy microservices trong container và đặt database ở dịch vụ được quản lý như Sun Database.
Cách tách dịch vụ cho sàn TMĐT theo nghiệp vụ
Tách theo nghiệp vụ (domain), không tách theo lớp kỹ thuật. Bảng dưới là cách chia tham khảo cho một sàn TMĐT, kèm đặc điểm tải giúp quyết định thứ tự tách.
| Dịch vụ | Trách nhiệm | Đặc điểm tải mùa sale | Ưu tiên tách |
|---|---|---|---|
| Catalog | Sản phẩm, biến thể, danh mục | Đọc rất nhiều, ghi ít | Trung bình |
| Search | Tìm kiếm, lọc, gợi ý từ khóa | Đọc rất nhiều, cần công cụ riêng | Cao |
| Cart | Giỏ hàng | Tăng vọt khi mở deal | Cao |
| Order | Tạo và theo dõi đơn | Tăng vọt, cần toàn vẹn dữ liệu | Cao (sau khi có nền tảng ổn định) |
| Payment | Kết nối cổng thanh toán | Tăng theo đơn, yêu cầu bảo mật cao | Trung bình |
| Inventory | Tồn kho, giữ chỗ | Ghi đồng thời cao | Cao |
| Promotion | Mã giảm giá, flash sale | Rất cao trong giờ G | Cao |
| User | Tài khoản, đăng nhập | Ổn định | Thấp |
| Notification | Email, SMS, push | Theo hàng đợi, chịu trễ được | Cao — tách đầu tiên vì rủi ro thấp |
Hướng dẫn 7 bước chuyển sàn TMĐT từ monolith sang microservices
Cách an toàn nhất là mô hình “strangler fig” (cây đa bóp nghẹt): đặt một lớp định tuyến trước monolith, tách từng chức năng ra dịch vụ mới, chuyển dần traffic sang, cho đến khi monolith chỉ còn phần nhỏ hoặc biến mất. Không dừng phát triển tính năng, không viết lại toàn bộ.
[ẢNH 2 — Mô hình strangler fig: tách dần dịch vụ khỏi monolith]
Bước 1: Vẽ bản đồ nghiệp vụ và chọn dịch vụ tách đầu tiên
Liệt kê các nghiệp vụ như bảng ở mục trên, xác định dữ liệu nào thuộc về nghiệp vụ nào. Chọn dịch vụ đầu tiên có rủi ro thấp và lợi ích rõ — thường là Notification (gửi email, SMS) hoặc Search. Tránh tách Order hay Payment đầu tiên.
Bước 2: Đóng gói monolith vào container
Trước khi tách, hãy chạy chính monolith trong container. Đội ngũ làm quen quy trình build, đẩy image, triển khai mà chưa phải xử lý hệ thống phân tán. Ví dụ Dockerfile nhiều giai đoạn cho ứng dụng Node.js:
# Giai đoạn build
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# Giai đoạn chạy: image gọn, không chứa công cụ build
FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER node
EXPOSE 3000
HEALTHCHECK CMD wget -qO- http://localhost:3000/healthz || exit 1
CMD ["node", "dist/server.js"]Bước 3: Dựng nền tảng container và quy trình CI/CD
Tạo cụm Sun Kubernetes (SKS) cho các dịch vụ cần kiểm soát chi tiết, hoặc dùng Sun Container (Spinner) cho dịch vụ không trạng thái muốn chạy mà không quản lý cụm. Thiết lập kho image, pipeline CI/CD tự động build, kiểm thử và triển khai từng dịch vụ.
Bước 4: Đặt lớp định tuyến trước monolith
Đặt API gateway hoặc ingress trước monolith. Ban đầu mọi request vẫn đi vào monolith. Khi một dịch vụ mới sẵn sàng, chỉ cần đổi quy tắc định tuyến (ví dụ /api/search/* sang dịch vụ Search) — có thể chuyển dần theo tỷ lệ phần trăm và quay lui ngay nếu lỗi.
Bước 5: Tách dịch vụ đầu tiên cùng dữ liệu của nó
Dịch vụ mới phải sở hữu dữ liệu của mình, không đọc thẳng vào database của monolith. Trong giai đoạn chuyển tiếp, monolith phát sự kiện khi dữ liệu thay đổi (sản phẩm cập nhật, đơn được tạo) lên Sun Kafka Highway; dịch vụ mới đọc sự kiện để xây dữ liệu riêng. Cách chọn database cho từng dịch vụ có trong bài database cho e-commerce.
Bước 6: Cấu hình tự động mở rộng cho từng dịch vụ
Đây là lúc lợi ích mùa sale xuất hiện: mỗi dịch vụ scale theo tải riêng. Ví dụ cấu hình HorizontalPodAutoscaler cho dịch vụ Cart trên Kubernetes:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: cart-service
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: cart-service
minReplicas: 3 # luôn có dự phòng
maxReplicas: 40 # chặn chi phí vượt kiểm soát
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
behavior:
scaleUp:
stabilizationWindowSeconds: 0 # tăng ngay khi tải lên
scaleDown:
stabilizationWindowSeconds: 600 # giảm từ từ, tránh dao độngTrước giờ mở flash sale, tăng minReplicas theo lịch để không phải chờ hệ thống phản ứng.
Bước 7: Giám sát, rồi lặp lại cho dịch vụ tiếp theo
Thiết lập ba trụ quan sát trước khi tách dịch vụ thứ hai: chỉ số (metrics), nhật ký tập trung (logs) và truy vết phân tán (tracing) để theo một request qua nhiều dịch vụ. Sun Monitor cảnh báo khi dịch vụ quá tải. Sau đó lặp lại bước 5–7 cho dịch vụ tiếp theo theo thứ tự ưu tiên.
| Giai đoạn | Thời gian tham khảo | Kết quả |
|---|---|---|
| Bước 1–3 | 4–8 tuần | Monolith chạy trong container, có CI/CD và nền tảng Kubernetes |
| Bước 4–7 cho dịch vụ đầu tiên | 4–6 tuần | Một dịch vụ chạy độc lập, có giám sát |
| Các dịch vụ tiếp theo | 3–6 tuần mỗi dịch vụ | Tách dần các nghiệp vụ tải cao |
Không nên đặt mốc chuyển đổi lớn trong 6–8 tuần trước mùa sale; giai đoạn đó dành cho ổn định hệ thống.
Xử lý đơn hàng phân tán với mô hình Saga
Trong monolith, đặt hàng là một giao dịch database: tạo đơn, giữ kho, trừ mã giảm giá, cùng thành công hoặc cùng hủy. Khi các bước nằm ở các dịch vụ khác nhau với database riêng, không còn một giao dịch chung. Mô hình Saga giải quyết bằng chuỗi bước cục bộ, mỗi bước có hành động bù trừ nếu bước sau thất bại.
[ẢNH 3 — Luồng Saga đặt hàng và các bước bù trừ]
Bước
Dịch vụ
Hành động
Bù trừ nếu bước sau lỗi
1
Order
Tạo đơn trạng thái “chờ xử lý”
Đánh dấu đơn “đã hủy”
2
Inventory
Giữ chỗ tồn kho
Trả lại tồn kho đã giữ
3
Promotion
Ghi nhận sử dụng mã giảm giá
Hoàn lượt dùng mã
4
Payment
Tạo yêu cầu thanh toán, chờ kết quả
Hoàn tiền nếu đã thu
5
Order
Xác nhận đơn, phát sự kiện “đơn đã xác nhận”
—
Có hai cách điều phối: choreography (mỗi dịch vụ lắng nghe sự kiện và tự làm bước tiếp theo — đơn giản khi ít bước) và orchestration (một dịch vụ điều phối gọi từng bước — dễ theo dõi khi luồng phức tạp). Với luồng đặt hàng TMĐT, orchestration thường dễ vận hành hơn.
Để không mất sự kiện khi dịch vụ ghi database xong nhưng chưa kịp gửi lên Kafka, dùng mẫu Outbox: ghi sự kiện vào bảng outbox trong cùng giao dịch database, một tiến trình riêng đọc bảng này và đẩy lên Sun Kafka Highway. Mọi bước xử lý sự kiện nên idempotent — nhận cùng một sự kiện hai lần vẫn cho cùng một kết quả.
6 sai lầm thường gặp khi chuyển sang microservices
- Dùng chung database giữa các dịch vụ: tạo ra “monolith phân tán” — phức tạp của microservices mà không có lợi ích.
- Tách quá nhỏ, quá sớm: hàng chục dịch vụ cho một đội 8 người khiến chi phí vận hành vượt lợi ích.
- Gọi đồng bộ dây chuyền: dịch vụ A gọi B, B gọi C, C gọi D — một dịch vụ chậm làm chậm cả chuỗi. Ưu tiên sự kiện bất đồng bộ cho những việc không cần trả lời ngay.
- Thiếu truy vết phân tán: khi lỗi xảy ra, không biết request hỏng ở dịch vụ nào.
- Không có timeout, retry và circuit breaker: một dịch vụ treo kéo theo toàn bộ hệ thống.
- Viết lại toàn bộ cùng lúc: dự án kéo dài, tính năng kinh doanh đứng yên, rủi ro thất bại cao.
Tìm hiểu sâu hơn về triển khai microservices với container trong Whitepaper: Triển khai microservices sử dụng công nghệ container của Sunteco. Bức tranh tổng thể về hạ tầng TMĐT có trong hướng dẫn giải pháp cloud thương mại điện tử.
Câu hỏi thường gặp về microservices cho sàn TMĐT
Khi nào nên chuyển sang microservices?
Khi đội kỹ thuật đông và phát hành chậm vì phụ thuộc lẫn nhau, khi một số phần hệ thống cần scale khác hẳn phần còn lại, hoặc khi một lỗi nhỏ thường làm sập toàn bộ. Nên có sẵn CI/CD và giám sát trước khi chuyển.
Container khác máy chủ ảo thế nào cho e-commerce?
Container chia sẻ nhân hệ điều hành nên khởi động trong vài giây và chạy được nhiều trên một máy, phù hợp để scale nhanh mùa sale. Máy chủ ảo có hệ điều hành riêng, nặng hơn nhưng cách ly mạnh hơn, phù hợp cho database tự quản hoặc ứng dụng cũ.
Microservices có phù hợp với startup TMĐT không?
Thường là chưa. Startup với đội dưới 10 người nên dùng monolith chia module rõ ràng để đi nhanh, và tách dịch vụ khi gặp giới hạn thật về tải hoặc tổ chức đội ngũ.
Chuyển từ monolith sang microservices mất bao lâu?
Thường cần 2–3 tháng để có nền tảng container, CI/CD và dịch vụ đầu tiên chạy ổn định, sau đó 3–6 tuần cho mỗi dịch vụ tiếp theo. Toàn bộ quá trình có thể kéo dài 6–18 tháng tùy quy mô, nhưng mang lại lợi ích ngay từ dịch vụ đầu tiên.
Làm sao đảm bảo đơn hàng chính xác khi dữ liệu nằm ở nhiều dịch vụ?
Dùng mô hình Saga: chia đặt hàng thành các bước cục bộ ở từng dịch vụ, mỗi bước có hành động bù trừ khi bước sau thất bại. Kết hợp mẫu Outbox để không mất sự kiện và thiết kế xử lý idempotent.
Bắt đầu hành trình microservices cùng Sunteco
Sun Kubernetes và Sun Container giúp bạn chạy microservices mà không phải tự dựng hạ tầng; Sun Kafka Highway lo phần sự kiện. Đọc whitepaper để có lộ trình chi tiết, hoặc dùng thử ngay.
