零、目录#

1、概述####

1-1、业务场景
1-2、整体架构

2、IM通道详细分析####

2-1、整体实现
2-2、通信协议
2-3、DeviceId和NodeId生成方法
2-4、消息流转过程
2-5、对点对点聊天的支持

3、消息推送与离线存储（通常方案）####

3-1、消息持久化
3-2、消息在线推送与送达确认
3-3、未送达消息离线拉取

4、消息推送与离线存储（有赞客服系统）####

4-1、消息持久化
4-2、未读数标识与已读确认
4-3、方案优缺点

一、概述#

1-1、业务场景####

业务场景图

客服系统，为有赞店铺和买家之间提供消息沟通渠道。

• 每个有赞店铺有自己的唯一ID标识——kdtId;
• 店铺的每个买家将产生一个会话用于消息沟通，每个会话有唯一ID标识——conversationId，会话由“店铺+买家”唯一确定;
• 一个店铺中可以有多个客服人员；
• 每个会话中包含买家和一个或多个客服人员；
• 会话中任意成员发出的消息将被会话中所有成员看到；
• 目前消息通道包含：与有赞客服系统直连的店铺客服，与有赞客服系统直连的店铺买家，通过微信公众号联系店铺的微信买家。

1-2、整体架构####

有赞客服系统整体架构图

图中：

• 进入系统的消息带有from和to标识。from代表发送消息的成员，由sender_uid唯一确定；to代表接收消息的店铺，由kdtId最终转换为conversation_id唯一确定；
• 系统推送给IM客户端的消息包含以下信息：消息所属会话(conversation_id,show_nickname,show_avatar)，消息发送者信息(sender_uid,sender_nickname,sender_avatar)，消息具体内容；
• 系统推送给微信的消息仅有客服给买家发消息的场景，通过调用微信API完成：发送消息的店铺公众号(sender_openId)，接收消息的微信粉丝(receiver_openId)，消息具体内容；
• sender_uid本身包含消息发送者类型（微信粉丝、IM粉丝、客服），Logic层根据该类型进行相应的业务处理（对粉丝消息执行客服调度逻辑，对客服消息执行接待及统计逻辑）；
• recv_uid本身包含消息接收者类型（微信粉丝，IM粉丝，客服），Channel层根据其类型区分通道完成消息推送；

1）Channel层：通道层
负责系统与外部通道（socket连接，微信）的直接通信交互，消息的统一格式、推送、接收。

• IM设备连接管理；
• IM通道消息路由推送；
• 微信通道消息格式统一转换；
• 微信通道消息推送；

2）Msg-Bus：消息总线
系统Channel层与Logic层的通信，消息流转的枢纽。
利用消息总线进行系统解耦，QoS。

3）Logic：业务层
客服系统具体业务实现。

• 消息离线存储；
• 消息业务维度拆分；
• 客服调度业务具体实现；

二、IM通道详细分析#

2-1、整体实现####

IM通道实现结构
1）Connector：socket连接层
职责包括：

• IM设备的连接管理；
• 用户设备的注册登录；
• 用户设备维度的消息推送；

2）Channel：通道层
职责包括：

• 用户维度的消息路由；
• 消息流转格式转换；

3）集群结构

• Channel节点向zk注册自己的信息；
• Connector节点通过zk获取Channel节点的信息并与其连接，每个Connector节点跟集群中所有Channel节点建立socket连接进行通信；
• 外部IM设备与Connector节点直接建立socket连接进行通信；
• 每个Connector节点本地维护自己管理的“设备DeviceId<-->连接信息Session”的关系；
• 全局维护"IM设备<-->Connector节点"关系表，用于记录设备登录情况；
• 全局维护"用户<-->设备连接"路由表，用于用户维度的消息推送；

2-2、通信协议####

1）外部IM设备与Connector节点间采用websocket协议进行通信

编解码过程

2）Connector节点与Channel节点之间采用私有定制协议进行通信，具体协议格式及编解码过程略。

2-3、DeviceId和NodeId生成方法####

1）DeviceId生成方法
DeviceId用于唯一标识一个用户登录到系统的连接设备。

DeviceId结构
使用64位(即java中的long类型)表示一个DeviceId，其生成方法参考snowflake分布式ID生成法。
[0]空缺
[1 - 3]节点类型

• 000 -> 外部IM客户端
• 001 -> Connector节点
• 010 -> Logic节点

[4 - 15]集群号，空缺不用
[16 - 17]Device类型，目前仅有[00]一种默认类型，留作后续扩展
[18 - 47]时间戳
[48 - 63]16位自增ID

2）NodeId生成方法
NodeId用于标识系统中一个服务节点，作为系统集群节点内部通信的唯一标识。

NodeId结构
使用64位(即java中的long类型)表示一个NodeId，其生成方法参考snowflake分布式ID生成法。
[0]空缺
[1 - 3]节点类型

• 000 -> 外部IM客户端
• 001 -> Connector节点
• 010 -> Logic节点

[4 - 15]集群号，每个节点在集群中有个唯一节点号，目前使用节点IP后4位
[16 - 47]32位节点IP信息
[48 - 63]16位节点Port信息

2-3、用户设备登录/注册过程&连接信息绑定####

1）几个关键存储

连接信息Session结构
DeviceId<-->Session映射表（本地）
设备连接映射表
用户设备路由表
用户设备表DeviceInfo
2）用户设备登录/注册
a、客户端建连

• 客户端发起连接到Connector节点，Connector服务端生成连接上下文Session，并作为Attachment绑定到对应Channel上；

b、用户设备登录/注册

• *注：userId为有赞统一账户体系，因此使用统一服务不做独立存储；
• 客户端发起用户设备登录请求，携带userId和deviceType信息；
• Connector节点处理登录请求，由userId和deviceType生成hashcode（目前是直接拼接）作为查询键，查询"DeviceInfo表"对应设备是否已登录/注册过。若注册过直接拿到对应DeviceId，若没注册过则新生成DeviceId并存入"DeviceInfo表"；
• 将DeviceId填充入连接上下文Session的index字段；
• Connector节点本地存储"DeviceId<-->Session映射表"；
• 全局存储"设备连接映射表"和"用户设备路由表"；

2-4、消息流转过程####

典型交互过程图

客户端建连&用户设备登录/注册过程，由图文“绿色”过程描述。
客户端请求&服务端响应过程，由图中“粉紫色”过程描述。
服务端推送消息到客户端，由图中“蓝色”过程描述。

2-5、对点对点聊天的支持####

1）目前业务现状
目前客服系统业务场景仅存在买家与店铺沟通的情况，即以“买家+店铺”作为会话维度（由conversationId唯一标识）。
消息接收维度均为“会话”，即会话内某成员发送一条消息会被推送给会话内所有其他成员。
消息离线存储也以会话维度进行存储及查询。
2）点对点支持
若要支持点对点聊天（客服间聊天），只需将消息接收维度扩展为“用户”。
消息离线存储也需单独实现为“消息接收者——消息发送者”维度进行存储及查询。

三、消息推送与离线存储（通常方案）#

3-1、消息持久化####

1）职责划分
a、用户各会话消息的存储与历史消息拉取由客户端本地存储实现；
b、用户各会话的未读消息数红点提示由客户端本地累加记录；
c、服务端保证对建连客户端消息的实时推送；
d、服务端提供未送达消息拉取接口，对因客户端不在线或因网络异常丢失的消息，当客户端下次建连登录时通过调用拉取接口获取未送达消息；
2）消息ID
a、消息量不大时，可通过集中发号器对每个会话维度的消息生成连续自增消息ID，并以“会话+消息ID”全局唯一标识一条消息。
b、消息量大的情况下，集中发号器将存在性能瓶颈。此时可通过snowflake方法分布式生成全局唯一消息ID，且消息ID趋势有序。
3）消息存储维度
a、对一般点对点单聊场景，消息以“消息接收者”作为“查询主键”进行存储与查询。
b、对特殊业务场景，需明确定义会话维度，并以“会话”作为“查询主键”进行存储与查询。

3-2、消息在线推送与送达确认####

消息在线推送过程

3-3、未送达消息离线拉取####

未送达消息离线拉取过程

由于im-server对每条消息维护“送达”状态，配合“未送达消息离线拉取接口”可保证消息100%理论上不丢失。

四、消息推送与离线存储（有赞客服系统）#

4-1、消息持久化####

1）职责划分
由于系统客户端大部分为web端，并不擅长做本地存储，因此持久化存储部分由服务端完成。
由于会话内消息Id连续递增，服务端对每个会话采用游标的方式记录最新消息位置及各用户已读消息位置。
a、会话消息的存储与历史消息拉取由服务端实现；
b、用户在各会话的未读消息游标由服务端存储，客户端调用服务端接口更新用户在某会话内已读消息游标；
c、服务端保证对建连客户端消息的实时推送；
d、服务端提供历史消息拉取接口，由客户端调用分页拉取会话内历史消息；
2）消息ID
通过集中发号器对每个会话维度的消息生成连续自增消息ID，并以“会话+消息ID”全局唯一标识一条消息。
集中发号器目前使用aerospike实现。
3）消息存储维度
以会话（conversationId）作为“查询主键”进行消息存储与查询。

4-2、未读数标识与已读确认####

因为系统客户端不进行消息持久存储，因此系统将维护消息的“已读状态”，而非“送达状态”。
a、系统为每个会话记录当前最大消息游标cursor。
b、系统为会话内每个成员记录其在会话中当前已读的最大消息游标。
c、用户客户端登录拉取会话列表时，后端系统会同时返回会话列表中每个会话的用户未读消息个数。
d、用户客户端在会话中读取了消息时，需给予后端系统反馈，后端系统会更新用户在对应会话中的已读游标。

4-3、方案优缺点####

优：方案根据系统业务特性使用“用户+店铺”作为会话维度存储消息，会话内消息由集中发号器生成连续自增ID。使得系统实现复杂度降低，历史消息分页拉取及未读消息数功能实现方便。
缺：消息存储维度与业务紧密关联，不便于系统通用扩展。
缺：集中发号器产生“会话内连续消息ID”的方式存在性能瓶颈风险。

五、模块化后的优化系统架构#

5-1、IM推送系统架构####

IM推送系统架构

5-2、客服系统与IM推送系统的模块关系####

模块职责关系图