具有數據訪問層/服務層的性能影響？

Question

我需要設計具有這些基本部件的系統：

• 一個網絡服務器，其將越來越〜100請求/秒。 Web服務器只需要將數據轉儲到原始數據存儲庫中。
• 原始數據存儲庫，其中有一個從Web服務器獲取100行/秒的表。
• 甲原始數據處理單元（簡單處理，不多。卸下無效的原始數據，將缺少的組件成損壞原始數據等）
• 處理過的數據存儲庫

是否有意義在這樣的系統有一個服務層的所有組件將建成？所有組件間的交互都將通過服務層進行。雖然這會使系統易於升級和維護，但是由於我擁有如此多的流量來處理，它是否會對性能產生重大影響？

Answer 1

你認爲具有單獨服務層的成本是什麼？

這些費用如何與必須產生的費用相比較？你的情況，這似乎是至少

1. 網絡讀取請求
2. 原始數據
3. 數據庫的數據庫寫入讀取原始數據的
4. 處理的數據
的數據庫寫入

加上一些數據消息。

你有什麼樣的服務？也許

• saveRawData（）
• getNextRawData（）
• writeProcessedData（）

爲什麼開銷比任何一個過程調用更多？服務不需要暗示「單獨進程」或「Web服務編組」。

我認爲結構總是有價值的，應用程序中的關注點分離真的很重要。與數據庫活動相比，一些過程調用很少花費太多。

順便說一下：原始數據的持久化可能最好做到排隊系統。然後，如果您需要它們，您可以在獨立的機器上安裝多個隊列閱讀器，從而實現自然縮放。實際上，排隊系統自然引入了一些類似服務的概念。

Answer 2

個人覺得您在設計系統時可能過於關注低層實現細節。在研究如何佈置組件，組件或服務之前，您應該考慮如何構建系統。

你可以用下面的高水平語句開始從中各地建立自己的系統架構：

1. 確認的技術技能的開發團隊和運營/支持團隊。
2. 同意將集成到您的服務，它們支持的協議和一些SLA的系統的初始有限列表。
3. 確定消息傳遞策略。
4. 瞭解如何部署您的服務/系統。
5. 決定選擇中間件（ESB，Message Brokers等），數據庫（SQL，Oracle，Memcache，DB2等）和第三方框架/工具。
6. 決定您的緩存和數據延遲策略。
7. 將您的應用程序分解爲各個業務責任領域 - 這將允許您分開工作並在開發/測試和實施過程中更輕鬆地交流里程碑。
8. 根據需要設計每個部件以符合責任範圍。責任領域應自動引導您決定如何設計組件，組裝或服務。

顯然不是所有的上述都符合你的具體情況，但我建議他們至少應該給一些想法。

祝你好運。

Answer 3

以下是可能發生的情況，除非您提防。

在層之間的通信中，選擇了一些格式，如XML。然後你建立並運行它，發現性能並不理想。

然後，你陷入探查器，讓你猜猜問題是什麼。

當我處理這樣的問題時，我使用了stackshot technique並很快發現了問題。你會認爲這是I/O。不。正是將數據轉換爲XML，並解析XML以恢復數據結構，大約需要80％的時間。找到更好的方法即並不難。結果 - 5倍加速。

Answer 4

抽象和分層將會引入延遲，但真正的問題是，你有什麼收穫使成本值得？鬆耦合，治理，可擴展性，可維護性都值得真實$。

即使是最好設計的分層應用程序也會比直接與數據庫交互的應用程序顯示更多延遲。知道原始系統的用戶會感覺到不同。他們可能不喜歡它，所以這可能是一個政治問題，就像技術問題一樣。