1. 網站架構的伸縮性設計
1.1. 不同功能進行物理分離實現伸縮
縱向分離（分層後分離）：將業務處理流程上的不同部分分離部署，實現系統伸縮性。
橫向分離（業務分割後分離）：將不同的業務模組分離部署，實現系統伸縮性。
1.2. 單一功能通過叢集規模實現伸縮
將不同功能分離部署可以實現一定程度的伸縮性，但是隨著網站的訪問量逐步增加，即使分離到最小粒度的獨立部署，單一的伺服器也不能滿足業務規模的要求。因此必須使用伺服器叢集，即將相同服務部署在多型伺服器上構成一個叢集整體對外提供服務。
2. 應用伺服器叢集的伸縮性設計
2.1. HTTP 重定向負載均衡
利用 HTTP 重定向協議實現負載均衡。
這種負載均衡方案的優點是比較簡單。缺點是瀏覽器需要兩次請求伺服器才能完成一次訪問，效能較差：重定向伺服器自身的處理能力有可能成為瓶頸，整個叢集的伸縮性規模有限；使用 HTTP 302 響應碼重定向，可能使搜尋引擎判斷為 SEO 作弊，降低搜尋排名。
2.2. DNS 域名解析負載均衡
利用 DNS 處理域名解析請求的同時進行負載均衡處理的一種方案。
在 DNS 伺服器中配置多個 A 記錄，如：
114.100.40.1 www.mysite.com
114.100.40.2 www.mysite.com
114.100.40.3 www.mysite.com
複製程式碼每次域名解析請求都會根據負載均衡演算法計算一個不同的 IP 地址返回，這樣 A 記錄中配置的多個伺服器就構成一個叢集，並可以實現負載均衡。
DNS 域名解析負載均衡的優點：
- 將負載均衡的工作轉交給了 DNS，省掉了網站管理維護的麻煩。
- 同時，許多 DNS 伺服器還支援基於地理位置的域名解析，即將域名解析成距離使用者地理最近的一個伺服器地址，這樣可以加快使用者訪問速度，改善效能。
DNS 域名解析負載均衡的缺點：
- DNS 是多級解析，每一級 DNS 都可能快取 A 記錄，當某臺伺服器下線後，即使修改了 DNS 的 A 記錄，要使其生效也需要較長時間。這段時間，依然會域名解析到已經下線的伺服器，導致使用者訪問失敗。
- DNS 的負載均衡的控制權在域名服務商那裡，網站無法對其做更多改善和更強大的管理。
2.3. 反向代理負載均衡
大多數反向代理伺服器同時提供反向代理和負載均衡的功能。
反向代理伺服器的優點是部署簡單。缺點是反向代理伺服器時所有請求和響應的中轉站，其效能可能會成為瓶頸。
2.4. IP 負載均衡
在網路層通過修改請求目標地址進行負載均衡。負載均衡伺服器（閘道器伺服器）在作業系統核心獲取網路資料包，根據負載均衡演算法計算得到一臺真實 Web 伺服器 10.0.0.1，然後將目的 IP 地址修改為 10.0.0.1，不需要通過使用者程式。真實 Web 伺服器處理完成後，響應資料包回到負載均衡伺服器，負載均衡伺服器再將資料包原地址修改為自身的 IP 地址（114.100.80.10）傳送給瀏覽器。
IP 負載均衡在核心完成資料分發，所以處理效能優於反向代理負載均衡。但是因為所有請求響應都要經過負載均衡伺服器，叢集的最大響應資料吞吐量受制於負載均衡伺服器網路卡頻寬。
2.5. 資料鏈路層負載均衡
資料鏈路層負載均衡是指在通訊協議的資料鏈路層修改 mac 地址進行負載均衡。
這種方式又稱作三角傳輸方式，負載均衡資料分發過程中不修改 IP 地址，只修改目的 mac 地址，通過配置真實物理伺服器叢集所有機器虛擬 IP 和負載均衡伺服器 IP 地址一致，從而達到不修改資料包的源地址和目的地址就可以進行資料分發的目的，由於實際處理請求的真實物理伺服器 IP 和資料請求目的 IP 一致，不需要通過負載均衡伺服器進行地址轉換，可將響應資料包直接返回給使用者瀏覽器，避免負載均衡伺服器網路卡頻寬成為瓶頸。這種負載方式又稱作直接路由方式。
在 Linux 平臺上最好的鏈路層負載均衡開源產品是 LVS(Linux Virtual Server)。
2.6. 負載均衡演算法
負載均衡伺服器的實現可以分為兩個部分：
- 根據負載均衡演算法和 Web 伺服器列表計算得到叢集中一臺 Web 伺服器的地址。
- 將請求資料傳送到該地址對應的 Web 伺服器上。
負載均衡演算法通常有以下幾種：
- 輪詢（Round Robin） - 所有請求被依次分發到每臺應用伺服器上，即每臺伺服器需要處理的請求資料都相同，適合於所有伺服器硬體都相同的場景。
- 加權輪詢（Weighted Round Robin） - 根據伺服器硬體效能情況，在輪詢的基礎上，按照配置權重將請求分發到每個伺服器，高效能伺服器能分配更多請求。
- 隨機（Random） - 請求被隨機分配到各個應用伺服器，在許多場合下，這種方案都很簡單實用，因為好的隨機數本身就很平均，即使應用伺服器硬體配置不同，也可以使用加權隨機演算法。
- 最少連線（Least Connection） - 記錄每個應用伺服器正在處理的連線數，將新到的請求分發到最少連線的伺服器上，應該說，這是最符合負載均衡定義的演算法。
- 源地址 Hash（Source Hash） - 根據請求來源的 IP 地址進行 Hash 計算，得到應用伺服器，這樣來自同一個 IP 地址的請求總在同一個伺服器上處理，該請求的上下文資訊可以儲存在這臺伺服器上，在一個會話週期內重複使用，從而實現會話粘滯。
3. 分散式快取叢集的伸縮性設計
一致性 HASH 演算法
4. 資料儲存伺服器叢集的伸縮性設計
4.1. 關係型資料庫的伸縮性設計
- 主從複製 - 主流關係型資料庫一般都支援主從複製。
- 分庫 - 根據業務對資料庫進行分割。制約條件是跨庫的表不能進行 Join 操作。
- 分表 - 使用資料庫分片中介軟體，如 Cobar 等。
4.2. NoSql 資料庫的伸縮性設計
一般而言，Nosql 不支援 SQL 和 ACID，但是強化了對於高可用和伸縮性的支援。