先简单说下本次的主题,由于我最近做的是物联网相关的开发工作,其中就不免会遇到和设备的交互。
最主要的工作就是要有一个系统来支持设备的接入、向设备推送消息;同时还得满足大量设备接入的需求。
所以本次分享的内容不但可以满足物联网领域同时还支持以下场景:
基于 WEB 的聊天系统(点对点、群聊)。
WEB 应用中需求服务端推送的场景。
基于 SDK 的消息推送平台。
技术选型
要满足大量的连接数、同时支持双全工通信,并且性能也得有保障。
在 Java 技术栈中进行选型首先自然是排除掉了传统 IO。
那就只有选 NIO 了,在这个层面其实选择也不多,考虑到社区、资料维护等方面最终选择了 Netty。
最终的架构图如下:
现在看着蒙没关系,下文一一介绍。
协议解析
既然是一个消息系统,那自然得和客户端定义好双方的协议格式。
常见和简单的是 HTTP 协议,但我们的需求中有一项需要是双全工的交互方式,同时 HTTP 更多的是服务于浏览器。我们需要的是一个更加精简的协议,减少许多不必要的数据传输。
因此我觉得最好是在满足业务需求的情况下定制自己的私有协议,在我这个场景下其实有标准的物联网协议。
如果是其他场景可以借鉴现在流行的 RPC 框架定制私有协议,使得双方通信更加高效。
不过根据这段时间的经验来看,不管是哪种方式都得在协议中预留安全相关的位置。
协议相关的内容就不过讨论了,更多介绍具体的应用。
简单实现
首先考虑如何实现功能,再来思考百万连接的情况。
注册鉴权
在做真正的消息上、下行之前首先要考虑的就是鉴权问题。
就像你使用微信一样,第一步怎么也得是登录吧,不能无论是谁都可以直接连接到平台。
所以第一步得是注册才行。
如上面架构图中的 注册/鉴权 模块。通常来说都需要客户端通过 HTTP 请求传递一个唯一标识,后台鉴权通过之后会响应一个 token,并将这个 token 和客户端的关系维护到 Redis 或者是 DB 中。
客户端将这个 token 也保存到本地,今后的每一次请求都得带上这个 token。一旦这个 token 过期,客户端需要再次请求获取 token。
鉴权通过之后客户端会直接通过TCP 长连接到图中的 push-server 模块。
这个模块就是真正处理消息的上、下行。
保存通道关系
在连接接入之后,真正处理业务之前需要将当前的客户端和 Channel 的关系维护起来。
假设客户端的唯一标识是手机号码,那就需要把手机号码和当前的 Channel 维护到一个 Map 中。
这点和之前 SpringBoot 整合长连接心跳机制 类似。
同时为了可以通过 Channel 获取到客