模式：每个服务一个数据库

Pattern: Database per service。

背景

如用微服务架构模式开发一个在线商店应用程序。大多数服务需要在某种数据库中持久化数据。如，订单服务存储订单信息，而客户服务存储客户信息。

微服务应用程序中的数据库架构是什么？

服务必须松耦合，以便能够独立开发、部署和扩展。
某些业务事务必须在多个服务之间强制执行不变量。例如，下订单用例必须验证新订单不会超出客户的信用额度。其他业务事务需要更新由多个服务拥有的数据。
一些业务事务需要查询多个服务的数据。例如，查看可用信用额度用例需要查询客户服务获取信用额度，并查询订单服务计算未结订单的总金额。
某些查询需要关联多个服务的数据。例如，查找特定地区的客户及其最近的订单需要在客户和订单之间进行数据关联。
数据库有时需要复制和分片以实现扩展。参见扩展立方体。
不同的服务对数据存储有不同的需求。例如，某些服务适合使用关系型数据库，而其他服务可能需要 NoSQL 数据库（如 MongoDB）来存储复杂的非结构化数据，或者需要 Neo4J 来高效存储和查询图数据。

让每个微服务的持久性数据对该服务私有，并仅通过其 API 访问。服务的事务只涉及其自己的数据库。
下图展示了这一模式的结构。

服务的数据库实际上是该服务实现的一部分。它不能被其他服务直接访问。

有几种方法可以让服务的持久性数据保持私有性。你不需要为每个服务配置一个独立的数据库服务器。例如，如果你使用的是关系型数据库，可以选择以下方式：

每服务私有表和每服务一个模式的实现开销最低。使用每服务一个模式较为吸引人，因为它可以更加清晰地划分所有权。一些高吞吐量服务可能需要独立的数据库服务器。

建议创建屏障以强制实现模块化。例如，可以为每个服务分配不同的数据库用户 ID，并通过数据库访问控制机制（如授权）来限制访问。如果没有这些强制手段，开发人员可能会直接绕过服务的 API 访问其数据。

FTGO 应用程序是一个使用这种方法的示例。每个服务都拥有数据库凭据，这些凭据仅允许其访问自己（逻辑）数据库的权限，数据库位于共享的 MySQL 服务器上。有关更多信息，请参阅这篇博客文章。

使用每个服务一个数据库具有以下优点：

但这一模式也有以下缺点：

针对跨服务事务和查询的实现，可以采用以下模式或解决方案：

实现跨服务事务：使用 Saga 模式。
实现跨服务查询：
- API 组合：由应用程序执行数据关联而非数据库。例如，一个服务（或 API 网关）可以先从客户服务检索客户信息，再从订单服务查询客户的最近订单。
- 命令查询职责分离（CQRS）：维护一个或多个包含来自多个服务数据的物化视图。这些视图由订阅服务更新事件的服务维护。例如，在线商店可以通过维护一个将客户与订单关联的视图来实现一个查询，用于查找特定地区的客户及其最近的订单。此视图由一个订阅客户和订单事件的服务更新。