《转》搭建 websocket 消息推送服务

近年，不论是正在快速增长的直播，远程教育以及 IM 聊天场景，还是在常规企业级系统中用到的系统提醒，对 websocket 的需求越来越大，对 websocket 的要求也越来越高。从早期对 websocket 的应用仅限于少部分功能和 IM 等特殊场景，逐步发展为追求支持高并发，百万、千万级每秒通讯的高可用 websocket 服务。

面对各种新场景对 websocket 功能和性能越来越高的需求，不同的团队有不同的选择，有的直接使用由专业团队开发的成熟稳定的第三方 websocket 服务，有些则选择自建 websocket 服务。作为一个具有多年 websocket 开发经验的老程序猿，经历了 GoEasy 企业级 websocket 服务从无到有，从小到大的过程，此文是根据过去几年在 GoEasy 开发过程中踩过的坑，以及为众多开发团队提供 websocket 服务、与众多开发者交流中的总结的一些经验和体会。

这次主要从搭建 websocket 服务的基本功能和特性方面做一些分享，下次有机会再从构建一个高可用 websocket 时要面对的高并发，海量消息，集群容灾，横向扩展，以及自动化运维等方面进更多的分享。

以下几点是个人认为在构建 websocket 服务时必须要考虑的一些技术特性以及能显著提高用户体验的功能，供各位同学参考：

1.建立心跳机制心跳机制几乎是所有网络编程的第一步，经常容易被新手忽略。因为在 websocket 长连接中，客户端和服务端并不会一直通信，如果双方长期没有沟通则都不清楚彼此当前状态，所以需要发送一段很小的报文告诉对方“我还活着”。另外还有两个目的：服务端检测到某个客户端迟迟没有心跳过来可以主动关闭通道，让它下线；客户端检测到某个服务端迟迟没有响应心跳也能重连获取一个新的连接。

2.建立具有良好兼容性的客户端 SDK 虽说现在主流浏览器都支持 websocket，但在编码中还是会遇到浏览器兼容性问题，而且通过 websocket 通信的客户端早已不仅限于各种 web 浏览器，还包括越来越多的 APP，小程序。因此就要求构建的 websocket 服务必须能够很友好的支持各种客户端。最好的方式就是构建一个能够兼容所有主流浏览器、小程序和 APP，以及 uni-app、vue、react-native 等目前常见的各种前端框架的客户端 SDK，这样不论公司的各个项目使用什么样的前端技术，都能够快速的集成 websocket 服务。

3.断网自动重连和消息补发机制移动互联网时代，终端用户所处的网络环境多样且复杂，如用户进出电梯，出入地下室或地铁等网络不稳定的场所，或其他原因导致的网络不稳定都是很常见的场景。因此，一个可靠的 websocket 服务必须具备完善的断网自动重连机制。确保断网后，网络一旦恢复，能第一时间自动重新建立长连接，并且能够立即补发在网络不稳定期间发送的消息。

4.离线消息基础的 Websocket 通讯从技术上来说，消息送达的前提条件就是建立起一个长连接，没有建立网络连接就来讨论通讯那是耍流氓。但是从使用者的角度上来说，随手关闭浏览器，或者将小程序、APP 进程直接杀掉而导致网络连接断开的情况是随时都在发生的。然后我们下意识的期待，就是我下次打开浏览器访问网页，或者打开 APP 时，能够收到用户离开系统期间的所有信息。从技术上这是一个跟 websocket 没有多大关系的需求，但实际上却是 websocket 服务不可或缺的基本特性，也是一个能够极大提升用户体验的功能。

5.上下线提醒，客户端在线列表掌握当前系统有哪些用户在线，捕捉用户上下线事件，是搭建一个企业级 websocket 服务，必不可少的特性，尤其是开发 IM 和游戏类产品。

6.支持历史消息查询 websocket 服务，某种意义也是属于一个消息系统，对于历史消息的查询需求，是无法绕开的话题。比如 IM 系统中常见的历史消息，因此在 websocket 服务内部实现一个高速，可靠的消息队列机制来支持 websocket 服务实现历史消息的查询就是一个必须的工作。

7.消息的压缩机制不论是为了保证消息通讯的速度和实时性，还是为了节约流量和带宽费用，或者是出于提高网卡的使用效率和增加系统的吞吐量，在通讯过程中对消息进行必要的压缩都是必不可少的。

除了需要考虑以上七点以外，笔者认为，还有几个问题也是很值得初学者积极关注的：

1.缓存和持久化选择合适的消息缓存机制，是企业级 websocket 服务保证性能必须要考虑的问题。

2.异步调用要支持大量消息通讯的高性能系统，必然推荐异步调用。若设计为同步调用，调用方就需要一直等待被调用方完成。如果一层一层的同步调用下去，所有的调用方需要相同的等待时间，调用方的资源会被大量的浪费。更糟糕的是一旦被调用方出问题，其他调用就会出现多米诺骨牌效应跟着出问题，导致故障蔓延。收到请求立即返回结果，然后再异步执行，不仅可以增加系统的吞吐量，最大的好处是让服务之间的解耦更为彻底。

3.独立于业务和标准化尽管在一个 web 项目中可以同时存在常规 http 服务和 websocket 服务，尤其对性能要求不高的单应用 web 系统，这种方式更简单，更便于维护。但对于性能和可用性高的企业级系统或者互联网平台，更好的方式，是将 websocket 服务作为一个单独的微服务来进行设计，避免和常规的 http 服务抢占资源，导致系统性能不可控，同时也更便于横向扩展。

一个设计良好的企业级 websocket 服务应该是一个独立于业务系统、标准化的单独存在的技术性微服务，能够作为公司基础架构的一部分为公司的所有项目提供通讯服务。

4.幂等性和重复消息的过滤所谓幂等性，就是一次和多次请求一个接口都应该具有同样的后果。为什么需要？对每个接口的调用都会有三种可能的结果：成功，失败和超时。对最后一种的原因很多可能是网络丢包，可能请求没有到达，也有可能返回没有收到。于是在对接口的调用时往往都会有重试机制，但重试机制很容易导致消息的重复发送，从用户层面这往往是不可接受的，因此在接口的设计时，我们就需要考虑接口的幂等性，确保同一条消息发送一次和十次都不回导致消息的重复到达。

5.支持 QoS 服务质量分级其实对于上一点消息重复的问题，行业已经有了解决方案和标准规范，对于消息到达率和重复，常用的手段就是通过消息确认的方式来确保消息到达，要求越高，意味着确认机制越复杂，成本越高。为了在成本和到达率之间有很好的平衡，通常对消息系统的服务质量（QoS）分为以下三个级别 ：

QoS 0(At most once)：“最多发一次”，意味着发送就可以了，不需要确认机制，发送了即可，适用于要求不高的场景，可以接受一定的不到达率，成本最低。

QoS 1(At least once)：“至少发一次”，意味着发送方必须明确收到接收方的确认信号，否则就会反复发，每条消息至少需要两次通信来确认到达，可以接受一些消息被重发，但成本不高 。

QoS 2(Exactly once)：“确保只发一次”，意味着每条消息只能到达一次，且不允许重复到达，为了达到这个目标就需要双方至少通讯三次，成本最高。

一个完善的 websocket 服务面对不同的应用场景，应该能够支持选择不同等级的 QoS，在成本和服务质量之间取得平衡。

最后虽然 websocket 已经广泛的应用于各种系统和平台，但如果要搭建一个满足企业级或者大型互联网平台的可靠、安全稳定的 websocket 服务，对于没有经验的同学，在具体的技术实践过程依然是有不少的坑要踩。

————————————————

版权声明：本文为 CSDN 博主「千锋 python 和唐唐」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/chen801090/article/details/106000222/