架構一個這樣的系統，管理後台如果需要操作數據，只能直接連各個資料庫？為什麼

01-15

架構一個這樣的系統，管理後台如果需要操作數據，只能直接連各個業務庫，還是連各個業務庫的從庫，還是走各個業務服務呢，為什麼？或者說有什麼其他好的架構設計，請不吝賜教，拜謝

謝邀。我相信只有「成本」這一件事影響決策，而且「不計成本」這種假設是耍流氓。

問題中畫出的直接訪問資料庫的方案，是成本相對小的。

包裝到業務服務API層，包裝到前台層，都會增加成本（設計API、新舊功能維護等）

這些方案都不衝突，可以互相轉換。對新項目來說還是按時交付第一個版本最重要。

說幾句我對SP方案的看法：

做企業開發這是可取的，面向用戶的系統盡量避免。

企業軟體的細節複雜，難抽象，但是用戶固定，數據量不大。面向用戶的系統尤其是互聯網系統用戶量和數據量都是單台資料庫無法支撐的，用SP也很難達到隔離數據結構的目的。

謝邀。

可以考慮分散式服務，即對業務庫和管理庫的訪問封裝在一組獨立部署的共用伺服器上，這些服務負責訪問資料庫並根據業務需求將這些服務包裝成相對獨立的服務，比如用戶服務，訂單服務等等。業務和後台管理不直接連資料庫，而是通過調用這些共用的分散式服務用戶完成請求。

具體方案可參考《大型網站技術架構：核心原理與案例分析》(李智慧)【摘要書評試讀】可擴展的網站架構一章。

PS：反對使用存儲過程，至於為什麼，維護過業務系統的都知道。

其實真正靠譜的方法是盡量把根schema耦合的東西寫進stored procedure裡面。譬如說，你根據某種需要你要刪掉一個column，如果你在程序里直接訪問這個資料庫，你就會發現所有東西都要改。但是如果你是在SP裡面訪問，你改SP就可以了。因為軟體的功能沒有變，所以SP的參數表也是不會變的，資料庫變都是因為其他原因。而且就算功能變了，你仍然要用SP來訪問資料庫，這樣可以保證所有沒有改的程序訪問到SP的時候會直接失敗，而不會有些query恰好能用，有些不能用，那到時候你就糟糕了。

而且用SP還有另外一個好處，就是你可以只給所有程序的資料庫用戶一個execute許可權，其他全部沒有。就算你的伺服器被爆了，人家也拿不到你的任何東西。

因此「管理後台」直接訪問所有stored procedure，具體的事情在SP裡面干。這樣做是沒有問題的。千萬不要直接發select什麼的。

1. 對於只讀不寫的操作，尤其是比較大的查詢，比如生成報告什麼的，請連從資料庫。

2. 如需更新數據，需考慮業務層是否有緩存，

a）無緩存時，可直接連主資料庫更新。

b）有緩存時，可用以下方法，

i）管理層更新主資料庫，通知業務層。好處是直觀，壞處是多了管理層和業務層的通訊協議，還有些安全問題。

ii）管理層通過業務層更新數據，這樣業務層可以通過write-through, 同時更新緩存和資料庫。相對來說比較安全，協議簡單，出問題的概率也較小。

iii）布置分散式緩存，管理層更新緩存，應有層直接讀就可以了。比較乾淨的做法，但需要一些架構上的改動。

3. 盡量把對數據的操作封裝在程序的API中，而不是資料庫的stored procedure。讓管理層和業務層都可以安全的使用這些API，使數據層透明，減少對特定資料庫的依賴。

「只能直接連各個業務庫，還是連各個業務庫的從庫，還是走各個業務服務呢」

這個只能是看具體功能場景了。

其實原則管理後台和前台差不多的策略，

比如

即時性高的數據讀寫直接訪問業務庫，

需要大量查詢比較佔資源的讀訪問業務從庫

能重用的就重用業務服務。

我覺得這張畫應該這麼畫。管理後台與前端網站有部分是重疊的，區分不同用戶許可權

一般原則是如果能走業務api就盡量不要直接走資料庫，如果不能可考慮抽象一個數據層來共用，實在不行，處理好緩存臟數據問題也是可以走資料庫的，沒有絕對正確的方案，結合業務場景，想明白就行。