長連接網(wǎng)關(guān)技術(shù)專題(十)：百度基于Go的千萬級統(tǒng)一長連接服務架構(gòu)實踐

Posted on 2024-03-07 10:59 Jack Jiang 閱讀(114) 評論(0) 編輯收藏

本文由百度技術(shù)團隊分享，引用自百度Geek說，原題“千萬級高性能長連接Go服務架構(gòu)實踐”，為了閱讀便利，本文進行了排版優(yōu)化等。

1、引言

移動互聯(lián)網(wǎng)時代，長連接服務成為了提升應用實時性和互動性的基礎(chǔ)服務。

本文將介紹百度基于golang實現(xiàn)的統(tǒng)一長連接服務，從統(tǒng)一長連接功能實現(xiàn)和性能優(yōu)化等角度，描述了其在設(shè)計、開發(fā)和維護過程中面臨的問題和挑戰(zhàn)，并重點介紹了解決相關(guān)問題和挑戰(zhàn)的方案和實踐經(jīng)驗。

* 關(guān)聯(lián)文章：《百度統(tǒng)一socket長連接組件從0到1的技術(shù)實踐》、《淘寶移動端統(tǒng)一網(wǎng)絡庫的架構(gòu)演進和弱網(wǎng)優(yōu)化技術(shù)實踐》，建議可一并閱讀。

技術(shù)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4623-1-1.html）

2、專題目錄

本文是專題系列文章的第10篇，總目錄如下：

《長連接網(wǎng)關(guān)技術(shù)專題(一)：京東京麥的生產(chǎn)級TCP網(wǎng)關(guān)技術(shù)實踐總結(jié)》
《長連接網(wǎng)關(guān)技術(shù)專題(二)：知乎千萬級并發(fā)的高性能長連接網(wǎng)關(guān)技術(shù)實踐》
《長連接網(wǎng)關(guān)技術(shù)專題(三)：手淘億級移動端接入層網(wǎng)關(guān)的技術(shù)演進之路》
《長連接網(wǎng)關(guān)技術(shù)專題(四)：愛奇藝WebSocket實時推送網(wǎng)關(guān)技術(shù)實踐》
《長連接網(wǎng)關(guān)技術(shù)專題(五)：喜馬拉雅自研億級API網(wǎng)關(guān)技術(shù)實踐》
《長連接網(wǎng)關(guān)技術(shù)專題(六)：石墨文檔單機50萬WebSocket長連接架構(gòu)實踐》
《長連接網(wǎng)關(guān)技術(shù)專題(七)：小米小愛單機120萬長連接接入層的架構(gòu)演進》
《長連接網(wǎng)關(guān)技術(shù)專題(八)：B站基于微服務的API網(wǎng)關(guān)從0到1的演進之路》
《長連接網(wǎng)關(guān)技術(shù)專題(九)：去哪兒網(wǎng)酒店高性能業(yè)務網(wǎng)關(guān)技術(shù)實踐》
《長連接網(wǎng)關(guān)技術(shù)專題(十)：百度基于Go的千萬級統(tǒng)一長連接服務架構(gòu)實踐》（* 本文）

3、內(nèi)容概述

移動互聯(lián)網(wǎng)時代，用戶對服務的實時性、互動性有了更高的要求，因此能夠極大提升服務實時性、互動性的長連接服務，成為了移動互聯(lián)網(wǎng)應用的剛需。

長連接，顧名思義，是應用存活期間和服務端一直保持的網(wǎng)絡數(shù)據(jù)通道，能夠支持全雙工上下行數(shù)據(jù)傳輸。其和請求響應模式的短連接服務最大的差異，在于它可以提供服務端主動給用戶實時推送數(shù)據(jù)的能力。

不過：長連接作為基礎(chǔ)服務，要做到低延時、高并發(fā)、高穩(wěn)定性，對服務的開發(fā)和維護有較高的要求。

如果每個業(yè)務都維護自身的長連接服務，一方面有較大的重復開發(fā)和維護成本，另一方面長連接服務功能迭代、服務穩(wěn)定性、專業(yè)性很難跟上業(yè)務訴求。

因此：統(tǒng)一長連接項目通過打造完整的端到服務端的長連接服務系統(tǒng)，給業(yè)務提供一套安全、高并發(fā)、低延遲、易接入、低成本的長連接服務能力。

4、需要什么樣的統(tǒng)一長連接服務

統(tǒng)一長連接服務主要目的是給業(yè)務提供一套安全、高并發(fā)、低延遲、易接入、低成本的長連接服務系統(tǒng)。

主要愿景包括：

1）滿足百度體系內(nèi)APP主要場景如直播、消息、PUSH、云控等業(yè)務對長連接能力的訴求，提供安全構(gòu)建、維護長連接和數(shù)據(jù)上下行能力；
2）保障服務的高并發(fā)、高穩(wěn)定性、低延遲，保障長連接服務的專業(yè)性和先進性；
3）支持長連接多業(yè)務長連接復用，減少APP建立和維護長連接的成本和壓力；
4）支持業(yè)務快速接入長連接，提供給業(yè)務簡單清晰的接入流程和對外接口。

5、問題和挑戰(zhàn)1：功能實現(xiàn)

統(tǒng)一長連接服務與接入業(yè)務的邊界關(guān)系是長連接業(yè)務架構(gòu)設(shè)計的首要問題。

與業(yè)務專用的長連接服務不同，統(tǒng)一長連接服務要實現(xiàn)的目標是多業(yè)務方共用一條長連接。因此在設(shè)計時既要考慮到不同業(yè)務方、不同業(yè)務場景對長連接服務的訴求，同時，也要明確長連接服務的服務邊界，避免過多介入業(yè)務邏輯，限制后續(xù)長連接服務的迭代和發(fā)展。

通常，業(yè)務對長連接服務的主要訴求包括三個方面：

1）連接建立、維護、管理；
2）上行請求轉(zhuǎn)發(fā)；
3）下行數(shù)據(jù)推送。

數(shù)據(jù)上下行過程中，需要能夠支持不同業(yè)務數(shù)據(jù)協(xié)議上的差異。

此外，根據(jù)不同的業(yè)務類型，對下行數(shù)據(jù)推送模式、推送量級有著不同的要求。

以長連接服務常見的消息、直播、PUSH業(yè)務方為例：

1）消息場景：主要是私信和有人數(shù)限制(500-1000)的群聊，推送通知的模式主要是單播和批量單播，推送頻率和并發(fā)度，依賴于私信和群里消息的發(fā)送頻率；
2）直播消息場景：直播消息是一個組播場景，組播成員數(shù)和直播間在線人數(shù)相關(guān)，峰值百萬甚至千萬，推送消息頻率高；
3）PUSH場景：PUSH 場景是對一個固定人群下發(fā)消息，推送模式是批量單播，推送頻率相對而言比較低。

綜上，統(tǒng)一長連接服務，要實現(xiàn)的服務能力如下：

1）連接建立、維護、管理；
2）上、下行數(shù)據(jù)轉(zhuǎn)發(fā)，區(qū)分不同業(yè)務、兼容不同業(yè)務消息協(xié)議；
3）下行推送上，支持單播、批量單播、廣播。

6、問題和挑戰(zhàn)2：性能優(yōu)化

統(tǒng)一長連接服務因為要給百度體系A(chǔ)PP提供長連接能力的服務，要做到高并發(fā)、高可用、高穩(wěn)定性。具體到長連接服務本身，其主要包括以下幾個方面。

1 ）建聯(lián)qps、延時、成功率、連接維持：

長連接在app打開同時需要完成建立、并在app存活期間保持連接存活。

因此，長連接服務要支持萬級別的建聯(lián)qps和千萬級別在在線連接維持，并支持橫向擴容。

此外，連接建立作為長連接服務的基礎(chǔ)，建聯(lián)的成功率和延時重中之重。

2）上行請求qps、延時、成功率：

連接建立完成后，需要將業(yè)務請求轉(zhuǎn)發(fā)給業(yè)務側(cè)，這個依賴于用戶規(guī)模和請求頻率，一般至少要支持到幾十乃至百萬級別，并可以支持橫向擴容。

3）下行請求qps，延時、成功率：

下行請求根據(jù)業(yè)務場景的不同，分為批量單播和組播，且不同業(yè)務對應請求qps要求不一樣，一般批量單播需要支持到百萬級ups，組播要支持到千萬級ups，且支持橫向擴容。

7、整體設(shè)計

下面簡單介紹下，為了完成上述目標，統(tǒng)一長連接服務所做的一些方案設(shè)計和實踐經(jīng)驗。

7.1整體架構(gòu)

統(tǒng)一長連接服務整體架構(gòu)如上圖所示，整個服務包括四個部分組成：

1）統(tǒng)一長連接SDK；
2）控制層；
3）接入層；
4）路由層。

統(tǒng)一長連接SDK歸屬于客戶端，控制層、接入層、路由層歸屬于服務端。每個組成部分在整體系統(tǒng)中的扮演的角色和功能如下。

1）統(tǒng)一長連接SDK：

統(tǒng)一長連接SDK歸屬于客戶端，負責連通業(yè)務SDK和長連接服務端。

其主要職責包括：

1）請求控制層，獲取能夠標識設(shè)備合法身份的token、長連接接入點和長連接接入?yún)f(xié)議；
2）同長連接接入層建立、維護長連接，在連接狀態(tài)異常時，主動觸發(fā)連接重連，維護端上連接的穩(wěn)定；
3）轉(zhuǎn)發(fā)各業(yè)務SDK請求到長連接服務。
4）接受長連接下發(fā)的數(shù)據(jù)并將數(shù)據(jù)轉(zhuǎn)發(fā)給指定的業(yè)務SDK。

2）控制層：

長連接建聯(lián)之前的一個前置服務，主要用來驗證接入設(shè)備的合法性和決定設(shè)備的接入策略。

其主要職責包括：

1）生成和驗證標識設(shè)備合法性的token；
2）根據(jù)客戶端屬性下發(fā)對應的接入點；
3）負責小流量控制策略等。

3）接入層：

接入層作為統(tǒng)一長連接核心服務，承擔了連接介入，連接維護、請求轉(zhuǎn)發(fā)、下行推送等主要功能，是長連接核心邏輯和主要壓力的承擔者。

其主要職責包括：

1）對端通訊：負責與長連接SDK建立、維護、釋放長連接；
2）連接管理：負責連接管理、構(gòu)建連接ID->連接信息的映射關(guān)系；
3）組管理：負責連接組的管理，構(gòu)建組ID-> 連接信息的映射關(guān)系；
4）上行轉(zhuǎn)發(fā)：接受并轉(zhuǎn)發(fā)業(yè)務請求到業(yè)務后端，接受業(yè)務后端的返回，并寫回給長連接SDK；
5）下行推送：接受業(yè)務的推送請求，寫到對應的長連接SDK。

4）路由層：

負責構(gòu)建設(shè)備標識和連接標識的映射關(guān)系，在業(yè)務指定設(shè)備標識進行推送的時候，提供設(shè)備標識查詢連接標識的能力。

7.2核心流程

長連接生命周期內(nèi)主要有四個核心流程：

1）建立連接；
2）維持連接；
3）上行請求；
4）下行推送。

具體是：

1）建立連接：由長連接SDK發(fā)起，先通過控制層獲取該設(shè)備的合法標識token和接入配置（接入點、接入?yún)f(xié)議），然后和接入層開始建聯(lián)長連接，成功則長連接建立完成；
2）維持連接：主要是通過長連接SDK定時發(fā)起心跳來保證長連接活躍；
3）上行請求：上行請求由業(yè)務SDK發(fā)起，長連接SDK封裝后發(fā)送給接入層，接入層根據(jù)請求來源發(fā)送給指定的業(yè)務Server；
4）下行推送：下行推送由業(yè)務Server發(fā)起，經(jīng)由路由層根據(jù)設(shè)備標識確定連接標識，然后將請求轉(zhuǎn)發(fā)到對應的接入層，寫入到設(shè)備指定連接上，經(jīng)由長連接SDK轉(zhuǎn)發(fā)給業(yè)務SDK。

8、功能實現(xiàn)

8.1連接狀態(tài)

長連接由于連接生命周期較長，在周期內(nèi)連接可能會因為各種網(wǎng)絡情況、數(shù)據(jù)傳輸異常導致連接發(fā)生狀態(tài)變化。同時也為了防止惡意設(shè)備模擬正常的客戶端對長連接服務進行攻擊，需要有一套機制能夠讓服務端驗證長連接狀態(tài)是合法有效的，同時對于處于異常狀態(tài)的連接，能夠觸發(fā)其重連并快速恢復。

統(tǒng)一長連接通過引入狀態(tài)機的方式構(gòu)建了該機制。即明確定義長連接在生命周期內(nèi)可能存在的各種狀態(tài)、每種狀態(tài)可以觸發(fā)的操作，以及狀態(tài)間相關(guān)轉(zhuǎn)移的場景等。

比如：

1）連接在可以發(fā)送數(shù)據(jù)前，需要通過登錄驗證連接合法有效，認證通過后的連接才能視為有效連接并支持上下行數(shù)據(jù)傳輸；
2）登錄后的連接如果發(fā)生異常情況，比如數(shù)據(jù)格式異常、網(wǎng)絡狀態(tài)異常，會觸發(fā)連接失效觸發(fā)端上重新建聯(lián)登錄等等。

引入這種的機制好處是：簡化長連接狀態(tài)流轉(zhuǎn)的開發(fā)邏輯，長連接生命周期里面每種狀態(tài)以及狀態(tài)間轉(zhuǎn)移關(guān)系，觸發(fā)的操作都是明確定義的，避免了線上因為各種未知原因?qū)е逻B接處于不可知狀態(tài)，導致長連接異常甚至無法恢復。

8.2多業(yè)務支持

統(tǒng)一長連接一個主要愿景是支持多業(yè)務復用一條長連接，即同一條連接上，能夠兼容不同業(yè)務的數(shù)據(jù)協(xié)議，且在上下行業(yè)務數(shù)據(jù)傳輸時候能夠區(qū)分不同業(yè)務的請求轉(zhuǎn)發(fā)給指定業(yè)務。

這個主要是通過長連接私有數(shù)據(jù)協(xié)議來支持，長連接數(shù)據(jù)協(xié)議是長連接SDK和長連接接入層交互使用的數(shù)據(jù)協(xié)議，采用的二進制私有協(xié)議。

協(xié)議主要分為三部分：

1）協(xié)議頭：包括協(xié)議標識、協(xié)議版本等；
2）公參：設(shè)備標識、應用標識、業(yè)務標識、請求元數(shù)據(jù)等；
3）業(yè)務數(shù)據(jù)：業(yè)務自定義數(shù)據(jù)，用來兼容不同業(yè)務的數(shù)據(jù)協(xié)議。

通過解析協(xié)議公參里面的業(yè)務標識，長連接SDK和長連接接入層能夠確認業(yè)務數(shù)據(jù)對應的業(yè)務方，并根據(jù)業(yè)務標識將請求做對應轉(zhuǎn)發(fā)。業(yè)務的請求數(shù)據(jù)放在業(yè)務數(shù)據(jù)部分，協(xié)議有業(yè)務側(cè)指定，長連接服務只做轉(zhuǎn)發(fā)，不介入業(yè)務具體細節(jié)。

8.3上行請求轉(zhuǎn)發(fā)

接入層根據(jù)業(yè)務標識確認業(yè)務數(shù)據(jù)來源后，會通過RPC請求將業(yè)務數(shù)據(jù)轉(zhuǎn)發(fā)給業(yè)務server，然后將業(yè)務Server的返回寫回給端上。

上行請求轉(zhuǎn)發(fā)除了會轉(zhuǎn)發(fā)業(yè)務上行請求數(shù)據(jù)外，也會講長連接公參數(shù)據(jù)一并帶給業(yè)務Server。

除此外，如果業(yè)務有訴求，在連接狀態(tài)發(fā)生變化，比如連接斷開等，長連接接入層也可以將該信號實時通知業(yè)務Server，以便業(yè)務Server 根據(jù)狀態(tài)信號變化做進一步操作。

8.4單播&多播推送

下行推送，根據(jù)業(yè)務需要，主要分為兩類，單播推送和組播推送，以下對比了單播推送和組播的差異。

1）單播推送：

服務端主動推送時候，比如一個業(yè)務要給某個設(shè)備推消息，由于接入層是多實例部署的，首先需要知道這個設(shè)備與哪個長連接實例相連。其次需要知道這個設(shè)備與這個實例內(nèi)哪條長連接相關(guān)聯(lián)，那么這個實例地址和對應的長連接一期就構(gòu)成了這個設(shè)備當時的連接信息，給某個用戶推消息。本質(zhì)上就是通過用戶設(shè)備找到這個設(shè)備對應的連接信息的過程，也就是設(shè)備ID -> 連接信息（實例ip+連接ID）映射關(guān)系的過程，路由層負責構(gòu)建和維護設(shè)備和連接信息的一個模塊。

這個對業(yè)務的主要成本是確定需要推送用戶的設(shè)備ID：

1）對于一些業(yè)務本身的業(yè)務場景是設(shè)備維度的，那就可以直接通過接口進行推送；
2）對于一些業(yè)務本身的業(yè)務場景是用戶維度的，一個用戶可以有多個設(shè)備，那么業(yè)務側(cè)需要做一個用戶->設(shè)備的映射關(guān)系，給用戶推消息，需要做用戶->設(shè)備，然后設(shè)備->連接信息的兩層轉(zhuǎn)換。

2）組播推送：

此外，由于下行推送的時候，在某些場景下，會存在需要給大批量用戶推送相同消息的場景，比如直播（聊天室）。

路由層會維護一個連接組信息，連接組ID->組內(nèi)連接信息的映射。連接組的創(chuàng)建、連接加入和退出連接組，主要由對應的業(yè)務場景來控制，路由層只提供對應的接口能力，在連接組建立好后，向?qū)倪B接組推消息，長連接服務會自動將消息拆分發(fā)給組內(nèi)每一條連接。

使用連接組，業(yè)務需要做的事情：

1）連接組創(chuàng)建；
2）客戶端主動加入和退出連接組；
3）根據(jù)連接ID，推送消息。

9、性能優(yōu)化

9.1多協(xié)議支持

長連接底層強依賴 tcp&tls、quic、websocket 等通訊協(xié)議。

一方面，不同的場景，可能會使用到不同的通訊協(xié)議，比如NA端一般傾向于tcp和tls，小程序和web端傾向于websocket。一方面，現(xiàn)有協(xié)議的迭代和新協(xié)議的出現(xiàn)，也會給長連接的性能和通道質(zhì)量帶來優(yōu)化。因此，為了適配不同場景下的通訊協(xié)議，同時也為了能夠快速探索通訊協(xié)議迭代對長連接服務質(zhì)量的提升。統(tǒng)一長連接做了對不同通訊協(xié)議的兼容。

即為了支持多種通訊協(xié)議，接入層對連接概念做了劃分，將連接分為了兩層，connection 和 session。

1）connection層: 和具體的通訊層協(xié)議交互，封裝不同通訊協(xié)議的接口和邏輯差異，比如tls、websocket、quic 等等。同時給上層session 層提供統(tǒng)一的數(shù)據(jù)接口，包括連接建立、數(shù)據(jù)讀取、寫入、連接信息獲取等。新協(xié)議的接入，只需要在connection做相應適配，不影響session層的長連接業(yè)務邏輯。

2）session層：長連接業(yè)務級別連接概念，維護長連接業(yè)務連接狀態(tài)，維護連接狀態(tài)機，支持請求轉(zhuǎn)發(fā)、下行推送等業(yè)務邏輯，本身依賴connection層提供的數(shù)據(jù)接口和實際的通訊協(xié)議進行交互。但是不感知具體的通訊協(xié)議差異。

同時，端上在建聯(lián)時，控制層會根據(jù)客戶端當前的情況，比如端類型（NA、小程序、Web）、當前的網(wǎng)絡類型（4G、5G）、設(shè)備質(zhì)量情況等，下發(fā)不同的建聯(lián)協(xié)議和對應的接入點，端上根據(jù)下發(fā)的建議協(xié)議和接入點，結(jié)合端上自身情況，選用合適的接入?yún)f(xié)議和接入點進行建聯(lián)。

這樣設(shè)計的主要優(yōu)勢在于：

1）長連接業(yè)務邏輯和通訊協(xié)議做了隔離，通訊協(xié)議的更新和新增，不影響長連接狀態(tài)機、請求轉(zhuǎn)發(fā)、下行推送等業(yè)務邏輯，簡化了兼容多通訊協(xié)議的實現(xiàn)難度，實現(xiàn)一套架構(gòu)支持多通訊協(xié)議接入。
2）客戶端可以根據(jù)實際情況，采用不同的通訊協(xié)議接入，通訊協(xié)議帶來的通道質(zhì)量優(yōu)勢能夠很好的體現(xiàn)在長連接服務質(zhì)量上。

9.2請求轉(zhuǎn)發(fā)組&下行任務組

連接建立完成后，接入層主要面臨著三個壓力來源：

1）連接維持；
2）請求轉(zhuǎn)發(fā)；
3）下行推送。

按照單個實例需要支持百萬連接來考慮：

1）假定單個連接心跳為1分鐘1次，則連接維持需要支持1.6w qps心跳請求；
2）請求轉(zhuǎn)發(fā)依賴于業(yè)務請求頻率，通常百萬在線至少需要支持1-2w qps 上行請求；
3）下行推送，根據(jù)推送場景的不同，通常組播場景下需要支持5-10w ups下行。

綜上：單個實例如果要支持百萬連接，通常需要支持3-4w qps 上行，5-10w 的ups下行。

統(tǒng)一長連接層接入層服務是使用golang來實現(xiàn)的，按照golang 常用的網(wǎng)絡模型，一條連接會有對應兩個goroutine，一個用來讀數(shù)據(jù)和處理數(shù)據(jù)，一個用來寫數(shù)據(jù)。

這個模型存在兩個問題：

1）統(tǒng)一長連接是多業(yè)務復用一個連接，連接上會存在同時有多個請求上行，一個goroutine讀和處理數(shù)據(jù)，如果一個請求處理比較慢，會導致后續(xù)其他請求處理排隊的情況；
2）每個連接至少需要2個goroutine,如果單實例需要支持一百萬連接，則單個實例常態(tài)下會有200萬goroutine, 而且，長連接服務，連接的建立和釋放非常頻繁，這個會導致goroutine的建聯(lián)和釋放也非常頻繁，進而給服務的gc帶來巨大的壓力。

統(tǒng)一長連接通過引入請求轉(zhuǎn)發(fā)組和下行任務組來解決上述兩個問題。

1）請求轉(zhuǎn)發(fā)組：

接入層在實例啟動的時候，會根據(jù)支持的業(yè)務上行qps，初始化對應的請求轉(zhuǎn)發(fā)組，連接在讀取完請求數(shù)據(jù)后，會根據(jù)請求屬于那個業(yè)務將請求轉(zhuǎn)給對應的請求轉(zhuǎn)發(fā)組，由請求轉(zhuǎn)發(fā)組內(nèi)的goroutine完成后續(xù)請求。

不同業(yè)務的請求轉(zhuǎn)發(fā)組是不同的goroutine池，避免業(yè)務間相互影響。連接本身的讀goroutine只是負責讀取數(shù)據(jù)，轉(zhuǎn)發(fā)請求給請求轉(zhuǎn)發(fā)組，避免請求處理存在排隊的情況。

2）下行任務組：

下行數(shù)據(jù)寫入的時候，會有一個公共的任務組，每個連接在任務組中會有一個固定的處理協(xié)程，有數(shù)據(jù)下行的時候會講寫入數(shù)據(jù)的任務發(fā)到下行任務組。

這個主要目的是，由于單個實例需要維護大量的在線長連接，每個長連接通常需要兩個協(xié)程，一個讀協(xié)程、一個寫協(xié)程，如果單實例支持50w連接，也就會單實例存在百萬協(xié)程，這個對服務gc和資源都會造成一定的壓力。

同時，一個實例維持的所有連接通常不會同時都下行寫消息，因而，可以通過維護一個下行任務組，任務組里面維護動態(tài)數(shù)量的協(xié)程數(shù)，每個連接綁定任務組里面一個協(xié)程，有下行任務時將任務發(fā)送到任務組里面，有任務組里面的協(xié)程負責將任務下行，減少實例服務壓力。

9.3服務部署

統(tǒng)一長連接服務部署上，主要做了以下幾點。

1）長連接在國內(nèi)三大運營商的華東、華北、華南地域均部署了接入點；部分業(yè)務需要支持海外業(yè)務，增加了香港機房的獨立接入點入口。

2）根據(jù)業(yè)務量級和重要性，分大小集群部署，每個集群對應不同的域名，不同業(yè)務通過控制層下發(fā)域名分流到對應集群。主要目的針對于重點業(yè)務，提供獨立部署的能力；對于次級業(yè)務，提供混部服務，降低成本和提高資源利用率。

3）針對接入層每個實例，將實例的配置和能夠支持的連接數(shù)，控制在10w-20w量級，避免單個實例支持連接數(shù)過多，實例發(fā)生服務抖動時，對整個集群服務產(chǎn)生較大影響；單個實例支持的連接數(shù)有限制，減少實例內(nèi)常態(tài)維護的goroutine數(shù)，減輕gc壓力。

10、業(yè)務接入

業(yè)務接入統(tǒng)一長連接通常涉及以下幾個步驟：

1）評估需要接入的能力：評估需要接入的長連接能力，比如下行推送中，是要接批量單播還是組播；是否要支持上行請求等，根據(jù)接入能力不同，需要對接不同的接口；
2）評估用戶量級：用戶量級涉及到資源評估以及是否需要單獨進行集群部署等等；
3）端上接入長連接SDK：客戶端需要接入長連接SDK，接入上下行收發(fā)消息接口；
4）服務端接入上下行接口：服務端需要根據(jù)接入能力，適配不同的服務端接口；
5）申請資源服務上線。

11、本文小結(jié)

目前統(tǒng)一長連接已支持了千萬級長連接并發(fā)在線，支持過百萬級ups 批量單播和組播消息下行，擁有實時橫向擴容能力。

服務第一次完成上線至今，長連接服務穩(wěn)定，經(jīng)歷過多次重大活動高并發(fā)推送的考驗，沒有出現(xiàn)過任何影響其他業(yè)務服務質(zhì)量的case。

總的來說，統(tǒng)一長連接項目從立項、開發(fā)到最后上線運維，服務質(zhì)量整體上是符合預期的。

從統(tǒng)一長連接項目整個項目流程，主要總結(jié)有以下三點經(jīng)驗：

1）需求：分析需求時候，要明確需求和業(yè)務的邊界，也就是明確什么應該長連接的能力，什么是業(yè)務邏輯，堅持長連接服務不深入介入業(yè)務邏輯這個原則，保證長連接服務與業(yè)務的邏輯解耦，確保長連接服務結(jié)構(gòu)的穩(wěn)定；
2）設(shè)計：需求明確的情況下，技術(shù)的方案的選擇以簡單滿足要求為優(yōu)先，長連接服務本身邏輯并不復雜，其主要在于服務的穩(wěn)定性和高性能，巧妙而復雜的方案在長連接的場景下，并不一定能夠適用；
3）運維：追求單實例性能的同時，也要在性能和運維之間做取舍，單實例性能再強，能夠支持的連接數(shù)再多，通常也比不上分拆多個小實例，帶來的穩(wěn)定性和資源利用率的提升大。