分佈式IM(即時通訊) 系統

老讀者應該還記得我在去年國慶節前分享過一篇《設計一個百萬級的消息推送系統》；雖然我在文中有貼一些偽代碼，依然有些朋友希望能直接分享一些可以運行的源碼；這麼久了是時候把坑填上了。
目錄結構：


於是在之前的基礎上我完善了一些內容，先來看看這個項目的介紹吧：
CIM(CROSS-IM)一款面向開發者的IM(即时通讯)系統；同時提供了一些組件幫助開發者構建一款屬於自己可水平擴展的IM。
借助CIM你可以實現以下需求：
  • IM 即時通訊系統。
  • 適用於APP的消息推送中間件。
  • IOT 海量連接場景中的消息透傳中間件。
完整源碼託管在GitHub : github.com/crossoverJi…

架構設計

下面來看看具體的架構設計。
  • CIM中的各個組件均採用SpringBoot構建。
  • 採用Netty + Google Protocol Buffer構建底層通信。
  • Redis 存放各個客戶端的路由信息​​、賬號信息、在線狀態等。
  • Zookeeper用於IM-server服務的註冊與發現。
整體主要由以下模塊組成：

cim-server

IM服務端；用於接收client連接、消息透傳、消息推送等功能。
支持集群部署。

cim-forward-route

消息路由服務器；用於處理消息路由、消息轉發、用戶登錄、用戶下線以及一些運營工具（獲取在線用戶數等）。

cim-client

IM 客戶端；給用戶使用的消息終端，一個命令即可啟動並向其他人發起通訊（群聊、私聊）；同時內置了一些常用命令方便使用。

流程圖

整體的流程也比較簡單，流程圖如下：

  • 客戶端向route發起登錄。
  • 登錄成功從Zookeeper中選擇可用IM-server返回給客戶端，並保存登錄、路由信息到Redis。
  • 客戶端向IM-server發起長連接，成功後保持心跳。
  • 客戶端下線時通過route清除狀態信息。
所以當我們自己部署時需要以下步驟：
  • 搭建基礎中間件Redis、Zookeeper。
  • 部署cim-server，這是真正的IM服務器，為了滿足性能需求所以支持水平擴展，只需要註冊到同一個Zookeeper即可。
  • 部署cim-forward-route，這是路由服務器，所有的消息都需要經過它。由於它是無狀態的，所以也可以利用Nginx代理提高可用性。
  • 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中的登錄不一樣，具有業務性質，
  • 登錄成功之後需要判斷是否是重複登錄（一個用戶只能運行一個客戶端）。
  • 登錄成功後需要從Zookeeper中獲取服務列表（cim-server）並根據某種算法選擇一台服務返回給客戶端。
  • 登錄成功之後還需要保存路由信息，也就是當前用戶分配的服務實例保存到Redis中。
為了實現只能一個用戶登錄，使用了Redis中的set來保存登錄信息；利用userID作為key，重複的登錄就會寫入失敗。
類似於Java 中的HashSet，只能去重保存。
獲取一台可用的路由實例也比較簡單：
  • 先從Zookeeper獲取所有的服務實例做一個內部緩存。
  • 輪詢選擇一台服務器（目前只有這一種算法，後續會新增）。
當然要獲取Zookeeper中的服務實例前自然是需要監聽cim-server之前註冊上去的那個節點。

具體代碼如下：
也是在應用啟動之後監聽Zookeeper中的路由節點，一旦發生變化就會更新內部緩存。
這裡使用的是Guava的cache，它基於ConcurrentHashMap，所以可以保證清除、新增缓存的原子性。

群聊接口

這是一個真正發消息的接口，實現的效果就是其中一個客戶端發消息，其餘所有客戶端都能收到！
流程肯定是客戶端發送一條消息到服務端，服務端收到後在上文介紹的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信息再創建連接。
image-20190102001525565

登錄過程中route接口會判斷是否為重複登錄，重複登錄則會直接退出程序。
接下來是利用route接口返回的cim-server實例信息（ip+port）創建連接。
最後一步就是發送一個登錄標誌的信息到服務端，讓它保持客戶端和Channel的關係。

自定義協議

上文提到的一些登录报文、真正的消息报文這些其實都是在我們自定義協議中可以區別出來的。
由於是使用Google Protocol Buffer編解碼，所以先看看原始格式。
其實這個協議中目前一共就三個字段：
  • requestId可以理解為userId。
  • reqMsg 就是真正的消息。
  • type 也就是上文提到的消息類別。
目前主要是三種類型，分別對應不同的業務：

心跳

為了保持客戶端和服務端的連接，每隔一段時間沒有發送消息都需要自動的發送心跳。

目前的策略是每隔一分鐘就是發送一個心跳包到服務端：
這樣服務端每隔一分鐘沒有收到業務消息時就會收到ping的心跳包：

內置命令

客戶端也內置了一些基本命令來方便使用。
命令描述
:q退出客戶端
:olu獲取所有在線用戶信息
:all獲取所有命令
:更多命令正在開發中。。
比如輸入:q就會退出客戶端，同時會關閉一些系統資源。
當輸入:olu( onlineUser的簡寫)就會去調用route的獲取所有在線用戶接口。

群聊

群聊的使用非常簡單，只需要在控制台輸入消息回車即可。
這時會去調用route的群聊接口。

私聊

私聊也是同理，但前提是需要觸發關鍵字；使用userId;;消息内容這樣的格式才會給某個
用戶發送消息，所以一般都需要先使用:olu命令獲取所以在線用戶才方便使用。

消息回調

為了滿足一些定制需求，比如消息需要保存之類的。
所以在客戶端收到消息之後會回調一個接口，在這個接口中可以自定義實現。
因此先創建了一個caller的bean，這個bean中包含了一個CustomMsgHandleListener接口，需要自行處理只需要實現此接口即可。

自定義界面

由於我自己不怎麼會寫界面，但保不准有其他大牛會寫。所以客戶端中的群聊、私聊、獲取在線用戶、消息回調等業務(以及之後的業務)都是以接口形式提供。
也方便後面做頁面集成，只需要調這些接口就行了；具體實現不用怎麼關心。
文章來源: https://juejin.im/post/5c2bffdc51882509181395d7

留言

張貼留言

這個網誌中的熱門文章

Json概述以及python對json的相關操作

圖片
什麼是json： JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。它基於JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一個子集。JSON採用完全獨立於語言的文本格式，但是也使用了類似於C語言家族的習慣（包括C, C++, C#, Java, JavaScript, Perl, Python等）。這些特性使JSON成為理想的數據交換語言。 JSON建構於兩種結構： “名稱/值”對的集合（A collection of name/value pairs）。不同的語言中，它被理解為對象（object），紀錄（record），結構（struct），字典（dictionary），哈希表（hash table），有鍵列表（keyed list），或者關聯數組（associative array）。 值的有序列表（An ordered list of values）。在大部分語言中，它被理解為數組（array）。 這些都是常見的數據結構。事實上大部分現代計算機語言都以某種形式支持它們。這使得一種數據格式在同樣基於這些結構的編程語言之間交換成為可能。 jso官方說 ​​明參見：http://json.org/ Python操作json的標準api庫參考：http://docs.python.org/library/json.html 對簡單數據類型的encoding 和decoding： 使用簡單的json.dumps方法對簡單數據類型進行編碼，例如： import json obj = [[ 1 , 2 , 3 ], 123 , 123.123 , 'abc' ,{ 'key1' :( 1 , 2 , 3 ), 'key2' :( 4 , 5 , 6 )}] encodedjson = json.dumps(obj) print repr (obj) print encodedjson 輸出： [[1, 2, 3], 123, 123.123, 'abc', {'ke...
閱讀完整內容

Docker容器日誌查看與清理

1. 問題 docker容器日誌導致主機磁盤空間滿了。 docker logs -f container_name 劈裡啪啦一大堆，很佔用空間，不用的日誌可以清理掉了。  2. 解決方法 2.1 找出Docker容器日誌 在linux上，容器日誌一般存放在 /var/lib/docker/containers/container_id/ 下面，查看各個日誌文件大小的腳本docker_log_size.sh，內容如下： #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do ls -lh $log done # chmod +x docker_log_size.sh # ./docker_log_size.sh 2.2 清理Docker容器日誌（治標） 如果docker容器正在運行，那麼使用 rm -rf 方式刪除日誌後，通過 df -h 會發現磁盤空間並沒有釋放。 原因是在Linux或者Unix系統中，通過 rm -rf 或者文件管理器刪除文件，將會從文件系統的目錄結構上解除鏈接（unlink）。 如果文件是被打開的（有一個進程正在使用），那麼進程將仍然可以讀取該文件，磁盤空間也一直被佔用。 正確姿勢是 cat /dev/null > *-json.log ，當然你也可以通過 rm -rf 刪除後重啟docker。 接下來，提供一個日誌清理腳本 clean_docker_log.sh ，內容如下： #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs d...
閱讀完整內容

利用 Keepalived 提供 VIP

Keepalived 是一種基於 VRRP 協定實現的高可靠 Web 服務方案，用於防止單點故障問題。因此一個 Web 服務運作至少會擁有兩台伺服器執行 Keepalived，一台作為 master，一台作為 backup，並提供一個虛擬 IP（VIP），master 會定期發送特定訊息給 backup 伺服器，當 backup 沒收到 master 訊息時，表示 master 已故障，這時候 backup 會接管 VIP，繼續提供服務，來確保服務的高可靠性。 VRRP VRRP（Virtual Router Redundancy Protocol，虛擬路由器備援協定），是一個提供備援路由器來解決單點故障問題的協定，該協定有兩個重要概念： * VRRP 路由器與虛擬路由器：VRRP 路由器是表示運作 VRRP 的路由器，是一個實體裝置，而虛擬路由器是指由 VRRP 建立的邏輯路由器。一組 VRRP 路由器協同運作，並一起構成一台虛擬路由器，該虛擬路由對外提供一個唯一固定的 IP 與 MAC 位址的邏輯路由器。 * 主控制路由器（master）與備援路由器（backup）：主要是在一組 VRRP 中的兩種互斥角色。一個 VRRP 群組中只能擁有一台是 master，但可以有多個 backup 路由器。 VRRP 協定使用選擇策略從路由器群組挑選一台作為 master 來負責 ARP 與轉送 IP 封包，群組中其他路由器則作為 backup 的角色處理等待狀態。當由於某種原因造成 master 故障時，backup 會在幾秒內成為 master 繼續提供服務，該階段不用改變任何 IP 與 MAC 位址。 Keepalived 節點配置 IP ADDRESS ROLE 172.16.1.101 vip 172.16.1.102 master 172.16.1.103 backup 安裝與設定 這 ubuntu 14.04 LTS Server 中已經內建了 Keepalived 可以透過 apt-get 來安裝： $ sudo apt-get install -y keepalived 也可以透過 source code 進行安裝，流程如下： $ sudo apt-get install build-essential libssl-dev $ wge...
閱讀完整內容