系統架構演變

架構演變是爲了解決性能瓶頸

 

一、最初，數據庫和應用服務器在一臺機器上，會致使一方CPU佔用高，另外一方也會受到干擾，解決方案：分開部署

 

二、應用和數據庫分開部署，應用和數據分離

三、隨着用戶量增長，數據庫訪問壓力變大，致使訪問延遲，性能較低，這時就須要緩存技術，將查詢較多或者改動不大的數據緩存起來，以加快應用訪問速度

爲何緩存技術能夠增長訪問速度？須要先了解硬盤數據庫和Redis的工做模式，硬盤數據，先從數據讀取數據到內存，內存中的數據保存到硬盤，咱們更改硬盤的數據後在保存到數據庫。這裏的步驟較多，並且還佔用咱們的硬盤容量。

Redis工做模式，相比硬盤數據庫的方式少了內存到硬盤這一步，速度回快不少，並且不佔用咱們的硬盤容量。Redis採用的是單進程單線程模型的 KV 數據庫，由C語言編寫，官方提供的數據是能夠達到100000+的QPS。

四、併發量更大的狀況下，應用服務器就成爲了整個網站的瓶頸，單一的應用服務器資源有限，高併發狀況下鏈接很快就會超限，這時，咱們就須要部署應用服務器集羣，利用負載均衡器分散訪問流量，減小單臺服務器的壓力

五、這個階段，數據繼續增長，請求數量繼續加大，單個數據庫已然不能知足要求，這個時候須要部署多個數據庫，實現讀寫分離，同時CDN加速，從最近的服務器上獲取資源，提升訪問速度

七、分佈式數據庫是網站數據庫拆分的最後手段，只有在單表數據規模很是龐大的時候才使用。

不到不得已時，網站更經常使用的數據庫拆分手段是業務分庫，將不一樣業務的數據庫部署在不一樣的物理服務器上。

八、微服務階段，將各個業務進行拆分，每一個業務線又能夠單獨部署集羣，業務線之間保持通信，實現業務解耦，一個應用節點出現問題，也不會影響其餘業務正常使用