1 引言

在石墨文檔的部分業(yè)務(wù)中，例如文檔分享、評(píng)論、幻燈片演示和文檔表格跟隨等場(chǎng)景，涉及到多客戶(hù)端數(shù)據(jù)同步和服務(wù)端批量數(shù)據(jù)推送的需求，一般的 HTTP 協(xié)議無(wú)法滿(mǎn)足服務(wù)端主動(dòng) Push 數(shù)據(jù)的場(chǎng)景，因此選擇采用 WebSocket 方案進(jìn)行業(yè)務(wù)開(kāi)發(fā)。

隨著石墨文檔業(yè)務(wù)發(fā)展，目前日連接峰值已達(dá)百萬(wàn)量級(jí)，日益增長(zhǎng)的用戶(hù)連接數(shù)和不符合目前量級(jí)的架構(gòu)設(shè)計(jì)導(dǎo)致了內(nèi)存和 CPU 使用量急劇增長(zhǎng)，因此我們考慮對(duì)網(wǎng)關(guān)進(jìn)行重構(gòu)。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

2 網(wǎng)關(guān) 1.0

網(wǎng)關(guān) 1.0 是使用 Node.js 基于 Socket.IO 進(jìn)行修改開(kāi)發(fā)的版本，很好的滿(mǎn)足了當(dāng)時(shí)用戶(hù)量級(jí)下的業(yè)務(wù)場(chǎng)景需求。

2.1 架構(gòu)

網(wǎng)關(guān) 1.0 版本架構(gòu)設(shè)計(jì)圖：

網(wǎng)關(guān) 1.0 客戶(hù)端連接流程：

1. 用戶(hù)通過(guò) NGINX 連接網(wǎng)關(guān)，該操作被業(yè)務(wù)服務(wù)感知；
2. 業(yè)務(wù)服務(wù)感知到用戶(hù)連接后，會(huì)進(jìn)行相關(guān)用戶(hù)數(shù)據(jù)查詢(xún)，再將消息 Pub 到 Redis；
3. 網(wǎng)關(guān)服務(wù)通過(guò) Redis Sub 收到消息；
4. 查詢(xún)網(wǎng)關(guān)集群中的用戶(hù)會(huì)話(huà)數(shù)據(jù)，向客戶(hù)端進(jìn)行消息推送。

2.2 痛點(diǎn)

雖然 1.0 版本的網(wǎng)關(guān)在線(xiàn)上運(yùn)行良好，但是不能很好的支持后續(xù)業(yè)務(wù)的擴(kuò)展，并且有以下幾個(gè)問(wèn)題需要解決：

• 資源消耗：Nginx 僅使用 TLS 解密，請(qǐng)求透?jìng)?，產(chǎn)生了大量的資源浪費(fèi)，同時(shí)之前的 Node 網(wǎng)關(guān)性能不好，消耗大量的 CPU、內(nèi)存。
• 維護(hù)與觀測(cè)：未接入石墨的監(jiān)控體系，無(wú)法和現(xiàn)有監(jiān)控告警聯(lián)通，維護(hù)上存在一定的困難；
• 業(yè)務(wù)耦合問(wèn)題：業(yè)務(wù)服務(wù)與網(wǎng)關(guān)功能被集成到了同一個(gè)服務(wù)中，無(wú)法針對(duì)業(yè)務(wù)部分性能損耗進(jìn)行針對(duì)性水平擴(kuò)容，為了解決性能問(wèn)題，以及后續(xù)的模塊擴(kuò)展能力，都需要進(jìn)行服務(wù)解耦。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

3 網(wǎng)關(guān) 2.0

網(wǎng)關(guān) 2.0 需要解決很多問(wèn)題：石墨文檔內(nèi)部有很多組件：文檔、表格、幻燈片和表單等等。在 1.0 版本中組件對(duì)網(wǎng)關(guān)的業(yè)務(wù)調(diào)用可以通過(guò)：Redis、Kafka 和 HTTP 接口，來(lái)源不可查，管控困難。此外，從性能優(yōu)化的角度考慮也需要對(duì)原有服務(wù)進(jìn)行解耦合，將 1.0 版本網(wǎng)關(guān)拆分為網(wǎng)關(guān)功能部分和業(yè)務(wù)處理部分，網(wǎng)關(guān)功能部分為 WS-Gateway：集成用戶(hù)鑒權(quán)、TLS 證書(shū)驗(yàn)證和 WebSocket 連接管理等；業(yè)務(wù)處理部分為 WS-API：組件服務(wù)直接與該服務(wù)進(jìn)行 gRPC 通信?？舍槍?duì)具體的模塊進(jìn)行針對(duì)性擴(kuò)容；服務(wù)重構(gòu)加上 Nginx 移除，整體硬件消耗顯著降低；服務(wù)整合到石墨監(jiān)控體系。

3.1 整體架構(gòu)

網(wǎng)關(guān) 2.0 版本架構(gòu)設(shè)計(jì)圖：

網(wǎng)關(guān) 2.0 客戶(hù)端連接流程：

1. 客戶(hù)端與 WS-Gateway 服務(wù)通過(guò)握手流程建立 WebSocket 連接；
2. 連接建立成功后，WS-Gateway 服務(wù)將會(huì)話(huà)進(jìn)行節(jié)點(diǎn)存儲(chǔ)，將連接信息映射關(guān)系緩存到 Redis 中，并通過(guò) Kafka 向 WS-API 推送客戶(hù)端上線(xiàn)消息；
3. WS-API 通過(guò) Kafka 接收客戶(hù)端上線(xiàn)消息及客戶(hù)端上行消息；
4. WS-API 服務(wù)預(yù)處理及組裝消息，包括從 Redis 獲取消息推送的必要數(shù)據(jù)，并進(jìn)行完成消息推送的過(guò)濾邏輯，然后 Pub 消息到 Kafka；
5. WS-Gateway 通過(guò) Sub Kafka 來(lái)獲取服務(wù)端需要返回的消息，逐個(gè)推送消息至客戶(hù)端。

3.2 握手流程

網(wǎng)絡(luò)狀態(tài)良好的情況下，完成如下圖所示步驟 1 到步驟 6 之后，直接進(jìn)入 WebSocket 流程；網(wǎng)絡(luò)環(huán)境較差的情況下，WebSocket 的通信模式會(huì)退化成 HTTP 方式，客戶(hù)端通過(guò) POST 方式推送消息到服務(wù)端，再通過(guò) GET 長(zhǎng)輪詢(xún)的方式從讀取服務(wù)端返回?cái)?shù)據(jù)。客戶(hù)端初次請(qǐng)求服務(wù)端連接建立的握手流程：

1. Client 發(fā)送 GET 請(qǐng)求嘗試建立連接；
2. Server 返回相關(guān)連接數(shù)據(jù)，sid 為本次連接產(chǎn)生的唯一 Socket ID，后續(xù)交互作為憑證；

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

1. Client 攜帶步驟 2 中的 sid 參數(shù)再次請(qǐng)求；
2. Server 返回 40，表示請(qǐng)求接收成功；
3. Client 發(fā)送 POST 請(qǐng)求確認(rèn)后期降級(jí)通路情況；
4. Server 返回 ok，此時(shí)第一階段握手流程完成；
5. 嘗試發(fā)起 WebSocket 連接，首先進(jìn)行 2probe 和 3probe 的請(qǐng)求響應(yīng)，確認(rèn)通信通道暢通后，即可進(jìn)行正常的 WebSocket 通信。

3.3 TLS 內(nèi)存消耗優(yōu)化

客戶(hù)端與服務(wù)端連接建立采用的 wss 協(xié)議，在 1.0 版本中 TLS 證書(shū)掛載在 Nginx 上，HTTPS 握手過(guò)程由 Nginx 完成，為了降低 Nginx 的機(jī)器成本，在 2.0 版本中我們將證書(shū)掛載到服務(wù)上，通過(guò)分析服務(wù)內(nèi)存，如下圖所示，TLS 握手過(guò)程中消耗的內(nèi)存占了總內(nèi)存消耗的大概 30% 左右。

這個(gè)部分的內(nèi)存消耗無(wú)法避免，我們有兩個(gè)選擇：

• 采用七層負(fù)載均衡，在七層負(fù)載上進(jìn)行 TLS 證書(shū)掛載，將 TLS 握手過(guò)程移交給性能更好的工具完成；
• 優(yōu)化 Go 對(duì) TLS 握手過(guò)程性能，在與業(yè)內(nèi)大佬曹春暉（曹大）的交流中了解到，他最近在 Go 官方庫(kù)提交的 PR https://github.com/golang/go/issues/43563 ，以及相關(guān)的性能測(cè)試數(shù)據(jù) https://github.com/golang/go/pull/48229 。

3.4 Socket ID 設(shè)計(jì)

對(duì)每次連接必須產(chǎn)生一個(gè)唯一碼，如果出現(xiàn)重復(fù)會(huì)導(dǎo)致串號(hào)，消息混亂推送的問(wèn)題。選擇 SnowFlake 算法作為唯一碼生成算法。

物理機(jī)場(chǎng)景中，對(duì)副本所在物理機(jī)進(jìn)行固定編號(hào)，即可保證每個(gè)副本上的服務(wù)產(chǎn)生的 Socket ID 是唯一值。

K8S 場(chǎng)景中，這種方案不可行，于是采用注冊(cè)下發(fā)的方式返回編號(hào)，WS-Gateway 所有副本啟動(dòng)后向數(shù)據(jù)庫(kù)寫(xiě)入服務(wù)的啟動(dòng)信息，獲取副本編號(hào)，以此作為參數(shù)作為 SnowFlake 算法的副本編號(hào)進(jìn)行 Socket ID 生產(chǎn)，服務(wù)重啟會(huì)繼承之前已有的副本編號(hào)，有新版本下發(fā)時(shí)會(huì)根據(jù)自增 ID 下發(fā)新的副本編號(hào)。于此同時(shí)，Ws-Gateway 副本會(huì)向數(shù)據(jù)庫(kù)寫(xiě)入心跳信息，以此作為網(wǎng)關(guān)服務(wù)本身的健康檢查依據(jù)。

3.5 集群會(huì)話(huà)管理方案：事件廣播

客戶(hù)端完成握手流程后，會(huì)話(huà)數(shù)據(jù)在當(dāng)前網(wǎng)關(guān)節(jié)點(diǎn)內(nèi)存存儲(chǔ)，部分可序列化數(shù)據(jù)存儲(chǔ)到 Redis，存儲(chǔ)結(jié)構(gòu)說(shuō)明如下：

鍵	說(shuō)明
wsclients:${uid}	存儲(chǔ)用戶(hù)和 WebSocket 連接的關(guān)系，采用有序集合方式存儲(chǔ)
wsclients:${guid}	存儲(chǔ)文件和 WebSocket 連接的關(guān)系，采用有序結(jié)合方式存儲(chǔ)
ws${socket.id}	存儲(chǔ)當(dāng)前 WebSocket 連接下的全部用戶(hù)和文件關(guān)系數(shù)據(jù)，采用 Redis Hash 方式進(jìn)行存儲(chǔ)，對(duì)應(yīng) key 為 user 和 guid

由客戶(hù)端觸發(fā)或組件服務(wù)觸發(fā)的消息推送，通過(guò) Redis 存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)，在 WS-API 服務(wù)查詢(xún)到返回消息體的目標(biāo)客戶(hù)端的 Socket ID，再有 WS-Gateway 服務(wù)進(jìn)行集群消費(fèi)，如果 Socket ID 不在當(dāng)前節(jié)點(diǎn)，則需要進(jìn)行節(jié)點(diǎn)與會(huì)話(huà)關(guān)系的查詢(xún)，找到客端戶(hù) Socket ID 實(shí)際對(duì)應(yīng)的 WS-Gateway 節(jié)點(diǎn)，通常有以下兩種方案：

	優(yōu)點(diǎn)	缺點(diǎn)
事件廣播	實(shí)現(xiàn)簡(jiǎn)單	消息廣播數(shù)量會(huì)隨著節(jié)點(diǎn)數(shù)量上升
注冊(cè)中心	會(huì)話(huà)與節(jié)點(diǎn)映射關(guān)系清晰	注冊(cè)中心強(qiáng)依賴(lài)，額外運(yùn)維成本

在確定使用事件廣播方式進(jìn)行網(wǎng)關(guān)節(jié)點(diǎn)間的消息傳遞后，進(jìn)一步選擇使用哪種具體的消息中間件，列舉了三種待選的方案：

特性	Redis	Kafka	RocKetMQ
開(kāi)發(fā)語(yǔ)言	C	Scala	Java
單機(jī)吞吐量	10w+	10w+	10w+
可用性	主從架構(gòu)	分布式架構(gòu)	分布式架構(gòu)
特點(diǎn)	功能簡(jiǎn)單	吞吐量、可用性極高	功能豐富、定制化強(qiáng)，吞吐量、可用性高
功能特性	數(shù)據(jù) 10K 以?xún)?nèi)性能優(yōu)異，功能簡(jiǎn)單，適用于簡(jiǎn)單業(yè)務(wù)場(chǎng)景	支持核心的 MQ 功能，不支持消息查詢(xún)或消息回溯等功能	支持核心的 MQ 功能，擴(kuò)展性強(qiáng)

于是對(duì) Redis 和其他 MQ 中間件進(jìn)行 100w 次的入隊(duì)和出隊(duì)操作，在測(cè)試過(guò)程中發(fā)現(xiàn)在數(shù)據(jù)小于 10K 時(shí) Redis 性能表現(xiàn)十分優(yōu)秀，進(jìn)一步結(jié)合實(shí)際情況：廣播內(nèi)容的數(shù)據(jù)量大小在 1K 左右，業(yè)務(wù)場(chǎng)景簡(jiǎn)單固定，并且要兼容歷史業(yè)務(wù)邏輯，最后選擇了 Redis 進(jìn)行消息廣播。

后續(xù)還可以將 WS-API 與 WS-Gateway 兩兩互聯(lián)，使用 gRPC stream 雙向流通信節(jié)省內(nèi)網(wǎng)流量。

3.6 心跳機(jī)制

會(huì)話(huà)在節(jié)點(diǎn)內(nèi)存與 Redis 中存儲(chǔ)后，客戶(hù)端需要通過(guò)心跳上報(bào)持續(xù)更新會(huì)話(huà)時(shí)間戳，客戶(hù)端按照服務(wù)端下發(fā)的周期進(jìn)行心跳上報(bào)，上報(bào)時(shí)間戳首先在內(nèi)存進(jìn)行更新，然后再通過(guò)另外的周期進(jìn)行 Redis 同步，避免大量客戶(hù)端同時(shí)進(jìn)行心跳上報(bào)對(duì) Redis 產(chǎn)生壓力。

1. 客戶(hù)端建立 WebSocket 連接成功后，服務(wù)端下發(fā)心跳上報(bào)參數(shù)；
2. 客戶(hù)端依據(jù)以上參數(shù)進(jìn)行心跳包傳輸，服務(wù)端收到心跳后會(huì)更新會(huì)話(huà)時(shí)間戳；
3. 客戶(hù)端其他上行數(shù)據(jù)都會(huì)觸發(fā)對(duì)應(yīng)會(huì)話(huà)時(shí)間戳更新；
4. 服務(wù)端定時(shí)清理超時(shí)會(huì)話(huà)，執(zhí)行主動(dòng)關(guān)閉流程；
5. 通過(guò) Redis 更新的時(shí)間戳數(shù)據(jù)進(jìn)行 WebSocket 連接、用戶(hù)和文件之間的關(guān)系進(jìn)行清理。會(huì)話(huà)數(shù)據(jù)內(nèi)存以及 Redis 緩存清理邏輯：

for{
select{
case<-t.C:
????????varnow=time.Now().Unix()
varclients=make([]*Connection,0)
dispatcher.clients.Range(func(_,vinterface{})bool{
client:=v.(*Connection)
lastTs:=atomic.LoadInt64(&client.LastMessageTS)
ifnow-lastTs>int64(expireTime){
clients=append(clients,client)
}else{
dispatcher.clearRedisMapping(client.Id,client.Uid,lastTs,clearTimeout)
}
returntrue
})
for_,cli:=rangeclients{
cli.WsClose()
}
}
}

在已有的兩級(jí)緩存刷新機(jī)制上，進(jìn)一步通過(guò)動(dòng)態(tài)心跳上報(bào)頻率的方式降低心跳上報(bào)產(chǎn)生的服務(wù)端性能壓力，默認(rèn)場(chǎng)景中客戶(hù)端對(duì)服務(wù)端進(jìn)行間隔 1s 的心跳上報(bào)，假設(shè)目前單機(jī)承載了 50w 的連接數(shù)，當(dāng)前的 QPS 為：QPS1 = 500000/1

從服務(wù)端性能優(yōu)化的角度考慮，實(shí)現(xiàn)心跳正常情況下的動(dòng)態(tài)間隔，每 x 次正常心跳上報(bào)，心跳間隔增加 a，增加上限為 y，動(dòng)態(tài) QPS 最小值為：QPS2=500000/y

極限情況下，心跳產(chǎn)生的 QPS 降低 y 倍。在單次心跳超時(shí)后服務(wù)端立刻將 a 值變?yōu)?1s 進(jìn)行重試。采用以上策略，在保證連接質(zhì)量的同時(shí)，降低心跳對(duì)服務(wù)端產(chǎn)生的性能損耗。

3.7 自定義 Headers

使用 Kafka 自定義 Headers 的目的是避免網(wǎng)關(guān)層出現(xiàn)對(duì)消息體解碼而帶來(lái)的性能損耗，客戶(hù)端 WebSocket 連接建立成功后，會(huì)進(jìn)行一系列的業(yè)務(wù)操作，我們選擇將 WS-Gateway 和 WS-API 之間的操作指令和必要的參數(shù)放到 Kafka 的 Headers 中，例如通過(guò) X-XX-Operator 為廣播，再讀取 X-XX-Guid 文件編號(hào)，對(duì)該文件內(nèi)的所有用戶(hù)進(jìn)行消息推送。

字段	說(shuō)明	描述
X-ID	WebSocket ID	連接 ID
X-Uid	用戶(hù) ID	用戶(hù) ID
X-Guid	文件 ID	文件 ID
X-Inner	網(wǎng)關(guān)內(nèi)部操作指令	用戶(hù)加入、用戶(hù)退出
X-Event	網(wǎng)關(guān)事件	Connect/Message/Disconnect
X-Locale	語(yǔ)言類(lèi)型設(shè)置	語(yǔ)言類(lèi)型設(shè)置
X-Operator	api 層操作指令	單播、廣播、網(wǎng)關(guān)內(nèi)部操作
X-Auth-Type	用戶(hù)鑒權(quán)類(lèi)型	SDKV2、主站、微信、移動(dòng)端、桌面
X-Client-Version	客戶(hù)端版本	客戶(hù)端版本
X-Server-Version	網(wǎng)關(guān)版本	服務(wù)端版本
X-Push-Client-ID	客戶(hù)端 ID	客戶(hù)端 ID
X-Trace-ID	鏈路 ID	鏈路 ID

在 Kafka Headers 中寫(xiě)入了 trace id 和 時(shí)間戳，可以追中某條消息的完整消費(fèi)鏈路以及各階段的時(shí)間消耗。

3.8 消息接收與發(fā)送

typePacketstruct{
...
}

typeConnectstruct{
*websocket.Con
sendchanPacket
}

funcNewConnect(connnet.Conn)*Connect{
c:=&Connect{
send:make(chanPacket,N),
}
goc.reader()
goc.writer()
returnc
}

客戶(hù)端與服務(wù)端的消息交互第一版的寫(xiě)法類(lèi)似以上寫(xiě)法，對(duì) Demo 進(jìn)行壓測(cè)，發(fā)現(xiàn)每個(gè) WebSocket 連接都會(huì)占用 3 個(gè) goroutine，每個(gè) goroutine 都需要內(nèi)存棧，單機(jī)承載連十分有限，主要受制于大量的內(nèi)存占用，而且大部分時(shí)間 c.writer() 是閑置狀態(tài)，于是考慮，是否只啟用 2 個(gè) goroutine 來(lái)完成交互。

typePacketstruct{
...
}

typeConnectstruct{
*websocket.Conn
muxsync.RWMutex
}

funcNewConnect(connnet.Conn)*Connect{
c:=&Connect{
send:make(chanPacket,N),
}
goc.reader()
returnc
}

func(c*Connect)Write(data[]byte)(errerror){
c.mux.Lock()
deferc.mux.Unlock()
...
returnnil
}

保留 c.reader() 的 goroutine，如果使用輪詢(xún)方式從緩沖區(qū)讀取數(shù)據(jù)，可能會(huì)產(chǎn)生讀取延遲或者鎖的問(wèn)題，c.writer() 操作調(diào)整為主動(dòng)調(diào)用，不采用啟動(dòng) goroutine 持續(xù)監(jiān)聽(tīng)，降低內(nèi)存消耗。

調(diào)研了 gev 和 gnet 等基于事件驅(qū)動(dòng)的輕量級(jí)高性能網(wǎng)絡(luò)庫(kù)，實(shí)測(cè)發(fā)現(xiàn)在大量連接場(chǎng)景下可能產(chǎn)生的消息延遲的問(wèn)題，所以沒(méi)有在生產(chǎn)環(huán)境下使用。

3.9 核心對(duì)象緩存

確定數(shù)據(jù)接收與發(fā)送邏輯后，網(wǎng)關(guān)部分的核心對(duì)象為 Connection 對(duì)象，圍繞 Connection 進(jìn)行了 run、read、write、close 等函數(shù)的開(kāi)發(fā)。使用 sync.pool 來(lái)緩存該對(duì)象，減輕 GC 壓力，創(chuàng)建連接時(shí)，通過(guò)對(duì)象資源池獲取 Connection 對(duì)象，生命周期結(jié)束之后，重置 Connection 對(duì)象后 Put 回資源池。在實(shí)際編碼中，建議封裝 GetConn()、PutConn() 函數(shù)，收斂數(shù)據(jù)初始化、對(duì)象重置等操作。

varConnectionPool=sync.Pool{
New:func()interface{}{
return&Connection{}
},
}

funcGetConn()*Connection{
cli:=ConnectionPool.Get().(*Connection)
returncli
}

funcPutConn(cli*Connection){
cli.Reset()
ConnectionPool.Put(cli)//放回連接池
}

3.10 數(shù)據(jù)傳輸過(guò)程優(yōu)化

消息流轉(zhuǎn)過(guò)程中，需要考慮消息體的傳輸效率優(yōu)化，采用 MessagePack 對(duì)消息體進(jìn)行序列化，壓縮消息體大小。調(diào)整 MTU 值避免出現(xiàn)分包情況，定義 a 為探測(cè)包大小，通過(guò)如下指令，對(duì)目標(biāo)服務(wù) ip 進(jìn)行 MTU 極限值探測(cè)。

ping-s{a}{ip}

a = 1400 時(shí)，實(shí)際傳輸包大小為：1428。其中 28 由 8（ICMP 回顯請(qǐng)求和回顯應(yīng)答報(bào)文格式）和 20（IP 首部）構(gòu)成。

如果 a 設(shè)置過(guò)大會(huì)導(dǎo)致應(yīng)答超時(shí)，在實(shí)際環(huán)境包大小超過(guò)該值時(shí)會(huì)出現(xiàn)分包的情況。

在調(diào)試合適的 MTU 值的同時(shí)通過(guò) MessagePack 對(duì)消息體進(jìn)行序列號(hào)，進(jìn)一步壓縮數(shù)據(jù)包的大小，并減小 CPU 的消耗。

3.11 基礎(chǔ)設(shè)施支持

使用 EGO 框架（ https://github.com/gotomicro/ego ）進(jìn)行服務(wù)開(kāi)發(fā)：業(yè)務(wù)日志打印，異步日志輸出，動(dòng)態(tài)日志級(jí)別調(diào)整等功能，方便線(xiàn)上問(wèn)題排查提升日志打印效率；微服務(wù)監(jiān)控體系，CPU、P99、內(nèi)存、goroutine 等監(jiān)控。

客戶(hù)端 Redis 監(jiān)控：

客戶(hù)端 Kafka 監(jiān)控：

自定義監(jiān)控大盤(pán)：

4 性能壓測(cè)

4.1 壓測(cè)準(zhǔn)備

• 選擇一臺(tái)配置為 4 核 8G 的虛擬機(jī)，作為服務(wù)機(jī)，目標(biāo)承載 48w 連接;
• 選擇八臺(tái)配置為 4 核 8G 的虛擬機(jī)，作為客戶(hù)機(jī)，每臺(tái)客戶(hù)機(jī)開(kāi)放 6w 個(gè)端口。

4.2 場(chǎng)景一

用戶(hù)上線(xiàn)，50w 在線(xiàn)用戶(hù)。

服務(wù)	CPU	Memory	數(shù)量	CPU%	Mem%
WS-Gateway	16 核	32G	1 臺(tái)	22.38%	70.59%

單個(gè) WS-Gateway 每秒建立連接數(shù)峰值為：1.6w 個(gè)/s，每個(gè)用戶(hù)占用內(nèi)存：47K。

4.3 場(chǎng)景二

測(cè)試時(shí)間 15 分鐘，在線(xiàn)用戶(hù) 50w，每 5s 推送一條所有用戶(hù)，用戶(hù)有回執(zhí)。推送內(nèi)容為：

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

測(cè)試經(jīng)過(guò) 5 分鐘后，服務(wù)異常重啟，重啟原因是內(nèi)存使用量到超過(guò)限制。

分析內(nèi)存超過(guò)限制的原因：

新增的廣播代碼用掉了 9.32% 的內(nèi)存。

接收用戶(hù)回執(zhí)消息的部分消耗了 10.38% 的內(nèi)存。

進(jìn)行測(cè)試規(guī)則調(diào)整，測(cè)試時(shí)間 15 分鐘，在線(xiàn)用戶(hù) 48w，每 5s 推送一條所有用戶(hù)，用戶(hù)有回執(zhí)。推送內(nèi)容為：

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

服務(wù)	CPU	Memory	數(shù)量	CPU%	Mem%
WS-Gateway	16 核	32G	1 臺(tái)	44%	91.75%

連接數(shù)建立峰值：1w 個(gè)/s，接收數(shù)據(jù)峰值：9.6w 條/s，發(fā)送數(shù)據(jù)峰值 9.6w 條/s。

4.4 場(chǎng)景三

測(cè)試時(shí)間 15 分鐘，在線(xiàn)用戶(hù) 50w，每 5s 推送一條所有用戶(hù)，用戶(hù)無(wú)需回執(zhí)。推送內(nèi)容為：

["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"}}]

服務(wù)	CPU	Memory	CPU%	Mem%
WS-Gateway	16 核	32G	1 臺(tái)	30%	93%

連接數(shù)建立峰值：1.1w 個(gè)/s，發(fā)送數(shù)據(jù)峰值 10w 條/s，出內(nèi)存占用過(guò)高之外，其他沒(méi)有異常情況。

內(nèi)存消耗極高，分析火焰圖，大部分消耗在定時(shí) 5s 進(jìn)行廣播的操作上。

4.5 場(chǎng)景四

測(cè)試時(shí)間 15 分鐘，在線(xiàn)用戶(hù) 50w，每 5s 推送一條所有用戶(hù)，用戶(hù)有回執(zhí)。每秒 4w 用戶(hù)上下線(xiàn)。推送內(nèi)容為：

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

服務(wù)	CPU	Memory	數(shù)量	CPU%	Mem%
WS-Gateway	16 核	32G	1 臺(tái)	46.96%	65.6%

連接數(shù)建立峰值：18570 個(gè)/s，接收數(shù)據(jù)峰值：329949 條/s，發(fā)送數(shù)據(jù)峰值 393542 條/s，未出現(xiàn)異常情況。

4.6 壓測(cè)總結(jié)

在 16C 32G 內(nèi)存的硬件條件下，單機(jī) 50w 連接數(shù)，進(jìn)行以上包括用戶(hù)上下線(xiàn)、消息回執(zhí)等四個(gè)場(chǎng)景的壓測(cè)，內(nèi)存和 CPU 消耗都符合預(yù)期，并且在較長(zhǎng)時(shí)間的壓測(cè)下，服務(wù)也很穩(wěn)定。滿(mǎn)足目前量級(jí)下的資源節(jié)約要求，可在此基礎(chǔ)上繼續(xù)完善功能開(kāi)發(fā)。

5 總結(jié)

面臨日益增加的用戶(hù)量，網(wǎng)關(guān)服務(wù)的重構(gòu)是勢(shì)在必行，本次重構(gòu)主要是：

• 對(duì)網(wǎng)關(guān)服務(wù)與業(yè)務(wù)服務(wù)的解耦，移除對(duì) Nginx 的依賴(lài)，讓整體架構(gòu)更加清晰。

• 從用戶(hù)建立連接到底層業(yè)務(wù)推送消息的整體流程分析，對(duì)其中這些流程進(jìn)行了具體的優(yōu)化。以下各個(gè)方面讓 2.0 版本的網(wǎng)關(guān)有了更少的資源消耗，更低的單位用戶(hù)內(nèi)存損耗、更加完善的監(jiān)控報(bào)警體系，讓網(wǎng)關(guān)服務(wù)本身更加可靠：

  • 可降級(jí)的握手流程；
  • Socket ID 生產(chǎn)；
  • 客戶(hù)端心跳處理過(guò)程的優(yōu)化；
  • 自定義 Headers 避免了消息解碼，強(qiáng)化了鏈路追蹤與監(jiān)控；
  • 消息的接收與發(fā)送代碼結(jié)構(gòu)設(shè)計(jì)上的優(yōu)化；
  • 對(duì)象資源池的使用，使用緩存降低 GC 頻率；
  • 消息體的序列化壓縮；
  • 接入服務(wù)觀測(cè)基礎(chǔ)設(shè)施，保證服務(wù)穩(wěn)定性。

• 在保證網(wǎng)關(guān)服務(wù)性能過(guò)關(guān)的同時(shí)，更進(jìn)一步的是收斂底層組件服務(wù)對(duì)網(wǎng)關(guān)業(yè)務(wù)調(diào)用的方式，從以前的 HTTP、Redis、Kafka 等方式，統(tǒng)一為 gRPC 調(diào)用，保證了來(lái)源可查可控，為后續(xù)業(yè)務(wù)接入打下了更好的基礎(chǔ)。