?[[414795]]?

Kirill Sh@Unsplash

高可用架構設計最核心的就是兩點：解耦和冗余。解耦包括業務狀態分離（無狀態架構設計）、分庫分表等。冗余包括緩存、CDN、主從備份、主主備份、GeoDNS 等。一個好的架構設計需要在產品迭代的不同階段選擇合適的技術，從而既能在合理的成本條件下有效保障當前的業務需求，又能考慮到業務下一步發展的可能性。

對于軟件架構師來說，設計一個支持數億用戶的系統是一個巨大的挑戰（不過在讀了這篇文章后，也許就沒那么難了 ）。

以下是本文涉及的一些主題：

• 從最簡單的開始：單體架構
• 可伸縮性的藝術：水平擴展（scaling out），縱向擴展（scaling up）
• 關系型數據庫的可擴展性：主從備份、主主備份、聯合、分片、去規范化和 SQL 調優
• 數據庫選型：NoSQL 還是 SQL?
• 高級概念：緩存、CDN、GeoDNS 等

我們暫時不討論高性能計算中的其他常用術語，比如容錯、可靠性、高可用性等。

讓我們平靜一下，旅程即將開始！

從 0 開始

我們先從設計一個僅支持少量用戶的基本應用程序開始。最簡單的方法就是將整個應用程序部署到單個服務器上，這可能也是大多數人開始的方式。如下圖所示：

• 一個網站（包括 API）運行在類似 Apache1（或 Tomcat2）這樣的 Web 服務器上。
• 一個 Oracle3（或 MySQL?）這樣的數據庫。

在同一臺物理服務器上部署 Web 服務器和數據庫服務器

但目前的架構有如下缺陷：

• 如果發生數據庫故障，則會導致系統故障。
• 如果 Web 服務器出現故障，也會導致整個系統故障。

在本例中，我們沒有做故障恢復和冗余。如果一個服務器宕機，意味著所有服務都會掛掉。

DNS 服務器解析主機名和 IP 地址

在上圖中，用戶（或客戶端）連接到 DNS?以獲得我們的系統所在服務器的 IP 地址。一旦獲得了 IP 地址，請求就直接發送到我們的系統。

每當你訪問一個網站，你的電腦將會執行一次 DNS 查尋。

通常，DNS 以付費服務的形式由服務器托管公司提供，并不需要在我們自己的服務器上運行。

可伸縮性的藝術

由于許多原因，例如數據量的增加、業務的增加（例如事務數量）和用戶的增長，我們的系統可能不得不進行擴展。

可伸縮性通常意味著能夠處理更多的用戶、客戶、數據、事務或請求，可以動態增加更多資源而不會影響用戶體驗。

我們必須決定如何擴大這個系統的規模。在本例中，有以下兩種類型的擴展：垂直擴展（scale-up）和水平擴展（scale-out）。

scale up vs scale out

Scaling up：向現有服務器添加更多內存和 CPU

Scaling up（也被稱為 vertical scaling），指的是使系統的資源最大化，以擴展其處理不斷增加的負載的能力——例如，我們通過增加內存和 CPU 來增加服務器的處理能力。

如果我們服務器的內存為 8GB，那么只需要更換或添加硬件就可以很容易地升級到 32GB 甚至 128GB。

有很多方法可以實現垂直擴展，如下所示：

• 通過增加 RAID 中的硬盤，增加 I/O 容量。
• 通過切換到固態驅動器（SSD）來改善 I/O 訪問時間。
• 切換到具有更多處理器的服務器。
• 通過升級網絡接口或安裝額外的網絡接口，提高網絡吞吐量。
• 通過增加內存來減少 I/O 操作。

如果可以負擔硬件升級的成本，垂直擴展對于小型系統來說是一個不錯的選擇，但它也有以下嚴重的限制：

• “不可能無限制的給一臺服務器增加硬件”。能夠增加多少硬件主要取決于操作系統和服務器的內存總線寬度。
• 當我們增加內存或者其他硬件時，必須關閉服務器，因此，如果系統只有一臺服務器，停機是不可避免的。
• 功能強大的機器通常比流行的硬件貴很多。

擴展不僅適用于硬件，也適用于軟件，例如，它包括優化數據庫查詢和優化應用程序代碼。

我們是否需要多個服務器?

隨著用戶數量的增長，一臺服務器是遠遠不夠的。我們需要考慮將一個服務器拆分為多個服務器。

隨著用戶數量的增長，一臺服務器遠遠不夠

這種架構有如下優點：

• Web 服務器與數據庫服務器的調優方式不同。
• Web 服務器需要更好的 CPU，而數據庫服務器需要更多內存。
• 為 Web 層和數據層使用獨立的服務器可以讓它們獨立擴展。

Scaling out：添加任意數量的硬件和應用實例

Scaling out（也被稱為“horizontal scaling”），指的是向資源池中添加更多的實體（機器、服務）。水平擴展比垂直擴展更難實現，需要我們在構建系統之前就考慮好。

因為需要更多的服務器來進行最基本的擴展，所以支持水平擴展通常會在業務初期增加更多的成本，但在后期會獲得回報，因此我們需要權衡利弊。

• 增加服務器數量意味著需要維護更多的資源。
• 系統的代碼也需要更改，從而支持并行處理，以及在多個服務器之間分配工作。

使用負載均衡器分發流量

負載均衡器是一種專門的硬件或軟件組件，幫助將流量均勻的分發到服務器集群中，以提高系統（包括但不限于應用程序、網站或數據庫）的響應性和可用性。

使用負載均衡器分發流量

通常，負載均衡器位于客戶端和服務器之間，接收網絡和應用程序流量，并使用各種算法將流量均勻分發到多個后端服務器。它也可以部署在各種環境中，例如：在 Web 服務器和數據庫服務器之間，或者在客戶端和 Web 服務器之間。

HAProxy 和 Nginx 是兩個流行的開源負載均衡軟件。

負載均衡是一種容錯保證技術，可提高系統可用性，如下所示：

• 如果服務器 1 下線，所有流量將路由到服務器 2 和服務器 3，因此網站服務不會下線。我們需要向服務器池中添加一個新的健康服務器，以平衡負載。
• 當流量快速增長時，只需要向 Web 服務器池中添加更多的服務器，負載均衡器就會自動路由流量。

負載均衡器采用各種策略和算法來優化負載分配，如下所示：

• 輪詢（Round robin） ：每個服務器按照類似先進先出（FIFO）的順序接收請求。
• 最少連接數（Least number of connections） ：將請求路由到連接數最少的服務器。
• 最快響應時間（Fastest response time） ：將請求路由到響應時間最快（通過最近一段時間采樣或統計最多次數）的服務器。
• 加權（Weighted） ：更強大的服務器將比較弱的服務器接收到更多的請求。
• IP 哈希（IP Hash） ：計算客戶端的 IP 地址的哈希值，將請求重定向到服務器。

在多個服務器之間均衡分發請求的最直接的方法是使用硬件設備。

• 可以在共享 IP 池中添加和刪除服務器，立即生效。
• 負載均衡可以按設計需求進行。

軟件負載均衡器是硬件負載平衡器的廉價替代品，工作在 4 層（網絡層）和 7 層（應用層）協議棧上。

• L4 負載均衡器 ：基于 TCP 在網絡層提供的信息，通常不查看請求的內容就選擇服務器。
• L7 負載均衡器 ：請求可以基于查詢字符串、cookie 或我們選擇的任何報頭中的信息，以及包括源和目的地址等常規信息進行負載均衡。

關系型數據庫的可擴展性

對于一個簡單的系統，我們可以使用像 Oracle 或 MySQL 這樣的 RDBMS 來保存數據。但是當我們需要擴展容量的時候，關系型數據庫系統也面臨挑戰。

有許多技術可以用來擴展關系型數據庫：主從備份（master-slave replication）、主主備份（master-master replication）、聯合（federation）、分片（sharding）、去規格化（denormalization）和 SQL 調優。

• 備份（Replication ） 通常指的是一種允許我們在不同的機器上存儲相同數據的多個副本的技術。
• 聯合（Federation） （或功能分區）按功能對數據庫進行分割。
• 分片（Sharding） 是一種與分區相關的數據庫架構模式，將數據的不同部分放到不同的服務器上，不同的用戶將訪問數據的不同部分。
• 去規格化（Denormalization） 試圖以犧牲部分寫性能為代價來提高讀性能，通過在多個表中寫入數據來避免昂貴的數據 joins 操作。
• SQL 調優（SQL tuning）

Federation 是數據庫垂直分庫，根據業務邏輯，將原本耦合在一起的數據庫劃分出多個不同的數據。Sharding 是數據庫水平分庫，以某個字段（比方說用戶 id）為 key，將一張大表切割成多個小表，每個用戶的數據可以通過訪問不同的小表獲取。Denormalization 通過冗余數據減少數據查詢開銷。

主從備份（master-slave replication）

主從備份允許將一個數據庫服務器（主服務器）的數據復制到一個或多個其他數據庫服務器（從服務器），如下圖所示。

所有變更提交到主服務器

• 客戶端連接到主服務器并更新數據。
• 數據將同步到從服務器，直到所有數據在所有服務器上保持一致。

實踐中仍然存在一些瓶頸：

• 如果主服務器由于某種原因宕機，數據仍然可以通過從服務器獲取，但是不能進行新的寫操作。
• 需要額外的算法將從服務器切換為主服務器。

對于只有一個服務器可以處理更新請求的實現，下面是一些解決方案：

• 同步解決方案（Synchronous solutions） ：只有在所有服務器都接受之后，才正式提交數據修改事務（分布式事務），因此故障恢復的時候不會丟失數據。
• 異步解決方案（Asynchronous solutions） ：提交->延遲->擴散到集群中的其他服務器，因此一些數據更新可能在故障恢復時丟失。

請記住，如果同步解決方案太慢，請更改為異步解決方案。

主主備份（master-master replication）

每個數據庫服務器都可以充當主服務器，同時其他服務器也被視為主服務器。所有主服務器在某個時間點同步數據，從而確保它們都有正確的和最新的數據。

所有節點讀寫所有數據

主主備份的優點：

• 如果一臺主服務器出現故障，其他數據庫服務器可以正常運行并填補漏洞。當失效的數據庫服務器重新上線時，它將復制最新的數據從而和其他服務器同步。
• 主服務器可以位于多個不同的物理位置，可以分布在整個網絡中。
• 受限于主服務器處理數據更新的能力。

聯合（Federation）

聯合（或功能分區）按功能對數據庫進行分割。例如，可以使用三個數據庫：論壇、用戶和產品，而不是單一的、整體的數據庫，從而減少對每個數據庫的讀寫流量，從而減少備份延遲。

Federation 根據功能對數據庫進行分割

更小的數據庫會產生更多的數據，這些數據可以放入內存中，而這又會由于緩存局部性的改善而導致更多的緩存命中。由于不需要單獨的中心化主服務器進行序列化寫操作，我們可以并行地進行寫操作，從而提高吞吐量。

分片（Sharding）

分片（也稱為數據分區）是一種將大數據庫分解為許多較小部分的技術，這樣每個數據庫只管理數據的一個子集。

理想情況下，我們讓不同的用戶與不同的數據庫節點通信。它有助于提高系統的可管理性、性能、可用性和負載均衡。

• 每個用戶只需要與一個服務器通信，因此可以從該服務器獲得快速響應。
• 負載可以在服務器之間很好地平衡——例如，如果我們有 5 臺服務器，每個服務器只需要處理 20%的負載。

實踐中有許多不同的技術可以將數據庫分解為多個更小的部分。

水平分片（Horizontal partitioning）

在這種技術中，我們將不同的行放入不同的表中。例如，如果我們將用戶概要文件存儲在一個表中，我們可以決定 id 小于 1000 的用戶存儲在一個表中，id 大于 1001 且小于 2000 的用戶存儲在另一個表中。

把不同的行放到不同的表中

垂直分片（Vertical partitioning）

在本例中，我們將數據劃分為與特定特性相關的表存儲在它們自己的服務器中。例如，如果我們正在構建一個類似 instagram 的系統——我們需要存儲與用戶、他們上傳的照片和他們關注的人相關的數據——我們可以決定將用戶的個人資料放在一個數據庫服務器上，朋友列表放在另一個服務器上，照片放在第三個服務器上。

將數據劃分為與特定特性相關的表存儲在各自的服務器上

基于目錄的分區

應用怎么知道數據儲存在哪個數據庫里呢？創建一個查找服務可以以一種松耦合的方式解決問題，該服務知道當前的分區模式，并保存每個實體的以及存儲在哪個數據庫分片上的映射。

請記住，分片技術存在以下一些常見問題：

• 在某些情況下，數據庫 joins 操作變得更加昂貴，甚至是不可行的。
• 分片會損害數據庫的引用完整性。
• 數據庫 schema 的更改可能會非常昂貴。
• 數據分布可能不均勻，一個分片上可能有過多負載。

去規格化（Denormalization）

去規格化試圖以犧牲部分寫性能為代價來提高讀性能，數據的冗余副本被寫入多個表中，以避免昂貴的 joins 操作。

一旦數據通過聯合和分片等技術分布，管理跨數據中心的 joins 操作將進一步增加復雜性。去規格化可以避免對這種復雜 joins 操作的需要。

大多數系統中，讀操作的數量可能遠遠超過寫操作，達到 100:1，甚至 1000:1。導致依賴于復雜數據庫 joins 操作的讀操作會非常昂貴，需要在磁盤操作上花費大量時間。

一些 RDBMS，如 PostgreSQL 和 Oracle，支持 Materialized 視圖來處理存儲冗余信息和保持冗余副本一致的工作。

Facebook 的 Ryan Mack 在他的一篇精彩文章中分享了不少 Timeline 利用去規格化技術實施數據庫優化的故事：Building Timeline: Scaling up to hold your life story?。

數據庫選型

當前有兩種主要類型的數據庫解決方案：SQL 和 NoSQL。它們在構建方式、存儲的信息類型和使用的存儲方法上都有所不同。

SQL

關系型數據庫以行和列的形式存儲數據。每一行包含關于一個實體的所有信息，每一列包含所有獨立的數據點。

當前最流行的關系型數據庫是 MySQL, Oracle, MS SQL Server, SQLite, Postgres 和 MariaDB。

NoSQL

也被稱為非關系型數據庫。這些數據庫通常分為五個主要類別：鍵值、圖、列、文檔和 Blob 存儲。

鍵值存儲（Key-Value stores)

數據存儲在鍵值對數組中。' key '是一個鏈接到' value '的屬性名。

知名的鍵值存儲數據庫包括 Redis、Voldemort 和 Dynamo。

文檔型數據庫（Document databases）

數據存儲在文檔中（而不是表中的行和列），這些文檔在集合中組合在一起。每個文檔可以有完全不同的結構。

文檔數據庫包括 CouchDB 和 MongoDB。

寬列數據庫（Wide-column databases）

在列式數據庫中，以列族（column families）存儲數據，而不是'表'，列族是行的容器。與關系數據庫不同，我們不需要預先知道所有的列，每一行也不需要有相同的列數。

列式數據庫最適合分析大型數據集，著名的有 Cassandra 和 HBase。

圖數據庫（Graph databases）

如果數據之間的關系最適合用圖的形式表現，那么圖數據庫是最好的選擇。數據在圖數據庫中保存在帶有節點（實體）、屬性（關于實體的信息）和線（實體之間的連接）的圖結構中。

圖數據庫的例子包括 Neo4J 和 InfiniteGraph。

Blog 數據庫（Blob databases）

Blob 更像是文件的鍵/值存儲，可以通過 Amazon S3、Windows Azure Blob Storage、谷歌 Cloud Storage、Rackspace Cloud Files 或 OpenStack Swift 等 API 訪問。

如何選擇使用哪個數據庫?

談到數據庫技術，沒有一刀切的解決方案。這就是為什么許多企業同時依賴 SQL 和 NosQL 數據庫來滿足不同的需求。

看看下面的指導吧!

用哪個數據庫?

Web 層水平縮放

我們已經擴展了數據層，現在我們還需要擴展 Web 層。為此，我們需要將用戶會話（狀態）數據從 Web 層移出，將它們存儲在數據庫中（關系型數據庫或 NoSQL）。這也被稱為無狀態架構。

簡單的無狀態系統

不要使用有狀態架構。必須盡可能選擇無狀態架構，因為狀態的實現限制了可伸縮性，降低了可用性，并增加了成本。

在上面的場景中，負載均衡器可以選擇任意服務器進行最優的請求處理，從而達到最大的效率。

高級概念

緩存

負載均衡可以幫助我們在不斷增加的服務器數量上進行水平擴展，但緩存將使我們能夠更好地利用已有資源，以便在后續請求期間更快地提供數據。

如果數據不在緩存中，從數據庫中獲取數據，然后將其保存到緩存中并從中讀取。

通過添加緩存，我們可以避免直接從服務器讀取網頁或數據，從而減少服務器的響應時間和負載，這有助于提高應用程序的可伸縮性。

緩存可以應用于多個層次，如數據庫層、Web 服務器層和網絡層。

內容分發網絡（CDN）

CDN 服務器保存靜態內容（如圖像、網頁等）的緩存副本，并從最近的位置提供服務。

因為數據可以在最接近用戶的位置獲取，因此使用 CDN 可以減少用戶頁面加載時間。另外，因為內容被存儲在多個節點上，也有助于增強內容的可用性。

因為數據是在最接近它的位置檢索的，因此使用 CDN 減少了用戶頁面加載時間。

CDN 服務器向我們的 Web 服務器發出請求，以驗證緩存的內容并在需要時更新它們。緩存的通常都是靜態內容的，如 HTML 頁面、圖像、JavaScript 文件、CSS 文件等。

全球化

當我們的應用面向全球用戶，我們將有機會擁有并運營世界各地的數據中心，以保證產品 7×24 運行。訪問請求將被路由到基于 GeoDNS 選擇的“最佳”數據中心進行處理。

GeoDNS 是一種可以根據用戶的位置將域名解析為 IP 地址的 DNS 服務，來自亞洲的客戶端連接到的 IP 地址可能與來自歐洲的客戶端連接到的 IP 地址不同。

總結

在產品迭代的不同階段應用所有這些技術（無狀態架構，負載均衡器，緩存，多數據中心，CDN，數據分片等），可以幫助我們很容易地將系統擴展到支持超過 1 億用戶的規模。

擴容是一個逐步迭代的過程

還有哪些需要考慮的技術？

有很多方法可以提高可伸縮性和系統性能：

• 數據分片和備份的融合
• 長輪詢 vs WebSockets VS 服務器事件
• 索引和代理
• SQL 調優
• 彈性計算

很簡單，不是么？

Reference:
[1] https://httpd.apache.org/ 
[2] http://tomcat.apache.org/ 
[3] https://www.oracle.com/database/ 
[4] https://www.mysql.com 
[5] https://en.wikipedia.org/wiki/Domain_Name_System 
[6] https://www.facebook.com/note.php?note_id=10150468255628920