互聯網系統架構演變

2021 年 5 月 27 日
筆記
架構

2. 傳統架構

2.1 提高伺服器性能（單機）
2.2 增加伺服器數量（DNS）
2.3 負載均衡
2.4 資料庫解決方案

1. 程式三高

1）高並發

高並發（High Concurrency）是互聯網分散式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時（並行）正確處理多個請求。高並發相關常用的一些指標如下：

響應時間：系統對請求做出響應的時間。例如系統處理一個 HTTP 請求需要 200ms，這個 200ms 就是系統的響應時間。
吞吐量：單位時間內處理的請求數量。
TPS：每秒響應事務數。
並發用戶數：同時承載能正常使用系統功能的用戶數量。

2）高性能

簡單地說，高性能（High Performance）就是指程式處理速度快，所佔記憶體少，CPU 佔用率低。

高並發和高性能是緊密相關的，提高應用的性能，是肯定可以提高系統的並發能力的。
應用性能優化的時候，對於計算密集型和 I/O 密集型還是有很大差別，需要分開來考慮。
增加伺服器資源（CPU、記憶體、伺服器數量），絕大部分時候是可以提高應用的並發能力和性能（前提是應用能夠支援多任務並行計算，多伺服器分散式計算才行），但也是要避免其中的一些問題，才可以更好的更有效率的利用伺服器資源。

3）高可用

高可用性（High Availability）通常來描述一個系統經過專門的設計，從而減少停工時間，保證其服務的高度可用性（一直都能用）。

2. 傳統架構

2.1 提高伺服器性能（單機）

硬體/系統級別的解決方案：

增強單機硬體性能（優先）：如增加 CPU 核數如 32 核；升級更好的網卡如萬兆；升級更好的硬碟如 SSD；擴充硬碟容量如 2T；擴充系統記憶體如 128G。
換掉免費的 Tomcat，使用商用 weblogic（Oracle 公司出品）。
聘請系統架構師優化 Linux 內核。
甚至花高價直接購買高性能伺服器。

應用級別的解決方案：

網頁 HTML 靜態化。
圖片伺服器分離。
快取：提高響應速度；減少 I/O 次數。
使用非同步來增加單服務吞吐量。
使用無鎖數據結構來減少響應時間。

隨著業務的不斷增加，伺服器性能很快又到達瓶頸。不管是提升單機硬體性能，還是提升單機架構性能，都有一個致命的不足：單機性能總是有極限的。所以互聯網系統架構對高並發的終極解決方案還是水平擴展。

水平擴展（Scale Out）：只要增加伺服器數量，就能線性擴充系統性能。水平擴展對系統架構設計是有要求的，難點在於：如何在架構各層進行可水平擴展的設計。

2.2 增加伺服器數量（DNS）

DNS（Domain Name System，域名系統），網際網路上作為域名和 IP 地址相互映射的一個分散式資料庫，能夠使用戶更方便地訪問互聯網，而不用去記住能夠被機器直接讀取的 IP 數串。通過主機域名得到該域名對應的 IP 地址的過程叫做域名解析。DNS 協議運行在 UDP 協議之上，使用埠號 53。

循環復用 DNS 是一個普遍使用的在 Web 伺服器上負載平衡的解決方案。

//www.company.cn : 192.168.1.100
                        192.168.1.101
                        192.168.1.102

弊端：循環復用 DNS 將傳入的 IP 請求映射到定義的一系列循環形式的伺服器。一旦其中的伺服器發生故障，循環復用 DNS 會繼續把請求發送到這個故障伺服器，直到把該伺服器從 DNS 中移走為止。在這之前，許多用戶必須等到 DNS 連接超時以後才能成功地訪問目標網站（正常運行的伺服器）。

2.3 負載均衡

由於現有系統的各個核心部分隨著業務量、訪問量和數據流量的快速增長，其處理能力和計算強度也需要相應地增大，使得單一的伺服器設備根本無法承擔。在此情況下，如果扔掉現有設備去做大量的硬體升級，這樣將造成現有資源的浪費，而且如果再面臨下一次業務量的提升時，這又將導致再一次硬體升級的高額成本投入，甚至性能再卓越的設備也不能滿足當前業務量增長的需求。

針對此情況而衍生出來的一種廉價、有效、透明的方法以擴展現有網路設備和伺服器的頻寬、增加吞吐量、加強網路數據處理能力、提高網路的靈活性和可用性的技術就是負載均衡（Load Balance）。

負載均衡的功能總結

轉發請求
故障移除
恢復添加

負載均衡種類

一種是通過硬體來解決，常見的硬體有 NetScaler、F5、Radware 和 Array 等商用的負載均衡器，但是它們是比較昂貴的。
一種是通過軟體來解決，常見的軟體有 LVS、Nginx、apache 等，它們是基於 Linux 系統並且開源的負載均衡策略。

負載均衡——主流的軟體解決方案

apache + JK
nginx + keepalived
lvs + keepalived

Apache + JK

Apache 是世界使用排名第一的 Web 伺服器軟體。它可以運行在幾乎所有廣泛使用的電腦平台上，由於其跨平台和安全性被廣泛使用，是最流行的 Web 伺服器端軟體。

JK 則是 apache 提供的一款為解決大量請求而分流處理的開源插件。

Keepalived

Keepalived 是一個基於 VRRP 協議來實現的 WEB 服務高可用方案，可以利用其來避免單點故障。Keepalived 的作用是檢測 Web 伺服器的狀態，如果有一台 Web 伺服器死機或工作出現故障，Keepalived 會檢測到並將有故障的 Web 伺服器從系統中剔除，當 Web 伺服器工作正常後 Keepalived 會自動將 Web 伺服器恢復加入到伺服器群中。這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的 Web 伺服器。

一個 Web 服務至少會有 2 台伺服器運行 Keepalived，一台為主伺服器（Master），一台為備份伺服器（Backup），但是對外表現為一個虛擬 IP，主伺服器會發送特定的消息給備份伺服器，當備份伺服器收不到這個消息的時候，即主伺服器宕機時，備份伺服器就會接管虛擬 IP，繼續提供服務，從而保證了高可用性。

Nginx

Nginx 是一款輕量級的反向代理伺服器，由俄羅斯的程式設計師 Igor Sysoev（伊戈爾·西索夫）所開發，供俄國大型的入口網站及搜索引擎 Rambler（漫步者）使用。

Nginx 特點是佔有記憶體少，並發能力強，事實上 Nginx 的並發能力確實在同類型的網頁伺服器中表現較好，中國大陸使用 Nginx 的網站用戶有騰訊、新浪、網易等。

優點

可運行在 Linux 上，並有 Windows 移植版。
在高連接並發的情況下，Nginx 是 Apache 伺服器不錯的替代品。Nginx 在美國是做虛擬主機生意的老闆們經常選擇的軟體平台之一。能夠支援高達 50,000 個並發連接數（頂級伺服器的基礎上）。

LVS

LVS 的英文全稱是 Linux Virtual Server，即 Linux 虛擬伺服器，它是中國的章文嵩博士的一個開源項目。在 Linux 內核 2.6 中，它已經成為內核的一部分，在此之前的內核版本則需要重新編譯內核。

優點：

抗負載能力強：因為 LVS 工作方式的邏輯非常簡單，而且工作在網路 4 層僅做請求分發之用（四層面向的是網路連接而不是數據包），幾乎沒有流量，保證了均衡器的 I/O 性能不會受到大流量的影響，所以在效率上基本不需要過多考慮。在我手裡的 LVS，僅僅出過一次問題：在並發最高的一小段時間內均衡器出現丟包現象，據分析為網路問題，即網卡或 Linux 2.4 內核的承載能力已到上限，記憶體和 CPU 方面基本無消耗（對機器性能要求不高，因此可運行在廉價機器上）。
配置性低：這通常是一大劣勢，但同時也是一大優勢，因為沒有太多可配置的選項，所以除了增減伺服器，並不需要經常去觸碰它，大大減少了人為出錯的幾率。
工作穩定：因為其本身抗負載能力很強，所以穩定性高也是順理成章，另外各種 LVS 自身都有完整的雙機熱備方案（如 LVS + Keepalived 和 LVS + Heartbeat），所以一點不用擔心均衡器本身會出什麼問題，節點出現故障的話，LVS 會自動判別，所以系統整體是非常穩定的。
基本上能支援所有應用：因為 LVS 工作在網路 4 層，所以它可以對幾乎所有應用做負載均衡，包括 HTTP、資料庫、聊天室等。

缺點：

軟體本身不支援正則處理，不能做動靜分離，這就凸顯了 Nginx/HAProxy + Keepalived 的優勢。
如果網站應用比較龐大，LVS/DR + Keepalived 就比較複雜了，特別是後面有 Windows 機器的話，實施及配置還有維護過程就比較麻煩，相對而言 Nginx/HAProxy+Keepalived 更簡單。

LVS 對比 Nginx：

負載度：LVS > Nginx
功能多少：Nginx > LVS
穩定性：LVS > Nginx
伺服器性能要求：LVS > Nginx

為什麼說 LVS 幾乎無流量產生？

LVS 總共有三種代理方式：

NAT（網路地址映射）：請求和響應產生流量
IP Tunnelling（IP 隧道）：請求產生流量
Direct Routing（直接路由）：請求產生流量

NAT（網路地址映射）工作原理圖

所有的連接都要經過 LVS，所以這種負載方式是有流量限制的，具體能撐起多大的流量跟機器有關。

IP Tunneling（IP 隧道）

我們可以發現 LVS 只對 Request 連接進行了負載，而 Response 直接通過 Real Server 發送到 Client。但是，Request 的時候應該也有流量啊，為什麼說它沒有流量產生呢？等介紹完第三種負載策略，我們放在後面一起討論。

Direct Routing（直接路由）

我們發現它的工作原理圖和 IP Tunneling 很像：Request 通過 LVS 進行轉發，然後 Real Server 直接將 Response 發送給 Client。

只是有一點不同，圖中說了 LVS 和 Real Server 需要在同一個網段上（Must be in a physical segment）。

總結

對於 NAT（網路地址映射）：因為 Request 和 Response 都要經過 LVS，所以這種負載策略是產生流量的，具體能夠撐起多大的流量更硬體配置有關（如網卡）。
對於 IP Tunneling（IP 隧道）和 Direct Routing（直接路由）：這兩種負載策略幾乎是不產生流量的（Client 發送的第一個數據包需要經過 LVS，所以會產生少量的流量），而後 Client 就直接與 Real Server 通訊了，不會再經過 LVS，所以後面這兩種負載策略能夠扛住更大的連接。也就是說，後面這兩種負載策略會在 Client 和 Real Server 之間直接建立起連接而不需要經過 LVS，所以除了前面幾個數據包會產生流量意外，後面的數據包根本不經過 LVS 了也就沒有產生流量了。

負載均衡解決方案示意圖

注意上圖中的三角鏈路：由 LVS 轉發的用戶請求，再經 Nginx 轉發 Real Server 處理完請求後，直接通過 Nginx 將響應返回給用戶。

CDN：全稱是 Content Delivery Network，即內容分發網路，也稱為內容傳送網路。CDN 是構建在現有網路基礎之上的智慧虛擬網路，依靠部署在各地的邊緣伺服器，通過中心平台的負載均衡、內容分發、調度等功能模組，使用戶就近獲取所需內容，降低網路擁塞，提高用戶訪問響應速度和命中率。CDN的關鍵技術主要有內容存儲和分發技術。

CDN 的基本原理是廣泛採用各種快取伺服器，將這些快取伺服器分布到用戶訪問相對集中的地區或網路中，在用戶訪問網站時，利用全局負載技術將用戶的訪問指向距離最近的工作正常的快取伺服器上，由快取伺服器直接響應用戶請求。

CDN 的基本思路是儘可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。通過在網路各處放置節點伺服器所構成的在現有的互聯網基礎之上的一層智慧虛擬網路，CDN 系統能夠實時地根據網路流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合資訊，將用戶的請求重新導向離用戶最近的服務節點上。其目的是使用戶可就近取得所需內容，解決 Internet 網路擁擠的狀況，提高用戶訪問網站的響應速度。