我正在处理具有大量集成任务的Web服务。我们将我们的服务与数十种其他服务连接起来，每种服务都有自己的持久存储。当然，我们为开发，舞台和制作目的提供了一些不同的环境。每个集成服务至少有两个环境：dev和prod。我考虑了两种可靠地分离环境的方法：
首先是对dev和（stage + prod）电路使用两个不同的DB 。这种方法允许每个域对象只有一个ID序列，因此第三方服务中不会有一个冲突。优点：简洁。缺点：从舞台到prod DB的危险访问。
第二个是对用于集成的对象的主键使用三个不同的DB 和保留范围（例如，用户pk，订单号等）。在这种情况下，我们将从不稳定阶段env的访问限制到阶段DB，并防止保留范围的任何冲突。
但是使用保留范围或ID的想法对我来说似乎很奇怪。有什么建议吗？
UPD：让我以另一种方式澄清我的情况。对于每个第三方服务生产环境，我都有两个环境：舞台和制作。因此，如果我的prod和stage envs有两个不同的数据库，而没有指定从我这边传送到第三方服务的对象ID的非交叉范围，那么我的舞台和第三方服务端的prod环境之间就会发生冲突。我应该在舞台和prod环境中使用一个DB还是引入ID范围？
答案 0 :(得分：2)
为什么你在同一个数据库中有stage和prod？我一直有三个数据库，dev，stage和prod，每个域对象都有一个ID序列。
这使舞台和生物保持物理分离。
如果没有别的，你怎么能允许在阶段验证新的数据库更改而不将它们（未经测试）应用于prod？