一区二区三区日韩精品-日韩经典一区二区三区-五月激情综合丁香婷婷-欧美精品中文字幕专区

分享

石墨文檔Websocket百萬長連接技術(shù)實踐

 520jefferson 2021-11-30

內(nèi)容簡介:Web 服務(wù)端推送技術(shù)經(jīng)過了長輪詢、短輪詢的發(fā)展,最終到 HTML5 標準帶來的 WebSocket 規(guī)范逐步成為了目前業(yè)內(nèi)主流技術(shù)方案。它使得消息推送、消息通知等功能的實現(xiàn)變得異常簡單,那么百萬級別連接下的 Websocket 網(wǎng)關(guān)該如何實踐呢?本文整理自石墨文檔資深工程師杜旻翔根據(jù)石墨websocket重構(gòu)的實踐經(jīng)驗。

1 引言

在石墨文檔的業(yè)務(wù)中,如文檔分享、評論、幻燈片演示和文檔表格跟隨等場景,涉及多客戶端數(shù)據(jù)同步和服務(wù)端批量數(shù)據(jù)推送的需求,采用短輪詢或長輪詢的方式無法很好的滿足服務(wù)端消息推送、消息通知的業(yè)務(wù)場景,因此選擇業(yè)內(nèi)的主流方案:基于 HTML5 標準定義的 WebSocket 規(guī)范。

隨著石墨文檔的發(fā)展,現(xiàn)在日連接峰值達到了百萬量級,日益增長的用戶連接數(shù)和停止更新的架構(gòu)設(shè)計導致了內(nèi)存和 CPU 使用量急劇增長,因此我們考慮對網(wǎng)關(guān)進行重構(gòu),以適應(yīng)發(fā)展需求。

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

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

2.1 架構(gòu)

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

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

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

2.2 痛點

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

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

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

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

3.1 整體架構(gòu)

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

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

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

3.2 握手流程

網(wǎng)絡(luò)狀態(tài)良好的情況下,完成如下圖所示步驟 1 到步驟 6 之后,直接進入 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}

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

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

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

這個部分的內(nèi)存消耗無法避免,我們有兩個選擇:

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

3.4 Socket ID 設(shè)計

對每次連接必須產(chǎn)生一個唯一碼,如果出現(xiàn)重復會導致串號,消息混亂推送的問題。選擇 SnowFlake 算法作為唯一碼生成算法。

物理機場景中,對副本所在物理機進行固定編號,即可保證每個副本上的服務(wù)產(chǎn)生的 Socket ID 是唯一值。

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

3.5 集群會話管理方案:事件廣播

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

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

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


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

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

特性RedisKafkaRocketMQ
開發(fā)語言CScalaJava
單機吞吐量10w+10w+10w+
可用性主從架構(gòu)分布式架構(gòu)分布式架構(gòu)
特點功能簡單吞吐量、可用性極高功能豐富、定制化強,吞吐量、可用性高
功能特性數(shù)據(jù) 10K 以內(nèi)性能優(yōu)異,功能簡單,適用于簡單業(yè)務(wù)場景支持核心的 MQ 功能,不支持消息查詢或消息回溯等功能支持核心的 MQ 功能,擴展性強

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

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

3.6 心跳機制

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

  1. 客戶端建立 WebSocket 連接成功后,服務(wù)端下發(fā)心跳上報參數(shù);
  2. 客戶端依據(jù)以上參數(shù)進行心跳包傳輸,服務(wù)端收到心跳后會更新會話時間戳;
  3. 客戶端其他上行數(shù)據(jù)都會觸發(fā)對應(yīng)會話時間戳更新;
  4. 服務(wù)端定時清理超時會話,執(zhí)行主動關(guān)閉流程;
  5. 通過 Redis 更新的時間戳數(shù)據(jù)進行 WebSocket 連接、用戶和文件之間的關(guā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 := range clients {
         cli.WsClose()
      }
   }
}

在已有的兩級緩存刷新機制上,進一步通過動態(tài)心跳上報頻率的方式降低心跳上報產(chǎn)生的服務(wù)端性能壓力,默認場景中客戶端對服務(wù)端進行間隔 1s 的心跳上報,假設(shè)目前單機承載了 50w 的連接數(shù),當前的 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 進行重試。采用以上策略,在保證連接質(zhì)量的同時,降低心跳對服務(wù)端產(chǎn)生的性能損耗。

3.7 自定義 Headers

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

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

在 Kafka Headers 中寫入了 trace id 和 時間戳,可以追中某條消息的完整消費鏈路以及各階段的時間消耗。圖片

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

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
}

客戶端與服務(wù)端的消息交互第一版的寫法類似以上寫法,對 Demo 進行壓測,發(fā)現(xiàn)每個 WebSocket 連接都會占用 3 個 goroutine,每個 goroutine 都需要內(nèi)存棧,單機承載連十分有限,主要受制于大量的內(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(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,如果使用輪詢方式從緩沖區(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)境下使用。

3.9 核心對象緩存

確定數(shù)據(jù)接收與發(fā)送邏輯后,網(wǎng)關(guān)部分的核心對象為 Connection 對象,圍繞 Connection 進行了 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) // 放回連接池
}

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

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

 ping -s {a} {ip}

a = 1400 時,實際傳輸包大小為:1428。其中 28 由 8(ICMP 回顯請求和回顯應(yīng)答報文格式)和 20(IP 首部)構(gòu)成。圖片如果 a 設(shè)置過大會導致應(yīng)答超時,在實際環(huán)境包大小超過該值時會出現(xiàn)分包的情況。圖片在調(diào)試合適的 MTU 值的同時通過 MessagePack 對消息體進行序列號,進一步壓縮數(shù)據(jù)包的大小,并減小 CPU 的消耗。

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

使用 EGO 框架( https://github.com/gotomicro/ego )進行服務(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)控大盤:圖片

4 性能壓測

4.1 壓測準備

  • 選擇一臺配置為 4 核 8G 的虛擬機,作為服務(wù)機,目標承載 48w 連接;
  • 選擇八臺配置為 4 核 8G 的虛擬機,作為客戶機,每臺客戶機開放 6w 個端口。

4.2 場景一

用戶上線,50w 在線用戶。

服務(wù)CPUMemory數(shù)量CPU%Mem%
WS-Gateway16 核32G1 臺22.38%70.59%

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

4.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)存。圖片

進行測試規(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'}}]

服務(wù)CPUMemory數(shù)量CPU%Mem%
WS-Gateway16 核32G1 臺44%91.75%

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

4.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'}}]

服務(wù)CPUMemory數(shù)量CPU%Mem%
WS-Gateway16 核32G1 臺30%93%

連接數(shù)建立峰值:1.1w 個/s,發(fā)送數(shù)據(jù)峰值 10w 條/s,出內(nèi)存占用過高之外,其他沒有異常情況。圖片圖片圖片圖片內(nèi)存消耗極高,分析火焰圖,大部分消耗在定時 5s 進行廣播的操作上。圖片

4.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'}}]

服務(wù)CPUMemory數(shù)量CPU%Mem%
WS-Gateway16 核32G1 臺46.96%65.6%

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

4.6 壓測總結(jié)

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

5 總結(jié)

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

  • 對網(wǎng)關(guān)服務(wù)與業(yè)務(wù)服務(wù)的解耦,移除對 Nginx 的依賴,讓整體架構(gòu)更加清晰。
  • 從用戶建立連接到底層業(yè)務(wù)推送消息的整體流程分析,對其中這些流程進行了具體的優(yōu)化。以下各個方面讓 2.0 版本的網(wǎng)關(guān)有了更少的資源消耗,更低的單位用戶內(nèi)存損耗、更加完善的監(jiān)控報警體系,讓網(wǎng)關(guān)服務(wù)本身更加可靠:
    • 可降級的握手流程;
    • Socket ID 生產(chǎn);
    • 客戶端心跳處理過程的優(yōu)化;
    • 自定義 Headers 避免了消息解碼,強化了鏈路追蹤與監(jiān)控;
    • 消息的接收與發(fā)送代碼結(jié)構(gòu)設(shè)計上的優(yōu)化;
    • 對象資源池的使用,使用緩存降低 GC 頻率;
    • 消息體的序列化壓縮;
    • 接入服務(wù)觀測基礎(chǔ)設(shè)施,保證服務(wù)穩(wěn)定性。
  • 在保證網(wǎng)關(guān)服務(wù)性能過關(guān)的同時,更進一步的是收斂底層組件服務(wù)對網(wǎng)關(guān)業(yè)務(wù)調(diào)用的方式,從以前的 HTTP、Redis、Kafka 等方式,統(tǒng)一為 gRPC 調(diào)用,保證了來源可查可控,為后續(xù)業(yè)務(wù)接入打下了更好的基礎(chǔ)。

6 Q&A

收錄了部分文章相關(guān)內(nèi)容的討論問題:

6.1 SocketID 存在的價值

問題:按照我的理解 socketID 存在的價值是 Kafka 的消費者需要根據(jù) socketID 找到對應(yīng)的tcp 鏈接,既然你們已經(jīng)有了自定義網(wǎng)關(guān),那么引入 kafka 的意義是什么?消息的持久化?為什么不在網(wǎng)關(guān)層做負載均衡,讓節(jié)點直接跟客戶端通信。另外我猜測消費發(fā)送者需要根據(jù)socketId 做 hash 然后發(fā)送到對應(yīng)的 partition,一旦初始 partition 過小,進行擴容時,客戶端和服務(wù)端都得進行重啟或則升級,不知道引入 kafka 的意義在哪里,相反還極大的增加了架構(gòu)的復雜度和維護成本,擴展性也沒那么好,如果是 http 短鏈接還能理解。

回答:圖中沒畫出 SLB,是有負載均衡的。我們沒有采用 socket id hash 到對應(yīng) partition,kafka 的作用是在處理網(wǎng)關(guān)內(nèi)部的不需要關(guān)心順序和推送消息的流轉(zhuǎn),如果沒有kafka,那么組件或者網(wǎng)關(guān)滾動更新,用戶重連的過程中,就可能丟消息;對于需要順序的消息,例如 ping pong 模式的是可以通過網(wǎng)關(guān)識別到 header 頭里的 cmd 信息,找到對應(yīng)后端,分發(fā)消息。

6.2 Redis 進行消息廣播的作用

問題:廣播內(nèi)容的數(shù)據(jù)量大小在 1K 左右,業(yè)務(wù)場景簡單固定,并且要兼容歷史業(yè)務(wù)邏輯,最后選擇了 Redis 進行消息廣播。api 與網(wǎng)關(guān)交互不是通過 kafka 嗎,這里是什么意思呢?

回答:網(wǎng)關(guān)節(jié)點對 kafka 的消費是集群模式。如果 kafka,在 k8s 條件下,使用廣播模式比較麻煩。所以老的網(wǎng)關(guān)是用 redis 做 pub/sub 的廣播,為了兼容老的邏輯仍然采用 redis 做廣播。同時后續(xù)我們打算直接將 api 和 ws 做兩兩互聯(lián),通過 grpc stream 做廣播,有更好的擴展性。

7 技術(shù)鏈接

  • 微服務(wù)框架:https://github.com/gotomicro/ego
  • Kafka、Redis、MySQL 客戶端監(jiān)控 SDK:https://github.com/gotomicro/ego-component

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導購買等信息,謹防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報。
    轉(zhuǎn)藏 分享 獻花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多

    五月激情五月天综合网| 国产精品福利一二三区| 黄色美女日本的美女日人| 国产伦精品一区二区三区高清版 | 日韩女优视频国产一区| 日韩性生活视频免费在线观看| 日韩中文字幕狠狠人妻| 国产精品午夜视频免费观看| 亚洲黄色在线观看免费高清 | 亚洲天堂有码中文字幕视频| 经典欧美熟女激情综合网| 欧美午夜一级特黄大片| 老司机精品视频免费入口 | 国产一区二区三区午夜精品| 亚洲av日韩一区二区三区四区 | 国产福利一区二区久久| 青青久久亚洲婷婷中文网| 精品国产91亚洲一区二区三区| 国产精品福利一二三区| 日本加勒比系列在线播放| 亚洲男人的天堂就去爱| 九九热在线视频观看最新| 亚洲专区中文字幕视频| 成年人黄片大全在线观看| 亚洲一级在线免费观看| 一级片黄色一区二区三区| 果冻传媒精选麻豆白晶晶 | 日本不卡在线一区二区三区| 欧洲亚洲精品自拍偷拍| 亚洲中文字幕有码在线观看| 久久经典一区二区三区| 91插插插外国一区二区婷婷| 女人高潮被爽到呻吟在线观看| 日韩人妻一区二区欧美| 日韩高清毛片免费观看| 国产肥妇一区二区熟女精品| 五月天婷亚洲天婷综合网| 欧美又大又黄刺激视频| 国产一区二区不卡在线视频| 国产原创中文av在线播放| 欧美成人久久久免费播放|