长连接网关

随着科技的飞速发展，技术的日新月异，长连接的运用场景日益增多。不仅在后端服务中被广泛运用，比较常见的有数据库的访问、服务内部状态的协调等，而且在 App 端的消息推送、聊天信息、直播弹字幕等场景长连接服务也是优选方案。长连接服务的重要性也在各个场合被业界专家不断提及，与此同时也引起了更为广泛地关注和讨论，各大公司也开始构建自己的长连接服务。

连接服务的产生是为了解决云端和终端的数据通信问题。不同的业务场景对通信的实时性、可用性和可靠性的要求都不一样，也就使得连接服务要适应各种各样的场景。

有些场景对实时性要求相对较高，对可靠性要求不是很严格，如对实时交通路 况的推送消息，该消息就要求在一定时间内送达，没有按时送达的消息，就没有推送的意义了。

而对于常见的 IM 场景就刚好相反的策略，用户希望接收到消息，尽管消息投递时用户不在线，这种情况下就对消息的可靠性要求提出更高的要求。

从以上常见场景出发，结合物联网的特殊性：既有业务对数据的实时性要求较高，又有设备对数据的可靠性有苛刻的要求，所以连接服务会结合不同的应用场景做出不同的应对策略。

背景特性

设计目标

• 实时性：满足云端能及时地将数据传达给设备，进而达到云端能够实时控制设备的目的。
• 低功耗：在一些物联网受限的设备上，功耗也是一个重要的考量标准，所以要针对功耗要求严格的设备，进行特殊的处理以满足功耗的要求。
• 多协议的支持：物联网设备类型繁多，不同的厂商、不同类型的设备可能采用不同的传输协议，所以连接服务要能够处理不同的协议，做到多协议的互通。
• 多网络运营商：作为和终端的接入点，保证不同网络运营商的用户都能正常，高效的接入服务，也是服务设计的一个重要指标，如果网络都不能介入的话，其它都将无从谈起。
• 多机房的部署：因为连接服务的定位是面向大量的物联网设备，而高可用性应放在一个非常重要的位置上，所以要求服务能够支持异地多机房的部署。说到多机房的方案必须要跟具体的业务相结合才有意义，连接服务之所以能够相对较简单的实现跟我们的服务本身定位有直接关系，服务没有持久化的消息数据，只是作为一个传输通道。另一方面，这个层面达到了多机房，但是如果具体的业务线不能达到多机房的部署（这个又是非常困难的，具体业务一般都有持久化的数据），对最终的终端来说依然是不能够达到机房宕机完全无影响的效果。假如每个点都提高一点高可用性，整体的可用性就会越来越好。
• 多业务线：由于各业务线的重要程度不同，对数据服务质量的要求也是不同的，所以要针对不同的业务线做不同的处理，并且要做好不同业务线之间的隔离。

且不同的业务线的技术栈的不同，业务回调的实时性要求不同，也决定了我们需要采用不同的业务数据回调方式。

7、数据安全性

物联网设备的数据都是直接和硬件相关的信息，所以对数据的安全性要求比传统的互联网模式下的要求要高。

技术要求

当我们在设计长连接网关时候，需要关注以下方面：

• 集中实现长连接管理和推送能力。统一技术栈，将长连接作为基础能力沉淀，便于功能迭代和升级维护。
• 与业务解耦。将业务逻辑与长连接通信分离，使业务系统不再关心通信细节，也避免了重复开发，浪费研发成本。
• 使用简单。提供 HTTP 推送通道，方便各种开发语言的接入。业务系统只需要简单的调用，就可以实现数据推送，提升研发效率。
• 分布式架构。实现多节点的集群，支持水平扩展应对业务增长带来的挑战；节点宕机不影响服务整体可用性，保证高可靠。
• 多端消息同步。允许用户使用多个浏览器或标签页同时登陆在线，保证消息同步发送。
• 多维度监控与报警。自定义监控指标与现有微服务监控系统打通，出现问题时可及时报警，保证服务的稳定性。