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

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

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

互聯網->Web層（Apache）->應用層（Rails）->數據層（MySQL）

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

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

我們的主要成本是機會成本，只要是阻礙了我們開發SoundCloud產品理念的東西，都被規避了。

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

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

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

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

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

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

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

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

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

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

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

該模型類似于銀行中使用的排號系統。

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

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

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

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

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

?

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

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

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

此時他們的架構圖如下：

當用戶達到十萬數量級時，Sean發現應用層占用了過多CPU，主要用在呈現引擎和Ruby運行時上。

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

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

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

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

為了通用化這個模式，他們利用了ActiveRecord的after-save鉤子，加入了ModelBroadcast方式。原則是：當業務領域變化時，事件會丟入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

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

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

解決方法是重新排序任意讀操作，將其變為順序方式，并以順序格式存儲供未來的讀取使用，這可能會擴展到多個主機上。排序字符串表非常適合用持久化格式，考慮到需要自由分區和擴展，我們選擇了Cassandra存儲Dashboard的索引。

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

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

此時他們的架構如下：

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

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

Sean這樣描述他們對未來的規劃：

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

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

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

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

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