汽車之家App詳細介紹、汽車之家app下載安裝

1.前言

早期之家在C端產品的即時通信功能是直接使用第三方商業軟件服務（SaaS），功能擴展性上存在很大制約，某些定制化業務需求很難實現，考慮到后續業務發展需要、數據安全、內容實時審核及性能、自主可控高可用架構等因素，決定自主開發IM即時通信平臺并逐步迭代替換。

2.網絡通信框架及協議

2.1

網絡通信框架

網絡通信系統通?？梢赃x擇原生NIO庫或者第三方網絡框架進行開發，原生NIO的類庫API比較底層基礎，缺少對常用操作的封裝，例如粘包、解碼、重連等，開發工作量和維護成本會比較高，需要關注很多底層的東西。我們選擇了目前非常熱門的網絡框架Netty進行開發，Netty功能強大開發門檻較低，預置了多種主流協議編解碼功能，成熟、穩定，且修復了大量已經發現的JDK NIO BUG。

? Netty具備如下優點：

1.入門簡單，文檔齊全，無其他依賴，只依賴 JDK 就夠了；

2.使用簡單，預置了多種編解碼功能，支持多種主流協議，對大量常用操作進行了封裝，減少開發周期；

3.高性能，高吞吐，低延遲，資源消耗少；

4.靈活的線程模型，支持阻塞和非阻塞的I/O 模型；

5.代碼質量高，目前主流版本基本沒有 Bug；

6.社區活躍，版本迭代周期短，發現的BUG可以被及時修復，同時，更多的新功能會加入；

7.經歷了大規模的商業應用考驗，穩定性得到驗證。

2.2

通信協議

TCP是個“流”協議，就是沒有界限的一串數據，數據傳輸時可能會存多包或半包傳輸的情況，原因如下：

1. 應用程序寫入字節大小于套接口發送緩沖區大??；

2. 進行 MSS 大小的 TCP 分段；

3. 以太網幀的 payload 大于 MTU 進行 IP 分片

? 解決策略

1. 消息定長，例如每個報文大小固定200字節，如果不夠，空位補空格。

2. 用回車符進行分割，例如FTP協議。

3. 約定特殊字符作為消息結束標記。

4. 將消息分為消息頭和消息體，消息頭中包含表示消息總長度（或消息體長度）

5. 更復雜的應用層協議。

按約定的方式編解碼保證數據完整性，就是通信協議。將消息分為消息頭和消息體是最常見的協議設計方式（定長消息頭，可變長度消息體），如下圖：

? 消息頭

固定長度字節來標記消息類型，及消息體字節長度。

?消息體

可以使用文本、XML、JSON、Protobuf等擴展性好的數據格式，盡量考慮以下幾點：

1. 精簡消息體大小，不要有冗余數據，減少網絡帶寬占用（尤其是大量用戶發消息群聊場景下），提高傳輸效率

2. 數據安全性（例如加密傳輸）

3. 編碼效率及可擴展性

? 除了自己設計實現通信協議，還可以直接使用現成的設計好的公開協議，如目前比較流行的websocket協議，相對于私有協議有以下優點：

1. 瀏覽器直接支持，方便web端接入

2. 降低接入成本，websocket是公開協議，接入時不需要在協議規范上耗費太多的溝通時間。

3. 很多框架包括Netty都自帶實現了websocket協議解碼器。

3.架構設計

客戶端：用戶收發消息終端

接入層：為客戶端連接、收發消息、關系建立提供入口

數據層：負責各類業務邏輯數據及消息數據緩存或持久化存儲，及消息指令的分發渠道。

3.1

消息設置

聊天場景常見的消息類型通常有：文本、圖片、表情、語音，視頻。我們把消息分為消息類型，及消息內容兩部分，客戶端通過識別消息類型去解析消息內容并展示，像圖片視頻等消息，并不需要通過消息即時傳遞其內容，而是先將圖片或視頻上傳到文件服務器，消息中只需要把uri帶過去，并且帶上base64編碼的縮略圖即可，如下示例：

msgType:msg_image

msgContent: { user: { id:1,name:xxx,portrait:xxxx }, content: "縮略小圖base64編碼",url:"大圖地址", extra: "" }

消息下發流程如下圖：

如圖，整體思路是將上行消息通過webapi寫入消息隊列，socket服務器通過消息隊列或離線消息庫進行增量消息分發同步。

socket服務承載連接著所有在線用戶，發生部署上線將會導致所有在線用戶斷開重連，瞬間大量增加其它服務器的連接壓力，且對部分用戶行為可能會有短暫的影響，上行消息通過webAPI實現，統一了消息入口，方便各類渠道消息的接入，并且使得socket服務的職責變得簡單單一，僅用于保持連接和推送消息，上行消息業務邏輯頻繁變動時僅需要重新部署webAPI，對用戶基本無感知。

還有一些建議是，對消息進行合并，壓縮能極大提升消息推送吞吐能力，減少帶寬占用，經測試十條以上消息壓縮率能達到80%左右；細分消息隊列，按不同維度拆分消息隊列可以分散壓力防止某類消息高峰期對其它業務消息造成延遲推送，保證其它消息的時效性，比如可以按場景用戶消息，系統指令等各自使用獨立的消息隊列。

3.2

消息擴散

消息擴散分發是im設計的重點，尤其是一對多的場景，如群聊。簡單的說就是每條消息需要擴散給群里所有人收到，通常有兩種方式，讀擴散，寫擴散。什么是讀擴散？什么是寫擴散？

? 讀擴散：

描述：每條消息只存一份，群組所有成員讀取這一份數據。

優點：節省存儲空間，無寫入壓力。

缺點：

1. 獲取離線增量消息邏輯復雜，需要根據用戶所有會話關系去遍歷獲取，且并未知道會話是否有增量消息，會造成大量無效空讀，效率極慢。

2. 針對消息做單個用戶個性化操作時設計會變的麻煩，比如其中一個用戶刪除消息，已讀回執等操作時，不能去影響其它用戶的視角。

? 寫擴散：

描述：每個用戶有獨立的消息列表，每條消息給所有消息關聯人同步一份副本。

優點：讀取邏輯簡單，效率極快，通過用戶自身消息列表一次性獲取所有離線增量消息即可，用戶個性化操作實現簡單，不會影響其它用戶的視角。

缺點：存儲空間增加，寫入壓力較大。

兩種方案如圖所示：

對比兩種消息擴散方案優缺點都比較明確，同時也都面臨無法接受的極端情況，比如讀擴散，如果某用戶擁有巨量會話，那他每次上線時讀取消息就是災難，再如寫擴散，如遇到萬人群，每條消息都會產生一萬分副本，作為設計者必須根據實際情況從邏輯上去結合兩種方案來平衡讀寫壓力。

消息寫擴散按需延遲擴散，我們通過登陸時間把用戶分類活躍和非活躍，只對活躍用戶進行即時寫擴散，非活躍用戶在上線時做一次補償同步操作，這樣能有效分散消息寫入壓力，還能對減少僵尸賬號進行無意義消息副本同步。

3.3

IMSDK架構構圖

IMSDK架構按模塊分工可以分為中間件層、核心層、協議層。

?中間件層

負責請求連接時需要的Token，以及對Token的緩存、Token過期更新等邏輯。當App啟動之后平臺層會設置用戶信息到中間件，中間件根據設置的用戶信息判斷本地是否緩存該用戶的Token，如果有則直接用該Token進行連接；如果沒有則會請求接口獲取Token。獲取到之后使用獲取到的Token進行連接，連接成功之后將該Token本地緩存，方便下次使用。如果連接過程中服務器端返回Token過期的錯誤，客戶端會刪除掉本地緩存的Token，并重新請求Token進行再次連接。

?核心層

包含連接模塊、監聽模塊、API封裝模塊、日志模塊、本地數據庫模塊。連接模塊負責Socket的連接、?；?、斷線重連、斷開、收發消息等操作，連接模塊每隔50秒發送一次ping來?；?，連接模塊重連機制是2秒、4秒、8秒、16秒等2的n次方逐漸增加，當重試次數到10次后會認為當前網絡有問題，不再重試，等待監聽網絡變化或者前后臺切換之后再次重試；監聽模塊當收到會話變更、消息變更、連接狀態變更時將變更內容通知到所有注冊監聽的業務層，業務層根據收到的通知做出相應處理。

API封裝模塊提供一些SDK基礎功能的API到業務層，例如發送消息、撤回消息、刪除消息、獲取會話未讀數、會話草稿等等，業務層調用提供的API完成相關功能。日志模塊提供日志采集的API，將每一條日志順序的記錄到日志文件中。日志模塊還負責日志文件的創建、刪除、保存與上傳工作。本地數據庫模塊負責數據庫相關的工作，當上層設置用戶信息時，數據庫模塊會打開相應的數據庫，如果沒有則會新建。數據庫模塊負責會話表和消息表的創建，負責會話和消息的增、刪、改、查。數據庫模塊執行操作時會增加一些必要的邏輯到其中，例如，在插入消息時需要更新會話的未讀數、會話的最后一條消息；在刪除消息時需要更新會話的未讀數、會話的最后一條消息；在消息已讀功能中需要修改會話的未讀數等等。

?協議層

主要負責跟服務端通訊內容的編解碼工作，包括消息的編解碼、會話的編解碼、命令的編解碼等工作，協議層將收到的數據進行解析，區分出諸如收到新消息、刪除消息、撤回消息、增加會話、刪除會話、會話更新等行為，同時將收到的數據解碼成消息或者會話Model傳遞到上層，通知到業務層。

3.4

連接流程圖

App需要同App Server進行數據交互，獲取IM連接需要的Token數據，并且App Server負責維護業務數據，如用戶數據、會話數據、好友關系等；

App通過Token數據與IM Server進行連接，建立數據通道實現消息的實時接收與推送功能；

IM Server維護App的連接狀態，在接收實時消息時判斷用戶是否在線，將消息轉發給目標設備或保存為離線消息；

?會話及氣泡：

在面對特殊用戶會話較多時每次從服務拉取會話信息時將面臨較大壓力，我們采用本地和服務端結合方案實現，本地緩存一份會話，接收消息對會話氣泡進行疊加，本地會話設置發生變更如免打擾，隱藏會話，已讀消息等，上報給服務端，服務端在發生好友關系或加入群組等操作時產生會話，或會話信息變更時也會對本地進行同步，服務器和本地之間會話同步包括連接時同步、實時同步、主動同步。

連接時同步：用戶每次連接時會向服務器傳遞會話唯一標識，服務端通過用戶傳遞的標識進行邏輯判斷并向用戶推送會話數據，包括全部會話和增量會話，SDK接收到會話數據后進行本地的新增、修改、刪除操作，并通知給UI層，本地會話“標識”由服務端每次同步會話時提供。

實時同步：本地會話修改會通知給服務端，服務端接收到會話信息變更時，會即時通過IM推送給SDK，其中包括新增、修改、刪除會話的操作，SDK接收到會話數據后進行本地的新增、修改、刪除操作，并通知給UI層。

主動同步：客戶端接收到不存在的會話消息時，會主動向服務器獲取此會話信息進行本地保存并通知UI層。

會話設計圖：

會話部分字段：

單聊：兩個用戶之間進行一對一的聊天，聊天消息可以持久化保存至本地進行查看。

群組：兩個或兩個以上的用戶在同一個會話中進行聊天，發送的消息會被群組所有成員接收并可以持久化保存至本地進行查看。

公眾號：企業或官方通過系統賬號向單個或多個賬號推送消息，消息可以持久化保存至本地進行查看。

聊天室：一個或多個用戶在同一個會話中進行聊天，發送的消息會被推送至當前聊天室中所有用戶，用戶接收端消息不會保存本地。

本地記錄每次會話同步時間，連接時服務端根據本地上報最后更新時間對比，增量同步變動過的會話記錄，保證本地會話與服務器端保持一致。之家的會話列表體現在個人主頁的消息部分，如下：

4.服務器優化

我們系統的設計要求是單機百萬連接支持、下行消息QPS一百萬。由于一個連接會占用一個文件描述符，首先就要對系統的文件描述符上限做調整，讓服務器能夠支持百萬級連接的建立；

# /etc/security/limits.conf

* soft nporc 1500000

* hard nporc 1500000

* soft nofile 1500000

* hard nofile 1500000

# /etc/sysctl.conf

fs.nr_open = 3000000

fs.file-max = 3000000

我們使用Nginx作為七層負載，并且開啟了TLS保障數據的傳輸安全。當Nginx層作為客戶端在與后端應用服務器建立連接的時候，會遇到本地端口瓶頸，可以依據TCP四元組規則，增加后端應用服務器的監聽端口，來實現本地端口的復用，從而突破本地端口資源的限制；

在實際壓測過車中，客戶端接收消息的毛刺問題比較嚴重，經排查發現nginx服務器有丟包，并且CPU的使用非常不均衡，特別是軟中斷，只集中在少數CPU上。為解決以上問題前，先了解下網卡收包流程以及相關的一些概念。

網卡收到數據幀后，將數據幀以DMA的方式拷貝到內存的Ring Buffer中，該步驟不需要CPU的參與。當拷貝完成后，網卡便會觸發一個網卡硬件中斷，CPU必須立即響應硬件中斷，CPU根據中斷類型，在中斷注冊表中查找對應的中斷處理程序，然后調用網卡注冊的中斷處理程序(網卡驅動)，此后網卡驅動程序觸發一個軟中斷，自此硬件中斷返回，硬中斷不會做過多事情，它只負責通知驅動有數據到達，具體的操作由軟中斷過程來處理。

DMA是Direct Memory Access，直接存儲器訪問。在DMA出現之前，CPU與外設之間的數據傳送方式有程序傳送方式、中斷傳送方式。CPU是通過系統總線與其他部件連接并進行數據傳輸，DMA就是指外部設備不通過CPU而直接與系統內存交換數據的接口技術。

Ring Buffer網卡環形緩沖區，如果該緩沖區被占滿，新到來的數據包將會被丟棄，從而導致丟包。把該緩沖區由原來的512調整到2048后，丟包問題得以解決，方法如下：

查看當前Buffer

ethtool -g em1

Ring parameters for em1:

Pre-set maximums:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

Current hardware settings:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

ethtool -G em1 rx 2048

ethtool -G em1 tx 2048

修改

ethtool -G em1 rx 4096

ethtool -G em1 tx 4096

4.1

設置網卡隊列

對于CPU軟中斷不均衡，與網卡的設置與CPU的親和力綁定有直接關系，借用網絡一張圖先了解下RSS多隊列網卡，如下：

當網卡收到報文時，通過Hash包頭的SIP、SPort、DIP、DPort四元組信息，將數據投遞到相應的網卡隊列，同時會觸發該隊列綁定的中斷，通知CPU進一步處理；由此可知CPU使用不均衡，無非就是兩個原因，隊列收到的數據包不均衡或者CPU與網卡隊列綁定不合理導致；

# 設定網卡隊列

ethtool -L em1 combined 16

4.2

網卡中斷號

Interrupt Request，簡稱IRQ，中斷就是由硬件或軟件所發送的中斷請求信號。系統上的每個硬件設備都會被分配一個 IRQ 號，通過這個唯一的 IRQ 號就能區是來自哪個硬件了。開啟了多隊列的網卡，每個隊列都會有唯一的中斷號。

# 查看網卡隊列中斷號

cat /proc/interrupts |grep em1 |awk '{print $1 $NF}'

4.3

CPU親和力綁定

把每個網卡隊列與CPU一一綁定，均衡CPU的使用

# CPU綁定

echo /proc/irq/107/smp_affinity_list 0

echo /proc/irq/108/smp_affinity_list 1

中斷號為107的隊列綁定0號CPU，中斷號為108的隊列綁定1號CPU，依此類推，每個網卡隊列都需要綁定到不同的CPU核上，這樣我們就完成了網卡隊列的設置以及與CPU的綁定。

這里還有個問題是，CPU不緊要處理網路數據，還要處理Nginx應用，這個時候CPU資源的分配要根據具體的壓測情況進行調整；

4.4

Intel Flow Director

上面提到投遞到網卡隊列的數據包是均衡的，如何能做到均衡呢？有個辦法是使用Intel以太網FD( Flow Director)技術，自定義數據包投遞規則，應用監聽多個端口，不同目標端口的數據包按制定的規則投遞到相應的網卡隊列，從而達到均衡數據包的目的，進而均衡CPU的使用；

# 數據投遞規則 根據目的端口把數據投遞到不同隊列

ethtool --features em1 ntuple on

ethtool --config-ntuple em1 flow-type tcp4 dst-port 9500 action 0 loc 1

ethtool --config-ntuple em1 flow-type tcp4 dst-port 9501 action 1 loc 2

至此網卡丟包以及CPU使用率不均衡的問題得到解決，基本就是解決了客戶端接收數據毛刺的問題；

4.5

其他優化

對部分需要更高時時性及穩定的用戶，如客服、商家號等，可以增加專用服務器來應對，專用服務器通常接入量較小，連接和消息推送都會更穩定快速。

增加備用域名（不同cdn），在連接失敗重試過程中使用可有效減少外部網絡波動帶來的影響，使系統更加穩定可靠。我們之前有一次線上故障，使用的第三方的即時通訊服務，

當時該服務商的一個關鍵域名被誤封，導致整個即時通訊服務不可用，由于處理過程復雜，故障持續了半天的時間才得以恢復?；诖?，我們自研的時候，把這部分設計了進去。

為提高連接效率及服務器連接壓力SDK增加了token緩存機制，IM連接成功后，會將token進行本地緩存，當設備再次觸發連接時，會優先檢查本地是否存在token，如存在立刻使用緩存數據進行連接，若不存在或過期會向服務器獲取新token數據進行連接，連接成功后將新Token緩存本地。

SDK具備自動重連機制，在整個應用全局只需要調用一次連接即可，連接異常斷開后會啟動重連機制進行多次重連，在這之后如果仍沒有連接成功，還會在當檢測到設備網絡狀態變化時再次進行重連。

心跳?；?，為了保持客戶端和服務端的實時雙向通信，需要確?？蛻舳撕头斩酥g的TCP通道保持連接不斷開，IM連接成功后，SDK每間隔50秒會向服務器發送一個ping包，服務器接收到ping包后立即響應一個pong包，如果服務在120秒內檢查沒有收到過ping包會立即斷開此連接，釋放資源。SDK在檢測斷開后會自動觸發重連機制。

發送方->接收方：ping

接收放->發送方：pong

5.總結

本文內容介紹了之家IM即時通信平臺部分設計策略，借此機會總結設計方案及技術實踐，與大家一起學習提升。目前該項目在之家已經落地兩年有余，接入十幾條業務線，包含單聊、群聊、聊天室、公眾號、通用信令服務等場景，日均服務三端用戶在千萬級，為之家三端產品提供全雙工消息總線基礎設施支撐；目前一些個性化產品需求以及相關運營平臺仍在不斷完善中，如果你對此很有興趣，歡迎加入我們。

作者簡介

林道輝

■ C端及中臺產研中心-看選技術團隊

■ 2012年加入汽車之家，目前主要負責參與熱聊業務及之家im通信平臺架構及研發工作。

來源:微信公眾號:之家技術

出處:https://mp.weixin.qq.com/s/kMGEpE_piFbeWTm9YxWVRA