• • 未修改配置。需修改前端的VUE_APP_WS_URL变量为im-server的服务地址
  • ws url前缀不正确。不带ssl证书时前缀是”ws://”，带ssl证书是”wss://”
  • 网站是https,但是用了ws协议（应该是用wss）

• • 服务器未配置ssl证书。未配置证书的网站，浏览器将阻止用户访问摄像头和麦克风
  • 浏览器不支持webrtc
  • 未搭建coturn。跨网段视频聊天需要搭建coturn，并暴露到公网

• • redis本身性能不弱，单线程能达到10w qps, 尤其在redis6.2版本之后，支持批量拉取消息。从原理上来说，其实跟一些MQ已经差不多，本质都是短轮训的模式
  • 引入MQ之后，依然不能舍弃redis(需要用来做缓存、分布式锁等)，多一个组件，则多一份负担，且主流的MQ(kafak、rocketmq、rabbitmq)均不是轻量级组件，把有限的资源让给redis, 未必不会有会有更好的效果。
  • 本项目是一个开源项目，需要考虑普适性。如果盒子IM使用的是rocketmq,如果客户的原有系统用的是rabbitmq，想集成盒子IM的功能，需要同时部署多个MQ。即使用的是相同的MQ，也可能是不同版本。而redis这类组件，大部分项目都会使用，且redis的sdk版本兼容性相当不错。

并不是复杂的架构就是好架构,也不是所有的项目都是大型项目,很多时候，架构越复杂,意味着消耗的资源就却多,排查问题的难度就越大.

• • 可以通过nginx代理，只是代理的是ws协议。
  • 这个是作者在本地测试im-server集群的nginx配置文件，通过监听nginx的9999端口，代理到两个im-server，各位可以自行参考：📎nginx.conf

• • 两种方案均是可行的，走ws的方案系统优势是消耗资源少、传输时延低，但是架构设计难度大，不利于后期做分布式扩展
  • 两种方案均需要有配套的架构设计，应在开发初期就敲定，不可以随意切换
  • http作为短连接协议, 请求时的确会消耗更多资源，但是对于整个系统而言，消耗的资源占比不会很高，也不会成为整个系统的瓶颈, 即便换成ws，对系统的整体的吞吐量也几乎不会有明显的提升