Pattern: Database per service。
背景
如用微服务架构模式开发一个在线商店应用程序。大多数服务需要在某种数据库中持久化数据。如，订单服务存储订单信息，而客户服务存储客户信息。
问题
微服务应用程序中的数据库架构是什么？
驱动力
- 服务必须松耦合，以便能够独立开发、部署和扩展。
- 某些业务事务必须在多个服务之间强制执行不变量。例如，
下订单用例必须验证新订单不会超出客户的信用额度。其他业务事务需要更新由多个服务拥有的数据。 - 一些业务事务需要查询多个服务的数据。例如，
查看可用信用额度用例需要查询客户服务获取信用额度，并查询订单服务计算未结订单的总金额。 - 某些查询需要关联多个服务的数据。例如，查找特定地区的客户及其最近的订单需要在客户和订单之间进行数据关联。
- 数据库有时需要复制和分片以实现扩展。参见扩展立方体。
- 不同的服务对数据存储有不同的需求。例如，某些服务适合使用关系型数据库，而其他服务可能需要 NoSQL 数据库（如 MongoDB）来存储复杂的非结构化数据，或者需要 Neo4J 来高效存储和查询图数据。
解决方案
让每个微服务的持久性数据对该服务私有，并仅通过其 API 访问。服务的事务只涉及其自己的数据库。
下图展示了这一模式的结构。
服务的数据库实际上是该服务实现的一部分。它不能被其他服务直接访问。
有几种方法可以让服务的持久性数据保持私有性。你不需要为每个服务配置一个独立的数据库服务器。例如，如果你使用的是关系型数据库，可以选择以下方式：
- 每服务私有表：每个服务拥有一组只能由该服务访问的表。
- 每服务一个模式：每个服务拥有一个私有的数据库模式。
- 每服务一个数据库服务器：每个服务都有自己的数据库服务器。
每服务私有表和每服务一个模式的实现开销最低。使用每服务一个模式较为吸引人，因为它可以更加清晰地划分所有权。一些高吞吐量服务可能需要独立的数据库服务器。
建议创建屏障以强制实现模块化。例如，可以为每个服务分配不同的数据库用户 ID，并通过数据库访问控制机制（如授权）来限制访问。如果没有这些强制手段，开发人员可能会直接绕过服务的 API 访问其数据。
示例
FTGO 应用程序 是一个使用这种方法的示例。每个服务都拥有数据库凭据，这些凭据仅允许其访问自己（逻辑）数据库的权限，数据库位于共享的 MySQL 服务器上。有关更多信息，请参阅这篇博客文章。
结果情境
使用每个服务一个数据库具有以下优点：
- 有助于确保服务之间的松耦合。对一个服务数据库的更改不会影响其他服务。
- 每个服务可以选择最适合其需求的数据库类型。例如，进行文本搜索的服务可以使用 ElasticSearch，而操作社交图的服务可以使用 Neo4j。
但这一模式也有以下缺点：
- 实现跨多个服务的业务事务并不简单。由于 CAP 定理，分布式事务应尽量避免。此外，许多现代（NoSQL）数据库不支持分布式事务。
- 实现跨多个数据库的数据关联查询较为复杂。
- 管理多个 SQL 和 NoSQL 数据库会增加系统复杂性。
针对跨服务事务和查询的实现，可以采用以下模式或解决方案：
- 实现跨服务事务：使用 Saga 模式。
- 实现跨服务查询：
- API 组合：由应用程序执行数据关联而非数据库。例如，一个服务（或 API 网关）可以先从客户服务检索客户信息，再从订单服务查询客户的最近订单。
- 命令查询职责分离（CQRS）：维护一个或多个包含来自多个服务数据的物化视图。这些视图由订阅服务更新事件的服务维护。例如，在线商店可以通过维护一个将客户与订单关联的视图来实现一个查询，用于查找特定地区的客户及其最近的订单。此视图由一个订阅客户和订单事件的服务更新。
相关模式
- 微服务架构模式：引发了对这种模式的需求。
- Saga 模式：是一种实现最终一致性事务的有效方法。
- API 组合和命令查询职责分离（CQRS）：提供了实现跨服务查询的实用方法。
- 共享数据库反模式：描述了微服务共享数据库时可能导致的问题。
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。
各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
负责：
- 中央/分销预订系统性能优化
- 活动&券等营销中台建设
- 交易平台及数据中台等架构和开发设计
- 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
- LLM Agent应用开发
- 区块链应用开发
- 大数据开发挖掘经验
- 推荐系统项目
目前主攻市级软件项目设计、构建服务全社会的应用系统。
参考：
本文由博客一文多发平台 OpenWrite 发布！
