?[[414795]]?

Kirill Sh@Unsplash

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

對于軟件架構(gòu)師來說，設計一個支持數(shù)億用戶的系統(tǒng)是一個巨大的挑戰(zhàn)（不過在讀了這篇文章后，也許就沒那么難了 ）。

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

• 從最簡單的開始：單體架構(gòu)
• 可伸縮性的藝術(shù)：水平擴展（scaling out），縱向擴展（scaling up）
• 關(guān)系型數(shù)據(jù)庫的可擴展性：主從備份、主主備份、聯(lián)合、分片、去規(guī)范化和 SQL 調(diào)優(yōu)
• 數(shù)據(jù)庫選型：NoSQL 還是 SQL?
• 高級概念：緩存、CDN、GeoDNS 等

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

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

從 0 開始

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

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

在同一臺物理服務器上部署 Web 服務器和數(shù)據(jù)庫服務器

但目前的架構(gòu)有如下缺陷：

• 如果發(fā)生數(shù)據(jù)庫故障，則會導致系統(tǒng)故障。
• 如果 Web 服務器出現(xiàn)故障，也會導致整個系統(tǒng)故障。

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

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

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

每當你訪問一個網(wǎng)站，你的電腦將會執(zhí)行一次 DNS 查尋。

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

可伸縮性的藝術(shù)

由于許多原因，例如數(shù)據(jù)量的增加、業(yè)務的增加（例如事務數(shù)量）和用戶的增長，我們的系統(tǒng)可能不得不進行擴展。

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

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

scale up vs scale out

Scaling up：向現(xiàn)有服務器添加更多內(nèi)存和 CPU

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

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

有很多方法可以實現(xiàn)垂直擴展，如下所示：

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

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

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

擴展不僅適用于硬件，也適用于軟件，例如，它包括優(yōu)化數(shù)據(jù)庫查詢和優(yōu)化應用程序代碼。

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

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

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

這種架構(gòu)有如下優(yōu)點：

• Web 服務器與數(shù)據(jù)庫服務器的調(diào)優(yōu)方式不同。
• Web 服務器需要更好的 CPU，而數(shù)據(jù)庫服務器需要更多內(nèi)存。
• 為 Web 層和數(shù)據(jù)層使用獨立的服務器可以讓它們獨立擴展。

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

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

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

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

使用負載均衡器分發(fā)流量

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

使用負載均衡器分發(fā)流量

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

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

負載均衡是一種容錯保證技術(shù)，可提高系統(tǒng)可用性，如下所示：

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

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

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

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

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

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

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

關(guān)系型數(shù)據(jù)庫的可擴展性

對于一個簡單的系統(tǒng)，我們可以使用像 Oracle 或 MySQL 這樣的 RDBMS 來保存數(shù)據(jù)。但是當我們需要擴展容量的時候，關(guān)系型數(shù)據(jù)庫系統(tǒng)也面臨挑戰(zhàn)。

有許多技術(shù)可以用來擴展關(guān)系型數(shù)據(jù)庫：主從備份（master-slave replication）、主主備份（master-master replication）、聯(lián)合（federation）、分片（sharding）、去規(guī)格化（denormalization）和 SQL 調(diào)優(yōu)。

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

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

主從備份（master-slave replication）

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

所有變更提交到主服務器

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

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

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

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

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

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

主主備份（master-master replication）

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

所有節(jié)點讀寫所有數(shù)據(jù)

主主備份的優(yōu)點：

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

聯(lián)合（Federation）

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

Federation 根據(jù)功能對數(shù)據(jù)庫進行分割

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

分片（Sharding）

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

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

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

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

水平分片（Horizontal partitioning）

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

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

垂直分片（Vertical partitioning）

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

將數(shù)據(jù)劃分為與特定特性相關(guān)的表存儲在各自的服務器上

基于目錄的分區(qū)

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

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

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

去規(guī)格化（Denormalization）

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

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

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

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

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

數(shù)據(jù)庫選型

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

SQL

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

當前最流行的關(guān)系型數(shù)據(jù)庫是 MySQL, Oracle, MS SQL Server, SQLite, Postgres 和 MariaDB。

NoSQL

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

鍵值存儲（Key-Value stores)

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

知名的鍵值存儲數(shù)據(jù)庫包括 Redis、Voldemort 和 Dynamo。

文檔型數(shù)據(jù)庫（Document databases）

數(shù)據(jù)存儲在文檔中（而不是表中的行和列），這些文檔在集合中組合在一起。每個文檔可以有完全不同的結(jié)構(gòu)。

文檔數(shù)據(jù)庫包括 CouchDB 和 MongoDB。

寬列數(shù)據(jù)庫（Wide-column databases）

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

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

圖數(shù)據(jù)庫（Graph databases）

如果數(shù)據(jù)之間的關(guān)系最適合用圖的形式表現(xiàn)，那么圖數(shù)據(jù)庫是最好的選擇。數(shù)據(jù)在圖數(shù)據(jù)庫中保存在帶有節(jié)點（實體）、屬性（關(guān)于實體的信息）和線（實體之間的連接）的圖結(jié)構(gòu)中。

圖數(shù)據(jù)庫的例子包括 Neo4J 和 InfiniteGraph。

Blog 數(shù)據(jù)庫（Blob databases）

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

如何選擇使用哪個數(shù)據(jù)庫?

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

看看下面的指導吧!

用哪個數(shù)據(jù)庫?

Web 層水平縮放

我們已經(jīng)擴展了數(shù)據(jù)層，現(xiàn)在我們還需要擴展 Web 層。為此，我們需要將用戶會話（狀態(tài)）數(shù)據(jù)從 Web 層移出，將它們存儲在數(shù)據(jù)庫中（關(guān)系型數(shù)據(jù)庫或 NoSQL）。這也被稱為無狀態(tài)架構(gòu)。

簡單的無狀態(tài)系統(tǒng)

不要使用有狀態(tài)架構(gòu)。必須盡可能選擇無狀態(tài)架構(gòu)，因為狀態(tài)的實現(xiàn)限制了可伸縮性，降低了可用性，并增加了成本。

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

高級概念

緩存

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

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

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

緩存可以應用于多個層次，如數(shù)據(jù)庫層、Web 服務器層和網(wǎng)絡層。

內(nèi)容分發(fā)網(wǎng)絡（CDN）

CDN 服務器保存靜態(tài)內(nèi)容（如圖像、網(wǎng)頁等）的緩存副本，并從最近的位置提供服務。

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

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

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

全球化

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

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

總結(jié)

在產(chǎn)品迭代的不同階段應用所有這些技術(shù)（無狀態(tài)架構(gòu)，負載均衡器，緩存，多數(shù)據(jù)中心，CDN，數(shù)據(jù)分片等），可以幫助我們很容易地將系統(tǒng)擴展到支持超過 1 億用戶的規(guī)模。

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

還有哪些需要考慮的技術(shù)？

有很多方法可以提高可伸縮性和系統(tǒng)性能：

• 數(shù)據(jù)分片和備份的融合
• 長輪詢 vs WebSockets VS 服務器事件
• 索引和代理
• SQL 調(diào)優(yōu)
• 彈性計算

很簡單，不是么？

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