本文由石墨文檔技術(shù)杜旻翔分享，原題“石墨文檔 Websocket 百萬長連接技術(shù)實踐”，有修訂。
1、引言
在石墨文檔的部分業(yè)務(wù)中，例如文檔分享、評論、幻燈片演示和文檔表格跟隨等場景，涉及到多客戶端數(shù)據(jù)實時同步和服務(wù)端批量數(shù)據(jù)在線推送的需求，一般的 HTTP 協(xié)議無法滿足服務(wù)端主動 Push 數(shù)據(jù)的場景，因此選擇采用 WebSocket 方案進(jìn)行業(yè)務(wù)開發(fā)。
隨著石墨文檔業(yè)務(wù)發(fā)展，目前日連接峰值已達(dá)百萬量級，日益增長的用戶連接數(shù)和不符合目前量級的架構(gòu)設(shè)計導(dǎo)致了內(nèi)存和 CPU 使用量急劇增長，因此我們考慮對長連接網(wǎng)關(guān)進(jìn)行重構(gòu)。
本文分享了石墨文檔長連接網(wǎng)關(guān)從1.0架構(gòu)演進(jìn)到2.0的過程，并總結(jié)了整個性能優(yōu)化的實踐過程。
學(xué)習(xí)交流：
（本文同步發(fā)布于：http://www.52im.net/thread-3757-1-1.html）
2、專題目錄
本文是系列文章的第6篇，總目錄如下：
3、v1.0架構(gòu)面臨的問題
這套長連接網(wǎng)關(guān)系統(tǒng)的v1.0版是使用 Node.js 基于 Socket.IO 進(jìn)行修改開發(fā)的版本，很好的滿足了當(dāng)時用戶量級下的業(yè)務(wù)場景需求。
3.1 架構(gòu)介紹
1.0版架構(gòu)設(shè)計圖：
1.0版客戶端連接流程：
- 1）用戶通過 NGINX 連接網(wǎng)關(guān)，該操作被業(yè)務(wù)服務(wù)感知；
- 2）業(yè)務(wù)服務(wù)感知到用戶連接后，會進(jìn)行相關(guān)用戶數(shù)據(jù)查詢，再將消息 Pub 到 Redis；
- 3）網(wǎng)關(guān)服務(wù)通過 Redis Sub 收到消息；
- 4）查詢網(wǎng)關(guān)集群中的用戶會話數(shù)據(jù)，向客戶端進(jìn)行消息推送。
3.2 面臨的問題
雖然 1.0 版本的長連接網(wǎng)關(guān)在線上運行良好，但是不能很好的支持后續(xù)業(yè)務(wù)的擴(kuò)展。
并且有以下幾個問題需要解決：
- 1）資源消耗：Nginx 僅使用 TLS 解密，請求透傳，產(chǎn)生了大量的資源浪費，同時之前的 Node 網(wǎng)關(guān)性能不好，消耗大量的 CPU、內(nèi)存；
- 2）維護(hù)與觀測：未接入石墨的監(jiān)控體系，無法和現(xiàn)有監(jiān)控告警聯(lián)通，維護(hù)上存在一定的困難；
- 3）業(yè)務(wù)耦合問題：業(yè)務(wù)服務(wù)與網(wǎng)關(guān)功能被集成到了同一個服務(wù)中，無法針對業(yè)務(wù)部分性能損耗進(jìn)行針對性水平擴(kuò)容，為了解決性能問題，以及后續(xù)的模塊擴(kuò)展能力，都需要進(jìn)行服務(wù)解耦。
4、v2.0架構(gòu)演進(jìn)實踐
4.1 概述
長連接網(wǎng)關(guān)系統(tǒng)的v2.0版需要解決很多問題。
比如，石墨文檔內(nèi)部有很多組件（文檔、表格、幻燈片和表單等等），在 1.0 版本中組件對網(wǎng)關(guān)的業(yè)務(wù)調(diào)用可以通過Redis、Kafka 和 HTTP 接口，來源不可查，管控困難。
此外，從性能優(yōu)化的角度考慮也需要對原有服務(wù)進(jìn)行解耦合，將 1.0 版本網(wǎng)關(guān)拆分為網(wǎng)關(guān)功能部分和業(yè)務(wù)處理部分。
具體是：
- 1）網(wǎng)關(guān)功能部分為 WS-Gateway：集成用戶鑒權(quán)、TLS 證書驗證和 WebSocket 連接管理等；
- 2）業(yè)務(wù)處理部分為 WS-API：組件服務(wù)直接與該服務(wù)進(jìn)行 gRPC 通信。
另外還有：
- 1）可針對具體的模塊進(jìn)行針對性擴(kuò)容；
- 2）服務(wù)重構(gòu)加上 Nginx 移除，整體硬件消耗顯著降低；
- 3）服務(wù)整合到石墨監(jiān)控體系。
4.2 整體架構(gòu)
2.0版本架構(gòu)設(shè)計圖：
2.0版本客戶端連接流程：
- 1）客戶端與 WS-Gateway 服務(wù)通過握手流程建立 WebSocket 連接；
- 2）連接建立成功后，WS-Gateway 服務(wù)將會話進(jìn)行節(jié)點存儲，將連接信息映射關(guān)系緩存到 Redis 中，并通過 Kafka 向 WS-API 推送客戶端上線消息；
- 3）WS-API 通過 Kafka 接收客戶端上線消息及客戶端上行消息；
- 4）WS-API 服務(wù)預(yù)處理及組裝消息，包括從 Redis 獲取消息推送的必要數(shù)據(jù)，并進(jìn)行完成消息推送的過濾邏輯，然后 Pub 消息到 Kafka；
- 5）WS-Gateway 通過 Sub Kafka 來獲取服務(wù)端需要返回的消息，逐個推送消息至客戶端。
4.3 握手流程
網(wǎng)絡(luò)狀態(tài)良好的情況下，完成如下圖所示步驟 1 到步驟 6 之后，直接進(jìn)入 WebSocket 流程；網(wǎng)絡(luò)環(huán)境較差的情況下，WebSocket 的通信模式會退化成 HTTP 方式，客戶端通過 POST 方式推送消息到服務(wù)端，再通過 GET 長輪詢的方式從讀取服務(wù)端返回數(shù)據(jù)。
客戶端初次請求服務(wù)端連接建立的握手流程：
流程說明如下：
- 1）Client 發(fā)送 GET 請求嘗試建立連接；
- 2）Server 返回相關(guān)連接數(shù)據(jù)，sid 為本次連接產(chǎn)生的唯一 Socket ID，后續(xù)交互作為憑證：
- {"sid":"xxx","upgrades":["websocket"],"pingInterval":xxx,"pingTimeout":xxx}
- 3）Client 攜帶步驟 2 中的 sid 參數(shù)再次請求；
- 4）Server 返回 40，表示請求接收成功；
- 5）Client 發(fā)送 POST 請求確認(rèn)后期降級通路情況；
- 6）Server 返回 ok，此時第一階段握手流程完成；
- 7）嘗試發(fā)起 WebSocket 連接，首先進(jìn)行 2probe 和 3probe 的請求響應(yīng)，確認(rèn)通信通道暢通后，即可進(jìn)行正常的 WebSocket 通信。
4.4 TLS 內(nèi)存消耗優(yōu)化
客戶端與服務(wù)端連接建立采用的 wss 協(xié)議，在 1.0 版本中 TLS 證書掛載在 Nginx 上，HTTPS 握手過程由 Nginx 完成。為了降低 Nginx 的機(jī)器成本，在 2.0 版本中我們將證書掛載到服務(wù)上。
通過分析服務(wù)內(nèi)存，如下圖所示，TLS 握手過程中消耗的內(nèi)存占了總內(nèi)存消耗的大概 30% 左右。
這個部分的內(nèi)存消耗無法避免，我們有兩個選擇：
- 1）采用七層負(fù)載均衡，在七層負(fù)載上進(jìn)行 TLS 證書掛載，將 TLS 握手過程移交給性能更好的工具完成；
- 2）優(yōu)化 Go 對 TLS 握手過程性能，在與業(yè)內(nèi)大佬曹春暉（曹大）的交流中了解到，他最近在 Go 官方庫提交的 PR，以及相關(guān)的性能測試數(shù)據(jù)。
4.5 Socket ID 設(shè)計
對每次連接必須產(chǎn)生一個唯一碼，如果出現(xiàn)重復(fù)會導(dǎo)致串號，消息混亂推送的問題。選擇SnowFlake算法作為唯一碼生成算法。
物理機(jī)場景中，對副本所在物理機(jī)進(jìn)行固定編號，即可保證每個副本上的服務(wù)產(chǎn)生的 Socket ID 是唯一值。
K8S 場景中，這種方案不可行，于是采用注冊下發(fā)的方式返回編號，WS-Gateway 所有副本啟動后向數(shù)據(jù)庫寫入服務(wù)的啟動信息，獲取副本編號，以此作為參數(shù)作為 SnowFlake 算法的副本編號進(jìn)行 Socket ID 生產(chǎn)，服務(wù)重啟會繼承之前已有的副本編號，有新版本下發(fā)時會根據(jù)自增 ID 下發(fā)新的副本編號。
于此同時，Ws-Gateway 副本會向數(shù)據(jù)庫寫入心跳信息，以此作為網(wǎng)關(guān)服務(wù)本身的健康檢查依據(jù)。
4.6 集群會話管理方案：事件廣播
客戶端完成握手流程后，會話數(shù)據(jù)在當(dāng)前網(wǎng)關(guān)節(jié)點內(nèi)存存儲，部分可序列化數(shù)據(jù)存儲到 Redis，存儲結(jié)構(gòu)說明如下圖所示。
由客戶端觸發(fā)或組件服務(wù)觸發(fā)的消息推送，通過 Redis 存儲的數(shù)據(jù)結(jié)構(gòu)，在 WS-API 服務(wù)查詢到返回消息體的目標(biāo)客戶端的 Socket ID，再由 WS-Gateway 服務(wù)進(jìn)行集群消費。如果 Socket ID 不在當(dāng)前節(jié)點，則需要進(jìn)行節(jié)點與會話關(guān)系的查詢，找到客端戶 Socket ID 實際對應(yīng)的 WS-Gateway 節(jié)點，通常有以下兩種方案（如下圖所示）。
在確定使用事件廣播方式進(jìn)行網(wǎng)關(guān)節(jié)點間的消息傳遞后，進(jìn)一步選擇使用哪種具體的消息中間件，列舉了三種待選的方案（如下圖所示）。
于是對 Redis 和其他 MQ 中間件進(jìn)行 100w 次的入隊和出隊操作，在測試過程中發(fā)現(xiàn)在數(shù)據(jù)小于 10K 時 Redis 性能表現(xiàn)十分優(yōu)秀。
進(jìn)一步結(jié)合實際情況：廣播內(nèi)容的數(shù)據(jù)量大小在 1K 左右，業(yè)務(wù)場景簡單固定，并且要兼容歷史業(yè)務(wù)邏輯，最后選擇了 Redis 進(jìn)行消息廣播。
后續(xù)還可以將 WS-API 與 WS-Gateway 兩兩互聯(lián)，使用 gRPC stream 雙向流通信節(jié)省內(nèi)網(wǎng)流量。
4.7 心跳機(jī)制
會話在節(jié)點內(nèi)存與 Redis 中存儲后，客戶端需要通過心跳上報持續(xù)更新會話時間戳，客戶端按照服務(wù)端下發(fā)的周期進(jìn)行心跳上報，上報時間戳首先在內(nèi)存進(jìn)行更新，然后再通過另外的周期進(jìn)行 Redis 同步，避免大量客戶端同時進(jìn)行心跳上報對 Redis 產(chǎn)生壓力。
具體流程：
- 1）客戶端建立 WebSocket 連接成功后，服務(wù)端下發(fā)心跳上報參數(shù)；
- 2）客戶端依據(jù)以上參數(shù)進(jìn)行心跳包傳輸，服務(wù)端收到心跳后會更新會話時間戳；
- 3）客戶端其他上行數(shù)據(jù)都會觸發(fā)對應(yīng)會話時間戳更新；
- 4）服務(wù)端定時清理超時會話，執(zhí)行主動關(guān)閉流程；
- 5）通過 Redis 更新的時間戳數(shù)據(jù)進(jìn)行 WebSocket 連接、用戶和文件之間的關(guān)系進(jìn)行清理。
會話數(shù)據(jù)內(nèi)存以及 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 := rangeclients {
cli.WsClose()
}
}
}
在已有的兩級緩存刷新機(jī)制上，進(jìn)一步通過動態(tài)心跳上報頻率的方式降低心跳上報產(chǎn)生的服務(wù)端性能壓力，默認(rèn)場景中客戶端對服務(wù)端進(jìn)行間隔 1s 的心跳上報，假設(shè)目前單機(jī)承載了 50w 的連接數(shù)，當(dāng)前的 QPS 為：QPS1 = 500000/1。
從服務(wù)端性能優(yōu)化的角度考慮，實現(xiàn)心跳正常情況下的動態(tài)間隔，每 x 次正常心跳上報，心跳間隔增加 a，增加上限為 y，動態(tài) QPS 最小值為：QPS2=500000/y。
極限情況下，心跳產(chǎn)生的 QPS 降低 y 倍。在單次心跳超時后服務(wù)端立刻將 a 值變?yōu)?1s 進(jìn)行重試。采用以上策略，在保證連接質(zhì)量的同時，降低心跳對服務(wù)端產(chǎn)生的性能損耗。
4.8 自定義Headers
使用 Kafka 自定義 Headers 的目的是避免網(wǎng)關(guān)層出現(xiàn)對消息體解碼而帶來的性能損耗。
客戶端 WebSocket 連接建立成功后，會進(jìn)行一系列的業(yè)務(wù)操作，我們選擇將 WS-Gateway 和 WS-API 之間的操作指令和必要的參數(shù)放到 Kafka 的 Headers 中，例如通過 X-XX-Operator 為廣播，再讀取 X-XX-Guid 文件編號，對該文件內(nèi)的所有用戶進(jìn)行消息推送。
在 Kafka Headers 中寫入了 trace id 和 時間戳，可以追中某條消息的完整消費鏈路以及各階段的時間消耗。
4.9 消息接收與發(fā)送
type Packet struct{
...
}
type Connect struct{
*websocket.Con
send chanPacket
}
func NewConnect(conn net.Conn) *Connect {
c := &Connect{
send: make(chanPacket, N),
}
goc.reader()
goc.writer()
return c
}
客戶端與服務(wù)端的消息交互第一版的寫法類似以上寫法。
對 Demo 進(jìn)行壓測，發(fā)現(xiàn)每個 WebSocket 連接都會占用 3 個 goroutine，每個 goroutine 都需要內(nèi)存棧，單機(jī)承載連十分有限。
主要受制于大量的內(nèi)存占用，而且大部分時間 c.writer() 是閑置狀態(tài)，于是考慮，是否只啟用 2 個 goroutine 來完成交互。
type Packet struct{
...
}
type Connect struct{
*websocket.Conn
mux sync.RWMutex
}
func NewConnect(conn net.Conn) *Connect {
c := &Connect{
send: make(chanPacket, N),
}
goc.reader()
return c
}
func(c *Connect) Write(data []byte) (err error) {
c.mux.Lock()
deferc.mux.Unlock()
...
return nil
}
保留 c.reader() 的 goroutine，如果使用輪詢方式從緩沖區(qū)讀取數(shù)據(jù)，可能會產(chǎn)生讀取延遲或者鎖的問題，c.writer() 操作調(diào)整為主動調(diào)用，不采用啟動 goroutine 持續(xù)監(jiān)聽，降低內(nèi)存消耗。
調(diào)研了 gev 和 gnet 等基于事件驅(qū)動的輕量級高性能網(wǎng)絡(luò)庫，實測發(fā)現(xiàn)在大量連接場景下可能產(chǎn)生的消息延遲的問題，所以沒有在生產(chǎn)環(huán)境下使用。
4.10 核心對象緩存
確定數(shù)據(jù)接收與發(fā)送邏輯后，網(wǎng)關(guān)部分的核心對象為 Connection 對象，圍繞 Connection 進(jìn)行了 run、read、write、close 等函數(shù)的開發(fā)。
使用 sync.pool 來緩存該對象，減輕 GC 壓力，創(chuàng)建連接時，通過對象資源池獲取 Connection 對象。
生命周期結(jié)束之后，重置 Connection 對象后 Put 回資源池。
在實際編碼中，建議封裝 GetConn()、PutConn() 函數(shù)，收斂數(shù)據(jù)初始化、對象重置等操作。
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) // 放回連接池
}
4.11 數(shù)據(jù)傳輸過程優(yōu)化
消息流轉(zhuǎn)過程中，需要考慮消息體的傳輸效率優(yōu)化，采用 MessagePack 對消息體進(jìn)行序列化，壓縮消息體大小。調(diào)整 MTU 值避免出現(xiàn)分包情況，定義 a 為探測包大小，通過如下指令，對目標(biāo)服務(wù) ip 進(jìn)行 MTU 極限值探測。
ping-s {a} {ip}
a = 1400 時，實際傳輸包大小為：1428。
其中 28 由 8（ICMP 回顯請求和回顯應(yīng)答報文格式）和 20（IP 首部）構(gòu)成。
如果 a 設(shè)置過大會導(dǎo)致應(yīng)答超時，在實際環(huán)境包大小超過該值時會出現(xiàn)分包的情況。
在調(diào)試合適的 MTU 值的同時通過 MessagePack 對消息體進(jìn)行序列號，進(jìn)一步壓縮數(shù)據(jù)包的大小，并減小 CPU 的消耗。
4.12 基礎(chǔ)設(shè)施支持
使用EGO框架進(jìn)行服務(wù)開發(fā)：業(yè)務(wù)日志打印，異步日志輸出，動態(tài)日志級別調(diào)整等功能，方便線上問題排查提升日志打印效率；微服務(wù)監(jiān)控體系，CPU、P99、內(nèi)存、goroutine 等監(jiān)控。
客戶端 Redis 監(jiān)控：
客戶端 Kafka 監(jiān)控：
自定義監(jiān)控大盤：
5、檢查成果的時刻：性能壓測
5.1 壓測準(zhǔn)備
準(zhǔn)備的測試平臺有：
- 1）選擇一臺配置為 4 核 8G 的虛擬機(jī)，作為服務(wù)機(jī)，目標(biāo)承載 48w 連接;
- 2）選擇八臺配置為 4 核 8G 的虛擬機(jī)，作為客戶機(jī)，每臺客戶機(jī)開放 6w 個端口。
5.2 模擬場景一
用戶上線，50w 在線用戶。
單個 WS-Gateway 每秒建立連接數(shù)峰值為：1.6w 個/s，每個用戶占用內(nèi)存：47K。
5.3 模擬場景二
測試時間 15 分鐘，在線用戶 50w，每 5s 推送一條所有用戶，用戶有回執(zhí)。
推送內(nèi)容為：
42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"xx@xx.xx","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"}}]
測試經(jīng)過 5 分鐘后，服務(wù)異常重啟，重啟原因是內(nèi)存使用量到超過限制。
分析內(nèi)存超過限制的原因：
新增的廣播代碼用掉了 9.32% 的內(nèi)存：
接收用戶回執(zhí)消息的部分消耗了 10.38% 的內(nèi)存：
進(jìn)行測試規(guī)則調(diào)整，測試時間 15 分鐘，在線用戶 48w，每 5s 推送一條所有用戶，用戶有回執(zhí)。
推送內(nèi)容為：
42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"xx@xx.xx","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"}}]
連接數(shù)建立峰值：1w 個/s，接收數(shù)據(jù)峰值：9.6w 條/s，發(fā)送數(shù)據(jù)峰值 9.6w 條/s。
5.4 模擬場景三
測試時間 15 分鐘，在線用戶 50w，每 5s 推送一條所有用戶，用戶無需回執(zhí)。
推送內(nèi)容為：
42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"xx@xx.xx","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"}}]
連接數(shù)建立峰值：1.1w 個/s，發(fā)送數(shù)據(jù)峰值 10w 條/s，出內(nèi)存占用過高之外，其他沒有異常情況。
內(nèi)存消耗極高，分析火焰圖，大部分消耗在定時 5s 進(jìn)行廣播的操作上。
5.5 模擬場景四
測試時間 15 分鐘，在線用戶 50w，每 5s 推送一條所有用戶，用戶有回執(zhí)。每秒 4w 用戶上下線。
推送內(nèi)容為：
42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"xx@xx.xx","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"}}]
連接數(shù)建立峰值：18570 個/s，接收數(shù)據(jù)峰值：329949 條/s，發(fā)送數(shù)據(jù)峰值：393542 條/s，未出現(xiàn)異常情況。
5.6 壓測總結(jié)
在16核32G內(nèi)存的硬件條件下：單機(jī) 50w 連接數(shù)，進(jìn)行以上包括用戶上下線、消息回執(zhí)等四個場景的壓測，內(nèi)存和 CPU 消耗都符合預(yù)期，并且在較長時間的壓測下，服務(wù)也很穩(wěn)定。
測試的結(jié)果基本上是能滿足目前量級下的資源節(jié)約要求的，我們認(rèn)為完全可以在此基礎(chǔ)上繼續(xù)完善功能開發(fā)。
6、本文小結(jié)
面臨日益增加的用戶量，網(wǎng)關(guān)服務(wù)的重構(gòu)是勢在必行。
本次重構(gòu)主要是：
- 1）對網(wǎng)關(guān)服務(wù)與業(yè)務(wù)服務(wù)的解耦，移除對 Nginx 的依賴，讓整體架構(gòu)更加清晰；
- 2）從用戶建立連接到底層業(yè)務(wù)推送消息的整體流程分析，對其中這些流程進(jìn)行了具體的優(yōu)化。
2.0 版本的長連接網(wǎng)關(guān)有了更少的資源消耗，更低的單位用戶內(nèi)存損耗、更加完善的監(jiān)控報警體系，讓網(wǎng)關(guān)服務(wù)本身更加可靠。
以上優(yōu)化內(nèi)容主要是以下各個方面：
- 1）可降級的握手流程；
- 2）Socket ID 生產(chǎn)；
- 3）客戶端心跳處理過程的優(yōu)化；
- 4）自定義 Headers 避免了消息解碼，強(qiáng)化了鏈路追蹤與監(jiān)控；
- 5）消息的接收與發(fā)送代碼結(jié)構(gòu)設(shè)計上的優(yōu)化；
- 6）對象資源池的使用，使用緩存降低 GC 頻率；
- 7）消息體的序列化壓縮；
- 8）接入服務(wù)觀測基礎(chǔ)設(shè)施，保證服務(wù)穩(wěn)定性。
在保證網(wǎng)關(guān)服務(wù)性能過關(guān)的同時，更進(jìn)一步的是收斂底層組件服務(wù)對網(wǎng)關(guān)業(yè)務(wù)調(diào)用的方式，從以前的 HTTP、Redis、Kafka 等方式，統(tǒng)一為 gRPC 調(diào)用，保證了來源可查可控，為后續(xù)業(yè)務(wù)接入打下了更好的基礎(chǔ)。
7、相關(guān)文章
[1] WebSocket從入門到精通，半小時就夠！
[2] 搞懂現(xiàn)代Web端即時通訊技術(shù)一文就夠：WebSocket、socket.io、SSE
[3] 從游擊隊到正規(guī)軍(三)：基于Go的馬蜂窩旅游網(wǎng)分布式IM系統(tǒng)技術(shù)實踐
[4] 12306搶票帶來的啟示：看我如何用Go實現(xiàn)百萬QPS的秒殺系統(tǒng)(含源碼)
[5] Go語言構(gòu)建千萬級在線的高并發(fā)消息推送系統(tǒng)實踐(來自360公司)
[6] 跟著源碼學(xué)IM(六)：手把手教你用Go快速搭建高性能、可擴(kuò)展的IM系統(tǒng)
本文已同步發(fā)布于“即時通訊技術(shù)圈”公眾號。
同步發(fā)布鏈接是：http://www.52im.net/thread-3757-1-1.html