最近，閱讀了Will Larson的文章，感覺很有價值。作者分享了他在Yahoo!與Digg收獲的設計可伸縮系統的架構經驗。在我過往的架構經驗中，由于主要參與開發企業軟件系統，這種面向企業內部的軟件系統通常不會有太大的負載量，太多的并發量，因而對于系統的可伸縮性考慮較少。大體而言，只要在系統部署上考慮集群以及負載均衡即可。本文給了我很多啟發，現把本文的主要內容摘譯出來，并結合自己對此的理解。

Larson首先認為，一個理想的系統，對于容量（Capacity）的增長應該與添加的硬件數是線性的關系。換言之，如果系統只有一臺服務器，在增加了另一臺同樣的機器后，容量應該翻倍。以此類推。這種線性的容量伸縮方式，通常被稱之為水平伸縮“Horizontal Scalability”。

[[73937]]

在設計一個健壯的系統時，自然必須首要考慮失敗的情況。Larson認為，一個理想的系統是當失去其中一臺服務器的時候，系統不會崩潰。當然，對應而言，失去一臺服務器也會導致容量的響應線性減少。這種情況通常被稱為冗余“Redundancy”。

負載均衡

無論是水平伸縮還是冗余，都可以通過負載均衡來實現。負載均衡就好似一個協調請求的調停者，它會根據集群中機器的當前負載，合理的分配發往Web服務器的請求，以達到有效利用集群中各臺機器資源的目的。顯然，這種均衡器應該介于客戶端與Web服務器之間，如下圖所示：

本文提到了實現負載均衡的幾種方法。其一是Smart Client，即將負載均衡的功能添加到數據庫（以及緩存或服務）的客戶端中。這是一種通過軟件來實現負載均衡的方式，它的缺點是方案會比較復雜，不夠健壯，也很難被重用（因為協調請求的邏輯會混雜在業務系統中）。對此，Larson在文章以排比的方式連續提出問題，以強化自己對此方案的不認可態度：

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.

第二種方式是采用硬件負載均衡器，例如Citrix NetScaler。不過，購買硬件的費用不菲，通常是一些大型公司才會考慮此方案。

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

緩存

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

應用緩存

提供緩存的方式可以分為應用緩存和數據庫緩存。此二者各擅勝場。應用緩存通常需要將處理緩存的代碼顯式地集成到應用代碼中。這就有點像使用代理模式來為真實對象提供緩存。首先檢查緩存中是否有需要的數據，如果有，就從緩存直接返回，否則再查詢數據庫。至于哪些值需要放到緩存中呢？有諸多算法，例如根據最近訪問的，或者根據訪問頻率。使用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) 

數據庫緩存

數據庫緩存對于應用代碼沒有污染，一些天才的DBA甚至可以在不修改任何代碼的情況下，通過數據庫調優來改進系統性能。例如通過配置Cassandra行緩存。

內存緩存

為了提高性能，緩存通常是存儲在內存中。常見的內存緩存包括Memcached和Redis。不過采用這種方式仍然需要合理的權衡。我們不可能一股腦兒的將所有數據都存放在內存中，雖然這會極大地改善性能，但比較起磁盤存儲而言，RAM的代價更昂貴，同時還會影響系統的健壯性，因為內存中的數據沒有持久化，容易丟失。正如之前提到的，我們應該將需要的數據放入緩存，通常的算法是least recently used，即LRU。

CDN

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

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

緩存失效

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

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

Off-Line處理

這篇文章還提到了Off-Line的處理方式，即通過引入消息隊列的方式來處理請求。事實上，在大多數企業軟件系統中，這種方式也是較為常見的做法。在我撰寫的文章《案例分析:基于消息的分布式架構》中，較為詳細地介紹了這種架構。在引入消息隊列后，Web服務器會充當消息的發布者，而在消息隊列的另一端可以根據需要提供消費者Consumer。如下圖所示。對于Off-Line的任務是否執行完畢，通常可以通過輪詢或回調的方式來獲知。

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

引入Message Queue，可以極大地緩解Web服務器的壓力，因為它可以將耗時較長的任務轉到專門的機器上去執行。

此外，通過引入定時任務，也可以有效地利用Web服務器的空閑時間來處理后臺任務。例如，通過Spring Batch Job來執行每日、每周或者每月的定時任務。如果需要多臺機器去執行這些定時任務，可以引入Spring提供的Puppet來管理這些服務器。Puppet提供了可讀性強的聲明性語言來完成對機器的配置。

Map-Reduce

對于大數據的處理，自然可以引入Map-Reduce。為整個系統專門引入一個Map-Reduce層來處理數據是有必要的。相對于使用SQL數據庫作為數據中心的方式，Map-Reduce對可伸縮性的支持更好。Map-Reduce可以與任務的定時機制結合起來。如下圖所示：

平臺層

Larson認為，大多數系統都是Web應用直接與數據庫通信，但如果能加入一個平臺層（Platform Layer），或許會更好。

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

其次，增加一個額外的平臺層，可以有效地提高系統的可重用性。例如我們可以將一些與系統共有特性以及橫切關注點的內容（如對緩存的支持，對數據庫的訪問等功能）抽取到平臺層中，作為整個系統的基礎設施（Infrastructure）。尤其對于產品線系統而言，這種架構可以更好地為多產品提供服務。

最后，這種架構也可能對跨團隊開發帶來好處。平臺可以抽離出一些與產品無關的接口，從而隱藏其具體實現的細節。如果劃分合理，并能設計出相對穩定的接口，就可以使得各個團隊可以并行開發。例如可以專門成立平臺團隊，致力于對平臺的實現以及優化。