既然說了大型，首先要考慮的就是高用戶並發的情況。這就需要結合妳實際用戶端應用場景，視頻都雙向傳輸和簡單的低通量的文本交互壹定不是壹個概念。做大型的系統，還要考慮平時的情況和突發的高占用率情況。
首先我們先對應用做壹個分類：
1.高帶寬消耗累應用
這個方面的代表就是直播相關或網絡教學領域。直播系統的大體原理，主播手機采集音視頻、編碼，然後推送壹個視頻流給服務器（實際上是壹個做了負載均衡的視頻服務器矩陣組）。然後負責實時流媒體數據流接收的服務器，會將流媒體數據流推送給分發服務器（現在有現成的CDN,這樣開發難度就小了很多。）然後觀眾申請觀看的時候，分發服務器就會將所申請的時時流媒體推薦給客戶。
這麽粗糙的應用就可能包換用戶端權限管理服務器組，業務調度服務器組，不同區域IDC建立的接入服務器組，不同區域IDC建立的分發服務器組，分等級的數據存儲服務器組，ai內容審核服務器組（基於分流實時分析，預設內容審核規則），歸檔視頻存儲服務器組，短視頻評級推薦服務器組，應用興趣行為分析服務器組。客戶在請求交互的時候可能還會有壹些緩沖的隊列呀，nosql之類的（redis，memcache）。各組服務器的規格和數量都是根據同時並發的情況定的，在程序開發好的時間可以通過自動化的方式模擬高並發，再通過查看分析瓶頸，而對前期的規劃做出合適的調整。
有些時間還要實現不經過分發，交互直通以降低延時。pk的連線的時候，太高延時是接受不了的。這個就不繼續展開了。
還有網盤類應用也也很多類似，只是延時要求沒那麽高。傳統的視頻網站也是基本相同原理。
傳統的微博也是類似的分發機制。
2.低延時需求型
這方面壹般是以網絡遊戲為主。對於壹些點電子競技類的應用，做到80ms以下的低延時是必須。服務器的核心響應速度和帶寬的低延時是重點。這種服務器最好可以獨享壹條專線，或者在虛擬網絡系統中設置壹個更高的優先級，數據線優先同行也會盡可能的降低延時。至於服務器組之間的vpc也應該有壹個更高的通過優先級，以保證服務器之間的訪問延時極地。這種應用服務器，最好要支持核心運算，不過這個要開發的架構支持。
再就是後期用戶量大的時候，做更新包下載的時候會采用分發服務器（CDN）。
3.高突發的緩沖
這種都是電商網站，平時就是講全段應用服務器做彼此依賴，後端選擇壹個大吞吐，大並發的後端框架（京東使用的go語言對高並發和數據挖掘就有很多優勢，我也剛開始學習）。這種系統網元架構就簡單很多，傳統的負載均衡後掛著不同模塊的應用服務器組，然後經過緩沖服務器組，之後到達數據服務器組和APIGateway。
日常的應用都是沒啥問題，都是因為壹些節日或促銷，或爆款等發生臨時性數據操作的擁堵。解決這種緩沖都方式有很多，比如臨時快速讀寫緩存，消息隊列等。甚至開發總線通信隊列等待機制，很多解決方案。
現在系統本身的規劃和後期都優化都有許多解決方案，現在的瓶頸往往是系統間的交互通信。
服務器種類各雲服務商都稱呼也不壹致，總體說分為輕量應用服務器，負載均衡服務器，超算服務器（CPU和GPU兩個方向,後者也常常被成為圖形處理服務器。）數據服務器（常見的版本都有），文件服務器（nas和oss），分發服務器，緩沖服務器，數據分析服務器。我項目中使用大大類就這些了，也許有些我沒用過和不知道的，希望大家在討論區補充糾正。
希望對妳認知有所拓展。