背景
假设你正在采用微服务架构构建一个在线商城。大多数服务需要将数据持久化到数据库。例如，订单服务存储订单信息，客户服务存储客户信息
数据库设计
问题
微服务应用的数据库架构是什么？
限制
- 服务必须松散耦合，因此它们可以独立的开发，部署和扩展
- 某些业务事务必须强制跨多个服务执行。比如，
Place Order用例必须验证一个新订单没有超出客户的信用额度。其他业务服务，必须更新多个服务拥有的数据。 - 一些业务事务需要查询多个服务拥有的数据。比如，
View Available Credit用例必须查询客户服务找出creditLimit，查询订单服务计算未结算订单的总金额。 - 一些查询必须关联多个服务拥有的数据。比如，查询指定区域的顾客和他们最近的订单，需要顾客和订单的关联。
- 数据库有时必须复制和分区，以便扩展。参见Scale Cube。
- 不同服务拥有不同的数据存储需求。一些服务，关系型数据库是最好的选择。其他服务可能需要NoSQL数据库，比如MongoDB，因为它适合存储复杂的非结构化数据，或者Neo4J，它设计来有效存储和查询图形数据。
解决方案
将每个服务微服务的存储保持为服务私有，仅通过它的API提供访问。下图展示了这个模式的结构。
每服务每数据库
服务的数据库是服务实现的有效部分。它不能被其他服务直接访问。
有几种不同的方式可以将服务的数据持久保持为服务私有。你没有必要为每个服务准备一个数据库服务器
比如，如果你杂横在使用关系型数据库，那么选择是：
- 每个服务私有的表 - 每个服务拥有一组仅能被它访问的表
- 每个服务一个schema - 每个服务都有一个私有的数据库schema
- 每个服务一个数据库 - 每个服务有自己的数据库服务器。
每个服务私有的表，和每个服务一个schema，有最小的开销。使用每个服务一个schema由于使关系更清晰，因此更吸引人。一些高吞吐量的服务也许需要自己的数据库服务器。
创建一个栅栏来强制模块化是个好主意。例如，你可以为不同服务分配不同的数据库账号，使用数据库访问机制，比如授权。如果没有一些类型的栅栏限制封装，开发人员往往被诱惑绕过服务的API，而直接访问它的数据。
结果
使用每服务每数据库有如下优势：
- 有利于确保服务是松散耦合的。对某个服务数据库的修改不会影响到其他服务。
- 每个服务可以使用最适合它需要的数据库。比如，进行文本查询的服务可以使用 ElasticSearch。操作社交图片的服务可以使用 Neo4j。
使用每服务每数据库有如下弊端：
- 无法简单直接的实现跨多个服务的业务事务。由于CAP理论，最好避免分布式事务。此外，大多数现代的（NoSQL）数据库不支持。最好的解决方案是使用Saga模式。当服务更新数据时，发布消息。其他服务订阅消息，并在响应时更新它们的数据。
- 实现查询并关联多个数据库的数据具有挑战性。
有各种各样的解决方案：
- API聚合 - 应用执行关联，而不是数据库。比如，服务（或网关）获取客户和他们的订单信息，可以首先从客户服务获取客户信息，接着从订单服务查询客户最近的订单。
- 命令查询职责分离（CQRS） - 维护一个或多个包含多个服务数据的物化视图。视图由服务维护，该服务订阅了其他服务更新数据时发布的事件。例如，在线商城实现查询特定区域的顾客和他们最近的订单时，应该维护一个关联了顾客和订单数据的视图。这个视图由订阅了顾客和订单事件的服务更新。
- 管理多个 SQL 和 NoSQL 数据库的复杂性
相关模式
- 微服务架构产生了对这个模式的需求
- Saga模式是实现最终一致性事务的有用方法
- API聚合和命令查询职责分离（CQRS）是实现查询的有用方法
- 共享数据库反模式描述了微服务共享数据库导致的问题
