58到家实时消息系统的架构设计及技术选型经验总结

JackJiang · 8 年前

前言

实时消息平台产生的背景是基于58核心的业务——58速运，58速运的业务是做最便捷的同城的货运。基于早期HTTP伪实时消息推送的种种问题，我们开发了新的实时消息推送平台，目的就是解决系统的稳定性等性能问题，为业务部门减少压力。

面临的问题和技术难点

需要解决什么业务问题：

端到云的实时上报需求：58速运司机端GPS实时上报
云到端的实时推送需求：58速运司机订单实时推送
端到端的聊天消息需求：用户、商户、客服之间的聊天沟通

技术难点：

APP无线环境下消息可达性
通用性：平台实现尽量与业务解耦

总结传统解决方案的不足

1端到云：http轮询上报GPS消息

方案一：直接通过业务线web-server写DB
58到家实时消息系统的架构设计及技术选型经验总结_1.png

方案二：通用web-server层调用业务服务层写DB
58到家实时消息系统的架构设计及技术选型经验总结_2.png

潜在不足：

http短连接代价高（反复创建与销毁连接）
web-server层吞吐量较低（每秒处理千级别请求）

2云到端：通过第三方push或者推送服务

方案一：通过APNs或者米推等第三方推送
方案二：通过自己搭建mqtt服务推送
潜在不足：

第三方可达性与实时性无法保证：为了整个云服务的可用性第3方可能会进行推送限速（PS：潜规则）
mqtt可用性是个问题

3端到端：结合上面两种方法实现

传统方案往往可以通过结合【端到云】与【云到端】来结合解决【端到端】的实时消息推送问题。

58到家实时消息平台的实现细节

1业务的分析与抽象

司机、用户、商家、客服均为“在线”业务。

2端到云的优化

传统方案潜在的问题：http轮询效率不高，web-server性能有限。

优化TIPS：消息平台使用tcp长连接（如下图）
58到家实时消息系统的架构设计及技术选型经验总结_4.png

潜在的问题：消息平台与业务线app-server耦合，需要switch case业务线类型来分发投递消息，新增业务线需要新增RPC调用（如下图）
58到家实时消息系统的架构设计及技术选型经验总结_5.png

优化TIPS：使用消息总线msg-queue解耦（如下图）
58到家实时消息系统的架构设计及技术选型经验总结_9.png

小结：
可以看到，使用消息总线后，新增消息发送方，消息平台只需要配置消息类型与消息总线主题的映射关系，新增的app-server消费方订阅新的主题即可，实现消息平台与业务的解耦。

3云到端的优化

潜在的问题：可用性问题与第三方限速
优化TIPS：自己提供消息平台集群，提供RPC接口，实现“云到端”的消息通道（见下图）
58到家实时消息系统的架构设计及技术选型经验总结_7.png

这里要注意的是，“端到云”使用消息总线，是为了业务解耦。“云到端”直接使用RPC接口，也是为了业务解耦，新增消息推送方，消息平台无需改动代码。

潜在的问题：不少司机推送订单无回复，抢单率比预期的低
优化TIPS：引入状态实时存储，只有“在线”状态的用户才推送消息（见下图）
58到家实时消息系统的架构设计及技术选型经验总结_8.png

4端到端的优化

如果业务无关，则直接通过tcp通道投递；如果业务相关，发送方先来一个“端到云”的投递（通过mq），业务服务器处理再反向来一个“云到端”的投递（RPC）给接收方。

潜在问题：如果接收方不在线怎么办
优化TIPS：增加DB存储离线消息（见下图）
58到家实时消息系统的架构设计及技术选型经验总结_9.png

潜在的问题：无线环境下经常网络不稳（例如进出电梯断网），消息经常丢失
优化TIPS：消息平台收到消息先落地数据库，接收方收到后应用层ACK再删除，以保证不丢失（见下图）
58到家实时消息系统的架构设计及技术选型经验总结_10.png

如上图（本文最重要的2张图之一），整个消息投递流程为：

发送发将消息发给消息平台
消息平台先将消息落地DB
消息平台回复发送方消息发送成功（此时和接收方是否接到无关）
与此同时，并行的把消息投递给接收方（如果不在线就存离线了）
接收方应用层ACK表示收到了消息
消息平台将消息删除
告之接收方ACK已经成功处理

可以看到，是使用“应用层ACK来解决消息可达性问题的”。

潜在问题：发送方没有收到第3步骤中的消息平台回复怎么办？
优化TIPS：发送方重发（服务器无状态）

潜在问题：接收方收到重发的冗余消息怎么办？
优化TIPS：接收方去重（可以做到服务端完全无状态，只需要简单投递消息即可）

5分层架构说明

整个系统的分层架构如上图（本文最重要的2张图之二），整个消息平台系统由：

消息平台在APP里的msg-sdk，向APP提供帅气的接口
msg-gate，整个消息平台的tcp接入门户，保持tcp长连接，初步攻防，加解密，压缩解压缩
msg-logic，整个消息平台逻辑处理的部分
redis，高可用redis集群存储用户在线状态online/offline，以及用户在哪一台msg-gate接入（如果在线）
DB，存储离线消息

非消息平台的几个业务部分：

APP：业务方APP，可以有多个，通过msg-sdk来接入消息平台
mq：消息平台通过mq来给业务方服务器发“端到云”的消息
app-server：业务方后端，可以有多个，通过mq接收“端到云”的消息，通过RPC发送“云到端”的消息

6对外提供的接口说明

消息平台对业务方提供的接口是很少很通用的接口。

msg-sdk对APP提供的核心接口有：

login：接入消息平台
logout：登出消息平台
c2s：发送client to server“端到云”的消息
c2c：发送client to client“端到端”的消息
get-offline-msg：拉取离线消息
on-msg-recieved：收到消息的callback回调接口

消息平台对app-server提供的核心接口有：

s2c：发送server to client“云到端”的消息

其他业务方不需要关注，是msg-sdk与消息平台之间的内部接口有：

keepalive：用于msg-sdk与消息平台的连接保持（对业务方透明）
c2c-ack：用户c2c接口的应用层ack接口（对业务方透明）

7如何实现跨帐号体系的聊天

既然是通用的消息平台，如何实现跨帐号体系的消息发送呢（即如何实现qq与旺旺的聊天）？

解决方案：不再使用uid作为整个系统运行的key，而使用domain+uid，或者appid+uid来作为整个系统运行的key
潜在耦合点：这样的话，login接口的逻辑处理，消息平台需要switch case (domain或者appid)来进行不同的登录验证，与业务有一定的耦合，不过新增帐号体系的频度很低，远比新增消息类型低。

8协议的扩展性设计

APP本质是cs架构，一旦放出去的版本就很难收回来，其兼容系要求远比bs架构难，如何做到新增功能的同时，还能方便的兼容历史旧版APP呢？

（1）如何方便的增加接口？
解决方案：协议使用定长包头 + 变长包体，使用命令号cmd来扩展新接口【这个变化对业务层是透明的，是msg-sdk与消息平台之间的事情】，具体协议设计请参见《58到家实时消息系统的协议设计等技术实践分享》。

（2）对于同一个接口，能否增加参数，而不影响旧版本的APP？
解决方案：使用可扩展的序列化协议，例如protobuffer【protobuffer这个东西也对业务线透明】。关于更多Protobuf及其它协议、数据传输格式的文章请见：《IM/推送的通信格式、协议篇》。

（3）对于业务方，有很多种类的消息类型，有很多复杂的业务需求，如何保证业务扩展性的同时，又不会增加消息平台的复杂性，并对旧版本APP兼容？
例如业务线可能有这样的潜在需求：

推送一个运营消息
推送消息内容支持字体、字号、加粗、颜色
推送消息支持图片
业务支持“窗口震动”，以及“对方正在输入......”等需求

解决方案：使用可扩展的消息体协议（对消息平台透明），例如xml/json来支持可扩展的多样消息类型，并对旧版本APP兼容。

<msg>
<type>1</type>
<fond>宋体</font>
<content>hello, world!</content>
<pic>[url=http://pic.daojia.com/hello.jpg</pic]http://pic.daojia.com/hello.jpg</pic>[/url]
</msg>

使用这种消息内容协议，能保证：扩展性好、旧版本兼容、对消息平台透明等诸多好处，强烈建议使用。

分布式架构细节

抱歉，主持人提醒时间已到，分布式架构扩展性、负载均衡性、可用性、一致性的问题线下和大家分享，先放一个分布式架构图吧：

58到家实时消息系统的架构设计及技术选型经验总结_12.png

总结

（1）“端到云”消息投递：
TCP消息通道，消息总线业务解耦。

（2）“云到端”消息投递：
提供RPC接口，引入状态存储。

（3）“端到端”消息投递步骤如下图：
58到家实时消息系统的架构设计及技术选型经验总结_13.png

（4）“端到端”消息投递技巧
      a）先存离线消息防丢失
      b）ACK机制保证可达
      c）发送方消息重发
      d）接收方消息去重

（5）可扩展协议设计
      a）定长包头，变长包体，随时增加接口
      b）可扩展序列化协议，随时变化接口
      c）可扩展消息协议，随时增加类型

（6）支持跨帐号体系聊天（多个域）：
使用domain（或者appid）+uid作为综合key

（7）分层架构如下图：
58到家实时消息系统的架构设计及技术选型经验总结_14.png

全站即时通讯技术资料分类

2 楼: zjjishitongxun · 6 年前

很详细，受益无穷

3 楼: danielstock · 4 年前

如上图（本文最重要的2张图之一），整个消息投递流程为：
发送发将消息发给消息平台

图中的数字次序，和文字解释的次序有点对不上啊。

4 楼: JackJiang · 4 年前

引用：danielstock 发表于 2020-05-10 14:19
如上图（本文最重要的2张图之一），整个消息投递流程为：
发送发将消息发给消息平台

是的，你的眼力很好，数字画重了，第2次出现的“3”应该改为“4”，后面的序号依此类推

本文目录

前言

面临的问题和技术难点

总结传统解决方案的不足

1端到云：http轮询上报GPS消息

2云到端：通过第三方push或者推送服务

3端到端：结合上面两种方法实现

58到家实时消息平台的实现细节

1业务的分析与抽象

2端到云的优化

3云到端的优化

4端到端的优化

5分层架构说明

6对外提供的接口说明

7如何实现跨帐号体系的聊天

8协议的扩展性设计

分布式架构细节

总结

更多资料

全站即时通讯技术资料分类

本帖已收录至以下技术专辑

MobileIMSDK (v4.0精编版)

MobileIMSDK-Web (有偿开源)

RainbowAVnew (有偿开源)

RainbowChat (技术转让)

RainbowChat-Web (技术转让)

精华之王

白金版主

终身成就

即时通讯网

友情链接[友链交换]

关于

微信公众号new

本文目录

前言

面临的问题和技术难点

总结传统解决方案的不足

1端到云：http轮询上报GPS消息

2云到端：通过第三方push或者推送服务

3端到端：结合上面两种方法实现

58到家实时消息平台的实现细节

1业务的分析与抽象

2端到云的优化

3云到端的优化

4端到端的优化

5分层架构说明

6对外提供的接口说明

7如何实现跨帐号体系的聊天

8协议的扩展性设计

分布式架构细节

总结

更多资料

全站即时通讯技术资料分类

本帖已收录至以下技术专辑

MobileIMSDK(v4.0精编版)

MobileIMSDK-Web(有偿开源)

RainbowAVnew(有偿开源)

RainbowChat(技术转让)

RainbowChat-Web(技术转让)

精华之王

白金版主

终身成就

即时通讯网

友情链接[友链交换]

关于

微信公众号new

MobileIMSDK (v4.0精编版)

MobileIMSDK-Web (有偿开源)

RainbowAVnew (有偿开源)

RainbowChat (技术转让)

RainbowChat-Web (技术转让)

即时通讯网　