在 Node 中构建微服务时应该考虑什么?

Question

Accepted Answer

**Microservices** 将应用程序拆分为小型、独立可部署的服务，每个服务都拥有特定的领域并通过网络进行通信。Node 的轻量级、快速启动的特性很适合它们 — 但是这种架构引入了分布式系统的复杂性，需要你进行规划。

## 单体 vs 微服务

```text
Monolith:      one codebase/deployment — simple to build, harder to scale teams
Microservices: many small services — independent deploy/scale, but distributed complexity
```

微服务用操作灵活性换取进程内的简洁性 — 只有在你真正需要独立伸缩/部署或拥有多个团队时才值得。

## 服务之间的通信

```text
Synchronous:  REST / gRPC — direct request/response (simple, but tight coupling + cascading failures)
Asynchronous: message queues (RabbitMQ, Kafka) — events, decoupled, resilient
```

```js
// async/event-driven decouples services — a service publishes an event;
// others react without the publisher knowing/waiting for them
await queue.publish("order.created", { orderId: 123 });
// the email service, inventory service, etc. each consume it independently
```

在可能的情况下优先考虑**异步消息传递**进行解耦和弹性；同步调用更简单但会造成紧密耦合和故障级联。

## 必须解决的关键问题

```text
✓ Service discovery / API gateway — how services find each other & route external traffic
✓ Data ownership — each service owns its OWN database (no shared DB) → loose coupling
✓ Resilience — timeouts, retries, circuit breakers (a down service shouldn't cascade)
✓ Distributed tracing & centralized logging — debug a request across many services
✓ Eventual consistency — no cross-service transactions; use sagas / events
✓ Authentication — propagate identity (JWT) across service calls
✓ Idempotency — retried messages shouldn't double-process
```

## 弹性示例：circuit breaker

```js
// stop hammering a failing dependency; fail fast and recover gracefully
const breaker = new CircuitBreaker(callPaymentService, { timeout: 3000, errorThreshold: 50 });
breaker.fallback(() => ({ status: "queued" })); // degrade gracefully when it's down
```

## 权衡的诚实性

```text
Microservices add real complexity: network failures, distributed debugging, data
consistency, deployment orchestration, more infrastructure. Many apps are better
as a well-structured monolith. Adopt microservices for specific needs, not by default.
```

## 为什么这很重要

微服务是一个重大的架构决策，伴随着重大的权衡。

Node 适合它们（轻量级、快速启动），但困难的部分不是代码 — 它们是**分布式系统问题**：服务间通信（优先考虑异步消息传递以实现解耦）、独立数据所有权、弹性（超时/重试/熔断器以防止级联故障）、可观测性（跨服务的追踪/日志记录）和最终一致性。

理解这些 — 以及微服务增加许多应用程序不需要的复杂性的坦诚现实（良好的单体通常更好）— 这是区分合理架构决策和跟风新兴模式的关键。