跳到主要內容

[閒聊] socket.io scaling out solution

socket.io scaling out solution

socket.io 一直以來都是在 node.js 許多 module 當中,受人注目的一個項目,自己也不例外,從 socket.io 6 進展到目前 socket.io 9 都一直持續關注他的發展。
長期以來這種 Comet 連線模式的環境,最讓人質疑的部份有幾個,
  1. server extend (scaling issue)
  2. message lost *. user connection
首先拿 server exetend 來說,最簡單的解法,同時也是 socket.io 支援的模式,
  1. 設定 socket.io redis config
  2. 使用 load balancer like 的機制
  3. 將 socket.io 服務視為一個 Application
因此就可以如下圖,所表示



http://blog.davidmisshula.com/images/4.png

使用者透過連線到 load balancer 之後,透過 load balaner 將資源分散到每個不同的 Application 機器,每個機器最終將會去向同一個 DB (SQL/ NoSql) 機器取得 session, user, message … 資訊回到應用程式當中。
讓每個使用者的資訊不致於斷線,在這邊 socket.io 預設的使用方式就是採用 redis。
這種連線方式其實有幾篇文章已經說明的相當清楚,
這邊的方式都是採用如同上述表示的規劃架構,可以達到 socket.io scaling 的機制。
當然聰明的各位也想到了,有需求就會有解決方案,因此也有廠商提供了類似的解決方案,
這兩間廠商都是提供 real time web service 給予 Web App provider ,當然這是一件好事情,對於開發者來說正是這個 provider。

可是其中有個問題就是,對於開發者來說這些服務都需要先熟悉他的 API 以及架構,假設…如果今天這個服務商倒了,或者使用者變少之後,那是不是就又成了另外一個科技孤兒。
當然我相信這是一種 trade-off ,對於開發者及廠商都是,話說回來如果我們今天針對的目標族群是 Node.js 開發者,那情況是不是又不太一樣。

針對 Socket.io 開發者


如果是 Node.js 開發者,族群上是針對 socket.io 開發者的話,似乎又有另外一個新的選擇。
沒錯,就在本月份 Widnows Azure(沒錯,就是你知道的那個微軟),目前也提供了類似的服務稱為 Windows Azure service bus,
http://ntotten.com/2013/04/05/scaling-out-socket-io-with-windows-azure-service-bus/
文章中提到了,如何去 scale out socket.io 服務,當做自己的後端服務。

how you can scale out Socket.IO to multiple servers in order to handle many simultaneous connections by using Windows Azure Service Bus as a backing store.

總之這是目前 real time service 當中,少數一個以 socket.io API 為基礎的一個服務(當然之後會不會偷改,我不曉得),不過對於長期關注 Socket.io 的開發者來說,是一個優勢。

從此之後我不需要再持續去注意 socket.io scale out 的問題,只需要去關注 deploy 的問題。

實際情況?

實際上,卻好像不是這麼簡單,如果真的要做到一個 real time service 實際上,對於服務背後幫你做的事情,身為一個開發者還是要可以知道後面的 log 狀況。

message lost

目前線上到底有多少 session connect 有哪些已經 fail, 哪些還是 alive ,這些都是需要被關注,而且需要可以查看 log 的部份。

如果真的要確保訊息都有被完善的發送到每個使用者手上,似乎 Queue 的機制也不得不製作,讓每個訊息不管是針對特定使用者,或者是廣播訊息都能夠使用 queue (例如 rabbitMQ, ZeroMQ),能夠確保訊息的傳遞,以及 log 的檢視。

似乎這樣的服務才足以讓開發者有十分強度的信任,不需要自己建立自己的服務,將整個 Web App 移植到某個 Service Provider。

對於開發者

其實親善開發者真的不難,要做到的就是幾個
  1. 統一的介面(API)
  2. 足夠的訊息回顧(Log)
  3. 穩定的網路
  4. 開源的程式
這四點,每個其實都打到許多廠商的要害,總之說很簡單,做很難,但是不論怎樣,做就對了,我們知道距離目標還有千萬公里遠,但是一步一腳印,就慢慢把步伐向前邁進吧!

註記:
此文同步轉載於,http://blogger.micloud.tw/2013/04/socketio-scaling-out-solution.html

留言

  1. Hi, just wanted to say, I loved this blog post. It was practical.
    Keep on posting!

    Feel free to surf to my web-site - ralph lauren polo sale

    回覆刪除

張貼留言

這個網誌中的熱門文章

[解釋] uuid 與 guid 的差異

uuid 與 guid 的差異 很多人都有使用過 MySQL 的 number auto increment, 可是實際使用之後就會發現,很快的數字會不夠使用,而且這個 id 是很容易被猜測出來連續性。 因此就開始進行了解,看到了 uuid 這個名詞,進而下去查詢發現 guid 的另外這個名詞,感覺上這兩個名詞似乎是有些什麼特殊關連。 這篇文章就小小記錄一下自己的查詢心得。

[分享] 腳踏車環島注意事項

很多人都期望自己能夠做點什麼,做些什麼,而退伍之後的第二個星期,就展開了環島之旅。 對很多人來說這不算什麼,甚至有人展開了走路、跑步、溜滑板、單輪車等方式環島一周,充分展現對台灣的愛與關懷。 這篇主要讓不知道怎麼準備環島的人,作一個完善的解說,首先隨身的東西要有: 證件現金類 : 身份證 健保卡 學生證 現金 提款卡 悠遊卡

[教學] 快快樂樂刪除CodeIgniter index.php

預設的CI網址預設都設定為index.php同一層級,因此所有的程式都必須指定index.php導向才能開始,例如 http://localhost/ci/index.php/welcome/test http://localhost/ci/welcome/test 本文將說明如何將惱人的index.php消除,還你一個漂亮的URL。 設定開始: 接下來說明如何使用rewrite方式將惱人的index.php去除。 rewrite不清楚的人,煩請先自行google 首先要先確定Apache的 mod_rewrite 有 開啟 ,如果沒有開啟請設定好之後重新啟動apache。 接著,在根目錄底下建立一個新檔案,檔名為 .htaccess ,裡面程式碼如下: <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php/$1 [L] </IfModule> 接著到 application/config/config.php ,開啟檔案修改 $config['index_page'] = ""; 注意: /index.php/$1 要根據你目錄,例如 http://localhost/index.php ,網站根目錄為 /ci/index.php 則要寫成 /ci/index.php/$1 接著至CI目錄下,尋找 config\config.php , 修改一下裡面的檔案,修改如下: $config['index_page'] = ""; 存檔後,如此一來大功告成。 參考資料 官方網站說明