DynamoDB“单表设计”能否与微服务架构完美搭配？

Question

微服务 - 多个数据库/表

当我第一次阅读微服务 (MS) 时，最引人注目的事情之一是每个 MS 都有自己的数据库。我想我现在理解这个概念并且我正在接受它。

NoSQL 数据库 - 单表

然后我开始研究 NoSQL DB，即 DynamoDB。我观看了这个深入的视频，其中演示者讨论了采用关系模型的想法 - 比如说 4 个表，并在一个表中表示数据。然后，他使用各种技术使数据即使在规模上也能超快查询。

再次，我想我理解这个概念。

将两者结合起来是我感到困惑的地方。MS 希望我将事物拆分为单独的服务，因此将数据库（或表）分开，但 NoSQL 模式希望我拥有一张表....

这两种设计模式/架构不能一起工作还是我遗漏了什么？

Answer 1

如果将这两种想法结合起来，那么最终每个微服务都有自己的数据库，而每个数据库只有一张表。

如果您在同一个 AWS 账户中运行多个微服务，我可以理解为什么您可能会感到困惑，因为您最终会在 dynamodb 中拥有多个表。我将解决一些问题，以尝试为您解决问题。

如何在 DynamoDB 中拥有单独的数据库？

在 DynamoDB 中，“独立数据库”的概念并不是一个非常有意义的想法。从 DynamoDB 的角度来看，每个表都独立于其他每个表（与关系数据库不同）。没有你需要管理的硬件，所以你看不到你的表是否在同一台服务器上，而且绝对没有数据库实例的概念。

如果 DynamoDB 没有“单独的数据库”，我如何拥有单独的数据库？

目标不一定是每个微服务都有一个单独的数据库。目标是确保微服务之间的唯一耦合是通过微服务提供的 API 进行的。拥有单独的数据库是帮助实施这一点的一种方法（这样微服务就不会绑定到共享的内部数据模式），但这不是唯一的方法。

所以我该怎么做？

每个微服务都应该有任何必要的表以使其正常运行。任何给定的表只能由一个微服务读取和写入。为了实现运行在同一 AWS 账户中的微服务之间的隔离，您应该使用 IAM 策略来确保每个微服务只访问自己的 dynamodb 表。在某些情况下，您最好将每个微服务放入自己的 AWS 账户中，以在它们之间提供更高级别的分离。（这种方法的另一个好处是，如果其中一个帐户遭到入侵，攻击者只能访问其中一个微服务。）