[閒聊] 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。
這種連線方式其實有幾篇文章已經說明的相當清楚，

• http://blog.cloudfoundry.com/2013/01/24/scaling-real-time-apps-on-cloud-foundry-using-node-js-and-redis/
• http://blog.davidmisshula.com/blog/2013/02/04/configure-haproxy-to-scale-multiple-nodes-with-stickiness-and-ssl/

這邊的方式都是採用如同上述表示的規劃架構，可以達到 socket.io scaling 的機制。
當然聰明的各位也想到了，有需求就會有解決方案，因此也有廠商提供了類似的解決方案，

• https://www.firebase.com/
• http://pusher.com/

這兩間廠商都是提供 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