1.大型網際網路應用的特點

•  高並大流量：面對的是高併發的使用者以及大流量的訪問。
• 高可用：系統7 * 24小時不斷服務。
• 海量資料：需要儲存並管理海量的資料，這會用到大量的伺服器。
• 使用者分佈廣泛，網路情況複雜：許多的大型網際網路應用都是為全球使用者服務的，但使用者分佈範圍廣，而且各地的網路情況千差萬別。
• 安全環境惡劣：由於網際網路的開放性，會使的網站很容易收到黑客的攻擊。
• 需求快速變更，釋出頻繁：大型網站每週都會有新版本釋出，而中小型網站可能一天釋出幾十次。
• 漸進式發展：幾乎所有的大型網際網路網站都是從小網站起步，然後漸進發展。

2.架構演化發展歷程

因為龐大的使用者，高併發的訪問量以及海量的資料，所以任何簡單的特務都要處理P（10的15次方，1000 T = 1 P）級的資料，以及面對數以數計的使用者。架構就是為了解決這些問題。

2.1初級階段

小型網站沒有太多人訪問，所以只需要一臺伺服器就夠了。

應用程式，檔案，資料庫都部署在一臺伺服器上，通常是使用LAMP（Linux Apache MYSQL PHP）。

2.2應用服務和資料服務分離

隨著業務的發展，越來越多使用者的訪問導致效能越來越差，而越來越多的資料也會耗盡儲存空間，這就需要將應用與資料分離;

  這裡使用三臺伺服器：應用伺服器，檔案伺服器和資料庫伺服器他們對硬體資源的要求不同。

不同特性的伺服器可以承擔不同的服務角色，使得網站的併發處理能力和資料儲存空間都有了很大的改善。

但隨著使用者數量的再次增長，發現數據庫的壓力太大而導致的網站訪問延遲問題，所以需要再次優化。

2.3使用快取改善效能

網站訪問的特點遵循經典的二八定律：80％的業務訪問集中在20％的資料上所有把這一小部分資料快取在記憶體中就能減少資料庫的訪問壓力。

快取可分為兩種。在應用伺服器上的本地快取和在分散式快取伺服器上的遠端快取。

遠端分散式快取使用叢集，而且可以使用安裝了大記憶體的伺服器作為專門的快取伺服器。

使用快取後，資料庫的訪問壓力得到緩解，但單一的應用伺服器能夠處理的請求連線有限，所以在網站訪問的高峰期，有可能成為整個網站的瓶頸。

2.4應用伺服器叢集

使用叢集是解決高併發，海量資料問題的常用手段。當一臺伺服器的處理能力，儲存空間不足時，最恰當的做法是正價新的伺服器，讓它來分擔原有伺服器的訪問和儲存壓力。

我們可以通過持續的增加伺服器，來不斷改善系統的效能，從而實現系統的可伸縮性。

通過負載均衡排程伺服器，可以將使用者的訪問請求分發到應用伺服器叢集中的任何一臺伺服器上。如果有更多的使用者，我們就可以在叢集中加入更多的應用伺服器。

2.5資料庫讀寫分離

使用了快取後，使得絕大對數資料的讀操作可以不通過資料庫就能完成。但仍然有部分的讀操作（因為快取訪問沒有命中或快取過期）和全部的寫操作需要訪問資料庫，所以在使用者量達到一定規模時，資料庫還是會因為負載過高而成為瓶頸。

目前的主流資料庫度提供了主從熱備功能，可以通過配置兩臺資料庫的主從關係，把一臺資料庫伺服器的資料同步到另一臺伺服器上。我們可以利用這個功能，實現資料庫的讀寫分離，進一步提高資料庫的負載能力。

為了便於應用程式訪問讀寫分離的資料庫，一般會在伺服器端使用專門的資料訪問模組，讓資料庫的讀寫分離機制對應用程式透明，這樣做不僅降低了程式碼編寫的複雜性，還提高了可維護性，可謂兩全其美

2.6使用反向代理和CPU加速相應

網站的訪問延遲與使用者的流失率正相關。因為網站訪問的越慢，使用者就越容易失去耐心而離去

反向代理和CPU都是依賴快取。區別是，CDN是部署在網路供應商的機房，使用者請求讀取時，會從距離他最近的網路供應商機房

獲取資料;而反向代理部署在網站的中心機房，所以使用者請求服務式，會先訪問反向代理伺服器，如果它快取著使用者所請求的資源，就會直接把資源返回給使用者。

使用反向代理和CDN的目的都是為儘早地把資料返回使用者，這樣不僅加快使用者的訪問資料，而且也減輕了後端伺服器的負載壓力。

2.7使用分散式檔案系統和分散式資料庫系統

如果之前的架構仍然不能滿足需求，那麼就要使用分散式的檔案系統和資料庫系統。

注意：一般情況下是對業務資料進行分庫，即將不同業務的資料庫部署到不同的物理伺服器上只用在單表的資料規模非常龐大，才使用分散式資料庫。

2.8使用NoSQL和搜尋引擎

隨著業務變得越來越複雜，對資料儲存和檢索的需求也會變得複雜起來。就會用到NOSQL和搜尋引擎啦

應用程式通過資料庫訪問模式來訪問搜尋引擎與NOSQL伺服器，這樣就可以減輕應用程式管理多資料來源的麻煩

2.9業務拆分

為了應對日益複雜的業務場景，通常使用分而治之的手段，把業務劃分為不同的產品線。

每個應對堵路部署維護，應用之間通過超連結建立關係，也可以通過訊息佇列進行資料分發，更通常的做法是通過訪問同一個資料村塾系統來構建一個完整的關聯關係。

2.10分散式服務

隨著業務被拆分的越來越小，儲存系統變得越來越小，應用系統的整體複雜度成指數級增長，部署和維護變得越來越困難。

可以把一些公用的服務提取出來，獨立部署而應用系統只需要管理使用者介面，然後通過分散式服務排程公用的服務，來3完成業務操作。：

1.單節點架構（初級階段）

2.叢集架構

3.叢集+分散式架構

轉載作者：https://www.cnblogs.com/starzy/archive/2018/08/16/9485947.html