為什麼我要選擇erlang+go進行伺服器架構(1)

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

原創文章，轉載請註明出處：伺服器非業餘研究http://blog.csdn.net/erlib 作者Sunface

估計很多同學看到這裡都會覺得迷惑，go的大名已經如雷貫耳了，但是erlang？這個東東是神馬？難道是程式設計語言？怎麼從來沒聽說過。

這裡請允許我先介紹一下使用Erlang開發的比較有名的應用：

一：whatsapp

      只憑32個技術人員，如何應付4.5億的使用者？對於剛剛被Facebook用190億美元收購的WhatsApp來說，答案是Erlang——一種誕生於上世紀80年代的程式設計語言，終於在此時走到了聚光燈下。

      這個應用把erlang的特性發揮到了極致，利用到了它最好的vm、 叢集基礎設施、資料庫mnesia, 消除了非常多的資料Scale、記憶體池和鎖的問題， 提到的技術和修正點非常值得我們參考。

雖然大部分的解決方案我們在日常都差不多用過。但是他很系統的整理出來，用在商業系統了，這是個非常大的飛躍。

可以服務4.5億使用者的高可靠架構：

需要注意的是， WhatsApp的整體架構並未公開，這裡僅僅是從不同資訊源中擷取不同的片段。Rick Reed的講座主要分享了使用Erlang實現單伺服器200萬串連數，雖然很有價值，但是並不是整個應用架構

這些統計是當下系統的一些資料，更多針對資料存放區、訊息、meta-clustering以及新加入的BEAM/OTP補丁。

·4.5億的活躍使用者，並且是史上最快達到這個數位公司

·32個工程師，平均每人支撐1400萬活躍使用者

·每天收發跨7個平台的500億訊息

·平均每天註冊使用者過百萬

·0廣告開銷

·800萬投資

·數百個節點

·8000+核心

·數百TB記憶體

·每秒Erlang訊息超過7000萬

·在2011年，WhatsApp單伺服器取得 100萬個tcp會話，同時還有記憶體和CPU剩餘。在2012年，tcp會話發展到了200萬。

·

2013年WhatsAppf發表twriter聲明70億訊息入站，110億訊息出戰，即每天處理180億訊息，偉大的2013！

二百多萬的長串連push伺服器：

whatsapp資料集mnesia的規模:

生產系統的資料：

每秒的訊息數：

發展曆程：

1. WhatsApp伺服器基本上完全使用Erlang實現

·做後端訊息路由的伺服器系統使用Erlang實現

·值得炫耀的是，如此龐大數量的活躍使用者只使用非常少的伺服器來管理，團隊一致認為這很大程度上歸功於Erlang。

·值得注意的是，Facebook Chat就是在2009年使用Erlang開發，他們棄用Erlang的原因是難以招聘到優秀的程式員。

2. WhatsApp伺服器最早從Ejabberd開始

·Ejabberd是個非常出名的開源Jabber伺服器，使用Erlang實現。

·最初選用它的原因是開放、廣受開發人員關注、易於開始以及Erlang在大型通訊系統上的長期口碑。

·接下來的許多年一直從事Ejabberd的重寫和修改，包括從XMPP轉換到內部開發協議、調整程式碼程式庫以及重設計一些核心組件，對Erlang VM做了大量的修改以獲得高效能。

3. 為了應對每天500億訊息，工作重心被放到可靠系統的打造上，貨幣化對於我們來說還是件遙遠的事情。

4. 系統的健康情況主要看隊列的長度，每個節點上訊息佇列的長度都會被一直監控，超過預先設定的臨界值則會發出提醒，多個警報發生則標誌著系統進入了下一個瓶頸。

5. 通過上傳圖片、音頻、視頻到一個HTTP伺服器上來發送多媒體訊息，然後將連結與Base64編碼的縮圖一起添加到內容（如果可用）。

6. 有些代碼基本上每天都在變化，通常情況下是一天幾次；當然，峰值期間必須避開的。Erlang非常適用於將修改或者是新功能添加到產品，熱載入意味著無需重新啟動就可以實現修改，錯誤可以很快的得到解決，同樣通過熱載入，系統變得更加松耦合，這可以讓更新快速的發布。

7. WhatsApp使用了什麼樣的協議？WhatsApp伺服器集區使用了SSL Socket，在用戶端重新串連對訊息進行檢索之前，所有訊息都會在伺服器上排隊。訊息的成功檢索會發回給WhatsApp伺服器，它將會被重新轉寄給原始寄件者；一旦用戶端成功接收這條訊息，它就會在伺服器儲存中擦除。

8. WhatsApp註冊程式的內部工作機制是什麼樣的？WhasApp依賴電話IMEI號碼來建立使用者名稱/密碼，這點在最近已經修改。WhatsApp現在會讓應用發送一個包含5位元Pin的一般請求，然後給這個電話號碼發送一個SMS，這意味著WhatsApp用戶端不再受限於某台手機。基於Pin的號碼，應用會從WhatsApp請求一個唯一的鍵，這個鍵將作為未來的使用密碼，這同樣意味著在新的裝置上註冊後會無效原有裝置上的鍵。

結果

開始時每個伺服器有20萬個並發串連。

第一個瓶頸出現每台伺服器42.5萬個串連的時候。系統遇到了很多衝突，工作停止了。安裝調度器檢測有多少有用的任務被停止、睡眠，或迴轉了。在載入時，它開始遇到睡眠鎖，整個系統只用35-45%的CPU利用率，但發送器的CPU利用率卻達到了95%。

第一輪修複使串連數超過100萬個。

VM利用率為76%，CPU利用率為73%，BEAM模擬器利用率為45%，與使用者百分比很吻合，這是件好事，因為模擬器得和使用者一樣。

通常CPU利用率並不是好的評估方法，因為可能由於發送器使用CPU導致系統看起來很忙。

一個月以後解決了瓶頸，每個伺服器串連數達到200萬個。

BEAM利用率為80%，與FreeBSD開始分頁的情況接近。CPU利用率大致相同，有兩倍的串連數。發送器遇到了衝突，但運行得很好。

看來測試可以暫停了，這時開始分析Erlang代碼。

最初每個串連有兩個Erlang進程，消減為一個。

用計時器完成一些工作。

在每個伺服器有280萬串連時達到頂峰

571k pkts/sec, >200k dist msgs/sec

做一些記憶體最佳化，VM載入下降到70%。

嘗試過將串連數增加到300萬，但沒有成功。

·當系統遇到故障時，查看長訊息隊列（單個訊息佇列或訊息佇列總和）。

·將每個進程的訊息佇列統計添加到BEAM裝置上。包括髮送/接收了多少條訊息以及發送/接收的速度。

二：RabbitMq

    這個相信大家都聽說過，世界上最好的企業訊息佇列系統之一。

三：Web架構

    Mochiweb,CowBoy等

四：電信層級的應用

    愛立信等電信公司

五：遊戲伺服器領域的大範圍應用

    特別是在頁遊和手遊領域，erlang簡直如魚得水，用erlang開發出的千萬級流水遊戲也是數不勝數

六：資料庫

    CouchDB,Riak等

七：其他領域的應用

    目前據我所知，在銀行業務，醫學業務，雲業務領域都可以看到erlang活躍的身影.

欲知下文，請繼續閱讀:為什麼我要選擇erlang+go進行伺服器架構(2)