擴展是一個奢侈的問題，它與組織架構的關系遠超與具體技術實現(xiàn)的關系。在每個變化階段，我們都會預測用戶的下一個數(shù)量級，從數(shù)千開始，我們的設計現(xiàn)在支持數(shù)億用戶。我們識別出瓶頸，解決它們的方法也很簡單：在基礎設施中加入明確的集成點，并以分而治之的方式處理各個問題。

識別擴展點，將其轉為一系列更小的問題；有良好定義的集成點；這些方法讓我們能夠以有機而系統(tǒng)的方式增長。

SoundCloud最開始的架構簡單而直接：

互聯(lián)網(wǎng)->Web層（Apache）->應用層（Rails）->數(shù)據(jù)層（MySQL）

Apache支持圖片、風格和行為資源，由MySQL支持的Rails提供一個環(huán)境，幾乎所有的產(chǎn)品都在其中有model，可以快速完成路由和呈現(xiàn)。大多數(shù)團隊成員都可以理解這種模型，交付的產(chǎn)品與我們現(xiàn)在的產(chǎn)品很類似。

我們有意沒有在這時處理高可用問題，也知道到時可能面臨哪些問題。 此時我們版本脫離private beta，面向公眾發(fā)布了SoundCloud。

我們的主要成本是機會成本，只要是阻礙了我們開發(fā)SoundCloud產(chǎn)品理念的東西，都被規(guī)避了。

在早期，我們有意確保構建的不僅是一個產(chǎn)品，而是一個平臺。從一開始，我們的公開API與網(wǎng)站同步開發(fā)。現(xiàn)在，我們與第三方集成者使用的API完全相同，并以之推動網(wǎng)站開發(fā)。

后來，SoundCloud用Nginx替換了Apache，主要原因有兩個：

Rails應用服務器運行在多個主機之上，而Apache處理多個虛擬主機的配置和路由很繁瑣，特別是要保持開發(fā)和生產(chǎn)環(huán)境之間的同步時；

為了更好地提供連接池和基于內容的路由配置，以便管理、分配接收到的web請求、緩存向外的響應，并可以空出一個應用服務器，盡快處理后續(xù)請求。

接下來，SoundCloud發(fā)現(xiàn)有些負載耗去的時間比其他要多幾百個毫秒，一些較快的請求必須要等較慢的請求處理完成。2008年，他們研發(fā)架構 時，Rails和ActiveRecord中的并行請求處理還不夠成熟。他們也開發(fā)了一些并行請求處理的代碼，但是為了不占用更多時間去檢查依賴，他們使 用的方法是：

在每個應用服務器進程上運行一個并行進程，并在每個主機上運行多個進程。

Sean接下來用到了排隊理論中的肯德爾記錄法（Kendall"s notation）。

我們從web服務器向應用服務器發(fā)送一個請求，這個請求過程可以建模為一個M/M/1隊列。該隊列的響應時間由之前所有的請求決定，因此，如果大幅提升一個請求的平均處理時間，那么平均響應時間也會大幅提升。

由于當時仍然處于機會成本較高的階段，所以Sean和他的團隊決定：在繼續(xù)開發(fā)產(chǎn)品的同時，用更好的請求分發(fā)方法來解決這個問題。

我們研究了Phusion旅客方法，也就是在每個主機上使用多個子進程，可是認為這樣可能很快會在每個子進程上填滿長時間運行的請求。這就像有多個隊列，每個隊列上有幾個工作者，模擬在單個監(jiān)聽端口上的并發(fā)請求處理。

這就把M/M/1隊列模型變成了M/M/c隊列模型，c是子進程數(shù)目。

該模型類似于銀行中使用的排號系統(tǒng)。

該模型降低的響應時間由c決定，如果有5個子進程，對緩慢請求的處理速度能快5倍。但是，我們當時已經(jīng)預計未來幾個月用戶會有10倍增長，而且每個主機上的處理能力有限，因此，只加入5到10個工作者并不足以解決排隊阻塞問題。

我們希望系統(tǒng)中不要有等待隊列，如果有，隊列中的等待時間也要降到較低。如果將M/M/c用到極致，我們自問：“如何才能讓c盡可能大？”

為了達到該目的，我們需要確保單個Rails應用服務器每次絕不接收超過1個請求，TCP方式的負載均衡就此出局，因為TCP無法區(qū)分HTTP請求 和響應。我們也要保證：如果所有的應用服務器都是忙碌狀態(tài)，請求將會被排隊到下一個可用的應用服務器中。這就意味著我們必須保證所有的服務器做到完全無狀 態(tài)。當時，我們做到了后者，但未實現(xiàn)前者。

我們在基礎設施中加入了HAProxy，將每個后端配置的較大連接數(shù)為1，并在所有主機中加入了后端進程，保證M/M/c在等待時間上的減少，生成HTTP請求隊列，當任何主機上的后端進程可以處理時再發(fā)送過去。

將HAProxy作為隊列負載均衡器，Sean他們就可以把其他組件中復雜的隊列設計推到請求管道中處理。此時架構如下圖：

?

Sean全力推薦Neil J. Gunther的書籍《使用Perl::PDQ分析計算機系統(tǒng)性能》，幫助大家復習排隊理論，更多了解如何針對HTTP請求隊列系統(tǒng)進行建模和度量，并可以深入到磁盤控制器的層面。

為了解決用戶通知和存儲增長方面的問題，SoundCloud決定加入中間層，以有效地解決工作隊列的失敗處理問題。最后他們選擇了AMQP，因為它提供可編程的拓撲，由RabbitMQ實現(xiàn)。

為了不修改網(wǎng)站中的業(yè)務邏輯，我們調整了Rails環(huán)境，并為每個隊列構建了一個輕量級的分發(fā)器。隊列的命名空間描述了預估的工作次數(shù)，這在異步工 作者中創(chuàng)建起一個優(yōu)先級系統(tǒng)，同時不需要向broker中加入信息優(yōu)先級的處理復雜性，因為每一類工作的分發(fā)器進程只處理該類工作中的多個隊列。應用服務 器中的絕大多數(shù)異步工作隊列，其命名空間中要么有“interactive”（工作時間小于250ms），要么是“batch”（任何工作時間）。其他命 名空間被用于特定應用。

此時他們的架構圖如下：

當用戶達到十萬數(shù)量級時，Sean發(fā)現(xiàn)應用層占用了過多CPU，主要用在呈現(xiàn)引擎和Ruby運行時上。

不過，他們沒有用Memcached，而是緩存了大量DOM片段和完整頁面。由此引發(fā)的失效問題，他們通過維護緩存主鍵的反向索引解決，使用Memcached，當應用中的model發(fā)生改變從而導致失效時，同樣需要該方法解決。

我們較高的海量請求，來自于某個特定的服務，它向頁面微件（widge）交付數(shù)據(jù)。我們在Nginx中為該服務創(chuàng)建了特定路由，并為其加入代理緩 存。不過我們希望緩存功能能夠通用化，做到任何服務都能創(chuàng)建正確的HTTP/1.1緩存控制頭，并可以由我們控制的某個中介正確處理。現(xiàn)在，我們的微件內容完全由公開API提供。

此后，為了處理后端部分呈現(xiàn)模板緩存和大多數(shù)只讀API響應，他們加入了Memcached，并在很晚之后加入了Varnish。此時，他們的架構是：

SoundCloud后來的處理模型變成：針對某個領域model，為其狀態(tài)設定連續(xù)處理方式，以便處理后續(xù)狀態(tài)。

為了通用化這個模式，他們利用了ActiveRecord的after-save鉤子，加入了ModelBroadcast方式。原則是：當業(yè)務領域變化時，事件會丟入AMQP總線中，任何對此變化感興趣的異步客戶端會得到該變化。

把寫路徑從閱讀者中解耦出來，這種技術容納了我們從未想到過的集成點，為未來的增長和演化提供了更大空間。

以下是示例代碼：

after_create do |r|
  broker.publish("models", "create.#{r.class.name}",  r.attributes.to_json)
end

after_save do |r|
  broker.publish("models", "save.#{r.class.name}", r.changes.to_json)
end

after_destroy do |r|
  broker.publish("models", "destroy.#{r.class.name}", r.attributes.to_json)
end

數(shù)據(jù)的快速增長引出了Dashboard功能。在SoundCloud中，用戶可以在Dashboard中看到個人和的社會化活動索引，并可以個人化來自自己關注的人制作的音樂片段。SoundCloud一直受困于Dashboard組件帶來的存儲和訪問問題。

讀寫的路徑各自不同，讀操作路徑需要針對每個用戶提供一定時間范圍內的順序讀并做優(yōu)化，寫操作路徑需要對任意訪問做優(yōu)化，而且一個事件就有可能影響幾百萬用戶的索引。

解決方法是重新排序任意讀操作，將其變?yōu)轫樞蚍绞剑⒁皂樞蚋袷酱鎯┪磥淼淖x取使用，這可能會擴展到多個主機上。排序字符串表非常適合用持久化格式，考慮到需要自由分區(qū)和擴展，我們選擇了Cassandra存儲Dashboard的索引。

我們從model廣播開始，然后用RabbitMQ做隊列完成步驟處理，主要包括三步：扇出（fan-out）、個性化、指向領域模型的外鍵引用串行化。

• 扇出會找出一個活動應該傳播到的社會化圖譜中的區(qū)域。
• 個性化查看發(fā)起者和目的用戶之間的關系，以及其他注解或過濾索引項目的信號。
• 串行化把Cassandra中的索引條目持久化，供以后查找使用，并與領域模型做聯(lián)接，以供顯示或API展示。

此時他們的架構如下：

SoundCloud的搜索通過HTTP接口暴露數(shù)據(jù)集操作子集，供查詢使用。索引的更新與Dashboard類似，通過ModelBroadcase完成，并使用了由Elastic Search管理的索引存儲，在復制數(shù)據(jù)庫方面有提升。

為確保用戶得到Dashboard的通知，SoundCloud在Dashboard的工作流中加入了一個階段，用來接收Dashboard索引更 新的消息。Agent可以通過消息總線得到路由到它們自己的AMQP隊列中的事件完成通知。他們的狀態(tài)和統(tǒng)計通過broker中介集成，但是沒有 ModelBroadcast，他們會發(fā)出在日志的隊列中的特定領域事件，然后保存在隔離的數(shù)據(jù)庫集群中，以滿足不同時間段快速訪問需要。

Sean這樣描述他們對未來的規(guī)劃：

我們已經(jīng)建立起了明確的集成點，包括供異步寫路徑的broker中介中，包括向后端服務完成同步讀和寫的路徑的應用中。

隨著時間演變，應用服務器的數(shù)據(jù)庫已經(jīng)承擔了集成和功能兩方面的職責。產(chǎn)品開發(fā)基本塵埃落定，我們現(xiàn)在有信心將功能與集成分開，轉移到后端服務中，供應用層還有其他后端服務使用，各自都可以在持久化層中有自己的命名空間。

我們在SoundCloud的研發(fā)方式，是識別擴展點，然后分別隔離、優(yōu)化讀路徑和寫路徑，并預估下一個成長階段的數(shù)量級。

最后，Sean指出了SoundCloud以前和現(xiàn)在在架構上的約束：

在產(chǎn)品開發(fā)開始階段，我們讀寫擴展的限制來自消費者的關注和開發(fā)人員的時間。現(xiàn)在，我們的工程方向是I/O、網(wǎng)絡和CPU的限制。