Cần cân nhắc gì khi xây microservices trong Node?

Question

IT Interview Practice · Accepted Answer

**Microservices** chia một ứng dụng thành các service nhỏ, triển khai độc lập, mỗi cái sở hữu một miền cụ thể và giao tiếp qua mạng. Bản chất nhẹ, khởi động nhanh của Node rất hợp — nhưng kiến trúc này đưa vào sự phức tạp của hệ phân tán mà bạn phải tính trước.

## Monolith vs microservices

```text
Monolith:      một codebase/triển khai — đơn giản để xây, khó mở rộng nhóm
Microservices: nhiều service nhỏ — triển khai/mở rộng độc lập, nhưng phức tạp phân tán
```

Microservices đánh đổi sự đơn giản trong-tiến-trình lấy linh hoạt vận hành — chỉ đáng khi bạn thực sự cần mở rộng/triển khai độc lập hoặc có nhiều nhóm.

## Giao tiếp giữa các service

```text
Đồng bộ:    REST / gRPC — request/response trực tiếp (đơn giản, nhưng kết dính chặt + thất bại dây chuyền)
Bất đồng bộ: hàng đợi tin nhắn (RabbitMQ, Kafka) — sự kiện, tách rời, bền bỉ
```

```js
// hướng sự kiện/bất đồng bộ tách rời các service — một service phát một sự kiện;
// các service khác phản ứng mà service phát không cần biết/đợi chúng
await queue.publish("order.created", { orderId: 123 });
// service email, service kho, v.v. mỗi cái tiêu thụ nó độc lập
```

Ưu tiên **tin nhắn bất đồng bộ** để tách rời và bền bỉ khi có thể; lệnh đồng bộ đơn giản hơn nhưng tạo kết dính chặt và thất bại dây chuyền.

## Các mối lo then chốt bạn phải xử lý

```text
✓ Service discovery / API gateway — cách service tìm nhau & định tuyến traffic ngoài
✓ Sở hữu dữ liệu — mỗi service sở hữu database RIÊNG (không DB chung) → kết dính lỏng
✓ Bền bỉ — timeout, retry, circuit breaker (một service chết không nên dây chuyền)
✓ Distributed tracing & log tập trung — debug một request qua nhiều service
✓ Nhất quán cuối cùng — không giao dịch xuyên service; dùng saga / sự kiện
✓ Xác thực — truyền danh tính (JWT) qua các lời gọi service
✓ Idempotency — tin nhắn được retry không nên xử lý hai lần
```

## Ví dụ bền bỉ: circuit breaker

```js
// ngừng dập một dependency đang lỗi; thất bại nhanh và phục hồi nhẹ nhàng
const breaker = new CircuitBreaker(callPaymentService, { timeout: 3000, errorThreshold: 50 });
breaker.fallback(() => ({ status: "queued" })); // suy giảm nhẹ nhàng khi nó chết
```

## Sự thẳng thắn về đánh đổi

```text
Microservices thêm phức tạp thật: lỗi mạng, debug phân tán, nhất quán dữ liệu,
điều phối triển khai, nhiều hạ tầng hơn. Nhiều app tốt hơn khi là một
monolith cấu trúc tốt. Chọn microservices vì nhu cầu cụ thể, không phải mặc định.
```

## Tại sao điều này quan trọng

Microservices là một lựa chọn kiến trúc lớn với đánh đổi đáng kể.

Node hợp với chúng (nhẹ, khởi động nhanh), nhưng phần khó không phải code — mà là các **mối lo hệ phân tán**: giao tiếp giữa service (ưu tiên tin nhắn bất đồng bộ để tách rời), sở hữu dữ liệu độc lập, bền bỉ (timeout/retry/circuit breaker để ngăn thất bại dây chuyền), khả năng quan sát (tracing/log qua các service), và nhất quán cuối cùng.

Hiểu những điều này — và sự thật thẳng thắn rằng microservices thêm phức tạp mà nhiều ứng dụng không cần (một monolith tốt thường tốt hơn) — là điều tách một quyết định kiến trúc đúng đắn khỏi việc bắt chước một mẫu thời thượng.

Monolith vs microservices

Giao tiếp giữa các service

Các mối lo then chốt bạn phải xử lý

Ví dụ bền bỉ: circuit breaker

Sự thẳng thắn về đánh đổi

Tại sao điều này quan trọng

Câu hỏi liên quan