前言： 


websocket相信經常逛cnode社區的孩紙們都知道..具體API使用方式也再熟悉不過了..使用nodejs開發的websocket服務端也是品種繁多..github上總有你喜歡的..平時耍耍當然沒問題..如果真要是承載一個生產環境服務的核心..總會有些問題需要你去解決. 

不可避免的問題： 

按照一個web請求占用線程數為參照..我們可以把nodejs稱之為單線程語言..而java的servlet這種應該就是多線程語言了..我們可以想象在高并發情況下..單線程語言的運行風險還是蠻高的..畢竟如果一個請求出事那么整個線程（進程）就退出了..于是乎停止服務了..為了規避風險..我們常常會使用負載均衡技術..保證整個系統的對外正常服務.. 

解決方案： 

負載均衡方案目前來講..用apache的也不多了吧..普遍的解決方案是使用nginx配置多個upstream.實現負載均衡..例子如下： 
http{ 
upstream http_sr { 
    server 192.168.0.2:8080; 
    server 192.168.0.3:8080; 
} 
server { 
     listen 80 ; 
     proxy_pass http_sr; 
} 
}

這樣對于部署在192.168.0.2和3這兩臺機器上http服務..就通過這臺nginx服務器實現了負載均衡...但是websocket的服務端nginx的http反向代理是不能支持的.從websocket的specs我們可以很明確的其實基于tcp協議的..http協議雖然也是基于tcp..它們都使用了tcp的握手方式..但是nginx的http_proxy_pass是不能支持websocket的.. 

于是我們可以尋根問主..讓nginx支持tcp_proxy_pass..那websocket負載均衡的問題不就迎刃而解了..nginx有豐富的第三方擴展..一頓搜索在github上找到了yaoweibin老師的nginx_tcp_proxy_module 

  

二話不說下載此模塊..重新編譯nginx(此過程略吧大家應該都懂) ..修改nginx配置文件加入下面conf: 
tcp { 
      upstream websocket { 
          server 192.168.0.2:8080; 
          server 192.168.0.3:8080; 
          check interval=3000 rise=2 fall=5 timeout=1000; 
      } 
      server { 
           listen 80; 
           proxy_pass websocket; 
      } 
}

這個module的作者在description寫到： 
 The motivation of writing these modules is Nginx's high performance and 
    robustness. At first, I developed this module just for general TCP 
    proxy. And now, this module is frequently used in websocket reverse 
    proxying.

目前基本就是用來做websocket反向代理的..測試后確實是支持的..非常感謝module的開發者另外值得注意的是你要在nginx里同時配置tcp和http..那么它們是不能listen同一端口的..