三層Web體系結構：分層機器上的圖層是否有益？

我正在爲之工作的一個客戶端有一個標準，要求將新應用程序的數據層包裝到Web服務中，並將一臺機器與業務/表示層的託管位置分開。有人能告訴我這樣做的好處是什麼？在我看來，這將導致更多的問題比它解決的：三層Web體系結構：分層機器上的圖層是否有益？

導致更多的流量/ CPU時間 - 生成的XML SOAP請求/反對響應直接連接到數據庫
難以調試 - 需要調試兩個獨立的項目反對一個

我猜這可能是由於安全問題（其中演示文稿的機器是暴露在互聯網和數據層機器沒有）;然而，我看不出如何比直接連接到數據庫更安全：登錄到數據庫的帳戶不應該具有比Web服務包裝器更多的訪問權限。

我錯過了什麼嗎？

來源

2009-10-06 John

那麼客戶給這個建築選擇的理由是什麼？ – SteveD 2009-10-06 14:54:07

他們還沒有完全解釋它...我現在寫這個，所以我會有一些背景，他們可能的原因可能是什麼，當他們做 – John 2009-10-06 18:19:00

可能是有益的。我想知道我們能找到一個真正的例子。 – Leo 2014-11-04 18:21:16

我認爲背後的原因與將域和業務邏輯包裝到存儲過程中的原因相同。爲在不同平臺上運行的多個應用程序和客戶端提供對數據的安全訪問，同時在數據層中執行數據完整性檢查和其他規則。

這個想法實際上是有道理的，但實現的想法並不完美。如果數據層佔用大量流量，那麼就性能和設備要求而言，序列化和反序列化數據將會產生巨大的成本。

來源

2009-10-06 14:02:21

+1我同意。只有集中多個應用程序的業務比每個應用程序的性能更重要，這纔是一個有效的解決方案。 – KLE 2009-10-06 14:08:47

另一個限制是，這應該只在1時使用。數據層很少變化;和2.如果它發生變化，綁定到它的應用程序將全部測試並可能重新部署。在多個功能獨立的項目中使用通用數據層是一個龐大的PITA。我發現一個更好的解決方案是每個應用程序維護自己的數據，並通過某種服務總線共享該數據。 – NotMe 2009-10-06 14:35:32

我認爲通過Web服務與數據層進行通信是很奇怪的，我不建議這樣做。

有既定的標準來訪問數據庫（我猜你的意思是一個數據庫，如果你談論一個數據層），其中還訪問遠程數據庫（如JDBC，ODBC，...）。所以沒有真正需要使用Web服務。
如果您使用網絡服務，您會遇到很多新問題，例如，超時，消息完整性，消息安全性或必須處理的可靠消息。這都是潛在的錯誤來源。
Web服務在延遲和消息大小方面都有巨大的開銷。爲了獲得快速的整體解決方案，Web服務必須是粗粒度的。例如。一個Web服務必須是整個過程的前端，比如註冊一個學生（保持消息交換的數量較低），但不像存儲學生的數據那麼細緻，然後將一個學習計劃附加到學生的數據中，然後追加爲學生的數據收取一些費用的新法案等（這些都是單獨的消息交換，但在訪問數據層時這也是一個通用粒度）。

所以我真的會去與數據層的JDBC/ODBC通信。 Web服務可能真的在業務層和表示層或第三方應用程序（應用程序集成）之間變得更有意義。

來源

2009-10-06 14:07:14 Macross

除了具有良好定義的接口的模塊化軟件的常見優勢之外，三層架構將獨立允許升級或替換三層中的任何一層，以滿足需求或技術更改。你也可以有許多前端服務器進行負載均衡。

例如，表示層中操作系統的更改只會影響用戶界面代碼。

看看銀行業務，您的網絡訪問帳戶信息仍然來自COBOL系統。

來源

2009-10-06 14:07:29

像許多建築問題一樣，它可以是一個平衡的行爲。

將3層Web應用程序拆分爲獨立機器上的每個層的一個好處是，您現在可以分別負載平衡應用程序的各個部分。例如，您可以有3個Web服務器只提供GUI，這個「集羣」將連接到3個應用程序服務器的「集羣」，所有這些服務器都很好地進行負載平衡，並被視爲Web服務器的單個「實例」。同樣，與DAL（數據訪問層）類似的情況。

以這種方式分離層也允許一定程度的整體應用層的「分離」。這允許每個層以不同的方式設置（即，可以使用不同的硬件或不同的OS等），並且只要界面保持一致，如果任何單獨的層被改變，則不應該存在問題。因爲DAL/BLL/UI現在將是獨立的程序集（可能是單獨編譯的DLL或等效的），並且真正地分離了層，而不是僅僅將代碼結構化爲單獨的一個應用程序/項目中的層。

過去，我已經將Web應用程序的業務層公開爲Web服務，並且Web GUI完全是針對該服務編寫的。這使得該公司可以將該產品作爲託管的基於網絡的解決方案進行銷售，客戶可以使用該解決方案，同時還可以銷售與Web服務相同的產品，從而允許客戶將產品的功能集成到自己的內部應用程序中（ala垂直市場解）。

當然，這是平衡的行爲。將各層分離到單獨的機器上會給系統的整體結構帶來一些複雜性。您正確地指出了一些潛在的問題，例如機器之間的流量，如果通信層位於同一臺機器上，現在會增加一些開銷，而這些開銷不在那裏。還有各層之間的數據編組也會增加開銷。當然，在Web服務的情況下，序列化和反序列化複雜對象可能會增加大量開銷並對性能產生負面影響，尤其是在流量非常大的情況下。

根據實際暴露給整個應用程序的用戶的情況，可能需要也可能不需要「較低」層的安全性。如果您只是公開Web GUI，則應將較低層配置爲不可訪問（不是通過Web服務器），但是，如果要公開「業務層」以及Web GUI層，則您將還有額外的負擔來確保您應用程序的多個潛在攻擊「表面」。儘管如此，如果你知道你不需要負載平衡單獨的層，並且你知道你不需要切換出一個層，或者將業務邏輯與Web分開公開用戶界面，它可能比它的價值更努力。

來源

2009-10-06 14:25:28 CraigTP

所以它聽起來像你在一臺服務器上有Web和業務邏輯，在另一臺服務器上有數據訪問代碼。這是不尋常的，因爲業務邏輯通常與Web服務器分離，並且在單獨的服務器上使用數據訪問代碼。這樣做的好處是，您的所有代碼邏輯（業務）都將與您的數據訪問代碼一起存在於安全區域（不在面向公衆的Web服務器上）。現有的Web服務會將API暴露給業務邏輯，而不僅僅是數據訪問代碼。

來源

2009-10-06 14:32:57

是的，這是安全應用程序的常見模式。

 
    - Database Node 
     | (database access protocol) 
    - Data Access Layer/Business Logic Layer Node 
     | (web services/RMI/CORBA/other protocol) 
    - Presentation Layer Node

通常web服務器暴露在DMZ中，所以BLL/DAL需要放在另一臺機器（節點）中。 Web服務被用作「連接協議」。很難通過Web服務闖入DAL服務器，並且數據由另一個節點保護。使用Web服務公開的表示層可以以自由形式（Java，.NET，Web客戶端或桌面應用程序）實現。

來源

2009-10-06 19:28:49 cetnar

三層Web體系結構：分層機器上的圖層是否有益？

回答

相關問題