實時的響應總是讓人興奮的，就如你在微信里看到對方正在輸入，如你在王者峽谷里一呼百應，如你們在直播彈幕里不約而同的 666，它們的背后都離不開長連接技術(shù)的加持。

每個互聯(lián)網(wǎng)公司里幾乎都有一套長連接系統(tǒng)，它們被應用在消息提醒、即時通訊、推送、直播彈幕、游戲、共享定位、股票行情等等場景。而當公司發(fā)展到一定規(guī)模，業(yè)務場景變得更復雜后，更有可能是多個業(yè)務都需要同時使用長連接系統(tǒng)。

業(yè)務間分開設計長連接會導致研發(fā)和維護成本陡增、浪費基礎設施、增加客戶端耗電、無法復用已有經(jīng)驗等等問題。共享長連接系統(tǒng)又需要協(xié)調(diào)好不同系統(tǒng)間的認證、鑒權(quán)、數(shù)據(jù)隔離、協(xié)議拓展、消息送達保證等等需求，迭代過程中協(xié)議需要向前兼容，同時因為不同業(yè)務的長連接匯聚到一個系統(tǒng)導致容量管理的難度也會增大。

經(jīng)過了一年多的開發(fā)和演進，經(jīng)過我們服務面向內(nèi)和外的數(shù)個 App、接入十幾個需求和形態(tài)各異的長連接業(yè)務、數(shù)百萬設備同時在線、突發(fā)大規(guī)模消息發(fā)送等等場景的錘煉，我們提煉出一個長連接系統(tǒng)網(wǎng)關(guān)的通用解決方案，解決了多業(yè)務共用長連接時遇到的種種問題。

知乎長連接網(wǎng)關(guān)致力于業(yè)務數(shù)據(jù)解耦、消息高效分發(fā)、解決容量問題，同時提供一定程度的消息可靠性保證。

我們怎么設計通訊協(xié)議？

業(yè)務解耦

支撐多業(yè)務的長連接網(wǎng)關(guān)實際上是同時對接多客戶端和多業(yè)務后端的，是多對多的關(guān)系，他們之間只使用一條長連接通訊。

這種多對多的系統(tǒng)在設計時要避免強耦合。業(yè)務方邏輯也是會動態(tài)調(diào)整的，如果將業(yè)務的協(xié)議和邏輯與網(wǎng)關(guān)實現(xiàn)耦合會導致所有的業(yè)務都會互相牽連，協(xié)議升級和維護都會異常困難。

所以我們嘗試使用經(jīng)典的發(fā)布訂閱模型來解耦長連接網(wǎng)關(guān)跟客戶端與業(yè)務后端，它們之間只需要約定 Topic 即可自由互相發(fā)布訂閱消息。傳輸?shù)南⑹羌兌M制數(shù)據(jù)，網(wǎng)關(guān)也無需關(guān)心業(yè)務方的具體協(xié)議規(guī)范和序列化方式。

權(quán)限控制

我們使用發(fā)布訂閱解耦了網(wǎng)關(guān)與業(yè)務方的實現(xiàn)，我們?nèi)匀恍枰刂瓶蛻舳藢?Topic 的發(fā)布訂閱的權(quán)限，避免有意或無意的數(shù)據(jù)污染或越權(quán)訪問。

假如講師正在知乎 Live 的 165218 頻道開講，當客戶端進入房間嘗試訂閱 165218 頻道的 Topic 時就需要知乎 Live 的后端判斷當前用戶是否已經(jīng)付費。這種情況下的權(quán)限實際上是很靈活的，當用戶付費以后就能訂閱，否則就不能訂閱。權(quán)限的狀態(tài)只有知乎 Live 業(yè)務后端知曉，網(wǎng)關(guān)無法獨立作出判斷。

所以我們在 ACL 規(guī)則中設計了基于回調(diào)的鑒權(quán)機制，可以配置 Live 相關(guān) Topic 的訂閱和發(fā)布動作都通過 HTTP 回調(diào)給 Live 的后端服務判斷。

同時根據(jù)我們對內(nèi)部業(yè)務的觀察，大部分場景下業(yè)務需要的只是一個當前用戶的私有 Topic 用來接收服務端下發(fā)的通知或消息，這種情況下如果讓業(yè)務都設計回調(diào)接口來判斷權(quán)限會很繁瑣。

所以我們在 ACL 規(guī)則中設計了 Topic 模板變量來降低業(yè)務方的接入成本，我們給業(yè)務方配置允許訂閱的 Topic 中包含連接的用戶名變量標識，表示只允許用戶訂閱或發(fā)送消息到自己的 Topic。

此時網(wǎng)關(guān)可以在不跟業(yè)務方通信的情況下，獨立快速判斷客戶端是否有權(quán)限訂閱或往 Topic 發(fā)送消息。

消息可靠性保證

網(wǎng)關(guān)作為消息傳輸?shù)臉屑~，同時對接業(yè)務后端和客戶端，在轉(zhuǎn)發(fā)消息時需要保證消息在傳輸過程的可靠性。

TCP 只能保證了傳輸過程中的順序和可靠性，但遇到 TCP 狀態(tài)異常、客戶端接收邏輯異常或發(fā)生了 Crash 等等情況時，傳輸中的消息就會發(fā)生丟失。

為了保證下發(fā)或上行的消息被對端正常處理，我們實現(xiàn)了回執(zhí)和重傳的功能。重要業(yè)務的消息在客戶端收到并正確處理后需要發(fā)送回執(zhí)，而網(wǎng)關(guān)內(nèi)暫時保存客戶端未收取的消息，網(wǎng)關(guān)會判斷客戶端的接收情況并嘗試再次發(fā)送，直到正確收到了客戶端的消息回執(zhí)。

而面對服務端業(yè)務的大流量場景，服務端發(fā)給網(wǎng)關(guān)的每條消息都發(fā)送回執(zhí)的方式效率較低，我們也提供了基于消息隊列的接收和發(fā)送方式，后面介紹發(fā)布訂閱實現(xiàn)時再詳細闡述。

在設計通訊協(xié)議時我們參考了 MQTT 規(guī)范，拓展了認證和鑒權(quán)設計，完成了業(yè)務消息的隔離與解耦，保證了一定程度的傳輸可靠性。同時保持了與 MQTT 協(xié)議一定程度上兼容，這樣便于我們直接使用 MQTT 的各端客戶端實現(xiàn)，降低業(yè)務方接入成本。

我們怎么設計系統(tǒng)架構(gòu)？

在設計項目整體架構(gòu)時，我們優(yōu)先考慮的是：

• 可靠性

• 水平擴展能力

• 依賴組件成熟度

簡單才值得信賴。

為了保證可靠性，我們沒有考慮像傳統(tǒng)長連接系統(tǒng)那樣將內(nèi)部數(shù)據(jù)存儲、計算、消息路由等等組件全部集中到一個大的分布式系統(tǒng)中維護，這樣增大系統(tǒng)實現(xiàn)和維護的復雜度。我們嘗試將這幾部分的組件獨立出來，將存儲、消息路由交給專業(yè)的系統(tǒng)完成，讓每個組件的功能盡量單一且清晰。

同時我們也需要快速地水平擴展能力。互聯(lián)網(wǎng)場景下各種營銷活動都可能導致連接數(shù)陡增，同時發(fā)布訂閱模型系統(tǒng)中下發(fā)消息數(shù)會隨著 Topic 的訂閱者的個數(shù)線性增長，此時網(wǎng)關(guān)暫存的客戶端未接收消息的存儲壓力也倍增。將各個組件拆開后減少了進程內(nèi)部狀態(tài)，我們就可以將服務部署到容器中，利用容器來完成快速而且?guī)缀鯚o限制的水平擴展。

最終設計的系統(tǒng)架構(gòu)如下圖：

系統(tǒng)主要由四個主要組件組成：

接入層使用 OpenResty 實現(xiàn)，負責連接負載均衡和會話保持

長連接 Broker，部署在容器中，負責協(xié)議解析、認證與鑒權(quán)、會話、發(fā)布訂閱等邏輯

Redis 存儲，持久化會話數(shù)據(jù)

Kafka 消息隊列，分發(fā)消息給 Broker 或業(yè)務方

其中 Kafka 和 Redis 都是業(yè)界廣泛使用的基礎組件，它們在知乎都已平臺化和容器化，它們也都能完成分鐘級快速擴容。

我們?nèi)绾螛?gòu)建長連接網(wǎng)關(guān)？

接入層

OpenResty 是業(yè)界使用非常廣泛的支持 Lua 的 Nginx 拓展方案，靈活性、穩(wěn)定性和性能都非常優(yōu)異，我們在接入層的方案選型上也考慮使用 OpenResty。

接入層是最靠近用戶的一側(cè)，在這一層需要完成兩件事：

負載均衡，保證各長連接 Broker 實例上連接數(shù)相對均衡

會話保持，單個客戶端每次連接到同一個 Broker，用來提供消息傳輸可靠性保證

負載均衡其實有很多算法都能完成，不管是隨機還是各種 Hash 算法都能比較好地實現(xiàn)，麻煩一些的是會話保持。

常見的四層負載均衡策略是根據(jù)連接來源 IP 進行一致性 Hash，在節(jié)點數(shù)不變的情況下這樣能保證每次都 Hash 到同一個 Broker 中，甚至在節(jié)點數(shù)稍微改變時也能大概率找到之前連接的節(jié)點。

之前我們也使用過來源 IP Hash 的策略，主要有兩個缺點：

分布不夠均勻，部分來源 IP 是大型局域網(wǎng) NAT 出口，上面的連接數(shù)多，導致 Broker 上連接數(shù)不均衡

不能準確標識客戶端，當移動客戶端掉線切換網(wǎng)絡就可能無法連接回剛才的 Broker 了

所以我們考慮七層的負載均衡，根據(jù)客戶端的唯一標識來進行一致性 Hash，這樣隨機性更好，同時也能保證在網(wǎng)絡切換后也能正確路由。常規(guī)的方法是需要完整解析通訊協(xié)議，然后按協(xié)議的包進行轉(zhuǎn)發(fā)，這樣實現(xiàn)的成本很高，而且增加了協(xié)議解析出錯的風險。

最后我們選擇利用 Nginx 的 preread 機制實現(xiàn)七層負載均衡，對后面長連接 Broker 的實現(xiàn)的侵入性小，而且接入層的資源開銷也小。

Nginx 在接受連接時可以指定預讀取連接的數(shù)據(jù)到 preread buffer 中，我們通過解析 preread buffer 中的客戶端發(fā)送的第一個報文提取客戶端標識，再使用這個客戶端標識進行一致性 Hash 就拿到了固定的 Broker。

發(fā)布與訂閱

我們引入了業(yè)界廣泛使用的消息隊列 Kafka 來作為內(nèi)部消息傳輸?shù)臉屑~。

前面提到了一些這么使用的原因：

• 減少長連接 Broker 內(nèi)部狀態(tài)，讓 Broker 可以無壓力擴容

• 知乎內(nèi)部已平臺化，支持水平擴展

還有一些原因是：

• 使用消息隊列削峰，避免突發(fā)性的上行或下行消息壓垮系統(tǒng)

• 業(yè)務系統(tǒng)中大量使用 Kafka 傳輸數(shù)據(jù)，降低與業(yè)務方對接成本

其中利用消息隊列削峰好理解，下面我們看一下怎么利用 Kafka 與業(yè)務方更好地完成對接。

發(fā)布

長連接 Broker 會根據(jù)路由配置將消息發(fā)布到 Kafka Topic，同時也會根據(jù)訂閱配置去消費 Kafka 將消息下發(fā)給訂閱客戶端。

路由規(guī)則和訂閱規(guī)則是分別配置的，那么可能會出現(xiàn)四種情況：

消息路由到 Kafka Topic，但不消費，適合數(shù)據(jù)上報的場景。

?

?

消息路由到 Kafka Topic，也被消費，普通的即時通訊場景。

直接從 Kafka Topic 消費并下發(fā)，用于純下發(fā)消息的場景。

消息路由到一個 Topic，然后從另一個 Topic 消費，用于消息需要過濾或者預處理的場景。

這套路由策略的設計靈活性非常高，可以解決幾乎所有的場景的消息路由需求。同時因為發(fā)布訂閱基于 Kafka，可以保證在處理大規(guī)模數(shù)據(jù)時的消息可靠性。

訂閱

當長連接 Broker 從 Kafka Topic 中消費出消息后會查找本地的訂閱關(guān)系，然后將消息分發(fā)到客戶端會話。

我們最開始直接使用 HashMap 存儲客戶端的訂閱關(guān)系。當客戶端訂閱一個 Topic 時我們就將客戶端的會話對象放入以 Topic 為 Key 的訂閱 Map 中，當反查消息的訂閱關(guān)系時直接用 Topic 從 Map 上取值就行。

因為這個訂閱關(guān)系是共享對象，當訂閱和取消訂閱發(fā)生時就會有連接嘗試操作這個共享對象。為了避免并發(fā)寫我們給 HashMap 加了鎖，但這個全局鎖的沖突非常嚴重，嚴重影響性能。

最終我們通過分片細化了鎖的粒度，分散了鎖的沖突。

本地同時創(chuàng)建數(shù)百個 HashMap，當需要在某個 Key 上存取數(shù)據(jù)前通過 Hash 和取模找到其中一個 HashMap 然后進行操作，這樣將全局鎖分散到了數(shù)百個 HashMap 中，大大降低了操作沖突，也提升了整體的性能。

會話

持久化

當消息被分發(fā)給會話 Session 對象后，由 Session 來控制消息的下發(fā)。

Session 會判斷消息是否是重要 Topic 消息， 是的話將消息標記 QoS 等級為 1，同時將消息存儲到 Redis 的未接收消息隊列，并將消息下發(fā)給客戶端。等到客戶端對消息的 ACK 后，再將未確認隊列中的消息刪除。

有一些業(yè)界方案是在內(nèi)存中維護了一個列表，在擴容或縮容時這部分數(shù)據(jù)沒法跟著遷移。也有部分業(yè)界方案是在長連接集群中維護了一個分布式內(nèi)存存儲，這樣實現(xiàn)起來復雜度也會變高。

我們將未確認消息隊列放到了外部持久化存儲中，保證了單個 Broker 宕機后，客戶端重新上線連接到其他 Broker 也能恢復 Session 數(shù)據(jù)，減少了擴容和縮容的負擔。

滑動窗口

在發(fā)送消息時，每條 QoS 1 的消息需要被經(jīng)過傳輸、客戶端處理、回傳 ACK 才能確認下發(fā)完成，路徑耗時較長。如果消息量較大，每條消息都等待這么長的確認才能下發(fā)下一條，下發(fā)通道帶寬不能被充分利用。

為了保證發(fā)送的效率，我們參考 TCP 的滑動窗口設計了并行發(fā)送的機制。我們設置一定的閾值為發(fā)送的滑動窗口，表示通道上可以同時有這么多條消息正在傳輸和被等待確認。

我們應用層設計的滑動窗口跟 TCP 的滑動窗口實際上還有些差異。

TCP 的滑動窗口內(nèi)的 IP 報文無法保證順序到達，而我們的通訊是基于 TCP 的所以我們的滑動窗口內(nèi)的業(yè)務消息是順序的，只有在連接狀態(tài)異常、客戶端邏輯異常等情況下才可能導致部分窗口內(nèi)的消息亂序。

因為 TCP 協(xié)議保證了消息的接收順序，所以正常的發(fā)送過程中不需要針對單條消息進行重試，只有在客戶端重新連接后才對窗口內(nèi)的未確認消息重新發(fā)送。消息的接收端同時會保留窗口大小的緩沖區(qū)用來消息去重，保證業(yè)務方接收到的消息不會重復。

我們基于 TCP 構(gòu)建的滑動窗口保證了消息的順序性同時也極大提升傳輸?shù)耐掏铝俊?/p>

?

寫在最后

基礎架構(gòu)組負責知乎的流量入口和內(nèi)部基礎設施建設，對外我們奮斗在直面海量流量的的第一戰(zhàn)線，對內(nèi)我們?yōu)樗械臉I(yè)務提供堅如磐石的基礎設施，用戶的每一次訪問、每一個請求、內(nèi)網(wǎng)的每一次調(diào)用都與我們的系統(tǒng)息息相關(guān)。

總結(jié)

以上是生活随笔為你收集整理的图文：知乎千万级高性能长连接网关是如何搭建的？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。