Web 應用程序的基礎架構
我很好奇 Web 應用程序的基礎架構……它是具有相同應用程序/原始碼的複製伺服器網路、複製數據庫伺服器網路和位於網路後面的媒體/資產伺服器網路嗎？負載均衡伺服器？如果是這樣，網路應用程序是否需要某種類型的功能來幫助實現這一點？
哇，這是一個非常廣泛的問題 :) 對於 serverfault 來說，這完全是題外話，所以它可能會在一段時間內關閉。但由於現在是星期六下午，我正處於講故事的心情中，所以這裡有一個答案，大致基於我們如何發展我目前工作的公司的簡化版本。
簡短的答案是我最喜歡的：這取決於。儘管有一些常見的模式，但沒有“這就是你建構 webapp 的方式”的秘訣。
您的問題假設 webapp 在多個伺服器上執行，儘管這不一定是真的。每個網站都可以被視為一個 webapp。像部落格這樣簡單的東西是一個在同一個盒子上包含數據庫、程式碼和靜態資產的 web 應用程序，沒有任何高可用性。這就是大多數啟動 webapps 的啟動方式。現在，如果它們長大會發生什麼？
在某些時候，它們超出了單個伺服器，因此它們向外擴展：拆分數據庫和應用伺服器（它也處理所有靜態資產）。任何非實時程式碼，如 cronjobs 都可以移動到另一台伺服器。業務已保存….暫時。
因為健康的企業也會超越這一點。應用程序伺服器往往易於擴展，因此您經常會看到人們在一對 HA 負載均衡器後面使用一組應用程序伺服器。正確設置環境使用諸如 puppet 或 func 之類的東西來保持它們同步，並對其程式碼使用部署方法，通過使用負載均衡器，在沒有使用者可見的停機時間的情況下進行部署/回滾。像這樣的設置允許您將應用伺服器水平擴展至相當大的規模。
但是當然數據庫會變得很忙，所以數據庫會增加一組從屬伺服器來解除安裝讀取操作。並且可能建構了一個記憶體層來完全避免從數據庫中讀取。然後，當主節點忙於處理所有寫入時，數據會被分片到多個複制鏈上。只要您的數據易於分片和複製，這也為您提供了很大的擴展空間。
與此同時，您的業務增長如此之快，以至於頻寬和靜態內容的數量也成為一個問題，因此靜態資產不再由應用伺服器提供服務，而是由一組專用伺服器提供服務。也許前面有一個 CDN 來幫助處理傳入的頻寬。
完成所有簡單的事情后，現在它開始變得有趣。當您達到這個規模時，您可能希望避免任何停機時間。因此，您可以為剩餘的單點故障（如數據庫主控）查看更多高可用性選項。如果您的主數據中心出現故障，您會考慮災難恢復。你也將成為網際網路上各種惡意人士的目標。DDOS 攻擊和企圖破壞您的安全邊界是您需要應對的持續威脅。
應用伺服器是否需要一些功能來處理這一切？不，但你的環境確實如此。最好讓面向客戶的伺服器保持低調和快速，並擁有智能控制機制來處理部署、一致性檢查、監控和處理攻擊。這使應用伺服器可以專注於為客戶服務，這就是賺錢的原因。