亿级流量架构演进实战 —— 架构演进构建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

Course Curriculum

1

2013 京麦平台

负责京麦(jm.jd.com)从0到1的平台化转型,打造面向商家一站式工作台,为京东商家提供移动和桌面端的操作业务;负责京麦服务端研发,构建高可用的 TCP 网关,演变成为支撑数百万级长连接的架构平台。
3

2018 京东服务市场

负责京东服务市场研发(fw.jd.com)从1到2的发展,完成京东服务市场和京麦插件市场的系统融合,进行 SOA 微服务化改造,演变成为支持千万级订单、亿交易额的交易服务平台;负责平台国际化改造,支持海外站点快速部署。
4

2019 阿里云通信

负责阿里云(aliyun.com)云通信短信全球对客、对供网关从1到2的架构演进和研发落地,聚焦云通信规模化、平台化、全球化的发展方向,深度参与和推动生态平台化项目、CMPP磐石项目、国际站稳定性专项等。
5

2025 阿里云飞天实验室

负责 Qwen Chat(chat.qwen.ai)服务架构的演进,支撑百万级 DAU 的用户流量,保障聊天会话的安全性与系统稳定性;提供 Agent 与 LLM 能力,并全面兼容 Qwen 全系列开源模型,为用户提供多样化的智能服务。