前言： 


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同一端口的..