以前也萌生过类似想法，主要问题是，游戏是共享状态太多，不像web应用那样client链接之间互相独立。用coroutine的方式，resume回来，全局的上下文信息改变，容易出bug。实践中，自写的server都不轻易用coroutine，宁愿写callback，虽繁琐但排查容易一点。不做长连接也没关系(特别是手机游戏)，用一个安全可信的client 凭证来标识链接状态即可。
所以关键还是在于，这个游戏的类型是不是强交互的，如果玩家间的交互状态较多，就不适合。如果只是简单的联机, 玩家间交互简单，状态不多，那倒可以，比自己做个server靠谱。
仅仅做个前端的连接管理server倒是可以，链接适合并行，逻辑就很难并行，需要后端进程处理逻辑。
On Monday, April 15, 2013 10:24:49 AM UTC+8, agentzh wrote:
Hello!
2013/4/14 Ken Lam:
> 现在openresty的方式非常的适合Web应用的开发。
> 最近我好奇，openresty能否作为Game Server来使用？
> 类似于传统的Game Server，支持tcp/udp等长连接。然后逻辑处理部分使用lua来
> 操作。客户端/浏览器仍然是使用http协议来数据通信。
> 一点儿胡思乱想，打扰了！
>
我知道的，已经有好几个用户在生产上这么搞了 :)
同时抄送给 openresty 中文邮件列表，建议总是在那里讨论这样的问题，谢谢合作 :)
Best regards,
-agentzh
