?[[414795]]?

Kirill Sh@Unsplash

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

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

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

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

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

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

從 0 開始

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

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

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

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

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

在本例中，我們沒有做故障恢復(fù)和冗余。如果一個(gè)服務(wù)器宕機(jī)，意味著所有服務(wù)都會(huì)掛掉。

DNS 服務(wù)器解析主機(jī)名和 IP 地址

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

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

通常，DNS 以付費(fèi)服務(wù)的形式由服務(wù)器托管公司提供，并不需要在我們自己的服務(wù)器上運(yùn)行。

可伸縮性的藝術(shù)

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

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

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

scale up vs scale out

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

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

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

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

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

如果可以負(fù)擔(dān)硬件升級(jí)的成本，垂直擴(kuò)展對(duì)于小型系統(tǒng)來說是一個(gè)不錯(cuò)的選擇，但它也有以下嚴(yán)重的限制：

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

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

我們是否需要多個(gè)服務(wù)器?

隨著用戶數(shù)量的增長(zhǎng)，一臺(tái)服務(wù)器是遠(yuǎn)遠(yuǎn)不夠的。我們需要考慮將一個(gè)服務(wù)器拆分為多個(gè)服務(wù)器。

隨著用戶數(shù)量的增長(zhǎng)，一臺(tái)服務(wù)器遠(yuǎn)遠(yuǎn)不夠

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

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

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

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

因?yàn)樾枰嗟姆?wù)器來進(jìn)行最基本的擴(kuò)展，所以支持水平擴(kuò)展通常會(huì)在業(yè)務(wù)初期增加更多的成本，但在后期會(huì)獲得回報(bào)，因此我們需要權(quán)衡利弊。

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

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

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

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

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

HAProxy 和 Nginx 是兩個(gè)流行的開源負(fù)載均衡軟件。

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

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

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

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

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

• 可以在共享 IP 池中添加和刪除服務(wù)器，立即生效。
• 負(fù)載均衡可以按設(shè)計(jì)需求進(jìn)行。

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

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

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

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

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

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

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

主從備份（master-slave replication）

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

所有變更提交到主服務(wù)器

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

實(shí)踐中仍然存在一些瓶頸：

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

對(duì)于只有一個(gè)服務(wù)器可以處理更新請(qǐng)求的實(shí)現(xiàn)，下面是一些解決方案：

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

請(qǐng)記住，如果同步解決方案太慢，請(qǐng)更改為異步解決方案。

主主備份（master-master replication）

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

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

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

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

聯(lián)合（Federation）

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

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

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

分片（Sharding）

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

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

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

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

水平分片（Horizontal partitioning）

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

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

垂直分片（Vertical partitioning）

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

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

基于目錄的分區(qū)

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

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

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

去規(guī)格化（Denormalization）

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

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

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

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

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

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

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

SQL

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

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

NoSQL

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

鍵值存儲(chǔ)（Key-Value stores)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

看看下面的指導(dǎo)吧!

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

Web 層水平縮放

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

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

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

在上面的場(chǎng)景中，負(fù)載均衡器可以選擇任意服務(wù)器進(jìn)行最優(yōu)的請(qǐng)求處理，從而達(dá)到最大的效率。

高級(jí)概念

緩存

負(fù)載均衡可以幫助我們?cè)诓粩嘣黾拥姆?wù)器數(shù)量上進(jìn)行水平擴(kuò)展，但緩存將使我們能夠更好地利用已有資源，以便在后續(xù)請(qǐng)求期間更快地提供數(shù)據(jù)。

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

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

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

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

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

因?yàn)閿?shù)據(jù)可以在最接近用戶的位置獲取，因此使用 CDN 可以減少用戶頁面加載時(shí)間。另外，因?yàn)閮?nèi)容被存儲(chǔ)在多個(gè)節(jié)點(diǎn)上，也有助于增強(qiáng)內(nèi)容的可用性。

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

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

全球化

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

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

總結(jié)

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

擴(kuò)容是一個(gè)逐步迭代的過程

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

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

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

很簡(jiǎn)單，不是么？

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