最近，閱讀了Will Larson的文章，感覺(jué)很有價(jià)值。作者分享了他在Yahoo!與Digg收獲的設(shè)計(jì)可伸縮系統(tǒng)的架構(gòu)經(jīng)驗(yàn)。在我過(guò)往的架構(gòu)經(jīng)驗(yàn)中，由于主要參與開(kāi)發(fā)企業(yè)軟件系統(tǒng)，這種面向企業(yè)內(nèi)部的軟件系統(tǒng)通常不會(huì)有太大的負(fù)載量，太多的并發(fā)量，因而對(duì)于系統(tǒng)的可伸縮性考慮較少。大體而言，只要在系統(tǒng)部署上考慮集群以及負(fù)載均衡即可。本文給了我很多啟發(fā)，現(xiàn)把本文的主要內(nèi)容摘譯出來(lái)，并結(jié)合自己對(duì)此的理解。

Larson首先認(rèn)為，一個(gè)理想的系統(tǒng)，對(duì)于容量（Capacity）的增長(zhǎng)應(yīng)該與添加的硬件數(shù)是線性的關(guān)系。換言之，如果系統(tǒng)只有一臺(tái)服務(wù)器，在增加了另一臺(tái)同樣的機(jī)器后，容量應(yīng)該翻倍。以此類推。這種線性的容量伸縮方式，通常被稱之為水平伸縮“Horizontal Scalability”。

[[73937]]

在設(shè)計(jì)一個(gè)健壯的系統(tǒng)時(shí)，自然必須首要考慮失敗的情況。Larson認(rèn)為，一個(gè)理想的系統(tǒng)是當(dāng)失去其中一臺(tái)服務(wù)器的時(shí)候，系統(tǒng)不會(huì)崩潰。當(dāng)然，對(duì)應(yīng)而言，失去一臺(tái)服務(wù)器也會(huì)導(dǎo)致容量的響應(yīng)線性減少。這種情況通常被稱為冗余“Redundancy”。

負(fù)載均衡

無(wú)論是水平伸縮還是冗余，都可以通過(guò)負(fù)載均衡來(lái)實(shí)現(xiàn)。負(fù)載均衡就好似一個(gè)協(xié)調(diào)請(qǐng)求的調(diào)停者，它會(huì)根據(jù)集群中機(jī)器的當(dāng)前負(fù)載，合理的分配發(fā)往Web服務(wù)器的請(qǐng)求，以達(dá)到有效利用集群中各臺(tái)機(jī)器資源的目的。顯然，這種均衡器應(yīng)該介于客戶端與Web服務(wù)器之間，如下圖所示：

本文提到了實(shí)現(xiàn)負(fù)載均衡的幾種方法。其一是Smart Client，即將負(fù)載均衡的功能添加到數(shù)據(jù)庫(kù)（以及緩存或服務(wù)）的客戶端中。這是一種通過(guò)軟件來(lái)實(shí)現(xiàn)負(fù)載均衡的方式，它的缺點(diǎn)是方案會(huì)比較復(fù)雜，不夠健壯，也很難被重用（因?yàn)閰f(xié)調(diào)請(qǐng)求的邏輯會(huì)混雜在業(yè)務(wù)系統(tǒng)中）。對(duì)此，Larson在文章以排比的方式連續(xù)提出問(wèn)題，以強(qiáng)化自己對(duì)此方案的不認(rèn)可態(tài)度：

Is it attractive because it is the simplest solution? Usually, no. Is it seductive because it is the most robust? Sadly, no. Is it alluring because it’ll be easy to reuse? Tragically, no.

第二種方式是采用硬件負(fù)載均衡器，例如Citrix NetScaler。不過(guò)，購(gòu)買硬件的費(fèi)用不菲，通常是一些大型公司才會(huì)考慮此方案。

如果既不愿意承受Smart Client的痛苦，又不希望花費(fèi)太多費(fèi)用去購(gòu)買硬件，那就可以采用一種混合（Hybird）的方式，稱之為軟件負(fù)載均衡器（Software Load Balancer）。Larson提到了HAProxy。它會(huì)運(yùn)行在本地，需要負(fù)載均衡的服務(wù)都會(huì)在本地中得到均衡和協(xié)調(diào)。

緩存

為了減輕服務(wù)器的負(fù)載，還需要引入緩存。文章給出了常見(jiàn)的對(duì)緩存的分類，分別包括：預(yù)先計(jì)算結(jié)果（precalculating result，例如針對(duì)相關(guān)邏輯的前一天的訪問(wèn)量）、預(yù)先生成昂貴的索引（pre-generating expensive indexes，例如用戶點(diǎn)擊歷史的推薦）以及在更快的后端存儲(chǔ)頻繁訪問(wèn)的數(shù)據(jù)的副本（例如Memcached）。

應(yīng)用緩存

提供緩存的方式可以分為應(yīng)用緩存和數(shù)據(jù)庫(kù)緩存。此二者各擅勝場(chǎng)。應(yīng)用緩存通常需要將處理緩存的代碼顯式地集成到應(yīng)用代碼中。這就有點(diǎn)像使用代理模式來(lái)為真實(shí)對(duì)象提供緩存。首先檢查緩存中是否有需要的數(shù)據(jù)，如果有，就從緩存直接返回，否則再查詢數(shù)據(jù)庫(kù)。至于哪些值需要放到緩存中呢？有諸多算法，例如根據(jù)最近訪問(wèn)的，或者根據(jù)訪問(wèn)頻率。使用Memcached的代碼如下所示：

key = "user.%s" % user_id 
user_blob = memcache.get(key) 
if user_blob is None: 
    user = mysql.query("SELECT * FROM users WHERE user_id=\"%s\"", user_id) 
    if user: 
        memcache.set(key, json.dumps(user)) 
    return user 
else: 
    return json.loads(user_blob) 

數(shù)據(jù)庫(kù)緩存

數(shù)據(jù)庫(kù)緩存對(duì)于應(yīng)用代碼沒(méi)有污染，一些天才的DBA甚至可以在不修改任何代碼的情況下，通過(guò)數(shù)據(jù)庫(kù)調(diào)優(yōu)來(lái)改進(jìn)系統(tǒng)性能。例如通過(guò)配置Cassandra行緩存。

內(nèi)存緩存

為了提高性能，緩存通常是存儲(chǔ)在內(nèi)存中。常見(jiàn)的內(nèi)存緩存包括Memcached和Redis。不過(guò)采用這種方式仍然需要合理的權(quán)衡。我們不可能一股腦兒的將所有數(shù)據(jù)都存放在內(nèi)存中，雖然這會(huì)極大地改善性能，但比較起磁盤存儲(chǔ)而言，RAM的代價(jià)更昂貴，同時(shí)還會(huì)影響系統(tǒng)的健壯性，因?yàn)閮?nèi)存中的數(shù)據(jù)沒(méi)有持久化，容易丟失。正如之前提到的，我們應(yīng)該將需要的數(shù)據(jù)放入緩存，通常的算法是least recently used，即LRU。

CDN

提高性能，降低Web服務(wù)器負(fù)載的另一種常見(jiàn)做法是將靜態(tài)媒體放入CDN（Content Distribution Network）中。如下圖所示：

CDN可以有效地分擔(dān)Web服務(wù)器的壓力，使得應(yīng)用服務(wù)器可以專心致志地處理動(dòng)態(tài)頁(yè)面；同時(shí)，CDN還可以通過(guò)地理分布來(lái)提高響應(yīng)請(qǐng)求的性能。在設(shè)置了CDN后，當(dāng)系統(tǒng)接收到請(qǐng)求時(shí)，首先會(huì)詢問(wèn)CDN以獲得請(qǐng)求中需要的靜態(tài)媒體（通常會(huì)通過(guò)HTTP Header來(lái)配置CDN能夠緩存的內(nèi)容）。如果請(qǐng)求的內(nèi)容不可用，CDN會(huì)查詢服務(wù)器以獲得該文件，并在CDN本地進(jìn)行緩存，最后再提供給請(qǐng)求者。如果當(dāng)前網(wǎng)站并不大，引入CDN的效果不明顯時(shí)，可以考慮暫不使用CDN，在將來(lái)可以通過(guò)使用一些輕量級(jí)的HTTP服務(wù)器如Nginx，為靜態(tài)媒體分出專門的子域名如static.domain.com來(lái)提供服務(wù)。

緩存失效

引入緩存所帶來(lái)的問(wèn)題是如何保證真實(shí)數(shù)據(jù)與緩存數(shù)據(jù)之間的一致性。這一問(wèn)題通常被稱之為緩存失效（Cache Invalidation）。從高屋建瓴的角度來(lái)講，解決這一問(wèn)題的辦法無(wú)非即使更新緩存中的數(shù)據(jù)。一種做法是直接將新值寫入緩存中（通常被稱為write-through cache）；另一種做法是簡(jiǎn)單地刪除緩存中的值，在等到下一次讀緩存值的時(shí)候再生成。

整體而言，要避免緩存實(shí)效，可以依賴于數(shù)據(jù)庫(kù)緩存，或者為緩存數(shù)據(jù)添加有效期，又或者在實(shí)現(xiàn)應(yīng)用程序邏輯時(shí)，盡量考慮避免此問(wèn)題。例如不直接使用DELETE FROM a WHERE…來(lái)刪除數(shù)據(jù)，而是先查詢符合條件的數(shù)據(jù)，再使得緩存中對(duì)應(yīng)的數(shù)據(jù)失效，繼而根據(jù)其主鍵顯式地刪除這些行。

Off-Line處理

這篇文章還提到了Off-Line的處理方式，即通過(guò)引入消息隊(duì)列的方式來(lái)處理請(qǐng)求。事實(shí)上，在大多數(shù)企業(yè)軟件系統(tǒng)中，這種方式也是較為常見(jiàn)的做法。在我撰寫的文章《案例分析:基于消息的分布式架構(gòu)》中，較為詳細(xì)地介紹了這種架構(gòu)。在引入消息隊(duì)列后，Web服務(wù)器會(huì)充當(dāng)消息的發(fā)布者，而在消息隊(duì)列的另一端可以根據(jù)需要提供消費(fèi)者Consumer。如下圖所示。對(duì)于Off-Line的任務(wù)是否執(zhí)行完畢，通常可以通過(guò)輪詢或回調(diào)的方式來(lái)獲知。

為了更好地提高代碼可讀性，可以在公開(kāi)的接口定義中明確地標(biāo)示該任務(wù)是On-Line還是Off-Line。

引入Message Queue，可以極大地緩解Web服務(wù)器的壓力，因?yàn)樗梢詫⒑臅r(shí)較長(zhǎng)的任務(wù)轉(zhuǎn)到專門的機(jī)器上去執(zhí)行。

此外，通過(guò)引入定時(shí)任務(wù)，也可以有效地利用Web服務(wù)器的空閑時(shí)間來(lái)處理后臺(tái)任務(wù)。例如，通過(guò)Spring Batch Job來(lái)執(zhí)行每日、每周或者每月的定時(shí)任務(wù)。如果需要多臺(tái)機(jī)器去執(zhí)行這些定時(shí)任務(wù)，可以引入Spring提供的Puppet來(lái)管理這些服務(wù)器。Puppet提供了可讀性強(qiáng)的聲明性語(yǔ)言來(lái)完成對(duì)機(jī)器的配置。

Map-Reduce

對(duì)于大數(shù)據(jù)的處理，自然可以引入Map-Reduce。為整個(gè)系統(tǒng)專門引入一個(gè)Map-Reduce層來(lái)處理數(shù)據(jù)是有必要的。相對(duì)于使用SQL數(shù)據(jù)庫(kù)作為數(shù)據(jù)中心的方式，Map-Reduce對(duì)可伸縮性的支持更好。Map-Reduce可以與任務(wù)的定時(shí)機(jī)制結(jié)合起來(lái)。如下圖所示：

平臺(tái)層

Larson認(rèn)為，大多數(shù)系統(tǒng)都是Web應(yīng)用直接與數(shù)據(jù)庫(kù)通信，但如果能加入一個(gè)平臺(tái)層（Platform Layer），或許會(huì)更好。

首先，將平臺(tái)與Web應(yīng)用分離，使得它們可以獨(dú)立地進(jìn)行伸縮。例如需要添加一個(gè)新的API，就可以添加新的平臺(tái)服務(wù)器，而無(wú)需增加Web服務(wù)器。要知道，在這樣一個(gè)獨(dú)立的物理分層架構(gòu)中，不同層次對(duì)服務(wù)器的要求是不一樣的。例如，對(duì)于數(shù)據(jù)庫(kù)服務(wù)器而言，由于需要頻繁地對(duì)磁盤進(jìn)行I/O操作，因此應(yīng)保證數(shù)據(jù)庫(kù)服務(wù)器的IO性能，如盡量使用固態(tài)硬盤。而對(duì)于Web服務(wù)器而言，則對(duì)CPU的要求比較高，盡可能采用多核CPU。

其次，增加一個(gè)額外的平臺(tái)層，可以有效地提高系統(tǒng)的可重用性。例如我們可以將一些與系統(tǒng)共有特性以及橫切關(guān)注點(diǎn)的內(nèi)容（如對(duì)緩存的支持，對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)等功能）抽取到平臺(tái)層中，作為整個(gè)系統(tǒng)的基礎(chǔ)設(shè)施（Infrastructure）。尤其對(duì)于產(chǎn)品線系統(tǒng)而言，這種架構(gòu)可以更好地為多產(chǎn)品提供服務(wù)。

最后，這種架構(gòu)也可能對(duì)跨團(tuán)隊(duì)開(kāi)發(fā)帶來(lái)好處。平臺(tái)可以抽離出一些與產(chǎn)品無(wú)關(guān)的接口，從而隱藏其具體實(shí)現(xiàn)的細(xì)節(jié)。如果劃分合理，并能設(shè)計(jì)出相對(duì)穩(wěn)定的接口，就可以使得各個(gè)團(tuán)隊(duì)可以并行開(kāi)發(fā)。例如可以專門成立平臺(tái)團(tuán)隊(duì)，致力于對(duì)平臺(tái)的實(shí)現(xiàn)以及優(yōu)化。