引言

 

网关 1.0

 

网关 1.0 是使用 Node.js 基于 Socket.IO 进行修改开发的版本，很好的满足了当时用户量级下的业务场景需求。

架构

网关 1.0 版本架构设计图：

网关 1.0 客户端连接流程：

1. 用户通过 Nginx 连接网关，该操作被业务服务感知；

2. 业务服务感知到用户连接后，会进行相关用户数据查询，再将消息 Pub 到 Redis；

3. 网关服务通过 Redis Sub 收到消息；

4. 查询网关集群中的用户会话数据，向客户端进行消息推送。

 

痛点

虽然 1.0 版本的网关在线上运行良好，但是不能很好的支持后续业务的扩展，并且有以下几个问题需要解决：

• 资源消耗：Nginx 仅使用 TLS 解密，请求透传，产生了大量的资源浪费，同时之前的 Node 网关性能不好，消耗大量的 CPU、内存。

• 维护与观测：未接入石墨的监控体系，无法和现有监控告警联通，维护上存在一定的困难；

• 业务耦合问题：业务服务与网关功能被集成到了同一个服务中，无法针对业务部分性能损耗进行针对性水平扩容，为了解决性能问题，以及后续的模块扩展能力，都需要进行服务解耦。

网关 2.0

 

网关 2.0 需要解决很多问题：石墨文档内部有很多组件：文档、表格、幻灯片和表单等等。在 1.0 版本中组件对网关的业务调用可以通过：Redis、Kafka 和 HTTP 接口，来源不可查，管控困难。此外，从性能优化的角度考虑也需要对原有服务进行解耦合，将 1.0 版本网关拆分为网关功能部分和业务处理部分，网关功能部分为 WS-Gateway：集成用户鉴权、TLS 证书验证和 WebSocket 连接管理等；业务处理部分为 WS-API：组件服务直接与该服务进行 gRPC 通信。可针对具体的模块进行针对性扩容；服务重构加上 Nginx 移除，整体硬件消耗显著降低；服务整合到石墨监控体系。

整体架构

网关 2.0 版本架构设计图：

网关 2.0 客户端连接流程：

1. 客户端与 WS-Gateway 服务通过握手流程建立 WebSocket 连接；

2. 连接建立成功后，WS-Gateway 服务将会话进行节点存储，将连接信息映射关系缓存到 Redis 中，并通过 Kafka 向 WS-API 推送客户端上线消息；

3. WS-API 通过 Kafka 接收客户端上线消息及客户端上行消息；

4. WS-API 服务预处理及组装消息，包括从 Redis 获取消息推送的必要数据，并进行完成消息推送的过滤逻辑，然后 Pub 消息到 Kafka；

5. WS-Gateway 通过 Sub Kafka 来获取服务端需要返回的消息，逐个推送消息至客户端。

 

握手流程

网络状态良好的情况下，完成如下图所示步骤 1 到步骤 6 之后，直接进入 WebSocket 流程；网络环境较差的情况下，WebSocket 的通信模式会退化成 HTTP 方式，客户端通过 POST 方式推送消息到服务端，再通过 GET 长轮询的方式从读取服务端返回数据。客户端初次请求服务端连接建立的握手流程：

1、Client 发送 GET 请求尝试建立连接；

2、Server 返回相关连接数据，sid 为本次连接产生的唯一 Socket ID，后续交互作为凭证；

{“sid”:“xxx”,“upgrades”:[“websocket”],“pingInterval”:xxx,“pingTimeout”:xxx}

3、Client 携带步骤 2 中的 sid 参数再次请求；

4、Server 返回 40，表示请求接收成功；

5、Client 发送 POST 请求确认后期降级通路情况；

6、Server 返回 ok，此时第一阶段握手流程完成；

7、尝试发起 WebSocket 连接，首先进行 2probe 和 3probe 的请求响应，确认通信通道畅通后，即可进行正常的 WebSocket 通信。

TLS 内存消耗优化

客户端与服务端连接建立采用的 WSS 协议，在 1.0 版本中 TLS 证书挂载在 Nginx 上，HTTPS 握手过程由 Nginx 完成，为了降低 Nginx 的机器成本，在 2.0 版本中我们将证书挂载到服务上，通过分析服务内存，如下图所示，TLS 握手过程中消耗的内存占了总内存消耗的大概 30% 左右。

这个部分的内存消耗无法避免，我们有两个选择：

• 采用七层负载均衡，在七层负载上进行 TLS 证书挂载，将 TLS 握手过程移交给性能更好的工具完成；

• 优化 Go 对 TLS 握手过程性能，在与业内大佬曹春晖（曹大）的交流中了解到，他最近在 Go 官方库提交的 PR https://github.com/golang/go/issues/43563 ，以及相关的性能测试数据 https://github.com/golang/go/pull/48229 。

 

Socket ID 设计

对每次连接必须产生一个唯一码，如果出现重复会导致串号，消息混乱推送的问题。选择 SnowFlake 算法作为唯一码生成算法。

物理机场景中，对副本所在物理机进行固定编号，即可保证每个副本上的服务产生的 Socket ID 是唯一值。

Kubernetes 场景中，这种方案不可行，于是采用注册下发的方式返回编号，WS-Gateway 所有副本启动后向数据库写入服务的启动信息，获取副本编号，以此作为参数作为 SnowFlake 算法的副本编号进行 Socket ID 生产，服务重启会继承之前已有的副本编号，有新版本下发时会根据自增 ID 下发新的副本编号。于此同时，Ws-Gateway 副本会向数据库写入心跳信息，以此作为网关服务本身的健康检查依据。

集群会话管理方案：事件广播

客户端完成握手流程后，会话数据在当前网关节点内存存储，部分可序列化数据存储到 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()
}
}
}

在 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
}

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
}

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) // 放回连接池
}

ping -s {a} {ip}

a = 1400 时，实际传输包大小为：1428。其中 28 由 8（ICMP 回显请求和回显应答报文格式）和 20（IP 首部）构成。

如果 a 设置过大会导致应答超时，在实际环境包大小超过该值时会出现分包的情况。

在调试合适的 MTU 值的同时通过 MessagePack 对消息体进行序列号，进一步压缩数据包的大小，并减小 CPU 的消耗。

基础设施支持

使用 EGO 框架（https://github.com/gotomicro/ego）进行服务开发：业务日志打印，异步日志输出，动态日志级别调整等功能，方便线上问题排查提升日志打印效率；微服务监控体系，CPU、P99、内存、goroutine 等监控。

客户端 Redis 监控：

客户端 Kafka 监控：

自定义监控大盘：

性能压测

 

测试经过 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”}}]

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”}}]

连接数建立峰值：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”}}]

连接数建立峰值：18570 个/s，接收数据峰值：329949 条/s，发送数据峰值 393542 条/s，未出现异常情况。

压测总结

在 16C 32G 内存的硬件条件下，单机 50w 连接数，进行以上包括用户上下线、消息回执等四个场景的压测，内存和 CPU 消耗都符合预期，并且在较长时间的压测下，服务也很稳定。满足目前量级下的资源节约要求，可在此基础上继续完善功能开发。

总结