分佈式分佈式應用程序的體系結構

Question

我們正在維護一個計劃應用程序，該應用程序部署在幾個物理分離的站點上。這些站點使用多主複製（使用Oracle 10g DB），這意味着沒有中央站點（分散式系統）。然而，隨着網站數量的增長 - 我們的困境也在增加：更多的衝突應該被手動解決。

我們將重新實現該應用程序，並且希望考慮此架構的替代方案。

是在站點之間共享的數據是2種口味：

• 地圖（附加的只讀數據，存儲爲存儲在數據庫文件的元數據。）
• 計劃和相關數據（存儲爲關係數據在數據庫中）

所有數據都需要在所有站點中存在，但它對於即時可用並不重要。

即使與網絡斷開連接，網站也應能夠正常工作。

任何幫助，將不勝感激。

Answer 1

最好的體系結構適合問題的背景：最終形成最佳體系結構和解決方案的驅動程序是什麼？例如（從Yuriys的角度來看）：你的困境可能是性能和/或數據管理相關的 - 兩者都需要解決，但是你不可能得到一個解決這兩個問題的解決方案，它們甚至可能是矛盾的。

在數據管理方面，我建議您需要擁有「真實」數據的主副本。但是這可能不適合表現 - 當然這取決於方法。

就具體情況而言：我會從數據開始：模型化，確保理解它，理解當前的數據流以及它們與業務流程的關係。您希望達到您可以說「我們這樣做，因爲業務流程合理要求」和「我們這樣做，因爲我們不應該有技術限制」。

在一般意義上，你需要：

1. 把你的問題，因爲輸入的背景。
2. 這將有助於塑造你的得分標準（這是你將如何評價你的想法）。
3. 定義初始高級解決方案選項 /方向。這些都是藍天的討論，可以相對不受限制：思考力量大，思考難題。關鍵的一點是不要開始思考實施 - 甚至是具體的技術。您也可以將業務限制放在一邊：「我們這樣做是因爲當前的業務流程是X，如果我們採用Y（使用這種新技術），那麼我們可以做Z並降低運營成本」。
4. 評論和得分這些違反你的得分標準。
5. 追查邏輯選項：基本上輸出3 & 4並帶他們到一個新的水平。您現在可能想開始考慮企業/設計模式。
6. 評論和評分這些對你的評分標準
7. 追求實施選項：你需要一個組件做「X」：你重複使用，購買或建造？有最好的工具可以使用嗎？它們是否與您當前的基礎設施兼容？等等。
8. 評論和得分這些違反你的得分標準。
9. 記錄結果（爲什麼）在建築決策註冊表中供將來參考;這應該/必須包括前面步驟的輸入和輸出。這裏的想法是阻止那些追隨你的人不得不重新做所有的工作 - 或者盲目地用一個糟糕的決定來重寫你的深思熟慮的決定。

更新：具體細節

• 您使用 「多主」 複製 - 怎麼樣主從？
• 您正在使用數據庫複製 - 那不是以數據庫爲中心的解決方案呢？
• 查看特定於數據和/或分佈式系統的設計模式; Data Patterns看起來像一個好的開始（我自己並沒有讀過它，也許Oracle提供了類似的材料，可能更適合您的平臺的具體情況）。
• 如果網站離線，您可以鎖定某些表格/數據，以便它們不能更改，直到再次上線爲止？
• 使用「檢出」源控制方法確保數據更改得到良好控制。
• 看看不同的緩存方法，這可能會給你一些有用的想法，因爲基本概念是保持本地數據副本以便快速訪問 - 而不會讓它們過時。
• 看看多租戶架構，他們經常需要處理以不同方式分離數據並在分佈式環境中工作。

是的，我確實提供了一個普遍的答案 - 但給出的信息也是相當普遍的:)