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

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

SoundCloud最開始的架構(gòu)簡單而直接：

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

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

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

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

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

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

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

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

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

在每個應(yīng)用服務(wù)器進(jìn)程上運(yùn)行一個并行進(jìn)程，并在每個主機(jī)上運(yùn)行多個進(jìn)程。

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

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

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

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

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

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

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

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

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

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

將HAProxy作為隊(duì)列負(fù)載均衡器，Sean他們就可以把其他組件中復(fù)雜的隊(duì)列設(shè)計(jì)推到請求管道中處理。此時架構(gòu)如下圖：

?

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

為了解決用戶通知和存儲增長方面的問題，SoundCloud決定加入中間層，以有效地解決工作隊(duì)列的失敗處理問題。最后他們選擇了AMQP，因?yàn)樗峁┛删幊痰耐負(fù)洌蒖abbitMQ實(shí)現(xiàn)。

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

此時他們的架構(gòu)圖如下：

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

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

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

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

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

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

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

以下是示例代碼：

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中看到個人和的社會化活動索引，并可以個人化來自自己關(guān)注的人制作的音樂片段。SoundCloud一直受困于Dashboard組件帶來的存儲和訪問問題。

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

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

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

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

此時他們的架構(gòu)如下：

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

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

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

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

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

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

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

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