程式員，如何逐漸去建構一個大型網站系統，面試必問！！！
2018-04-22 16:10
耿直的小碼農
閱讀(1045)
評論(1)
編輯
收藏
舉報
往往程式員在面試的時候，公司的面試任職資格上，總有一個大型系統網站的開發經驗，我們先來看看幾張面試招聘資訊截圖.......
大型網站定義
首先我們要思考一個問題，什麼樣的網站才是大型網站，從網站的技術名額角度考慮這個問題人們很容易犯一個毛病就是認為網站的通路量是衡量的名額，懂點 行的人也許會認為是網站在機關時間裡的并發量的大小來作為名額，如果按這些标準那麼像hao123這樣的網站就是大型網站了，如下圖所示：
其實這種網站通路量非常大，并發數也非常高，但是它卻能用最為簡單的Web技術來實作：我們隻要保持網站的充分的靜态化，多部署幾台伺服器，那麼就算地球上所有人都用它，網站也能正常運作。
大型網站是技術和業務的結合，一個滿足某些使用者需求的網站隻要技術和業務二者有一方難度很大，必然會讓企業投入更多的、更優秀的人力成本實作它，那麼這樣的網站就是所謂的大型網站了。0
如何逐漸去建構一個大型網站系統
網際網路時代，怎麼建構一個大型網站是不可缺少的技能。當然，本人目前接觸的網站都是讀遠遠大于寫。本文将一步步講訴，怎麼去使用lamp建構完善一個大型網站（讀大于寫）。
網站架構，我個人認為最為重要的是兩方面的考慮：計算和存儲。有些是屬于計算密集型，有些是IO密集型。是以以下都将圍繞計算和存儲來講述問題。
1、最簡單的搭建
假設我們自己創業了，那麼我們可能需要自己去搭建一個網站。
這個時候，我們需要去租借一個主機（比如阿裡雲的虛拟主機等）。對于網站來說，資料是最為重要的，是以需要有一個備份。但是每天pv肯定不高，是以理論上隻需要一個計算機器即可。是以，我們隻需要3台機器就能完整一個完整的架構。
從上圖可以看到計算機器上主要部署2部分内容，一部分是webserver(輕量級可以考慮niginx,lighttpd等)，一個是UI邏輯處理部分，lamp架構則使用php語言來搞定這個問題。因為資料是最重要的，是以database則明顯需要2台機器，一台主機，一台做備援備份。lamp使用mysql來存儲資料。
2 增加資料緩存
随着我們網站知名度變高，每天pv越來越大，導緻的問題是資料庫壓力越來越大。很明顯，絕大部分網站，讀流量都遠遠高于寫流量。即使我們開了mysql的query cache，它也隻能在一定程度上通過減少DB機器I的操作來減少DB伺服器壓力。更為靠譜的是，減少對DB伺服器的請求。那麼這個時候就需要使用cache.
cache為非關系型kv存儲，在使用過程中一般為記憶體操作。下面的架構改進如下。
可以看出ui寫資料仍然直接寫入到資料庫，但是讀則先從cache讀取，cache讀取不到再從database讀取。因為很有可能大部分資料都直接通路cache就可以搞定，這樣就可以大大減少資料庫的壓力。
3、增加計算機器叢集(計算方向)
随着整個系統pv繼續上漲。單台的計算機器已經無法滿足要求。這個時候就需要使用增加計算機器來解決問題。為了友善起見，可以把這個機器放入一個叢集進行統一管理。
這個時候，我們可能需要考慮2個問題：負載均衡、資料同步。負載均衡系統相對難度較大，但是是必不可少的，最簡單的可以通過zookkeeper等對配置檔案進行統一管理。對于節點下的若幹機器，可以簡單通過機率來進行請求分發。資料同步也是一個難點，比如session同步、檔案操作等。
需要說明的是，好的架構結果如下：N台機器能撐住的PV為X，那麼T*N台機器基本能撐住T*X pv。換句話說，架構必須能支援橫向擴充。如果機器加了一倍，但是撐住的峰值pv不能增加（接近）一倍，那個這個架構就是失敗的架構，不是可擴充性的架構。
可以看出的是在負載均衡系統下可以挂很多機器。好的擴充是，加入多少倍機器，計算能力就相應提高多少倍（暫時不考慮存儲的瓶頸）。
4、搭建簡單的資料庫叢集(存儲方向)
流量上升，計算能力提升的同時，也需要提升資料庫的能力。這時候，我們可以采用讀寫分離。也就有了主從之說。主庫可以寫，當然也肯定能提供寫，從庫隻能提供讀，我們目前主從延時在20ms以内。目前這種工具不少，比如mysql proxy等。(下圖應該是ui logic通路dbproxy，圖有稍許錯誤，但是不影響了解)。
如上圖，dbproxy作用主要有3個：
1、讀寫分離。讀主要讀從庫，寫隻能是寫主庫。我們在實際設計的時候需要考慮主從延時，比如事務讀必須讀主庫，寫完若幹秒内最好讀主庫等等。
2、負載均衡。他能自動根據dbproxy下面挂在的db進行負載均衡。
3、dbproxy維持sql連接配接池，裡面存在和db的長連接配接。請求過來之後，直接從連接配接池取連接配接即可。
5、靜态頁面跨地域緩存
很明顯，我們網站有很多靜态頁面，若幹天才會更換一次。但是因為跨地域、跨機房的問題，外地使用者可能通路較慢，是以我們可以通過cdn等技術緩存靜态頁面。這樣就可以減少對伺服器的請求，同時加快外地、不同機房使用者的通路時間。
如上圖所示，加入了靜态頁面緩存
6、跨地域跨機房設計
當我們業務進一步擴大，我們可能需要跨地域進行機器部署，目前我們主要分為華北(北京)和華東機房(杭州、南京)。跨地域部署，可以加快因為區域帶來的通路過慢問題。比如廣州通路北京機房資料，就不如北京通路北京機房速度快。這個時候，還是主要分為計算和存儲兩方面進行講述。
6.1 計算方向
除了該機房的标示以外，各個機房的機器部署應該完全一緻。
6.2 存儲方向
在我看來，對于讀遠遠大于寫的系統而言，最好隻有一個主庫，若幹個從庫。是以隻需要在其他機房搭建從庫，讓從庫從主庫進行資料同步即可。當然，這樣的代價是主從時間比比較長。在資料鍊路不穩定的情況下，主從同步可能在400ms以上，是以設計需要考慮這個。
當然cache等等也需要跨地域跨機房部署。
如圖簡要勾勒出了跨地域跨機房的一個部署方案。
7、通用服務的使用
随着業務拓寬，我們可能會有一些需要考慮新能的子產品或者業務。
如搜尋業務，我們不可能直接通過資料庫的select like來實作，就需要使用C等編譯型語言來搭建其他系統。是以需要我們根據業務進行架構調整來通過http等使用一些通用的高性能計算方向的服務。
同樣，出于業務發展等因素的考慮，我們需要使用記憶體型的資料庫，比如redis等，這些屬于存儲方向的通用服務。
這些服務，有的可以跨機房部署，各個機房無耦合，有的則互相之間有耦合，比如類似于資料庫的主庫從庫。
8、其他考慮
除此以外，我們還需要有其他因素進行考慮。需要了解的可以加JAVA架構師學術交流群：587372254
8.1 網站資料
這個主要是比如uv/pv。這個有幾種做法，第一種是借助第三方的統計攻擊，比如百度統計、Google統計等。第二種是對我們現有系統的日志進行統計，同時可以進行深一步的資料挖掘。
8.2 安全性
這個需要考慮網站是不是存在sql注入，xss漏洞，csrf漏洞等。這個方面對于網站是非常關鍵的。一旦有黑客攻入，後果不堪設想。
對于管理者背景，最好不要開通外網權限，隻能通過内網通路。
8.3 seo等
搜尋引擎優化對于網站作用不言而喻。 後續可能會專門針對百度SEO進行一些分析。
