大型網站技術架構

看完《大型網站技術架構》讀後感，這個書主要內容是以大型網站架構爲題，進行分析，如何搭建一個成熟的架構，和其中遇到的問題，以及最後規劃了架構師的職業方向。

大型網站架構的進化史

沒有一個網站是一誕生就是一個大網站，無論淘寶、亞馬遜仍是其餘等等，龐大的用戶量都是慢慢積累的，因此網站架構也都是從最基礎的LAMP（Linux+Apache+MySQL+PHP）,畢竟這種開源免費最適合初創企業。慢慢隨着業務的發展，用戶量慢慢上去了，而後所謂的海量數據、高併發等等問題隨之出現，而升級架構其實就是解決遇到的問題。

淘寶的架構之路從最開始的LAMP到慢慢升級到JAVA+ORACLE升級到付費的各類產品，再日後阿里開始專一本身的技術路線，本身的開源框架等等，而架構也是在每一年的雙十一大促的時候通過一次一次的錘鍊。

下面是一個網站架構從剛開始慢慢升級打怪的步驟：

1.一個網站的初始架構都是在一個服務器上面包含應用程序+數據庫+文件

2.隨着用戶量增加，對應用程序、數據庫、文件進行分離，放到三臺服務器上，針對業務需求選擇機器的配置，好比應用程序須要處理大量的業務要選擇一個更快更強大的CPU，數據庫須要快速磁盤檢索和數據緩存，須要更快的磁盤和更大的內存，而文件須要出存儲大量用戶上傳的文件，所以須要更大的硬盤。分離完成後，網站的併發能力和數據存儲都有了很大改善。

3.下一個問題就是廣泛都在討論的性能問題，可能淘寶和你的網站的區別就在於它的打開速度比你快了1-2秒，但是每每起決定性因素的就是這些小的細節。網站的訪問和現實世界的財富分配同樣都遵循着二八定律，網站的訪問這是80%的業務訪問集中在20%的數據上，好比淘寶或者微博，常常操做的確定是那些活躍用戶，常常購買的確定是口碑評價都好的店鋪,因此能夠給這20%的數據放到緩存中，能夠提升數據庫的訪問壓力

4.解決了數據庫訪問壓力的問題，網站的併發能力是下一個攻克的難點，當一個服務器處理能力不足的時候不要試想找一個更大的服務器來解決（就像一匹馬拉不動一輛車的時候，不要試圖找一個更強壯的馬來拉，應該找兩匹馬來解決）經過配置服務器集羣，採用負載均衡服務器來解決數據量併發問題

5.看似好像都解決了，可是接着回到數據庫問題，若是有些數據不是讀緩存的，或者緩存過時等問題，又回到以前的數據庫壓力問題，能夠選擇數據庫讀寫分離，數據庫配置主從關係，會自動完成同步，改善了數據庫負載壓力

6.隨着網站的持續增加，能夠把數據庫拆分到兩臺服務器，文件服務器也使用分佈式文件系統

7.再以後一些大型的網站架構會從業務下手，將業務拆分，拆成不一樣的應用，每一個應用獨立部署，其實業務纔是最核心的，好比最典型的12306的網站，2010年剛上線的時候一直崩潰，網上各類大神出謀劃策，可是其實12306的問題不在於技術，而在於業務，把幾億人搶票放到同一個時間點，然後面12306的改革也看到了，加入了排隊機制，分時間段放票。（12306技術後面由阿里給了技術支持）

秒殺產品架構設計

秒殺是各大電商平臺都會搞的促銷活動，那對於技術人員來講秒殺意味着什麼：1.對現有網站業務的衝擊 2.高併發下應用 3.網絡及服務器帶寬 4.直接下單

解決方式:1.秒殺系統獨立部署，爲了避免影響現有網站的業務 2.秒殺系統頁面靜態化，不要動態讀取內容，寫死html內容 3.租借秒殺活動帶寬 4.經過js提交到下單