德国SNS交友/视频网站Poppen.de的技术架构分享
Poppen.de是一個德國的 交友/ 聊天/ 視頻 的SNS網(wǎng)站, 部分內容NSFW，網(wǎng)站采用了很多我們熟悉的技術，像Nginx ，MySQL，CouchDB，Erlang，Memcached的，RabbitMQ(消息服務器)，采用了Graphite作為網(wǎng)站的系統(tǒng)監(jiān)控，Red5作為視頻服務，Tsung作為壓力測試工具，選擇的技術種類較多，還采用PHP和Erlang?2種程序語言作為不同功能的開發(fā)。
關于 Poppen.de 的資料統(tǒng)計數(shù)據(jù)
??? *? 2 000 000 用戶數(shù)
??? *? 20.000并發(fā)用戶數(shù)
??? *? 300.000條私人訊息/每天
??? *? 250.000登錄/每天
功能概要
??? * 用戶在線搜索其他用戶；
??? * 站內對方寫私人消息；
??? * 用戶上傳圖片和視頻；
??? * 用戶與用戶之間的在線視頻聊天。
?Poppen.de整個網(wǎng)站的技術團隊有 11個人開發(fā)人員，2個界面設計師和兩個系統(tǒng)管理員。
H.E的口水1：
Poppen.de 是德國的交友網(wǎng)站，與Facebook這樣巨頭網(wǎng)站相比算是一個小型網(wǎng)站了，但是通過Poppen.de網(wǎng)站這次對外的技術信息分享，可以看出網(wǎng)站有個不錯的技術架構，讓我們可以從中得到很多值得學習與借鑒的內容。?
H.E的口水2：
NSFW這個英文縮寫常常出現(xiàn)在Blog中，表示某個站點含有露點或者極度暴力的內容，如果你在上班的時候打開這個網(wǎng)站你的同事經(jīng)過你身邊的時候估計會讓你很尷尬，呵呵。所以在我朝廷的大局域網(wǎng)內是無法打開這個站點，如果一定要滿足自己的好奇心，你可以動動腦筋看看有什么辦法。
下面是最新的截圖，如圖所示：
系統(tǒng)架構描述：
* Web 層服務器
采用Nginx作為Web App 服務器，2臺機器在前端作為www的請求，在高峰的時候每分鐘能夠處理150.000個用戶的請求，并且結合Memcached一起使用，用來緩存一些用戶的資料信息。
另外3臺Ngixn 服務器作為圖片服務器的請求 例如:img.bilder.poppen.de (image servers),每分鐘處理用戶80.000請求,用戶通過這3臺服務器進行圖片的讀、寫操作，只使用每臺服務器的本地緩存，并不通過Memcached服務器，并且將用戶上傳的圖片信息存放在中央式的文件系統(tǒng)中，估計這樣目的是為了減輕主要儲存設備的負荷。網(wǎng)站已經(jīng)這樣使用了4年，一共5臺Ngixn服務器，每臺配置普通32位CPU、3GB RAM 內存。
* 語言環(huán)境
使用 PHP的5.3 版本 為程序語言運行環(huán)境，整個網(wǎng)站使用28臺機器作為PHP Ap 服務器，每臺機器配置6G內存。每個機器運行運行100個worker processes， 將運行環(huán)境的可選PHP緩存(Alternative PHP Cache, APC)打開, 據(jù)說網(wǎng)站透露這樣可以提高性能，能夠減少 30％的CPU和內存使用率，使用了Symfony1.2版本作為PHP的Web開發(fā)框架，可以提高網(wǎng)站開發(fā)效率，可快速創(chuàng)建復雜的WEB程序。
* 緩存(Memcached)
網(wǎng)站使用memcached的節(jié)點據(jù)說有50個總大小超過45 GB，Memcached用來用戶會話、個人信息、功能執(zhí)行中需要的緩存、數(shù)據(jù)中需要執(zhí)行l(wèi)ike的查詢結果的存儲，網(wǎng)站對于將來可能會漸漸的采用 MongoDB Hash 的解決方法來進行代替現(xiàn)在大量的使用Memcached的現(xiàn)象，Javabloger個人也認為以為大量的使用Memcached緩存服務器不是明智之舉，因為Memcached的原則就不是給你放什么重要信息和可以長期存放的地方，你見過有人拿超市的存包格當私人的保險柜嗎？但一味的使用數(shù)據(jù)庫存儲也不是可取的方法，大量數(shù)據(jù)庫連接/關閉 執(zhí)行SQL的開銷帶來的負載是很多機器設備不能接受的，所以使用像 MongoDB 之類的東西 還是比較折中的選擇，我們相信將來會有更多的網(wǎng)站會向MongoDB靠攏的。
* 消息服務器
整個網(wǎng)站采用的算是一種分布式的異步架構體系，中間采用RabbitMQ作為異步通訊服務器，通過上層28臺PHP Ap Server做成的LVS集群對下層2臺集群的 RabbitMQ 消息系統(tǒng)進行調用，這里消息系統(tǒng)主要用來發(fā)送運行日志，電子郵件通知，系統(tǒng)消息，用戶圖片上傳，每天大約需要處理 500.000條消息，這樣的架構體系可以對系統(tǒng)的運行性能有所改善，在Javabloger看一般有3個原因：????
????第一是加強了系統(tǒng)的可擴展性，
????第二是提高系統(tǒng)資源的使用率，
????第三是降低系統(tǒng)運行中瞬間的瓶頸。
比如在系統(tǒng)繁忙的時間里，每分鐘有1000個用戶進行登錄,這意味著我們將有1000個并發(fā)的用戶請求需要對緩存/數(shù)據(jù)庫表的更新，但是現(xiàn)在有了消息隊列的架構，我們可以運行他們每個順序相反。如果我們需要更多的處理速度，我們可以添加更多的消費者到消息隊列，還可以加入更多的機器到MQ消息群集中，不需要修改以前任何的配置或部署任何新的代碼。網(wǎng)站表示系統(tǒng)將來會向異步式架構發(fā)展，將更多的業(yè)務放入RabbitMQ 系統(tǒng)隊列中進行處理。
H.E的口水1：
? 在2010年4月份中旬，VMware旗下的SpringSource 將RabbitMQ給收購了，不過這次收購應該是一件好事，因為SpringSource計劃對RabbitMQ開發(fā)者社區(qū)提供全方位的支持，另外，SpringSource還針對此次收購發(fā)布了一個FAQ。詳見：http://www.springsource.com/rabbit-technologies-acquisition-faq
H.E.的口水2:
來自2位國內/外網(wǎng)友的經(jīng)驗分享 (Ref1) (Ref2) (Ref3)
1.RabbitMQ支持AMQP協(xié)議，而ZeroMQ的極為簡單。
2.RabbitMQ較慢，幾十個并發(fā)以內，延時為幾十毫秒，但當客戶端達到1000個并發(fā)的時候，速度就無法容忍了（參考）；ZeroMQ上則據(jù)稱可以達到13毫米延時和高達每秒4.1兆次傳遞（參考, 國內需要翻墻才能訪問）。
3.如果隊列較多的話，RabbitMQ很容易把內存耗盡，而ZeroMQ則把隊列內容保存在發(fā)送端。
4.JMS僅僅是Java領域內的API規(guī)范，只能說AMQP比JMS更先進，它有自己的wire-level protocol 可編程的協(xié)議，并且RabbitMQ服務器充分利用了Erlang的分布式、高可靠性、并發(fā)等特性，而并不能一概而論的說JMS沒有RabbitMQ服務器好與壞。
??
* 分布式文檔數(shù)據(jù)庫(CouchDB)
系統(tǒng)中運行CouchDB的服務器只有一臺，主要是用來存日志的，因為在過去我們需要查看某臺機器的日志需要登錄某臺機器進行tail -f 的查看，如果機器一多肯定混亂，采用CouchDB 中一些查詢方法 query/group 就會讓工作簡化很多，而且采用分布式文檔數(shù)據(jù)庫存放系統(tǒng)日志似乎真的很合理，而且管理，使用也不算很復雜。Javabloger前端時間一個人看管了15臺機器，需要查看日志的時候還真的有點不方便，所以日后會在項目中嘗試一下將日志系統(tǒng)進行集中化處理的方案。
* 數(shù)據(jù)庫服務器
采用MySQL數(shù)據(jù)庫作為網(wǎng)站主要的數(shù)據(jù)信息存儲，有4臺MySQL服務器使用基于集群方式NDB表引擎用來存放用戶資料和用戶相關數(shù)據(jù)，這組集群每臺機器配置32GB內存 、4個CPU，但是他們打算在將來采用 Sharing的方式根據(jù)用戶的id來進行水平劃分，這樣當然有好處，可是這樣做了以后需要面對事物和跨庫查詢的問題，網(wǎng)站還有另外3臺MySQL服務器使用的是 master-slave-slave 架構存放用戶在論壇里面的信息，目前數(shù)據(jù)庫表引擎采用的是MyISAM，這樣讀寫會很快，但是會遇到全表鎖的問題，所以將來打算使用?XtraDB?引擎進行存儲，網(wǎng)站對于查詢SQL和建立數(shù)據(jù)庫表結構也進行了多次考慮，為了避免like和join帶來的開銷，因此創(chuàng)建數(shù)據(jù)庫匯總表，以紓緩用戶查詢帶來壓力。
* 系統(tǒng)監(jiān)控(Graphite)
Graphite是這個網(wǎng)站一個重要的部分，用來進行收集服務器所有的及時狀態(tài)，用戶請求信息，Memcached命中率，RabbitMQ消息服務器的狀態(tài)，Unix操作系統(tǒng)的負載狀態(tài)，Graphite服務器大約每分鐘需要有4800次更新操作，Graphite采用簡單的文本協(xié)議和繪圖功能可以方便地使用在任何操作系統(tǒng)上。Graphite 是一個Python寫的web應用，采用django框架，如果你想嘗試一下的話，具體的安裝步驟參見：http://graphite.wikidot.com/installation
安裝好以后的效果如圖所示：
對于具體的PHP程序性能運行的監(jiān)控是采用Facebook開源出來的一個php性能測試工具，XHProf是一個分層PHP性能分析工具。它報告函數(shù)級別的請求次數(shù)和各種指標，包括阻塞時間，CPU時間和內存使用情況。一個函數(shù)的開銷，可細分成調用者和被調用者的開銷。原始數(shù)據(jù)收集部分是用純C實現(xiàn)的，是一個名叫xhprof的 Zend擴展 。XHProf有一個簡單的HTML的用戶界面（ PHP寫成的）。基于瀏覽器的性能分析用戶界面能更容易查看，或是與同行們分享成果。也能繪制調用關系圖。如果他們通過 Graphite發(fā)現(xiàn)那臺Unix負荷高了，將會進一步的使用 XHProf 分析器進行測試。并且有一個單獨的服務器發(fā)送 XHProf測試的概況，并從那里進行分析，找到性能問題的所在。
* 視頻服務器 (Red5)
網(wǎng)站還為用戶提供視頻服務，一種是用戶上傳的一段視頻，還可以彼此進行分享與評價，此外，網(wǎng)站還有一個在線的視頻聊天，在2009年中期每月視頻說產(chǎn)生的網(wǎng)絡流量達到17TB。網(wǎng)站將會尋找更換Red5 視頻服務的方案，可能會選擇Oneteam媒體服務器。
* 壓力測試 (Tsung)
Tsung是采用Erlang編寫一個分布式測試工具。在Tsung控制機器上寫tsung.xml，在這個文件中指定所有的client機器地址、每臺機器的權重、模擬的用戶數(shù)量 配置完成就可以進行測試了，網(wǎng)站用它做HTTP的 benchmarks? 測試，測試 MySQL存儲引擎的處理能力，例如是否需要使用新的MySQL引擎 XtraDB，并且還需要知道XtraDB的處理能力是多大，都是通過Tsung得出的結果，因為Tsung可以輸出不同的格式的報告和圖表信息，如圖所示：
查看大圖請點擊這里，如果你有興趣的話，可以查看Tsung詳細的用戶手冊：http://tsung.erlang-projects.org/user_manual.html
通過Poppen.de這次的對外技術分享，整個網(wǎng)站在我腦海中的架構如圖所示，這只是我的猜想，與實際的架構有出入，請多多見諒：
查看大圖請點擊這里
總結：
1.越來越多的網(wǎng)站由于業(yè)務的壯大，在尋求通過消息傳遞的，異步式架構的方案，在poppen.de中使用的RabbitMQ是Erlang編寫的消息服務器，支持Java、C/C++、.Net 、PHP 等語言。
2.MySQL 的第三方引擎 XtraDB 受到越來越多人的認知，MyISAM依然有用武之地，只是老大難鎖表問題一直沒有很好的解決辦法。
3.Graphite是一款不錯的系統(tǒng)監(jiān)控軟件，對與一個網(wǎng)站來說監(jiān)控其運行狀態(tài)，觀測硬盤、CPU的使用率，Memcached的命中率，客戶的訪問動向、來源，是一件比較重要的事情， 采用Python語言寫的，個人感覺Python如果能得到更好的商業(yè)支持，將來的前景會比Java好。
4.CouchDB是Apache組織又一款經(jīng)典產(chǎn)品，作為非關鍵性的數(shù)據(jù)進行存儲是一個絕佳的方案，例如：系統(tǒng)中的日志。
5.Memcached 和 數(shù)據(jù)庫之間會逐漸的多出一個產(chǎn)物，比如?MongoDB ，不會像現(xiàn)在這樣緩存和數(shù)據(jù)庫2者之間有這么大的跨度。
6.凡是接觸過 Erlang 的人，都會對其產(chǎn)生喜好，可見Erlang的勢頭。
7.MySQL 的 官方集群方案仍然不會被人看好，但是 MySQL 的 MMM 和 MSS 依然是經(jīng)典。
8.Ngixn的性能強大和配置簡單讓他成為web服務器的新寵兒， 對一些圖片的訪問/讀寫還可以使用Ngixn的本地緩存 。
??
–end–
總結
以上是生活随笔為你收集整理的德国SNS交友/视频网站Poppen.de的技术架构分享的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Javascript到PHP加密通讯的简
- 下一篇： UNIX环境编程