当每个服务都有自己的数据库时，您如何管理数据？

Question

Accepted Answer

在**没有共享数据库**的情况下，您无法使用跨服务的JOIN或单一ACID事务。您可以使用**API composition**、**replication/CQRS read models**和**events**来组合数据并保持其一致性。

## 跨服务读取数据

**API composition** — 一个协调器调用每个服务并拼接结果：

```js
// build an order view from three services
const order    = await ordersApi.get(orderId);
const customer = await usersApi.get(order.customerId);   // separate service
const shipment = await shippingApi.get(orderId);
return { ...order, customer, shipment }; // composed in memory
```

对于重型查询，维护一个**read model**（CQRS）：一个服务订阅事件并构建一个非规范化的本地副本，可以直接查询。

```text
Orders ─event→ ┐
Users  ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
```

## 跨服务写入

使用**Saga**模式 — 一系列本地事务加上补偿操作 — 而不是分布式事务。

## 权衡

| 方法 | 优点 | 缺点 |
|---|---|---|
| API composition | 始终最新 | 延迟、扇出、易出故障 |
| Replicated read model | 快速读取 | 最终一致性 |
| Saga | 不需要2PC | 复杂、需要补偿 |

## 陷阱

不要仅仅为了简化JOIN而共享一张表 — 那样会重新耦合服务。在业务允许的范围内接受最终一致性。

## 为什么这很重要

数据管理是微服务真正变得困难的地方，因为简单工具（join、事务）在设计上已经不可用。

理解composition、read models和sagas是让您保持服务独立而不失正确性的关键。

方法	优点	缺点
API composition	始终最新	延迟、扇出、易出故障
Replicated read model	快速读取	最终一致性
Saga	不需要2PC	复杂、需要补偿