2.14.1　每个微服务对应一个数据存储

每个微服务对应一个数据存储是微服务架构的关键要素。当两个微服务可以直接访问同一数据存储时，它们就是紧耦合的，不再独立。有一些重要的细微差别需要理解，多个微服务可以使用相同的数据库实例，但是它们一定不能共享相同的逻辑数据库。

数据库实例是一个资源供应问题。在某些情况下，开发微服务的团队也负责提供数据存储。在这种情况下，明智的做法可能是为每个微服务在物理上分离数据库实例，而不仅仅是逻辑上的。注意，在使用云数据存储时，微服务开发人员不知道也无法控制数据存储的物理配置。

我们同意两个微服务不应共享同一数据存储。但是，如果单个微服务管理两个或更多数据存储呢？通常这是不被允许的。如果你的设计需要两个独立的数据存储，最好是分别提供一个微服务，如图2-3所示。

图2-3　每个微服务对应一个数据存储

有一个常见的例外：你可能希望通过同一个微服务来管理内存中的数据存储（缓存）和持久化数据存储。工作流程通常是服务向持久化存储和缓存中写入数据，并从缓存获得查询结果。缓存会定期刷新，或基于更改通知来刷新，或者在缓存未命中时刷新。

但是，即使在这种情况下，最好有一个单独的集中式缓存，例如由单独的微服务管理的Redis。注意，在为许多用户服务的大型系统中，每个微服务可能都有多个实例。

从微服务本身抽象出物理配置和数据存储的另一个原因是，这些配置在不同的环境中可能是不同的。你的生产环境可能为每个微服务配置在物理上独立的数据存储，但是在开发环境中，最好只有一个物理数据库实例，其中包含许多小型逻辑数据库。