網絡應用程序的N層體系結構模式

Question

我正在尋找服務器端軟件的架構模式，尤其是網絡應用程序，這些模式在現實世界中被用於很好的理由。這裏有一些我能想到的：

• 單服務器：在同一臺服務器上的應用程序運行的所有部分（數據庫，應用程序，Web服務器偵聽端口80等）
• 簡單的2 -Tier：數據庫在單個服務器「DB」上運行，而「應用服務器」層中的所有其他部分可能包含任意數量的服務器。層通過ODBC等進行通信。這
• ，變化（？我們多少能一一列舉）包括單主/多從的DB服務器和多主數據庫服務器
• 3層：數據庫上一層運行，業務對象和邏輯在第二層上運行，在第三層上呈現，其中1和2通過ODBC進行通信，2和3通過某種形式的遠程調用（例如RMI）進行通信
• 我似乎從一些介紹中回憶起， ，eBay擁有一個應用程序層生成XML的架構，然後在單獨的層中轉換爲HTML。這是常見還是怪異？
• 一些網絡應用程序使用memcachedb等來加快速度。也許有一組緩存服務器可以說是另一個層次？

你能幫我列舉一些這些模式，或者指出一些已經描述過的地方嗎？

Answer 1

你可能會喜歡十年前的但仍然相關的經典Building a Large-Scale E-commerce site with Apache and mod_perl。他們的層次是：

1. 負載均衡
2. 反向代理
3. 的Web /應用服務器
4. 數據庫服務器

這仍然是大型網站的藍圖。甚至更大的網站規模的網站可能需要更神祕的東西，但這是理解它們的基礎。

請注意，他們使用mod_perl，這意味着他們的Web服務器是他們的應用服務器。如果您當時正在使用Java，那麼您將運行應用程序服務器作爲Web服務器後面的一個層（通過「web服務器」，我的意思是Apache，處理HTTP解析，TLS和靜態文件;提取並攜帶，但不包含邏輯），並將它們與AJP連接起來。您今天仍然可以這樣做，但是您更可能僅將應用程序服務器用作您的Web服務器（即根本就沒有Apache，只是JBoss或類似服務器）。應用程序服務器現在已經足夠強大，可以完成這項任務，並且您可以依靠反向代理服務器和內容分發網絡來完成大部分抓取操作。

至於緩存層，反向代理是位於應用服務器前面的緩存層，但他們在應用服務器機器上做了應用層緩存，帶有聯合緩存（您可以使用memcached或類似的今天這個）。我認爲今天仍然是一個可行的選擇。我沒有看到將您的應用層服務器劃分爲專用應用和緩存服務器的理由;我有興趣聽說有理由這樣做。

我不認爲將應用層中的表示和業務邏輯分開是一個真正起飛的想法。有些項目可能會這樣做，但我會想象，因爲他們有架構宇航員負責，而不是任何理由。也就是說，通常有一個應用程序層大量使用服務層（我猜這是SOA），並且最終的擴展本質上是一個表示/邏輯分離，但是使用異構邏輯服務器，以及演示服務器非常重要。