2
我正在處理大量集成任務的Web服務。我們將我們的服務與數十種其他服務連接起來，每種服務都有自己的持久存儲。當然，我們有幾種不同的開發，舞臺和製作環境。每個集成服務都至少有兩個環境：dev和prod。我認爲兩種方法可以可靠地分離環境：爲dev和prod數據庫使用不同的ID範圍
第一個是使用兩個不同的DB用於dev和（stage + prod）電路。這種方法允許每個域對象只有一個ID序列，因此在第三方服務中不會有一個衝突。優點：簡單。缺點：從舞臺到產品數據庫的危險訪問。
第二個是使用三個不同的DB和用於集成的對象的主鍵（例如用戶pk，訂單號等）的保留範圍。在這種情況下，我們僅限於從不穩定階段env訪問階段DB，並防止保留範圍發生任何衝突。
但使用保留範圍或ID的想法對我來說似乎很陌生。任何建議？
UPD：讓我以另一種方式闡明我的情況。對於每個第三方服務生產環境，我都有兩個環境：階段和生產。因此，如果我的prod和stage envs有兩個不同的數據庫，而沒有指定從我身邊傳輸到第三方服務的對象ID的非相交範圍，則我的舞臺和第三方服務端的prod環境之間會發生衝突。我應該使用一個DB用於舞臺和刺激環境還是引入一系列ID？
我同意，如果數據庫後臺和prod環境相同，那麼prod上會有未經測試的數據庫更改。你說你有你的數據庫，每個域對象都有一個ID序列。序列是按範圍分開還是在你的情況下無關緊要？請在我的問題更新中查看。 – 2014-10-17 16:14:05
讓我確定我明白了。您正在向第三方系統發送內容。你可以從產品和舞臺環境中做到這一點。您需要某種方式來區分產品和舞臺內容之間的另一端，並且您希望使用序列範圍來完成此操作。 – 2014-10-18 16:56:54
您發送給第三方系統的ID是否必須是數字，單字段ID？如果不是，我會嘗試製作某種合成編號。有一個字段指定環境，一個字段指定對象ID。這樣你就可以擁有開發，舞臺，產品，beta，qa等......許多不同的環境，以及一個簡單的過濾器來告訴哪些內容來自哪個。如果他們需要單個字段，但它可以是字母數字，請將這些環境用作前綴（prod-1234是與stage-1234不同的對象）。 – 2014-10-18 17:00:54