如果用nginx的话不会是瓶颈吧，只是做了下转发，文档只是推荐这样做，你也可以直连gateway
感觉这样浪费资源啊
特别是聊天用户多的时候
哈哈，那就直连gateway，我记得很清楚一个事儿，以前和一个同事讨论字段用char还是varchar，刚开始学sql的时候字段长度固定说是最好用char，varchar会多一位记录长度，同事说现在的电脑性能，不需要考虑那个
这个属于优化细节了
如果GatewayWorker进程宕机了，怎么办
gateway只是负责长连接，没有业务逻辑，不会那么容易宕机吧，分布式部署，哪个宕机就重启O_o
能不能进程守护啊？宕机自动重启？
-d啊，不过我用的supervisor，你也可以试试pm2
是第三方的吗
首次初始化和鉴权走web服务器，其他的直连就行了
绑定uid的时候？登录鉴权？
我觉得你的提议比较合理
消息存储呢？怎么解决
Redis
是在tp框架中还是gatewayworker？中
两个公用一个redis实例
多谢你的技术支持，我的二把刀技术需要继续深造了
聊天服务器是单独部署？单独处理消息？
还是跟web服务器一起？
都可以，人数多的话就分开或者分部署部署都行
非常感谢
聊天消息不是保存数据库吗？redis存储？
redis存储，持久化到数据库
我都是直接在每次发消息的时候写入数据库了
做一个系统稳定性、可扩展、易用、可维护、性能这几点要综合考虑达到一个平衡，不能一味追求性能。
业务逻辑压力要么在web，要么在businessWorker，对于服务器来说都是一样的压力，给谁都差不多。 如果在web做业务，没有学习成本，直接就可以开发了，后面扩展、维护也非常方便。 如果非要在businessWorker做业务，需要你有很强的整合能力，将mvc的数据库等组件移植到businessWorker，还要考虑数据库连接 redis等连接保活问题。并且要保证业务处理足够快，因为一个businessWorker进程卡顿可能影响整个服务消息传递的顺畅性。
这确实需要很强的专业性，像作者这样的就好了
所以还是在web端处理业务逻辑比较合理性
感觉还是直连比较符合即时通讯，每次发消息都得经过web感觉跟轮询有点像，不太符合常理
如果用nginx的话不会是瓶颈吧，只是做了下转发，文档只是推荐这样做，你也可以直连gateway
感觉这样浪费资源啊
特别是聊天用户多的时候
哈哈，那就直连gateway，我记得很清楚一个事儿，以前和一个同事讨论字段用char还是varchar，刚开始学sql的时候字段长度固定说是最好用char，varchar会多一位记录长度，同事说现在的电脑性能，不需要考虑那个
这个属于优化细节了
如果GatewayWorker进程宕机了，怎么办
gateway只是负责长连接，没有业务逻辑，不会那么容易宕机吧，分布式部署，哪个宕机就重启O_o
能不能进程守护啊？宕机自动重启？
-d啊，不过我用的supervisor，你也可以试试pm2
是第三方的吗
首次初始化和鉴权走web服务器，其他的直连就行了
绑定uid的时候？登录鉴权？
我觉得你的提议比较合理
消息存储呢？怎么解决
Redis
是在tp框架中还是gatewayworker？中
两个公用一个redis实例
多谢你的技术支持，我的二把刀技术需要继续深造了
聊天服务器是单独部署？单独处理消息？
还是跟web服务器一起？
都可以，人数多的话就分开或者分部署部署都行
非常感谢
聊天消息不是保存数据库吗？redis存储？
redis存储，持久化到数据库
我都是直接在每次发消息的时候写入数据库了
做一个系统稳定性、可扩展、易用、可维护、性能这几点要综合考虑达到一个平衡，不能一味追求性能。
业务逻辑压力要么在web，要么在businessWorker，对于服务器来说都是一样的压力，给谁都差不多。
如果在web做业务，没有学习成本，直接就可以开发了，后面扩展、维护也非常方便。
如果非要在businessWorker做业务，需要你有很强的整合能力，将mvc的数据库等组件移植到businessWorker，还要考虑数据库连接 redis等连接保活问题。并且要保证业务处理足够快，因为一个businessWorker进程卡顿可能影响整个服务消息传递的顺畅性。
这确实需要很强的专业性，像作者这样的就好了
所以还是在web端处理业务逻辑比较合理性
感觉还是直连比较符合即时通讯，每次发消息都得经过web感觉跟轮询有点像，不太符合常理