1. 為自己搭建一個分布式 IM(即時通訊) 系統
CIM(CROSS-IM) 一款面向開發者的 IM(即時通訊)系統；同時提供了一些組件幫助開發者構建一款屬於自己可水平擴展的 IM 。
藉助 CIM 你可以實現以下需求：
下面來看看具體的架構設計。
整體主要由以下模塊組成：
cim-server
IM 服務端；用於接收 client 連接、消息透傳、消息推送等功能。
支持集群部署。
cim-forward-route
消息路由伺服器；用於處理消息路由、消息轉發、用戶登錄、用戶下線以及一些運營工具（獲取在線用戶數等）。
cim-client
IM 客戶端；給用戶使用的消息終端，一個命令即可啟動並向其他人發起通訊（群聊、私聊）；同時內置了一些常用命令方便使用。
整體的流程也比較簡單，流程圖如下：
所以當我們自己部署時需要以下步驟：
接下來重點看看具體的實現，比如群聊、私聊消息如何流轉；IM 服務端負載均衡；服務如何注冊發現等等。
IM 服務端
先來看看服務端；主要是實現客戶端上下線、消息下發等功能。
首先是服務啟動：
由於是在 SpringBoot 中搭建的，所以在應用啟動時需要啟動 Netty 服務。
從 pipline 中可以看出使用了 Protobuf 的編解碼（具體報文在客戶端中分析）。
注冊發現
需要滿足 IM 服務端的水平擴展需求，所以 cim-server 是需要將自身數據發布到注冊中心的。
所以在應用啟動成功後需要將自身數據注冊到 Zookeeper 中。
最主要的目的就是將當前應用的 ip + cim-server-port+ http-port 注冊上去。
上圖是我在演示環境中注冊的兩個 cim-server 實例（由於在一台伺服器，所以只是埠不同）。
這樣在客戶端（監聽這個 Zookeeper 節點）就能實時的知道目前可用的服務信息。
登錄
當客戶端請求 cim-forward-route 中的登錄介面（詳見下文）做完業務驗證（就相當於日常登錄其他網站一樣）之後，客戶端會向服務端發起一個長連接，如之前的流程所示：
這時客戶端會發送一個特殊報文，表明當前是登錄信息。
服務端收到後就需要將該客戶端的 userID 和當前 Channel 通道關系保存起來。
同時也緩存了用戶的信息，也就是 userID 和 用戶名。
離線
當客戶端斷線後也需要將剛才緩存的信息清除掉。
同時也需要調用 route 介面清除相關信息（具體介面看下文）。
IM 路由
從架構圖中可以看出，路由層是非常重要的一環；它提供了一系列的 HTTP 服務承接了客戶端和服務端。
目前主要是以下幾個介面。
注冊介面
由於每一個客戶端都是需要登錄才能使用的，所以第一步自然是注冊。
這里就設計的比較簡單，直接利用 Redis 來存儲用戶信息；用戶信息也只有 ID 和 userName 而已。
只是為了方便查詢在 Redis 中的 KV 又反過來存儲了一份 VK，這樣 ID 和 userName 都必須唯一。
登錄介面
這里的登錄和 cim-server 中的登錄不一樣，具有業務性質，
為了實現只能一個用戶登錄，使用了 Redis 中的 set 來保存登錄信息；利用 userID 作為 key ，重復的登錄就會寫入失敗。
獲取一台可用的路由實例也比較簡單：
當然要獲取 Zookeeper 中的服務實例前自然是需要監聽 cim-server 之前注冊上去的那個節點。
具體代碼如下：
也是在應用啟動之後監聽 Zookeeper 中的路由節點，一旦發生變化就會更新內部緩存。
群聊介面
這是一個真正發消息的介面，實現的效果就是其中一個客戶端發消息，其餘所有客戶端都能收到！
流程肯定是客戶端發送一條消息到服務端，服務端收到後在上文介紹的 SessionSocketHolder 中遍歷所有 Channel（通道）然後下發消息即可。
服務端是單機倒也可以，但現在是集群設計。所以所有的客戶端會根據之前的輪詢演算法分配到不同的 cim-server 實例中。
因此就需要路由層來發揮作用了。
路由介面收到消息後首先遍歷出所有的客戶端和服務實例的關系。
路由關系在 Redis 中的存放如下：
由於 Redis 單線程的特質，當數據量大時；一旦使用 keys 匹配所有 cim-route:* 數據，會導致 Redis 不能處理其他請求。
所以這里改為使用 scan 命令來遍歷所有的 cim-route:*。
接著會挨個調用每個客戶端所在的服務端的 HTTP 介面用於推送消息。
在 cim-server 中的實現如下：
cim-server 收到消息後會在內部緩存中查詢該 userID 的通道，接著只需要發消息即可。
在線用戶介面
這是一個輔助介面，可以查詢出當前在線用戶信息。
實現也很簡單，也就是查詢之前保存 」用戶登錄狀態的那個去重 set 「即可。
私聊介面
之所以說獲取在線用戶是一個輔助介面，其實就是用於輔助私聊使用的。
一般我們使用私聊的前提肯定得知道當前哪些用戶在線，接著你才會知道你要和誰進行私聊。
類似於這樣：
在我們這個場景中，私聊的前提就是需要獲得在線用戶的 userID。
所以私聊介面在收到消息後需要查詢到接收者所在的 cim-server 實例信息，後續的步驟就和群聊一致了。調用接收者所在實例的 HTTP 介面下發信息。
只是群聊是遍歷所有的在線用戶，私聊只發送一個的區別。
下線介面
一旦客戶端下線，我們就需要將之前存放在 Redis 中的一些信息刪除掉（路由信息、登錄狀態）。
IM 客戶端
客戶端中的一些邏輯其實在上文已經談到一些了。
登錄
第一步也就是登錄，需要在啟動時調用 route 的登錄介面，獲得 cim-server 信息再創建連接。
登錄過程中 route 介面會判斷是否為重復登錄，重復登錄則會直接退出程序。
接下來是利用 route 介面返回的 cim-server 實例信息（ip+port）創建連接。
最後一步就是發送一個登錄標志的信息到服務端，讓它保持客戶端和 Channel 的關系。
自定義協議
上文提到的一些登錄報文、真正的消息報文這些其實都是在我們自定義協議中可以區別出來的。
由於是使用 Google Protocol Buffer 編解碼，所以先看看原始格式。
其實這個協議中目前一共就三個欄位：
目前主要是三種類型，分別對應不同的業務：
心跳
為了保持客戶端和服務端的連接，每隔一段時間沒有發送消息都需要自動的發送心跳。
目前的策略是每隔一分鍾就是發送一個心跳包到服務端：
這樣服務端每隔一分鍾沒有收到業務消息時就會收到 ping 的心跳包：
內置命令
客戶端也內置了一些基本命令來方便使用。
比如輸入 :q 就會退出客戶端，同時會關閉一些系統資源。
當輸入 :olu(onlineUser 的簡寫)就會去調用 route 的獲取所有在線用戶介面。
群聊
群聊的使用非常簡單，只需要在控制台輸入消息回車即可。
這時會去調用 route 的群聊介面。
私聊
私聊也是同理，但前提是需要觸發關鍵字；使用 userId;;消息內容 這樣的格式才會給某個用戶發送消息，所以一般都需要先使用 :olu 命令獲取所以在線用戶才方便使用。
消息回調
為了滿足一些定製需求，比如消息需要保存之類的。
所以在客戶端收到消息之後會回調一個介面，在這個介面中可以自定義實現。
因此先創建了一個 caller 的 bean，這個 bean 中包含了一個 CustomMsgHandleListener 介面，需要自行處理只需要實現此介面即可。
自定義界面
由於我自己不怎麼會寫界面，但保不準有其他大牛會寫。所以客戶端中的群聊、私聊、獲取在線用戶、消息回調等業務(以及之後的業務)都是以介面形式提供。
也方便後面做頁面集成，只需要調這些介面就行了；具體實現不用怎麼關心。
cim 目前只是第一版，BUG 多，功能少（只拉了幾個群友做了測試）；不過後續還會接著完善，至少這一版會給那些沒有相關經驗的朋友帶來一些思路。
歡迎工作一到五年的Java工程師朋友們加入Java程序員開發： 721575865
群內提供免費的Java架構學習資料（裡面有高可用、高並發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間「來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！