大型網站的可伸縮性架構如何設計？

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. 負載均衡算法

負載均衡服務器的實現能夠分爲兩個部分：

1. 根據負載均衡算法和 Web 服務器列表計算獲得集羣中一臺 Web 服務器的地址。
2. 將請求數據發送到該地址對應的 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，可是強化了對於高可用和伸縮性的支持。