Microservices vs Monolithic Workflow: Ranh giới chia nhỏ hay giữ nguyên khối?

Tóm tắt nhanh
– Microservices: tách từng bước workflow thành dịch vụ độc lập → linh hoạt, dễ scale, nhưng tăng chi phí vận hành và độ phức tạp quản lý.
– Monolithic: gói toàn bộ workflow trong một ứng dụng duy nhất → triển khai nhanh, chi phí hạ tầng thấp, nhưng khó mở rộng và bảo trì khi quy mô tăng.
– Khi nào chọn gì? Đánh giá dựa trên khối lượng giao dịch, độ phức tạp nghiệp vụ, ngân sách và kế hoạch mở rộng của doanh nghiệp.

1️⃣ Tóm tắt nội dung chính

Best Practice: Nếu dự án chưa vượt quá 10 k giao dịch/ngày và ngân sách hạn chế, nên bắt đầu với monolithic rồi dần chuyển sang microservices khi nhu cầu mở rộng thực sự xuất hiện.

2️⃣ Vấn đề thật mà mình và khách hay gặp mỗi ngày

1️⃣ Khó mở rộng khi traffic tăng đột biến – Một khách hàng trong lĩnh vực e‑commerce đã gặp “cú sập” vào đêm lễ hội mua sắm vì toàn bộ workflow đặt hàng được chạy trong một process monolithic duy nhất. Khi traffic tăng 3‑4× so với bình thường, CPU lên tới 95 % và hệ thống ngừng phản hồi trong vòng 5 phút.

2️⃣ Độ trễ không đồng nhất giữa các bước – Dự án quản lý hồ sơ ngân hàng dùng microservices nhưng thiếu chuẩn đồng bộ thời gian (clock sync). Kết quả là bước “Xác thực khách hàng” mất trung bình 800 ms trong khi các service khác chỉ mất <200 ms, gây bottleneck và khách hàng phàn nàn về thời gian chờ.

3️⃣ Chi phí hạ tầng bùng nổ – Một startup fintech quyết định “đi thẳng” vào kiến trúc microservices mà không có kế hoạch tài chính rõ ràng. Sau 6 tháng, chi phí AWS EC2 + EKS tăng từ 2 k$ lên hơn 12 k$/tháng chỉ vì số lượng pod và load balancer tăng lên không kiểm soát được.

🐛 Câu chuyện thực tế: Khi mình đang fix lỗi “duplicate order” cho một công ty logistics, phát hiện ra rằng lỗi này xuất hiện do hai service “order‑creation” và “order‑validation” cùng ghi vào DB mà không có lock cơ chế. Việc tách service đã giải quyết được vấn đề nhưng đồng thời làm tăng chi phí DB read/write lên 30 %.

3️⃣ Giải pháp tổng quan (text art)

┌─────────────────────┐          ┌─────────────────────┐
│   Monolithic App    │   ⇢      │   Microservices     │
│   (Single Process) │          │   (Service Mesh)    │
└─────────┬───────────┘          └───────┬─────────────┘
          │                               │
   ┌──────▼───────┐               ┌───────▼───────┐
   │   Workflow   │               │   Service A   │
   │   Engine     │               ├───────────────┤
   └──────┬───────┘               │   Service B   │
          │                       └───────┬───────┘
   ┌──────▼───────┐               ┌───────▼───────┐
   │ Step 1 → …  │               │ Step N → …    │
   └──────────────┘               └───────────────┘

Ở bên trái là mô hình monolithic truyền thống; bên phải là kiến trúc microservices với mỗi step được đóng gói thành một service độc lập.

4️⃣ Hướng dẫn chi tiết từng bước

Bước 1: Đánh giá hiện trạng workflow

• Thu thập số liệu số lượng transaction/ngày, độ trễ trung bình, tần suất lỗi.
• Sử dụng công cụ APM (New Relic / Datadog) để xác định “hot‑spot”.

Bước 2: Xác định ranh giới chia service

Bước 3: Thiết kế API contract

POST /order/create
{
    "customerId": "string",
    "items": [{ "sku": "string", "qty": number }],
    "paymentMethod": "string"
}

• Định dạng JSON chuẩn, versioning (v1, v2) để tránh breaking change.

Bước 4: Xây dựng Docker image cho mỗi service

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
CMD ["node", "src/index.js"]

• Đặt tag version (service-a:v1.0.0) để quản lý release.

Bước 5: Orchestrate bằng Kubernetes / Docker‑Compose

version: "3.8"
services:
  service-a:
    image: registry.example.com/service-a:v1.0.0
    ports:
      - "8081:8080"
    environment:
      - DB_HOST=db
  service-b:
    image: registry.example.com/service-b:v1.0.0
    ports:
      - "8082:8080"

• Đảm bảo healthcheck cho mỗi container để tự động restart khi lỗi.

Bước 6: Thiết lập CI/CD pipeline

• GitHub Actions → Build → Test → Push image → Deploy.
• Sử dụng canary deployment để giảm rủi ro khi cập nhật service mới.

Bước 7: Kiểm thử end‑to‑end

• Sử dụng Postman/Newman hoặc k6 để mô phỏng luồng toàn bộ workflow.
• Đo KPI: latency, success rate, resource usage.

5️⃣ Template quy trình tham khảo

[Workflow] Order Processing

1️⃣ Receive Order (Service A)
   - Input: JSON payload từ Frontend
   - Output: orderId -> Message Queue

2️⃣ Validate Order (Service B)
   - Subscribe Queue -> Validate data & inventory
   - Output: validationStatus -> DB

3️⃣ Payment Capture (Service C)
   - Triggered khi validationStatus = OK
   - Call Payment Gateway API

4️⃣ Confirm & Notify (Service D)
   - Khi payment success -> Update order status & gửi email/SMS

🛡️ Logging & Monitoring:
   - Centralized ELK stack.
   - Alert nếu latency >500ms hoặc error rate >1%.

6️⃣ Những lỗi phổ biến & cách sửa

⚡ Tip: Khi phát hiện bottleneck ở một service, hãy kiểm tra cpu/memory usage qua Grafana dashboard trước khi quyết định scale lên.

7️⃣ Khi muốn scale lớn thì làm sao

1️⃣ Horizontal Pod Autoscaler (HPA) – Đặt target CPU = 70 % → hệ thống tự động tạo thêm pod khi vượt mức.

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: service-a-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: service-a-deploy
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

2️⃣ Sharding Database – Khi DB trở thành điểm nghẽn, chia dữ liệu theo customerId hoặc region để giảm contention.

3️⃣ Event‑driven Architecture – Thay vì đồng bộ HTTP call giữa services, dùng Kafka/RabbitMQ để buffer traffic và cho phép consumer xử lý async.

4️⃣ Cache Layer – Áp dụng Redis cache cho các query read‑heavy như “order status”.

5️⃣ Cost‑aware scaling – Kết hợp spot instances cho workload không time‑critical để giảm chi phí hạ tầng.

8️⃣ Chi phí thực tế

Ước tính chi phí hạ tầng AWS (tháng)

ROI = (Tiết kiệm thời gian xử lý – Chi phí đầu tư) / Chi phí đầu tư × 100%

Giải thích: Nếu giảm thời gian xử lý đơn hàng từ 5 giây xuống 2 giây ⇒ tiết kiệm ≈ 3 giây/order × 100k orders/tháng ≈ 83 giờ/tháng; với mức lương trung bình developer $30/h → tiết kiệm $2 500/tháng so với chi phí hạ tầng tăng $345/tháng ⇒ ROI ≈ 627 %.

Phân tích chi phí

• Monolithic: Chi phí thấp hơn ~70 % nhưng giới hạn khả năng mở rộng; nếu traffic bùng nổ sẽ phải đầu tư lại toàn bộ kiến trúc.
• Microservices: Chi phí cao hơn ~210 % nhưng mang lại khả năng scale linh hoạt và giảm downtime khi cập nhật từng service riêng lẻ.

9️⃣ Số liệu trước – sau

Trường hợp khách hàng “ShopX” chuyển từ monolithic sang microservices

🎉 Kết quả: Sau ba tháng triển khai microservices, ShopX giảm thời gian giao đơn từ trung bình 48h xuống 12h nhờ pipeline xử lý song song và auto‑scale pod tại giờ cao điểm.

🔟 FAQ hay gặp nhất

Q1: Microservices có thực sự cần Kubernetes?

Không bắt buộc; nếu quy mô nhỏ (<5 services) Docker‑Compose đủ. Tuy nhiên khi số lượng services >10 và cần auto‑scale thì K8s là lựa chọn tiêu chuẩn.

Q2: Làm sao tránh “service sprawl” – quá nhiều services không kiểm soát?

Áp dụng nguyên tắc “single responsibility” kết hợp với review kiến trúc định kỳ; giữ số services dưới mức tối đa là log₂(traffic_per_day) để tránh quá tải quản trị.

Q3: Có nên dùng GraphQL thay vì REST trong microservices workflow?

GraphQL giúp client lấy dữ liệu tùy chỉnh nhưng làm tăng độ phức tạp backend; nếu workflow chủ yếu là chuỗi các hành động CRUD thì REST vẫn phù hợp hơn về hiệu năng và debugging.

Q4: Chi phí bảo trì log aggregation có đáng đầu tư không?

Rất đáng – việc tập trung log giúp phát hiện lỗi nhanh hơn gấp 5 lần so với việc kiểm tra từng pod riêng lẻ; chi phí ELK stack thường chỉ chiếm <5% tổng ngân sách hạ tầng.

🔚 Giờ tới lượt bạn

Bạn đang đứng trước quyết định chọn kiến trúc nào cho workflow của mình? Hãy bắt đầu bằng việc:

1️⃣ Đánh giá khối lượng giao dịch hiện tại và dự báo tăng trưởng trong vòng 12‑24 tháng tới.
2️⃣ Vẽ sơ đồ workflow hiện tại (có thể dùng giấy + bút), sau đó thử chia thành các khối chức năng độc lập xem có lợi ích gì không.
3️⃣ Thử triển khai một service mẫu trên Docker Compose để cảm nhận overhead thực tế trước khi quyết định chuyển toàn bộ sang Kubernetes.

Nếu cảm thấy chưa chắc chắn hoặc muốn tính toán ROI chính xác hơn, mình sẵn sàng hỗ trợ bạn thiết kế kiến trúc phù hợp với ngân sách của doanh nghiệp Việt Nam – vừa tối ưu hiệu năng vừa giữ chi phí ở mức hợp lý.

Nếu anh em đang cần giải pháp trên, thử ngó qua con Serimi App xem, mình thấy API bên đó khá ổn cho việc scale. Hoặc liên hệ mình để được trao đổi nhanh hơn nhé.