大規模動態應用系統平臺主要針對大流量、高併發網站構建的底層系統架構。執行大型網站需要一個可靠、安全、可擴充套件、易維護的應用系統平臺作為支援，以保證網站應用的平穩執行。

下面的圖表很好地概述了現代Web應用體系結構。要是沒有一個有經驗的Web開發人員，你可能會覺得這很複雜。使用下面的介紹可以對每個元件的詳細資訊有一個初步的瞭解和理解。

1。DNS

DNS的意思是“域名伺服器”，是實現全球資訊網的中樞技術。為從域名（例如，google。com）到IP地址（例如，85。129。83。120）的關鍵字/值提供查詢，這對於計算機將請求路由到適當的位置是必要的。與電話號碼相似，域名和IP地址之間的差別在於“打電話給我”和“打電話給我201-867-5309”。類似於需要一個電話簿去查詢過去的號碼一樣，需要一個用來查詢域名IP地址的通行權。因此，可以將DNS視為網際網路的電話簿。

2。負載均衡

在深入研究負載平衡的細節之前，需要退一步討論水平與垂直應用程式擴充套件。水平擴充套件意味著可以透過在資源池中新增更多計算機來擴充套件，而“垂直”擴充套件意味著可以透過向現有計算機新增更多功率（例如，CPU，RAM）來擴充套件。

在Web開發中，總是希望水平擴充套件，為了簡單起見，也是因為內容可能會中斷。服務執行的過程中會出現伺服器隨機崩潰、網路降級、整個資料中心離線等問題。擁有多個伺服器允許規劃中斷，以便應用程式繼續執行。換句話說，應用程式是“容錯的”。其次，橫向擴充套件允許透過讓每個部分在不同的伺服器上執行來最小化地耦合應用程式後端的不同部分（Web伺服器，資料庫，服務X等）。

回到負載平衡器，它們使水平縮放成為可能。它們將傳入的請求路由到許多應用程式伺服器中的一個，這些伺服器通常是彼此的克隆/映象映像，並將響應從應用程式伺服器傳送回客戶端。它們中的任何一個都應該以相同的方式處理請求，因此只需要在伺服器集中分發請求，這樣就不會使這些請求過載。

3。Web應用伺服器

Web應用程式伺服器的描述相對簡單。它們執行處理使用者請求的核心業務邏輯，並將HTML傳送回用戶的瀏覽器。為了完成其工作，它們通常與各種後端基礎設施進行通訊，例如資料庫，快取層，作業佇列，搜尋服務，其他微服務，資料/日誌記錄佇列等。如上所述，為了處理使用者請求，通常需要多個應用伺服器，並且需要插入負載均衡服務。

應用伺服器的實現需要選擇特定語言（Node。js，Ruby，PHP，Scala，Java，C＃。NET等）和該語言的WebMVC框架（ExpressforNode。js，RubyonRails，PlayforScala，LaravelforPHP等）。深入研究這些語言和框架的細節超出了本文的範圍。

4。資料庫伺服器

每個現代Web應用程式都利用一個或多個數據庫來儲存資訊。資料庫提供了定義資料結構，插入新資料，查詢現有資料，更新或刪除現有資料，跨資料執行計算等的方法。在大多數情況下，Web應用程式伺服器與作業伺服器直接對話。此外，每個後端服務可能擁有自己的資料庫，該資料庫與應用程式的其餘部分隔離。

NoSQL代表“Non-SQL”，它是一種新的資料庫技術集，它可以處理大規模Web應用程式可以生成的大量資料（SQL的大多數變體都不能很好地水平擴充套件，只能垂直縮放到某一點）。大體上，業界正在將SQL作為一個介面，即使對於NoSQL資料庫也是如此。學習SQL是必不可少的，幾乎所有的Web應用都會使用它。

5。快取服務

快取服務提供了一個簡單的鍵/值資料儲存，可以在接近O（1）的時間內儲存和查詢資訊。應用程式通常利用快取服務來儲存昂貴計算的結果，以便可以從快取中檢索結果，而不是在下次需要時重新計算它們。應用程式可能會快取資料庫查詢，對外部服務的呼叫，給定URL的HTML等等的結果。以下是來自實際應用的一些示例：

Google會為常見搜尋查詢（如“dog”或“TaylorSwift”）快取搜尋結果，而不是每次都重新計算它們

Facebook會快取您在登入時看到的大部分資料，例如釋出資料，朋友等。在此處閱讀有關Facebook快取技術的詳細文章。

目前兩種最普遍的快取伺服器技術是Redis和Memcache。

6。任務佇列&伺服器

大多數Web應用程式需要在幕後非同步執行一些與響應使用者請求無直接關聯的工作。例如，Google需要抓取並索引整個網際網路才能返回搜尋結果。但是它不是每次搜尋時都會這樣做。相反，它非同步爬取資訊，在整個過程中更新搜尋索引。

雖然有不同的體系結構可以完成非同步工作，但最普遍的就是我稱之為“作業佇列”的體系結構。它由兩部分組成：需要執行的“作業”佇列和執行佇列中作業的一個或多個作業伺服器（通常稱為“工作者”）。

作業佇列儲存需要非同步執行的作業列表。最簡單的是先進先出（FIFO）佇列，但大多數應用程式最終需要某種優先順序排隊系統。每當應用程式需要執行作業時，無論是在某種常規計劃中還是由使用者操作確定，它只需將相應的作業新增到佇列中。

例如，相關公司可以利用一個工作佇列提供後臺支援。執行工作來編碼影片和照片，處理CSV以進行元資料標記，聚合使用者統計資訊，傳送密碼重置電子郵件等。工作佇列可以採用優先順序佇列演算法，以確保儘快完成傳送密碼重置電子郵件等時間敏感操作。

作業伺服器處理作業。它們輪詢作業佇列以確定是否有工作要做，如果有，它們會從佇列中彈出作業並執行它。

7。全文搜尋服務

許多Web應用程式支援某種搜尋功能，其中使用者提供文字輸入（通常稱為“查詢”），並且應用程式返回最相關的結果。支援此功能的技術通常稱為“全文搜尋”，它利用反向索引快速查詢包含查詢關鍵字的文件。

雖然可以直接從某些資料庫進行全文搜尋（例如，MySQL支援全文搜尋），但通常執行單獨的“搜尋服務”來計算和儲存反向索引並提供查詢介面。今天最流行的全文搜尋平臺是Elasticsearch，儘管還有其他選項，如Sphinx或ApacheSolr。

8。通用服務

一旦應用程式達到一定規模，可能會有某些“服務”被分割出來作為單獨的應用程式執行。它們沒有暴露於外部世界，但應用程式和其他服務與它們互動：

帳戶服務：在網站上儲存使用者資料，這使得商家能夠輕鬆提供交叉銷售機會並建立更統一的使用者體驗

內容服務儲存所有影片，音訊和影象內容的元資料。它還提供用於下載內容和檢視下載歷史記錄的介面。

支付服務提供用於對客戶信用卡進行計費的介面。

HTML→PDF服務提供了一個接受HTML並返回相應PDF文件的簡單介面。

9。資料

如今，公司存亡取決於他們利用資料的能力。幾乎每個應用程式，一旦達到一定規模，就會利用資料管道來確保收集，儲存和分析資料。典型的管道有三個主要階段：

1、該應用程式將資料（通常是關於使用者互動的事件）傳送到資料“firehose”，該資料提供用於攝取和處理資料的流介面。通常，原始資料被轉換或擴充並傳遞給另一個firehose。AWSKinesis和Kafka是用於此目的的兩種最常用的技術。

2、原始資料以及最終轉換/增強資料儲存到雲端儲存。AWSKinesis提供了一個名為“firehose”的設定，可以將原始資料儲存到雲端儲存（S3）中，非常容易配置。

3、經過轉換/增強的資料通常被載入到資料倉庫中進行分析。大型公司通常會使用Oracle或其他專有儲存技術。如果資料集足夠大，則可能需要類似Hadoop的NoSQLMapReduce技術進行分析。

架構圖中沒有描繪的另一個步驟：將資料從應用程式和服務的操作資料庫載入到專門儲存資料的資料庫中。透過將核心業務資料與使用者互動事件資料結合起來，為分析師提供一個整體資料集。

10。雲端儲存

據AWS稱，“雲端儲存是一種透過網際網路儲存，訪問和共享資料的簡單且可擴充套件的方式”。您可以使用它來儲存和訪問或多或少儲存在本地檔案系統上的任何內容，並且可以透過HTTP上的RESTfulAPI與其進行互動。亞馬遜的S3產品是目前最流行的雲端儲存產品，也是許多多媒體行業公司廣泛依賴的產品，用於儲存影片，照片和音訊資產，CSS和Javascript，使用者事件資料等等。

11。CDN

CDN代表“內容分發網路”，該技術提供了一種透過網路提供靜態HTML，CSS，Javascript和圖片等內容的方式，比從單一源伺服器提供服務要快得多。它的工作原理是在世界各地的許多“邊緣”伺服器上分發內容，以便使用者最終從“邊緣”伺服器而不是源伺服器下載內容。例如，在下圖中，西班牙的使用者從位於紐約市的原始伺服器的站點請求網頁，但該頁面的靜態資產是從英格蘭的CDN“邊緣”伺服器載入的，從而防止了許多緩慢的跨大西洋HTTP要求。

通常，Web應用程式應始終使用CDN來提供CSS，Javascript，影象，影片和其他媒體內容。某些app也可能利用CDN來提供靜態HTML頁面。