对 dev 和 prod 数据库使用不同的 ID 范围答案

【问题标题】：Use different ID's ranges for dev and prod databases对 dev 和 prod 数据库使用不同的 ID 范围
【发布时间】：2014-10-17 11:24:04
【问题描述】：

我正在开发具有大量集成任务的 Web 服务。我们将我们的服务与数十个其他服务连接起来，每个服务都有自己的持久存储。当然，我们有几个不同的环境用于开发、阶段和生产目的。每个集成服务至少有两个环境：dev 和 prod。我考虑了两种可靠地分离环境的方法：

第一个是使用 两个不同的 DB 用于开发和（阶段 + 产品）电路。这种方法允许每个域对象只有一个 ID 序列，因此在第三方服务中不会发生一次冲突。优点：简单。缺点：从舞台到产品数据库的危险访问。

第二个是使用三个不同的数据库并为用于集成的对象的主键保留范围（例如，用户pk、订单号等）。在这种情况下，我们将来自不稳定阶段 env 的访问限制为仅对阶段 DB 进行访问，并防止保留范围内的任何冲突。

但使用保留范围或 ID 的想法对我来说似乎很奇怪。有什么建议吗？

UPD：让我以另一种方式澄清我的情况。对于每个第三方服务生产环境，我都有两个环境：舞台和生产。因此，如果我的 prod 和 stage envs 有两个不同的数据库，而没有指定从我这边传输到第三方服务的对象 ID 的非相交范围，那么我的 stage 和第三方服务端的 prod 环境之间将会发生冲突。我应该将一个 DB 用于 stage 和 prod 环境还是引入 ID 范围？

【问题讨论】：

标签： database architecture integration primary-key

【解决方案1】：

为什么你在同一个数据库中有stage和prod？我一直有三个数据库，dev、stage 和 prod，每个域对象都有一个 ID 序列。

这使得舞台和产品在物理上是分开的。

如果没有别的，您如何允许在阶段验证新的数据库更改而不将它们（未经测试）应用于产品？

【讨论】：

我同意，如果后台和 prod env 相同的数据库，prod 上会有未经测试的数据库更改。你说你有你的数据库，每个域对象都有一个 ID 序列。序列是按范围拆分还是与您的情况无关？请参阅我的问题更新。
让我确保我理解。您正在向第三方系统发送内容。您可以从 prod 和 stage 环境中执行此操作。您希望通过某种方式在另一端区分 prod 和 stage 内容，并且您希望使用序列范围来做到这一点。
您发送到第三方系统的 id 是否必须是数字、单字段 id？如果没有，我会尝试制作某种复合 id。有一个指定环境的字段，一个用于对象ID。这样你就可以拥有 dev、stage、prod、beta、qa 等......许多不同的环境，以及一个简单的过滤器来区分哪些内容来自哪个。如果他们需要单个字段，但它可以是字母数字，请使用这些环境作为前缀（prod-1234 与 stage-1234 是不同的对象）。
如果你真的需要一个数字键，你可以将它们用作掩码，但这似乎非常冒险，除非你在它们之间放置足够大的间隙以使其永远不会重叠。我想这最终是 ID 范围，尽管如果可能的话，我会将其作为与底层数据库序列分开的逻辑来驱动。制作一些相当硬编码的东西，否则在你从开发到阶段再到产品的过程中，你总是需要考虑这一点。
使用 env 的字符串前缀作为传输的 ID 的好主意。遗憾的是，并非所有服务都允许使用非数字 ID。我使用 PostgreSQL 作为主数据库，最后一个提供灵活的序列功能来组织范围。