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