实简单现websocket信道服务

实简单现websocket信道服务

开端

之前有为一个项目做顾问工作，帮助解决了几个问题。该项目完全按照wafer解决方案做的，我在解决问题过程中，发现wafer信道容易出现消息丢失情况，当时由于金主预算有限，没有从根本上解决这个问题，只是做了些曲线救国的优化，然后继续将就着用。与此同时腾讯官方表态wafer整套解决方案都不再提倡，同时不再维护，希望开发者往小程序“云开发”的方向靠拢。

直到有一天，wafer信道停止了服务，导致整个项目瘫住，金主没辙了，又找到了我…

可选方案

为了生计，来活了，自己当然是考虑的，所以为金主想了两个方案：重写信道服务与重写项目。

重写信道服务

wafer不再维护，但原有的功能可以继续使用，只是不再提供信道服务，如果要让整个项目“复活”，可以选择再实现一个信道服务用来替代曾经的免费信道服务。

这个方案的优点是只需要专心解决技术问题，对项目原有业务的影响几乎为0，对金主而言成本一般。

但从开发的角度来看，缺点也比较明显：“需要严格适配已有的SDK”，wafer信道的参与方是server、tunnel-server与client，这其中与tunnel-server通信的双方都依赖wafer提供的SDK。要做到不影响业务代码，需严格适配这两个SDK，也就是要去仔细阅读SDK源码，然后定义tunnel-server的相关接口和参数，这对我而言并不是一件愉快的事。

重写项目

只是重新实现信道服务，金主担心不稳定，所以就咨询了一下重写的成本。我的评估是相差不大，因为重写，信道服务由自己定接口相较于适配SDK会快很多，而且整个项目的业务并不复杂，从零实现也比较快。

这里我个人也偏向于重写，因为老的代码质量我个人觉得很不靠谱，而且设计也不合理。比如对战匹配队列、用户对战信息等，竟然全放在内存中，这意味着无法部署多个实例，要知道金主的单机可是8核16G。