亿级流量架构演进实战 —— 架构演进构建TCP长连接网关 04
这不是一个讲概念的专栏,而且我也不擅长讲概念,每一篇文章都是一个故事,我希望你可以通过这些故事了解我当时在实际工作中遇到问题和背后的思考,架构设计是种经验,我有幸参与到多个亿级系统的架构设计中,有所收获的同时也希望把这些收获分享与大家。
承接上篇,网关是负责接口调用获取请求数据的,HTTP 属于单向操作,建客户端与服务平台的 TCP 双向通道,保持客户端与服务平台的会话状态,则可以提供更多、更灵活的技术实现和业务实现。在业务服务调用上通过 HTTP 网关,在平台服务调用上则通过 TCP 网关,实现平台与业务解耦,并且平台采用 TCP 通道还可以增加对平台的控制力,如下图所示:

本文继续讲述构建TCP长连接网关的故事。
1。Session 管理
网关为什么需要 Session 管理?因为 HTTP 网关是单向通信的短连接,是无状态的;而 TCP 网关是双向通信的长连接,是有状态的。所谓有状态,简单的理解,用户在 Web 网站登录会后浏览器会基于 Session 缓存用户的认证信息,以实现用户有状态下的服务访问。HTTP 网关 API 的安全访问目前是基于 OAuth2 技术,而 TCP 网关则可以通过长连接实现访问鉴权后基于 Session 管理实现 API 有状态下的服务访问。而且 TCP 属于 OSI 的传输层,所以建立 Session 管理机制构建会话层来提供应用层服务,可以极大的降低系统复杂度。
TCP 网关的 Session 是客户端与服务端建立的一次会话链接,会话信息中保存着 SessionId、连接创建时间、上次访问事件,以及 Connection 和 SessionListener 对象。因为 TCP 网关采用 Netty 框架,所以 Session 中的 Connection 保存了 Netty 的 ChannelHandlerContext 上下文信息。所有连接的 Session 会话信息会保存在 SessionManager 内存管理器中。
TCP 网关通过在 Netty 的 ChannelPipe 中加载自定义 ChannelHandler,构建 Container 容器,将每个 TCP Connection 封装到一个 Session 会话中,保存在 Container 容器中,由 Container 容器构建 Session Layer 提供 Logic 请求调用,如下图所示:
This chapter requires login to view full content. You are viewing a preview.
Login to View Full Content