大型網站架構演化

1. 最初始的網站架構

 

1. 最初始的網站架構

 

就像咱們在本身電腦上搭建了一個論壇的網站，應用程序（例如Apache服務器）、數據庫等都部署在咱們本身的電腦上的。就能夠正常運行了。

2. 應用服務和數據服務分離

咱們的論壇愈來愈受歡迎，用戶愈來愈多，論壇也十分越活。可是面臨的問題是數據庫中的信息愈來愈多，存儲不夠了。這個時候咱們又多弄了幾臺服務器，應用程序（Apache服務器）、數據庫和保存用戶上傳的文件（圖片）單獨部署在不一樣的服務器上。

應用服務器處理大量的業務邏輯，因此須要更好的CPU

數據庫服務器須要完成數據的快速查詢，因此須要更大的硬盤和內存

文件服務器保存用戶上傳的圖片等文件，因此須要更大的硬盤

3. 使用緩存改善網站性能

咱們的論壇用戶繼續快速增漲，咱們發現訪問速度愈來愈慢，緣由就是不少請求都要訪問數據庫（例如，讀取用戶的我的信息，打個不恰當的比喻，每次進入一個話題，該話題中的每個發言用戶的信息都要從數據庫中讀取）。這個時候若是咱們能緩存這些用戶信息，每次從緩存中讀取，這樣對數據庫的壓力會大大下降，而且讀取的性能也提高了不少。

4. 使用應用服務器集羣改善網站的併發處理能力。

使用緩存後，又出現問題了，在論壇使用高峯的時候，單一應用服務器處理請求鏈接有限，這個時候就須要部署應用服務器集羣，而後在使用一個負載均衡服務器（例如Nginx,apache Server)。

5. 數據庫讀寫分離

用戶繼續增長，使用緩存後，雖然大部分讀的操做都不會直接訪問數據庫，可是仍是有一些讀操做（緩存未命中，緩存過時）和所有的寫操做仍是必須操做數據庫。當用戶達到必定規模，數據庫又成了系統的性能瓶頸。

在原來單一數據庫的模式上，設置一個主數據庫和從數據庫，寫操做的時候寫入主數據庫，而後從主數據庫同步到從數據庫中。讀操做就在從數據庫中讀。固然咱們須要一個數據訪問的模塊來處理這些邏輯

6. 使用反向代理和CDN加速網站響應

論壇用戶反應，打開大家的論壇速度太慢了，再不改善我就不用了。

緣由也很簡單，一個訪問請求中，也許存在不少靜態資源（CSS，圖片）等，又或者用戶的使用的聯通，咱們的服務器在電信。適應反向代理和CDN技術能夠大大改善用戶請求的響應速度

7. 使用分佈式數據庫和分佈式文件系統

雖然數據庫進行讀寫分離之後，可是在咱們論壇瘋狂增漲下，任何強大的單一服務器的性能都是有限的，只有使用分佈式系統，才能在業務不斷增漲進行橫向擴展。這個是咱們最後手段了，使用以前應該先考慮可否根據業務不一樣來拆分數據庫。例如咱們論壇的包括了不一樣主題（汽車、房子、以及你懂的話題），若是按照這些主題來區分數據庫，也是好的選擇。（注意這個雖然也是要使用多個數據庫，但和分佈式數據庫的概念是有很大區別的）

8. 使用NoSql和搜索引擎

論壇中，要搜索一些帖子，若是每次進行數據庫查詢，在數據量十分大的狀況，顯然是不可取的。還有就是對數據存儲的要求，須要使用搜索引擎（例如lucene）。

NoSql主要是對一些特殊需求的數據進行存儲，例如配置信息能夠放redis中（也算是緩存），日誌信息能夠存儲在Hbase上等等。

9. 業務拆分

爲了之後之後的發展，咱們的業務須要擴展，咱們須要增長即時通信的業務（相似微信），知識問答（相似知乎）。可是這些業務是分開開發的，若是和原有的論壇業務耦合在一塊兒，在代碼發佈的時候，就會十分麻煩。這個時候，根據不一樣的業務，分別進行部署和發佈。

10. 分佈式服務

雖然按照業務進行拆分之後，雖然不一樣業務之間的管理隔離開來，可是問題又出現了，但咱們部署了上萬臺服務器的時候，每一個服務器都保持有與數據庫的鏈接，這樣會致使數據集的鏈接資源不夠。並且還有個問題就是對一些基礎功能每一個業務之間有重複開發的問題。

因此，咱們把一些基礎業務功能提取出來，作成基礎服務獨立部署（登陸服務、用戶信息管理，日誌功能等）。這樣上層只用關係本身的業務邏輯，調用底層統一的基礎服務。