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