網站架構的演化

1，原始時代，一臺伺服器解決所有，經典的LAMP，廉價伺服器+開源軟體，網站就建起來了。

→ 等到訪問量越來越大，資料儲存空間吃緊了，所以。。。

2，使用三臺伺服器，應用，檔案，資料庫分開。應用伺服器加CPU，檔案伺服器加大容量硬碟，資料庫伺服器用更貴更快的硬碟。

→ 80%的訪問集中在20%的資料上，成為瓶頸

3，應用伺服器加本地快取。

→ 本地快取和應用爭記憶體

4，加遠端獨立伺服器放快取，再不行上分散式快取伺服器，要多大有多大。

→單臺應用伺服器應對請求數量有限，限制了併發能力

5，使用應用伺服器叢集，可伸縮性大大增強，再多使用者都不怕。

→使用者操作頻繁，高頻率的寫操作讓資料庫不堪重負

6，資料庫讀寫分離，配置主從資料庫，讀從從庫讀，寫就寫到主庫，利用主從複製讓資料一致

→網站內容越來越豐富，響應時間變長

7，上CDN服務，靜態資料或者不頻繁更新的資料都到CDN。再利用反向代理，選擇距離使用者最近響應最快的應用伺服器，大大加快響應時間。

→寫資料操作量級上來了，資料伺服器真的又撐不住了

8.1有錢，上分散式檔案系統和分散式資料庫系統，還慢就繼續加機器，總有快的時候。省心省力

8.2沒錢，花點心思，根據業務對資料庫進行拆分，將不同細分業務資料放到不同的資料伺服器上，重點資料用更好的伺服器。

→資料量大，檢索和生成報表巨慢

9，使用NoSQL放需要檢索的資料，減輕原來資料庫伺服器壓力

→業務複雜，技術開發難度提高

10，業務拆分，根據不同的產品線拆分技術開發，看起來是一個網站，其實是不同的應用來共同提供資料的

→業務拆分粒度越來越小，服務部署維護困難

11，分散式服務，統一運維

架構模式

模式，描述了一個不斷重複發生的問題和該問題解決方案的核心。這樣，你就能一次次的使用該方案而不必做重複工作。

網站架構要解決的問題，就這幾種:

• 高效能。就是要快！

• 高可用。7*24線上可用，掛了就不好了。

• 易伸縮。能隨訪問量，資料處理量的大小。進行擴容降容，不再門庭若市時候奔潰，不在人去樓空時浪費錢。

• 可擴充套件。師傅師傅大師兄又加需求了！好的架構，要隨業務的發展，無痛加功能加服務。

• 安全。不安全，以上都是白搭。
  以上這些問題重複的出現，也就形成了解決的模式。

常見的模式:

1.分層。橫向切割。應用層靠近使用者，負責具體業務和頁面展示，也就是常說的後臺和前端那部分，現在都是前後端分離了，也是分層的一種方法。伺服器提供具體服務支援，比如訂單結算，購物車服務等，我現在工作大概就是在這一層，所以不要再問我後臺後端差別了啊啊啊。資料層，最後面，提供資料儲存的。

2.分割。縱向切割。將不同業務進行分割，例如淘寶，購物車，搜尋，廣告分割成不同的應用，由獨立團隊進行負責。

3.分散式。不同應用放不同物理機子，分散式部署可以對不同的應用服務做到資源的有效分配。

4.叢集。多臺伺服器部署相同的應用，通過負載均衡對外提供服務，叢集再提高更好的併發特性的同時，也能提供系統的可用性，一臺掛了還有一臺嘛。

5.快取。CDN，redis等等。快取主要是兩個難點，怎樣提供快取命中率和設定過期時間避免髒讀。

6.非同步。這一塊是重點，非同步架構是典型的生產者消費者模式，應用使用佇列進行訊息傳遞而不直接互相呼叫。好處有二，可用性提高，如果後面的應用掛了，前面的應用還能繼續接收使用者請求，資料堆入佇列，等掛了的應用重啟繼續消費佇列就可以了。消除訪問波峰，突然的一波訪問，如果沒有非同步處理，後端壓力會驟增，很可能就崩了，非同步處理能將訊息放進訊息佇列，後端依次處理，就不會有太大問題。

7.冗餘。伺服器隨時會掛，多備一臺伺服器，資料多做一份備份，總是好事。雖然有點費錢。

8.自動化。釋出過程自動化，人為操作很容易出錯，當然，需要自動釋出系統足夠好用。

9.安全。加密，驗證碼，風險控制。

非同步的問題

和人不同的是，網站系統，任何可以晚點再做的事情都應該晚點再做。

一般就是使用訊息佇列將呼叫非同步化，一個應用接一個應用的處理資料，上游處理完了丟到下游，上游無需下游立即甚至壓根不用下游進行反饋。

訊息佇列的應用，使系統的靈活性大大提高，起到很好的削峰作用。前面的應用將短時間內大量的請求存入訊息佇列，推遲處理時間，使到後面吃大量記憶體CPU的應用不至於被壓垮。固定的消費速率也使資料庫伺服器的併發數得到控制。

但是，非同步也會帶來很多麻煩的事情。

由於資料操作被非同步化了，所以很難確定資料究竟處理完了沒有，也很難保障資料的一致性，前端應用認為處理完了，後端其實還沒好，就會出現很多問題，導致資料不一致，處理結果出現異常。這經常需要額外的同步操作來進行核實資料，帶來額外的開銷。

另一個問題是，非同步會導致資料的更新不及時，當然，這是非同步的目的，同樣也是缺點，看不同的場合。比如每日賣家報表，推遲個幾分鐘再統計出來沒有任何問題，但是像秒殺系統，推廣限額系統，就不能容忍資料統計延遲。在應用了非同步處理的架構裡，這些需求也就都需要額外處理，提供系統的複雜性。

不是任何網站都需要非同步化的，也不是非同步架構裡每個環節都需要非同步化的。技術用到正確的地方才是好的技術。