在40岁老架构师 尼恩的读者交流群(50+)中,很多小伙伴拿到一线互联网企业如阿里、网易、有赞、希音、百度、滴滴的面试资格。
最近,尼恩指导一个小伙伴简历,写了一个《高并发网关项目》,此项目帮这个小伙拿到 字节/阿里/微博/汽车之家 面邀, 所以说,这是一个牛逼的项目。
为了帮助大家拿到更多面试机会,拿到更多大厂offer,
尼恩决定:9月份给大家出一章视频介绍这个项目的架构和实操,《33章:10Wqps 高并发 Netty网关架构与实操》,预计月底发布。然后,提供一对一的简历指导,让你简历金光闪闪、脱胎换骨。
《33章:10Wqps 高并发 Netty网关架构与实操》 海报如下:
配合《33章:10Wqps 高并发 Netty网关架构与实操》, 尼恩会梳理几个工业级、生产级网关案例,作为架构素材、设计的素材。
前面梳理了
除了以上的6个案例,这里,尼恩又找到一个漂亮的生产级案例:
《100万级连接,石墨文档WebSocket网关如何架构?》,
注意,这又一个非常 牛逼的工业级、生产级网关案例。
这些案例,并不是尼恩的原创。这些案例,仅仅是尼恩在《33章:10Wqps 高并发 Netty网关架构与实操》备课的过程中,在互联网查找资料的时候,收集起来的,供大家学习和交流使用。
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF,请到公号【技术自由圈】获取
作者:石墨文档技术团队
在石墨文档的部分业务中,例如文档分享、评论、幻灯片演示和文档表格跟随等场景,涉及到多客户端数据实时同步和服务端批量数据在线推送的需求,一般的 HTTP 协议无法满足服务端主动 Push 数据的场景,因此选择采用 WebSocket 方案进行业务开发。
随着石墨文档业务发展,目前日连接峰值已达百万量级,日益增长的用户连接数和不符合目前量级的架构设计导致了内存和 CPU 使用量急剧增长,因此我们考虑对长连接网关进行重构。
本文分享了石墨文档长连接网关从1.0架构演进到2.0的过程,并总结了整个性能优化的实践过程。
这套长连接网关系统的v1.0版是使用 Node.js 基于 Socket.IO 进行修改开发的版本,很好的满足了当时用户量级下的业务场景需求。
1.0版架构设计图:
1.0版客户端连接流程:
虽然 1.0 版本的长连接网关在线上运行良好,但是不能很好的支持后续业务的扩展。
并且有以下几个问题需要解决:
长连接网关系统的v2.0版需要解决很多问题。
比如,石墨文档内部有很多组件(文档、表格、幻灯片和表单等等),在 1.0 版本中组件对网关的业务调用可以通过Redis、Kafka 和 HTTP 接口,来源不可查,管控困难。
此外,从性能优化的角度考虑也需要对原有服务进行解耦合,将 1.0 版本网关拆分为网关功能部分和业务处理部分。
具体是:
另外还有:
2.0版本架构设计图:
2.0版本客户端连接流程:
网络状态良好的情况下,完成如下图所示步骤 1 到步骤 6 之后,直接进入 WebSocket 流程;
网络环境较差的情况下,WebSocket 的通信模式会退化成 HTTP 方式,客户端通过 POST 方式推送消息到服务端,再通过 GET 长轮询的方式从读取服务端返回数据。
客户端初次请求服务端连接建立的握手流程:
流程说明如下:
{"sid":"xxx","upgrades":["websocket"],"pingInterval":xxx,"pingTimeout":xxx}
客户端与服务端连接建立采用的 wss 协议,在 1.0 版本中 TLS 证书挂载在 Nginx 上,HTTPS 握手过程由 Nginx 完成。为了降低 Nginx 的机器成本,在 2.0 版本中我们将证书挂载到服务上。
通过分析服务内存,如下图所示,TLS 握手过程中消耗的内存占了总内存消耗的大概 30% 左右。
这个部分的内存消耗无法避免,我们有两个选择:
对每次连接必须产生一个唯一码,如果出现重复会导致串号,消息混乱推送的问题。
这里,选择SnowFlake算法作为唯一码生成算法。
物理机场景中,对副本所在物理机进行固定编号,即可保证每个副本上的服务产生的 Socket ID 是唯一值。
K8S 场景中,这种方案不可行,于是采用注册下发的方式返回编号,WS-Gateway 所有副本启动后,向数据库写入服务的启动信息,获取副本编号,以此作为参数作为 SnowFlake 算法的副本编号进行 Socket ID 生产,服务重启会继承之前已有的副本编号,有新版本下发时会根据自增 ID 下发新的副本编号。
于此同时,Ws-Gateway 副本会向数据库写入心跳信息,以此作为网关服务本身的健康检查依据。
客户端完成握手流程后,会话数据在当前网关节点内存存储,部分可序列化数据存储到 Redis,
redis 会话存储结构说明如下图所示。
键 | 说明 |
---|---|
ws:user:clients:${uid} | 存储用户和 WebSocket 连接的关系,采用有序集合方式存储 |
ws:guid:clients:${guid} | 存储文件和 WebSocket 连接的关系,采用有序结合方式存储 |
ws:client:${socket.id} | 存储当前 WebSocket连接下的全部用户和文件关系数据,采用Redis Hash 方式进行存储,对应 key 为 user和guid |
由客户端触发或组件服务触发的消息推送,通过 Redis 存储的数据结构,在 WS-API 服务查询到返回消息体的目标客户端的 Socket ID,再由 WS-Gateway 服务进行集群消费。
如果 Socket ID 不在当前节点,则需要进行节点与会话关系的查询,找到客端户 Socket ID 实际对应的 WS-Gateway 节点,通常有以下两种方案(如下图所示)。
优点 | 缺点 | |
---|---|---|
事件广播 | 实现简单 | 消息广播数量会随着节点数量上升 |
注册中心 | 会话与节点映射关系清晰 | 注册中心强依赖,额外运维成本 |
在确定使用事件广播方式进行网关节点间的消息传递后,进一步选择使用哪种具体的消息中间件,列举了三种待选的方案(如下图所示)。
特性 | Redis | Kafka | RocketMQ |
---|---|---|---|
开发语言 | C | Scala | Java |
单机吞吐量 | 10w+ | 10w+ | 10w+ |
可用性 | 主从架构 | 分布式架构 | 分布式架构 |
特点 | 功能简单 | 吞吐量、可用性极高 | 功能丰富、定制化强,吞吐量可用性高 |
功能特性 | 数据10K 以内性能优异,功能简单,适用于简单业务场景 | 支持核心的 MQ 功能,不支持消息查询或消息回溯等功能 | 支持核心的 MQ 功能,扩展性强 |
于是对 Redis 和其他 MQ 中间件进行 100w 次的入队和出队操作,在测试过程中发现在数据小于 10K 时 Redis 性能表现十分优秀。
进一步结合实际情况:广播内容的数据量大小在 1K 左右,业务场景简单固定,并且要兼容历史业务逻辑,最后选择了 Redis 进行消息广播。
后续还可以将 WS-API 与 WS-Gateway 两两互联,使用 gRPC stream 双向流通信节省内网流量。
会话在节点内存与 Redis 中存储后,客户端需要通过心跳上报持续更新会话时间戳,客户端按照服务端下发的周期进行心跳上报,上报时间戳首先在内存进行更新,然后再通过另外的周期进行 Redis 同步,避免大量客户端同时进行心跳上报对 Redis 产生压力。
具体流程:
会话数据内存以及 Redis 缓存清理逻辑:
for {
select {
case <-t.C:
var now = time.Now().Unix()
var clients = make([]*Connection, 0)
dispatcher.clients.Range(func(_, v interface{}) bool {
client := v.(*Connection)
lastTs := atomic.LoadInt64(&client.LastMessageTS)
if now-lastTs > int64(expireTime) {
clients = append(clients, client)
} else {
dispatcher.clearRedisMapping(client.Id, client.Uid, lastTs, clearTimeout)
}
return true
})
for _, cli := range clients {
cli.WsClose()
}
}
}
在已有的两级缓存刷新机制上,进一步通过动态心跳上报频率的方式降低心跳上报产生的服务端性能压力,默认场景中客户端对服务端进行间隔 1s 的心跳上报,假设目前单机承载了 50w 的连接数,当前的 QPS 为:QPS1 = 500000/1。
从服务端性能优化的角度考虑,实现心跳正常情况下的动态间隔,每 x 次正常心跳上报,心跳间隔增加 a,增加上限为 y,动态 QPS 最小值为:QPS2=500000/y。
极限情况下,心跳产生的 QPS 降低 y 倍。在单次心跳超时后服务端立刻将 a 值变为 1s 进行重试。采用以上策略,在保证连接质量的同时,降低心跳对服务端产生的性能损耗。
使用 Kafka 自定义 Headers 的目的是避免网关层出现对消息体解码而带来的性能损耗。
客户端 WebSocket 连接建立成功后,会进行一系列的业务操作,我们选择将 WS-Gateway 和 WS-API 之间的操作指令和必要的参数放到 Kafka 的 Headers 中,例如通过 X-XX-Operator 为广播,再读取 X-XX-Guid 文件编号,对该文件内的所有用户进行消息推送。
字段 | 说明 | 描述 |
---|---|---|
X-ID | WebSocket ID | 连接 ID |
X-Uid | 用户 ID | 用户 ID |
X-Guid | 文件 ID | 文件 ID |
X-Inner | 网关内部操作指令 | 用户加入、用户退出 |
X-Event | 网关事件 | Connect/Message/Disconnect |
X-Locale | 语言类型设置 | 语言类型设置 |
X-Operator | api层操作指令 | 单播、广播、网关内部操作 |
X-Auth-Type | 用户鉴权类型 | SDKV2、主站、微信、移动端、桌面 |
X-Client-Version | 客户端版本 | 客户端版本 |
X-Server-Version | 网关版本 | 服务端版本 |
X-Push-Client-ID | 客户端 ID | 客户端 ID |
X-Trace-ID | 链路 ID | 链路 ID |
在 Kafka Headers 中写入了 trace id 和 时间戳,可以追中某条消息的完整消费链路以及各阶段的时间消耗。
type Packet struct {
...
}
type Connect struct {
*websocket.Con
send chan Packet
}
func NewConnect(conn net.Conn) *Connect {
c := &Connect{
send: make(chan Packet, N),
}
go c.reader()
go c.writer()
return c
}
客户端与服务端的消息交互第一版的写法类似以上写法。
对 Demo 进行压测,发现每个 WebSocket 连接都会占用 3 个 goroutine,每个 goroutine 都需要内存栈,单机承载连十分有限。
主要受制于大量的内存占用,而且大部分时间 c.writer() 是闲置状态,
于是考虑,是否只启用 2 个 goroutine 来完成交互。
type Packet struct {
...
}
type Connect struct {
*websocket.Conn
mux sync.RWMutex
}
func NewConnect(conn net.Conn) *Connect {
c := &Connect{
send: make(chan Packet, N),
}
go c.reader()
return c
}
func (c *Connect) Write(data []byte) (err error) {
c.mux.Lock()
defer c.mux.Unlock()
...
return nil
}
保留 c.reader() 的 goroutine,如果使用轮询方式从缓冲区读取数据,可能会产生读取延迟或者锁的问题,c.writer() 操作调整为主动调用,不采用启动 goroutine 持续监听,降低内存消耗。
调研了 gev 和 gnet 等基于事件驱动的轻量级高性能网络库,实测发现在大量连接场景下可能产生的消息延迟的问题,所以没有在生产环境下使用。
确定数据接收与发送逻辑后,网关部分的核心对象为 Connection 对象,围绕 Connection 进行了 run、read、write、close 等函数的开发。
使用 sync.pool 来缓存该对象,减轻 GC 压力,创建连接时,通过对象资源池获取 Connection 对象。
生命周期结束之后,重置 Connection 对象后 Put 回资源池。
在实际编码中,建议封装 GetConn()、PutConn() 函数,收敛数据初始化、对象重置等操作。
var ConnectionPool = sync.Pool{
New: func() interface{} {
return &Connection{}
},
}
func GetConn() *Connection {
cli := ConnectionPool.Get().(*Connection)
return cli
}
func PutConn(cli *Connection) {
cli.Reset()
ConnectionPool.Put(cli) // 放回连接池
}
消息流转过程中,需要考虑消息体的传输效率优化,采用 MessagePack 对消息体进行序列化,压缩消息体大小。调整 MTU 值避免出现分包情况,定义 a 为探测包大小,通过如下指令,对目标服务 ip 进行 MTU 极限值探测。
ping -s {a} {ip}
a = 1400 时,实际传输包大小为:1428。
其中 28 由 8(ICMP 回显请求和回显应答报文格式)和 20(IP 首部)构成。
如果 a 设置过大会导致应答超时,在实际环境包大小超过该值时会出现分包的情况。
在调试合适的 MTU 值的同时通过 MessagePack 对消息体进行序列号,进一步压缩数据包的大小,并减小 CPU 的消耗。
使用EGO框架进行服务开发:业务日志打印,异步日志输出,动态日志级别调整等功能,方便线上问题排查提升日志打印效率;微服务监控体系,CPU、P99、内存、goroutine 等监控。
客户端 Redis 监控:
客户端 Kafka 监控:
自定义监控大盘:
准备的测试平台有:
用户上线,50w 在线用户。
服务 | CPU | Memory | 数量 | CPU% | Mem% |
---|---|---|---|---|---|
WS-Gateway | 16核 | 32G | 1台 | 22.38% | 70.59% |
单个 WS-Gateway 每秒建立连接数峰值为:1.6w 个/s,每个用户占用内存:47K。
测试时间 15 分钟,在线用户 50w,每 5s 推送一条所有用户,用户有回执。
推送内容为:
42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"[email protected]","avatar":"ZgG5kEjCkT6mZla6.png","created_at":1623811084000,"name_pinyin":"","team_id":13,"team_role":"member","merged_into":0,"team_time":1623811084000,"mobile":"+xxxx","mobile_account":"","status":1,"has_password":true,"team":null,"membership":null,"is_seat":true,"team_role_enum":3,"register_time":1623811084000,"alias":"","type":"anoymous"}],"userCount":1,"from":"ws"}}]
测试经过 5 分钟后,服务异常重启,重启原因是内存使用量到超过限制。
分析内存超过限制的原因:
新增的广播代码用掉了 9.32% 的内存:
接收用户回执消息的部分消耗了 10.38% 的内存:
进行测试规则调整,测试时间 15 分钟,在线用户 48w,每 5s 推送一条所有用户,用户有回执。
推送内容为:
42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"[email protected]","avatar":"ZgG5kEjCkT6mZla6.png","created_at":1623811084000,"name_pinyin":"","team_id":13,"team_role":"member","merged_into":0,"team_time":1623811084000,"mobile":"+xxxx","mobile_account":"","status":1,"has_password":true,"team":null,"membership":null,"is_seat":true,"team_role_enum":3,"register_time":1623811084000,"alias":"","type":"anoymous"}],"userCount":1,"from":"ws"}}]
服务 | CPU | Memory | 数量 | CPU% | Mem% |
---|---|---|---|---|---|
WS-Gateway | 16核 | 32G | 1台 | 44% | 91.75% |
连接数建立峰值:1w 个/s,接收数据峰值:9.6w 条/s,发送数据峰值 9.6w 条/s。
测试时间 15 分钟,在线用户 50w,每 5s 推送一条所有用户,用户无需回执。
推送内容为:
42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"[email protected]","avatar":"ZgG5kEjCkT6mZla6.png","created_at":1623811084000,"name_pinyin":"","team_id":13,"team_role":"member","merged_into":0,"team_time":1623811084000,"mobile":"+xxxx","mobile_account":"","status":1,"has_password":true,"team":null,"membership":null,"is_seat":true,"team_role_enum":3,"register_time":1623811084000,"alias":"","type":"anoymous"}],"userCount":1,"from":"ws"}}]
服务 | CPU | Memory | 数量 | CPU% | Mem% |
---|---|---|---|---|---|
WS-Gateway | 16核 | 32G | 1台 | 30% | 93% |
连接数建立峰值:1.1w 个/s,发送数据峰值 10w 条/s,出内存占用过高之外,其他没有异常情况。
内存消耗极高,分析火焰图,大部分消耗在定时 5s 进行广播的操作上。
测试时间 15 分钟,在线用户 50w,每 5s 推送一条所有用户,用户有回执。每秒 4w 用户上下线。
推送内容为:
42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"[email protected]","avatar":"ZgG5kEjCkT6mZla6.png","created_at":1623811084000,"name_pinyin":"","team_id":13,"team_role":"member","merged_into":0,"team_time":1623811084000,"mobile":"+xxxx","mobile_account":"","status":1,"has_password":true,"team":null,"membership":null,"is_seat":true,"team_role_enum":3,"register_time":1623811084000,"alias":"","type":"anoymous"}],"userCount":1,"from":"ws"}}]
服务 | CPU | Memory | 数量 | CPU% | Mem% |
---|---|---|---|---|---|
WS-Gateway | 16核 | 32G | 1台 | 46.96% | 65.6% |
连接数建立峰值:18570 个/s,接收数据峰值:329949 条/s,发送数据峰值:393542 条/s,未出现异常情况。
在16核32G内存的硬件条件下:单机 50w 连接数,进行以上包括用户上下线、消息回执等四个场景的压测,内存和 CPU 消耗都符合预期,并且在较长时间的压测下,服务也很稳定。
测试的结果基本上是能满足目前量级下的资源节约要求的,我们认为完全可以在此基础上继续完善功能开发。
面临日益增加的用户量,网关服务的重构是势在必行。
本次重构主要是:
2.0 版本的长连接网关有了更少的资源消耗,更低的单位用户内存损耗、更加完善的监控报警体系,让网关服务本身更加可靠。
以上优化内容主要是以下各个方面:
在保证网关服务性能过关的同时,更进一步的是收敛底层组件服务对网关业务调用的方式,从以前的 HTTP、Redis、Kafka 等方式,统一为 gRPC 调用,保证了来源可查可控,为后续业务接入打下了更好的基础。
架构之路,充满了坎坷
架构和高级开发不一样 , 架构问题是open/开放式的,架构问题是没有标准答案的
正由于这样,很多小伙伴,尽管耗费很多精力,耗费很多金钱,但是,遗憾的是,一生都没有完成架构升级。
所以,在架构升级/转型过程中,确实找不到有效的方案,可以来找40岁老架构尼恩求助.
前段时间一个小伙伴,他是跨专业来做Java,现在面临转架构的难题,但是经过尼恩几轮指导,顺利拿到了Java架构师+大数据架构师offer 。所以,如果遇到职业不顺,找老架构师帮忙一下,就顺利多了。
《百亿级访问量,如何做缓存架构设计》
《多级缓存 架构设计》
《消息推送 架构设计》
《阿里2面:你们部署多少节点?1000W并发,当如何部署?》
《美团2面:5个9高可用99.999%,如何实现?》
《网易一面:单节点2000Wtps,Kafka怎么做的?》
《字节一面:事务补偿和事务重试,关系是什么?》
《网易一面:25Wqps高吞吐写Mysql,100W数据4秒写完,如何实现?》
《亿级短视频,如何架构?》
《炸裂,靠“吹牛”过京东一面,月薪40K》
《太猛了,靠“吹牛”过顺丰一面,月薪30K》
《炸裂了…京东一面索命40问,过了就50W+》
《问麻了…阿里一面索命27问,过了就60W+》
《百度狂问3小时,大厂offer到手,小伙真狠!》
《饿了么太狠:面个高级Java,抖这多硬活、狠活》
《字节狂问一小时,小伙offer到手,太狠了!》
《收个滴滴Offer:从小伙三面经历,看看需要学点啥?》
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF,请到下面公号【技术自由圈】取↓↓↓