一、早期優化策略回顧：三大分離

在互聯網發展的早期，為了快速解決系統性能瓶頸，業界總結出了一系列對架構影響最小、但效果顯著的優化方法，其中“三大分離”是核心思想：

1. 動靜分離：將網站的靜態資源（如圖片、CSS、JavaScript）和動態內容（需要服務器實時處理的數據）分開部署和處理，通過專門的靜態資源服務器或CDN加速靜態內容的訪問，減輕應用服務器的壓力。
2. 讀寫分離：將數據庫的讀操作和寫操作分離到不同的數據庫實例上，以提高數據庫的并發處理能力和整體性能。
3. 熱點數據分離：將訪問頻率極高的數據（熱點數據）從主數據庫中剝離出來，存儲到高速緩存（如Redis、Memcached）中，從而顯著提升數據讀取速度。

這“三大分離”理念為后續更復雜的分布式系統架構奠定了基礎。

二、讀寫分離：數據庫性能提升的關鍵

讀寫分離是一種通過用數據庫分組來快速提升數據庫性能的優化策略。其核心思想是：在大多數Web應用中，讀操作的頻率遠高于寫操作。如果所有讀寫請求都集中在一個數據庫實例上，該實例很容易成為性能瓶頸。通過將讀寫操作分離到不同的數據庫實例上，可以有效分攤壓力，提高數據庫集群的整體吞吐量。

1. 讀寫分離的實現方式

• 主從復制（Master-Slave Replication）：這是讀寫分離最常見的實現基礎。一個主數據庫（Master）負責所有的寫操作，并將數據同步（復制）到一個或多個從數據庫（Slave）。所有的讀操作則分發到這些從數據庫上。
• 路由層：在應用層和數據庫層之間引入一個路由層（可以是代碼邏輯、數據庫中間件或代理），負責識別SQL語句是讀操作還是寫操作，并將其轉發到相應的主庫或從庫。

應用層實現：在應用程序代碼中判斷SQL類型，手動選擇連接到主庫或從庫。這種方式實現簡單，但代碼侵入性強，維護成本高。

數據庫中間件/代理：使用專門的數據庫中間件（如MyCAT、ShardingSphere、DRDS等）或代理層。這些中間件可以透明地實現讀寫分離，應用程序無需感知底層數據庫的拓撲結構，只需連接到中間件即可。這是目前主流且推薦的實現方式。

2. 讀寫分離的優勢

• 提升數據庫并發能力：讀操作不再阻塞寫操作，反之亦然，大大增加了數據庫集群的并發處理能力。
• 增強系統可用性：當主庫發生故障時，可以快速將某個從庫提升為新的主庫，保證服務的連續性。部分從庫故障不影響讀服務。
• 擴展性：可以通過增加從庫的數量來線性擴展讀服務的承載能力。
• 降低成本：從庫可以使用配置較低的服務器，降低硬件成本。

3. 讀寫分離的挑戰

• 數據同步延遲：主從之間的數據同步可能存在延遲，導致從庫讀取到的數據不是最新的。這需要應用層在對實時性要求高的場景下進行特殊處理（如強制讀主庫）。
• 復雜性增加：引入主從架構和路由層會增加系統的復雜性，需要額外的運維和監控。

三、水平切分：提升數據庫存儲容量

除了讀寫分離，當單一數據庫的存儲容量或寫入性能達到瓶頸時，水平切分（Sharding）成為必要的手段。水平切分通過用數據庫分片，提升數據庫存儲容量，這往往涉及復雜的系統改造。

1. 水平切分的概念

水平切分是將一個大表的數據，按照某種規則（如用戶ID的哈希值、時間范圍等）分散存儲到多個獨立的數據庫實例或表中。每個數據庫實例或表只存儲整個數據集合的一部分。

2. 水平切分的優勢

• 突破單機存儲限制：不再受限于單臺服務器的存儲容量。
• 提升并發處理能力：讀寫請求被分散到多個數據庫實例，提高了整體的并發處理能力。
• 隔離故障：單個分片故障不會影響整個系統。

3. 水平切分的挑戰

• 數據路由復雜：需要一個機制來確定某個數據應該存儲在哪個分片上，以及從哪個分片讀取。
• 跨分片查詢：涉及到多個分片的查詢（如聚合查詢、聯表查詢）會變得非常復雜且效率低下。
• 事務管理：跨分片的分布式事務管理難度大。
• 數據遷移和擴容：后期進行數據遷移或增加分片時，操作復雜。

四、前后端分離：系統解耦與資源瓶頸消除

前后端分離是一種將Web應用的用戶界面（前端）和業務邏輯（后端）完全獨立開發、部署和運行的架構模式。其核心目標是系統解耦，消除底層資源瓶頸。

1. 前后端分離的實現方式

• 獨立項目：前端項目（HTML, CSS, JavaScript，通常使用Vue, React, Angular等框架）和后端項目（提供API接口，如Java Spring Boot, Node.js Express）作為兩個獨立的項目進行開發。
• API接口通信：前端通過HTTP/HTTPS協議調用后端提供的RESTful API或GraphQL接口來獲取和提交數據。
• 獨立部署：前端代碼通常部署在CDN或靜態Web服務器上，后端API服務則部署在應用服務器集群中。

2. 前后端分離的優勢

• 職責分離與專業化：前端和后端團隊可以專注于各自領域，提高開發效率和專業度。
• 并行開發：前后端可以并行開發，縮短項目周期。
• 技術棧獨立：前后端可以采用不同的技術棧，互不影響，方便技術升級和創新。
• 提升用戶體驗：前端可以獨立部署在CDN，靜態資源加載更快，提供更流暢的用戶體驗。
• 消除后端渲染瓶頸：后端專注于提供數據接口，不再承擔頁面渲染的壓力，減輕了服務器負擔。
• 多端適應：一套后端API可以服務于Web、移動App、小程序等多個前端應用。
• 更好的擴展性：前端和后端可以獨立擴展，當某一端成為瓶頸時，可以單獨擴容。

3. 前后端分離的挑戰

• 聯調成本：前后端接口定義和聯調需要良好的協作和接口文檔。
• 部署復雜性：需要獨立部署前端和后端，增加了部署和運維的復雜性。
• SEO問題：對于完全由JavaScript渲染的單頁面應用（SPA），搜索引擎爬蟲可能難以抓取內容，需要配合SSR（服務端渲染）或預渲染技術解決。