先簡單說下本次的主題，由于我最近做的是物聯(lián)網(wǎng)相關(guān)的開發(fā)工作，其中就不免會遇到和設(shè)備的交互。
最主要的工作就是要有一個系統(tǒng)來支持設(shè)備的接入售淡、向設(shè)備推送消息斤葱；同時還得滿足大量設(shè)備接入的需求慷垮。
所以本次分享的內(nèi)容不但可以滿足物聯(lián)網(wǎng)領(lǐng)域同時還支持以下場景：
基于 WEB 的聊天系統(tǒng)（點對點、群聊）揍堕。
WEB 應(yīng)用中需求服務(wù)端推送的場景料身。
基于 SDK 的消息推送平臺。
技術(shù)選型
要滿足大量的連接數(shù)衩茸、同時支持雙全工通信芹血，并且性能也得有保障。
在 Java 技術(shù)棧中進行選型首先自然是排除掉了傳統(tǒng) IO。
那就只有選 NIO 了幔烛，在這個層面其實選擇也不多啃擦，考慮到社區(qū)、資料維護等方面最終選擇了 Netty饿悬。
最終的架構(gòu)圖如下：
現(xiàn)在看著蒙沒關(guān)系令蛉，下文一一介紹。
另外現(xiàn)在私信我“資料”即可獲取Java工程化狡恬、高性能及分布式珠叔、高性能、高架構(gòu)弟劲。性能調(diào)優(yōu)祷安、Spring，MyBatis兔乞，Netty源碼分析和大數(shù)據(jù)等多個知識點高級進階干貨的直播免費學(xué)習(xí)權(quán)限及領(lǐng)取相關(guān)資料
協(xié)議解析
既然是一個消息系統(tǒng)汇鞭，那自然得和客戶端定義好雙方的協(xié)議格式。
常見和簡單的是 HTTP 協(xié)議庸追，但我們的需求中有一項需要是雙全工的交互方式虱咧，同時 HTTP 更多的是服務(wù)于瀏覽器。我們需要的是一個更加精簡的協(xié)議锚国，減少許多不必要的數(shù)據(jù)傳輸腕巡。
因此我覺得最好是在滿足業(yè)務(wù)需求的情況下定制自己的私有協(xié)議，在我這個場景下其實有標(biāo)準(zhǔn)的物聯(lián)網(wǎng)協(xié)議血筑。
如果是其他場景可以借鑒現(xiàn)在流行的 RPC 框架定制私有協(xié)議绘沉，使得雙方通信更加高效。
不過根據(jù)這段時間的經(jīng)驗來看豺总，不管是哪種方式都得在協(xié)議中預(yù)留安全相關(guān)的位置车伞。
協(xié)議相關(guān)的內(nèi)容就不過討論了，更多介紹具體的應(yīng)用喻喳。
簡單實現(xiàn)
首先考慮如何實現(xiàn)功能另玖，再來思考百萬連接的情況。
注冊鑒權(quán)
在做真正的消息上表伦、下行之前首先要考慮的就是鑒權(quán)問題谦去。
就像你使用微信一樣，第一步怎么也得是登錄吧蹦哼，不能無論是誰都可以直接連接到平臺鳄哭。
所以第一步得是注冊才行。
如上面架構(gòu)圖中的 注冊/鑒權(quán) 模塊纲熏。通常來說都需要客戶端通過 HTTP 請求傳遞一個唯一標(biāo)識妆丘，后臺鑒權(quán)通過之后會響應(yīng)一個 token锄俄，并將這個 token 和客戶端的關(guān)系維護到 Redis 或者是 DB 中。
客戶端將這個 token 也保存到本地勺拣，今后的每一次請求都得帶上這個 token奶赠。一旦這個 token 過期，客戶端需要再次請求獲取 token药有。
鑒權(quán)通過之后客戶端會直接通過TCP 長連接到圖中的 push-server 模塊车柠。
這個模塊就是真正處理消息的上、下行塑猖。
保存通道關(guān)系
在連接接入之后竹祷，真正處理業(yè)務(wù)之前需要將當(dāng)前的客戶端和 Channel 的關(guān)系維護起來。
假設(shè)客戶端的唯一標(biāo)識是手機號碼羊苟，那就需要把手機號碼和當(dāng)前的 Channel 維護到一個 Map 中塑陵。
這點和之前 SpringBoot 整合長連接心跳機制 類似。
同時為了可以通過 Channel 獲取到客戶端唯一標(biāo)識（手機號碼）蜡励，還需要在 Channel 中設(shè)置對應(yīng)的屬性：
public static void putClientId(Channel channel, String clientId) {
channel.attr(CLIENT_ID).set(clientId);
}
復(fù)制代碼
獲取時手機號碼時：
public static String getClientId(Channel channel) {
return (String)getAttribute(channel, CLIENT_ID);
}
復(fù)制代碼
這樣當(dāng)我們客戶端下線的時便可以記錄相關(guān)日志：
String telNo = NettyAttrUtil.getClientId(ctx.channel());
NettySocketHolder.remove(telNo);
log.info("客戶端下線令花，TelNo=" + telNo);
復(fù)制代碼
這里有一點需要注意：存放客戶端與 Channel 關(guān)系的 Map 最好是預(yù)設(shè)好大小（避免經(jīng)常擴容）凉倚，因為它將是使用最為頻繁同時也是占用內(nèi)存最大的一個對象兼都。
消息上行
接下來則是真正的業(yè)務(wù)數(shù)據(jù)上傳，通常來說第一步是需要判斷上傳消息輸入什么業(yè)務(wù)類型稽寒。
在聊天場景中扮碧，有可能上傳的是文本、圖片杏糙、視頻等內(nèi)容慎王。
所以我們得進行區(qū)分，來做不同的處理宏侍；這就和客戶端協(xié)商的協(xié)議有關(guān)了赖淤。
可以利用消息頭中的某個字段進行區(qū)分。
更簡單的就是一個 JSON 消息谅河，拿出一個字段用于區(qū)分不同消息咱旱。
不管是哪種只有可以區(qū)分出來即可。
消息解析與業(yè)務(wù)解耦
消息可以解析之后便是處理業(yè)務(wù)绷耍，比如可以是寫入數(shù)據(jù)庫吐限、調(diào)用其他接口等。
我們都知道在 Netty 中處理消息一般是在 channelRead() 方法中锨天。
在這里可以解析消息毯盈，區(qū)分類型剃毒。
但如果我們的業(yè)務(wù)邏輯也寫在里面病袄，那這里的內(nèi)容將是巨多無比搂赋。
甚至我們分為好幾個開發(fā)來處理不同的業(yè)務(wù)，這樣將會出現(xiàn)許多沖突益缠、難以維護等問題脑奠。
所以非常有必要將消息解析與業(yè)務(wù)處理完全分離開來。
這時面向接口編程就發(fā)揮作用了幅慌。
這里的核心代碼和 「造個輪子」——cicada(輕量級 WEB 框架) 是一致的宋欺。
都是先定義一個接口用于處理業(yè)務(wù)邏輯，然后在解析消息之后通過反射創(chuàng)建具體的對象執(zhí)行其中的處理函數(shù)即可胰伍。
這樣不同的業(yè)務(wù)齿诞、不同的開發(fā)人員只需要實現(xiàn)這個接口同時實現(xiàn)自己的業(yè)務(wù)邏輯即可。
偽代碼如下：
想要了解 cicada 的具體實現(xiàn)請點擊這里：
github.com/TogetherOS/…
上行還有一點需要注意骂租；由于是基于長連接祷杈，所以客戶端需要定期發(fā)送心跳包用于維護本次連接。同時服務(wù)端也會有相應(yīng)的檢查渗饮，N 個時間間隔沒有收到消息之后將會主動斷開連接節(jié)省資源但汞。
這點使用一個 IdleStateHandler 就可實現(xiàn)，更多內(nèi)容可以查看 Netty(一) SpringBoot 整合長連接心跳機制互站。
消息下行
有了上行自然也有下行私蕾。比如在聊天的場景中，有兩個客戶端連上了 push-server,他們直接需要點對點通信胡桃。
這時的流程是：
A 將消息發(fā)送給服務(wù)器踩叭。
服務(wù)器收到消息之后，得知消息是要發(fā)送給 B翠胰，需要在內(nèi)存中找到 B 的 Channel懊纳。
通過 B 的 Channel 將 A 的消息轉(zhuǎn)發(fā)下去。
這就是一個下行的流程亡容。
甚至管理員需要給所有在線用戶發(fā)送系統(tǒng)通知也是類似：
遍歷保存通道關(guān)系的 Map嗤疯，挨個發(fā)送消息即可。這也是之前需要存放到 Map 中的主要原因闺兢。
偽代碼如下：
具體可以參考：
github.com/crossoverJi…
分布式方案
單機版的實現(xiàn)了茂缚，現(xiàn)在著重講講如何實現(xiàn)百萬連接。
百萬連接其實只是一個形容詞屋谭，更多的是想表達(dá)如何來實現(xiàn)一個分布式的方案脚囊，可以靈活的水平拓展從而能支持更多的連接。
再做這個事前首先得搞清楚我們單機版的能支持多少連接桐磁。影響這個的因素就比較多了悔耘。
服務(wù)器自身配置。內(nèi)存我擂、CPU衬以、網(wǎng)卡缓艳、Linux 支持的最大文件打開數(shù)等。
應(yīng)用自身配置看峻，因為 Netty 本身需要依賴于堆外內(nèi)存阶淘，但是 JVM 本身也是需要占用一部分內(nèi)存的，比如存放通道關(guān)系的大 Map互妓。這點需要結(jié)合自身情況進行調(diào)整溪窒。
結(jié)合以上的情況可以測試出單個節(jié)點能支持的最大連接數(shù)。
單機無論怎么優(yōu)化都是有上限的冯勉，這也是分布式主要解決的問題澈蚌。
架構(gòu)介紹
在將具體實現(xiàn)之前首先得講講上文貼出的整體架構(gòu)圖。
先從左邊開始灼狰。
上文提到的 注冊鑒權(quán) 模塊也是集群部署的惜浅，通過前置的 Nginx 進行負(fù)載。之前也提過了它主要的目的是來做鑒權(quán)并返回一個 token 給客戶端伏嗜。
但是 push-server 集群之后它又多了一個作用坛悉。那就是得返回一臺可供當(dāng)前客戶端使用的 push-server。
右側(cè)的 平臺 一般指管理平臺承绸，它可以查看當(dāng)前的實時在線數(shù)裸影、給指定客戶端推送消息等。
推送消息則需要經(jīng)過一個推送路由（push-server）找到真正的推送節(jié)點军熏。
其余的中間件如：Redis轩猩、Zookeeper、Kafka荡澎、MySQL 都是為了這些功能所準(zhǔn)備的均践，具體看下面的實現(xiàn)。
注冊發(fā)現(xiàn)
首先第一個問題則是 注冊發(fā)現(xiàn)摩幔，push-server 變?yōu)槎嗯_之后如何給客戶端選擇一臺可用的節(jié)點是第一個需要解決的彤委。
這塊的內(nèi)容其實已經(jīng)在 分布式(一) 搞定服務(wù)注冊與發(fā)現(xiàn) 中詳細(xì)講過了。
所有的 push-server 在啟動時候需要將自身的信息注冊到 Zookeeper 中或衡。
注冊鑒權(quán) 模塊會訂閱 Zookeeper 中的節(jié)點焦影，從而可以獲取最新的服務(wù)列表。結(jié)構(gòu)如下：
以下是一些偽代碼：
應(yīng)用啟動注冊 Zookeeper封断。
對于注冊鑒權(quán)模塊來說只需要訂閱這個 Zookeeper 節(jié)點：
路由策略
既然能獲取到所有的服務(wù)列表斯辰，那如何選擇一臺剛好合適的 push-server 給客戶端使用呢？
這個過程重點要考慮以下幾點：
盡量保證各個節(jié)點的連接均勻坡疼。
增刪節(jié)點是否要做 Rebalance彬呻。
首先保證均衡有以下幾種算法：
輪詢。挨個將各個節(jié)點分配給客戶端。但會出現(xiàn)新增節(jié)點分配不均勻的情況闸氮。
Hash 取模的方式剪况。類似于 HashMap，但也會出現(xiàn)輪詢的問題湖苞。當(dāng)然也可以像 HashMap 那樣做一次 Rebalance拯欧，讓所有的客戶端重新連接详囤。不過這樣會導(dǎo)致所有的連接出現(xiàn)中斷重連财骨，代價有點大。
由于 Hash 取模方式的問題帶來了一致性 Hash算法藏姐，但依然會有一部分的客戶端需要 Rebalance隆箩。
權(quán)重「嵫睿可以手動調(diào)整各個節(jié)點的負(fù)載情況捌臊，甚至可以做成自動的，基于監(jiān)控當(dāng)某些節(jié)點負(fù)載較高就自動調(diào)低權(quán)重兜材，負(fù)載較低的可以提高權(quán)重理澎。
還有一個問題是：
當(dāng)我們在重啟部分應(yīng)用進行升級時，在該節(jié)點上的客戶端怎么處理曙寡？
由于我們有心跳機制糠爬，當(dāng)心跳不通之后就可以認(rèn)為該節(jié)點出現(xiàn)問題了。那就得重新請求注冊鑒權(quán)模塊獲取一個可用的節(jié)點举庶。在弱網(wǎng)情況下同樣適用执隧。
如果這時客戶端正在發(fā)送消息，則需要將消息保存到本地等待獲取到新的節(jié)點之后再次發(fā)送户侥。
有狀態(tài)連接
在這樣的場景中不像是 HTTP 那樣是無狀態(tài)的镀琉，我們得明確的知道各個客戶端和連接的關(guān)系。
在上文的單機版中我們將這個關(guān)系保存到本地的緩存中蕊唐，但在分布式環(huán)境中顯然行不通了屋摔。
比如在平臺向客戶端推送消息的時候，它得首先知道這個客戶端的通道保存在哪臺節(jié)點上替梨。
借助我們以前的經(jīng)驗凡壤，這樣的問題自然得引入一個第三方中間件用來存放這個關(guān)系。
也就是架構(gòu)圖中的存放路由關(guān)系的 Redis耙替，在客戶端接入 push-server 時需要將當(dāng)前客戶端唯一標(biāo)識和服務(wù)節(jié)點的 ip+port 存進 Redis亚侠。
同時在客戶端下線時候得在 Redis 中刪掉這個連接關(guān)系。
這樣在理想情況下各個節(jié)點內(nèi)存中的 map 關(guān)系加起來應(yīng)該正好等于 Redis 中的數(shù)據(jù)俗扇。
偽代碼如下：
這里存放路由關(guān)系的時候會有并發(fā)問題硝烂，最好是換為一個 lua 腳本。
推送路由
設(shè)想這樣一個場景：管理員需要給最近注冊的客戶端推送一個系統(tǒng)消息會怎么做铜幽？
結(jié)合架構(gòu)圖
假設(shè)這批客戶端有 10W 個滞谢，首先我們需要將這批號碼通過平臺下的 Nginx 下發(fā)到一個推送路由中串稀。
為了提高效率甚至可以將這批號碼再次分散到每個 push-route 中。
拿到具體號碼之后再根據(jù)號碼的數(shù)量啟動多線程的方式去之前的路由 Redis 中獲取客戶端所對應(yīng)的 push-server狮杨。
再通過 HTTP 的方式調(diào)用 push-server 進行真正的消息下發(fā)（Netty 也很好的支持 HTTP 協(xié)議）母截。
推送成功之后需要將結(jié)果更新到數(shù)據(jù)庫中，不在線的客戶端可以根據(jù)業(yè)務(wù)再次推送等橄教。
消息流轉(zhuǎn)
也許有些場景對于客戶端上行的消息非城蹇埽看重，需要做持久化护蝶，并且消息量非常大华烟。
在 push-sever 做業(yè)務(wù)顯然不合適，這時完全可以選擇 Kafka 來解耦持灰。
將所有上行的數(shù)據(jù)直接往 Kafka 里丟后就不管了盔夜。
再由消費程序?qū)?shù)據(jù)取出寫入數(shù)據(jù)庫中即可。
其實這塊內(nèi)容也很值得討論堤魁，可以先看這篇了解下：強如 Disruptor 也發(fā)生內(nèi)存溢出喂链？
后續(xù)談到 Kafka 再做詳細(xì)介紹。
分布式問題
分布式解決了性能問題但卻帶來了其他麻煩妥泉。
應(yīng)用監(jiān)控
比如如何知道線上幾十個 push-server 節(jié)點的健康狀況椭微？
這時就得監(jiān)控系統(tǒng)發(fā)揮作用了，我們需要知道各個節(jié)點當(dāng)前的內(nèi)存使用情況涛漂、GC赏表。
以及操作系統(tǒng)本身的內(nèi)存使用，畢竟 Netty 大量使用了堆外內(nèi)存匈仗。
同時需要監(jiān)控各個節(jié)點當(dāng)前的在線數(shù)瓢剿，以及 Redis 中的在線數(shù)。理論上這兩個數(shù)應(yīng)該是相等的悠轩。
這樣也可以知道系統(tǒng)的使用情況间狂，可以靈活的維護這些節(jié)點數(shù)量。
日志處理
日志記錄也變得異常重要了火架，比如哪天反饋有個客戶端一直連不上鉴象，你得知道問題出在哪里。
最好是給每次請求都加上一個 traceID 記錄日志何鸡，這樣就可以通過這個日志在各個節(jié)點中查看到底是卡在了哪里纺弊。
以及 ELK 這些工具都得用起來才行。
# **讀者福利**
讀到這的朋友還可以免費領(lǐng)取一份唔我收集的Java核心知識體系文檔及更多Jav進階知識筆記和視頻資料骡男。
###資料領(lǐng)取方式：? **[點擊Java高級架構(gòu)群](http://qm.qq.com/cgi-bin/qm/qr?k=Bd4NyjGC-utCVPSktv_KlAJ5m7dG5ncs)**
**更多筆記分享**
