Cinchcast架構:處理龐大數據的技術決策
譯文【編者按】這篇博文的作者是Cinchcast和BlogTalkRadio的首席技術官Aleksandr Yampolskiy博士,他在這兩個網站負責工程技術、質量保證、技術運營、電話系統和產品等團隊。
【51CTO快譯】Cinchcast提供的解決方案讓其他公司可以制作、共享、度量和銷售音頻內容,以便覆蓋和吸引對本公司來說最重要的人群。我們的技術整合了會議橋和實時音頻流,從而簡化了網上活動,加強了參與者的互動性。Cinchcast技術還用于支持Blogtalkradio的運行,這是世界上規模最大的音頻社交網絡。如今,我們的平臺每天制作和分發的原創音頻內容超過了1500個小時。我們在本文中描述了我們為了擴展平臺、支持數量這么龐大的數據所做的技術決策。
統計數據
■每個月的頁面瀏覽量超過5000萬
■制作的音頻內容長達50000小時
■1500萬路媒體流
■1.75億廣告瀏覽次數
■峰值速度達到每秒40000次并發請求
■每天數TB的數據存儲在微軟SQL、Redis和ElasticSearch等集群中
■由10名工程師組成的團隊(Cinchcast共有20名技術人員)
■生產環境中大約有100個硬件節點
數據中心
■實際網站從位于布魯克林的數據中心來運行。我們喜歡掌控自己的命運,而不是把數據交給云平臺保管。
■亞馬遜彈性計算云(EC2)實例主要用于質量保證(QA)環境和試運行(Staging)環境。
硬件
■大概50臺Web服務器
■15臺微軟SQL數據庫服務器
■2臺Redis NoSQL鍵值服務器
■2臺NodeJS服務器
■2臺服務器用于彈性搜索集群
開發工具
■NET
■Visual Studio 2010團隊套件充當集成開發環境(IDE)
■StyleCop和ReSharper用于執行代碼標準
■敏捷開發方法,Scrum用于大的開發任務,看板/任務板則用于比較小的任務
■Jenkins + Nunit用于測試和持續集成
■Sauce On Demand——Selenium用于自動化測試
使用的軟件和技術
■Windows Server 2008 R2 64位操作系統
■在微軟Windows Server 2008 Web服務器下運行的SQL Server 2005
■Equalizer負載均衡器用于負載均衡
■REDIS用作分布式緩存層,用于消息發布/訂閱隊列
■NODEJS用于實時分析和更新Studio儀表板
■ElasticSearch用于分布式搜索
■Sawmill+自定義分析器腳本用于日志分析
監控
■NewRelic用于性能監控
■Chartbeat用于分析性能對關鍵績效指標(轉換率和頁面瀏覽量)的影響
■Gomez、WhatsupGold和Nagios用于各種警報
■來自Red Gate的SQL Monitor 用于監控SQL Server
我們采用的方法
■“簡潔、明快、高效,辦完事就走人”:尊重別人的時間。不要帶著問題來,要帶著解決辦法來。
■不盲目追求當下的熱門技術。而是“化解你的首要問題”。我們是采用新技術,但只是業務需要新技術時才這么做。如果你有數以百萬的用戶,針對避免工作網站停運的要求就大大提高。
■先做好“基本功”,然后再考慮“干得漂亮”。
■成為“注重解決辦法的團隊”,而不是“凡事說不的團隊”。
■把安全融入到軟件開發生命周期中。你需要培訓開發人員,教他們如何編寫安全的軟件,并且一開始就把這列為一項優先工作。
架構
■所有的Javascript、CSS和圖片都緩存在內容分發網絡(CDN)處。域名服務系統(DNS)指向CDN,再由CDN將請求傳遞到源服務器。我們之所以使用Cotendo,是因為它允許在CDN做出第七層路由決策。
■使用不同的Web服務器集群,分別為常規用戶和廣告用戶處理各自的請求,由cookie來進行區分。
■我們正在向面向服務的架構遷移;其中,系統的各個關鍵部分(如搜索、驗證和緩存)是由不同語言實現的充分利用REST的服務。這些服務還提供了緩存層。
■Redis NOSQL鍵值存儲區(redis.io)用作數據庫調用之前的緩存層。
■Scaleout用于跨Web服務器園(Web server garden)維護會話狀態。不過,我們在考慮切換到REDIS上。
汲取的經驗教訓
■SQL Server數據庫中的文本搜索不好用。它經常造成處理器阻塞,于是我們改用ElasticSearch(Lucene衍生版本)。
■微軟的內置會話模塊容易出現死鎖,于是我們最后把它換成了AngiesList會話模塊,將數據存儲到REDIS。
■日志功能是發現問題的關鍵。
■重新發明輪子也可以是件好事。比如說,起初我們使用一家廠商的產品,用于將JavaScript/CSS捆綁起來,這開始引起了性能問題。隨后,我們自己重新編寫了捆綁方法,因而顯著改善了我們網站的性能。
■不是所有的數據都是關系型數據,所以數據庫并非總是一種很好的媒介。打個恰當的比方是“設想一下水沿管道流動。管道上頭很寬,但到了下頭變得很窄。”這個上頭就是Web服務器(有好多這種服務器),下頭就是數據庫(數據庫沒多少,變得阻塞起來。)
■開發過程中不使用度量指標就好比高度計失靈的情況下,試圖在暴風雨中讓飛機著落。在整個開發過程中,要估算網站吞吐量、修復致命缺陷/嚴重缺陷的時間和代碼覆蓋率等度量指標,以此來評估你的性能。