【問底】徐漢彬：億級Web系統搭建——單機到分佈式集羣（三）

異地部署（地理分佈式）

完成了上述架構建設以後，咱們的系統是否就已經足夠強大了呢？答案固然是否認的哈，優化是無極限的。Web系統雖然表面上看，彷佛比較強大了，可是給予用戶的體驗卻不必定是最好的。由於東北的同窗，訪問深圳的一個網站服務，他仍是會感到一些網絡距離上的慢。這個時候，咱們就須要作異地部署，讓Web系統離用戶更近。

1、 核心集中與節點分散

有玩過大型網遊的同窗都會知道，網遊是有不少個區的，通常都是按照地域來分，例如廣東專區，北京專區。若是一個在廣東的玩家，去北京專區玩，那麼他會感受明顯比在廣東專區卡。實際上，這些大區的名稱就已經說明了，它的服務器所在地，因此，廣東的玩家去鏈接地處北京的服務器，網絡固然會比較慢。

當一個系統和服務足夠大的時候，就必須開始考慮異地部署的問題了。讓你的服務，儘量離用戶更近。咱們前面已經提到了Web的靜態資源，能夠存放在CDN上，而後經過DNS/GSLB的方式，讓靜態資源的分散「全國各地」。可是，CDN只解決的靜態資源的問題，沒有解決後端龐大的系統服務還只集中在某個固定城市的問題。

這個時候，異地部署就開始了。異地部署通常遵循：核心集中，節點分散。

• 核心集中：實際部署過程當中，總有一部分的數據和服務存在不可部署多套，或者部署多套成本巨大。而對於這些服務和數據，就仍然維持一套，而部署地點選擇一個地域比較中心的地方，經過網絡內部專線來和各個節點通信。
• 節點分散：將一些服務部署爲多套，分佈在各個城市節點，讓用戶請求儘量選擇近的節點訪問服務。

例如，咱們選擇在上海部署爲核心節點，北京，深圳，武漢，上海爲分散節點（上海本身自己也是一個分散節點）。咱們的服務架構如圖： 

 

須要補充一下的是，上圖中上海節點和核心節點是同處於一個機房的，其餘分散節點各自獨立機房。 
國內有不少大型網遊，都是大體遵循上述架構。它們會把數據量不大的用戶核心帳號等放在覈心節點，而大部分的網遊數據，例如裝備、任務等數據和服務放在地區節點裏。固然，核心節點和地域節點之間，也有緩存機制。 

2、 節點容災和過載保護

節點容災是指，某個節點若是發生故障時，咱們須要創建一個機制去保證服務仍然可用。毫無疑問，這裏比較常見的容災方式，是切換到附近城市節點。假如系統的天津節點發生故障，那麼咱們就將網絡流量切換到附近的北京節點上。考慮到負載均衡，可能須要同時將流量切換到附近的幾個地域節點。另外一方面，核心節點自身也是須要本身作好容災和備份的，核心節點一旦故障，就會影響全國服務。

過載保護，指的是一個節點已經達到最大容量，沒法繼續接接受更多請求了，系統必須有一個保護的機制。一個服務已經滿負載，還繼續接受新的請求，結果極可能就是宕機，影響整個節點的服務，爲了至少保障大部分用戶的正常使用，過載保護是必要的。

解決過載保護，通常2個方向：

• 拒絕服務，檢測到滿負載以後，就再也不接受新的鏈接請求。例如網遊登入中的排隊。
• 分流到其餘節點。這種的話，系統實現更爲複雜，又涉及到負載均衡的問題。

小結

Web系統會隨着訪問規模的增加，漸漸地從1臺服務器能夠知足需求，一直成長爲「龐然大物」的大集羣。而這個Web系統變大的過程，實際上就是咱們解決問題的過程。在不一樣的階段，解決不一樣的問題，而新的問題又誕生在舊的解決方案之上。

系統的優化是沒有極限的，軟件和系統架構也一直在快速發展，新的方案解決了老的問題，同時也帶來新的挑戰。

 

觀後感：這個web系統級的搭建設計，從小到大，由淺及深，感受做者再寫的不是技術經驗，而是web這個武林的葵花寶典啊，熟讀幾遍能夠窺見武林的宏大，深刻了解後切忌不可走火入魔，仍是要有本身的路走出來