一、解决什么问题 + 难点

解决什么业务问题

端到云的实时上报需求：58速运司机端GPS实时上

云到端的实时推送需求：58速运司机订单实时推送

（3）端到端的聊天消息需求：用户、商户、客服之间的聊天沟通

难点：

（1）APP无线环境下消息可达性<

（2）通用性，平台实现尽量与业务解耦

二、传统解决方案与潜在不足

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

方案一：直接通过业务线web-server写DB

方案二：通用web-server层调用业务服务层写DB

潜在不足：

（1）http短连接代价高（反复创建与销毁连接）

（2）web-server层吞吐量较低（每秒处理千级别请求）

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

方案一：通过APNs或者米推等第三方推送

方案二：通过自己搭建mqtt服务推送

潜在不足：

（1）第三方可达性与实时性无法保证，第三方会进行推送限速

（2）mqtt可用性是个问题

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

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

三、通用实时消息平台实现细节

业务的分析与抽象：司机、用户、商家、客服均为“在线”业务 【端到云的优化】

传统方案潜在的问题：http轮询效率不高，web-server性能有限 优化TIPS：消息平台使用tcp长连接（如上图）

潜在的问题：消息平台与业务线app-server耦合，需要switch case业务线类型来分发投递消息，新增业务线需要新增RPC调用（如上图） 优化TIPS：使用消息总线msg-queue解耦（如下图）

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

【云到端的优化】

潜在的问题：可用性问题与第三方限速

优化TIPS：自己提供消息平台集群，提供RPC接口，实现“云到端”的消息通道

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

潜在的问题：不少司机推送订单无回复，抢单率比预期的低

优化TIPS：引入状态实时存储，只有“在线”状态的用户才推送消息

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

潜在问题：如果接收方不在线怎么办

优化TIPS：增加DB存储离线消息

潜在的问题：无线环境下经常网络不稳（例如进出电梯断网），消息经常丢失

优化TIPS：消息平台收到消息先落地数据库，接收方收到后应用层ACK再删除，以保证不丢失

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

（1）发送发将消息发给消息平?

（2）消息平台先将消息落地DB

（3）消息平台回复发送方消息发送成功（此时和接收方是否接到无关）

（3）与此同时，并行的把消息投递给接收方（如果不在线就存离线了）

（4）接收方应用层ACK表示收到了消息

（5）消息平台将消息删除

（6）告之接收方ACK已经成功处理

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

潜在问题：发送方没有收到第3步骤中的消息平台回复怎么办？

优化TIPS：发送方重发（服务器无状态）

潜在问题：接收方收到重发的冗余消息怎么办？

优化TIPS：接收方去重（可以做到服务端完全无状态，只需要简单投递消息即可）

【分层架构说明】

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

（1）消息平台在APP里的msg-sdk，向APP提供帅气的接口

（2）msg-gate，整个消息平台的tcp接入门户，保持tcp长连接，初步攻防，加解密，压缩解压缩

（3）msg-logic，整个消息平台逻辑处理的部分

（4）redis，高可用redis集群存储用户在线状态online/offline，以及用户在哪一台msg-gate接入（如果在线）

（5）DB，存储离线消息

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

（1）APP：业务方APP，可以有多个，通过msg-sdk来接入消息平台

（2）mq：消息平台通过mq来给业务方服务器发“端到云”的消息

（3）app-server：业务方后端，可以有多个，通过mq接收“端到云”的消息，通过RPC发送“云到端”的消息

【对外提供的接口说明】

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

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

1）login：接入消息平台

（2）logout：登出消息平台

（3）c2s：发送client to server“端到云”的消息

（4）c2c：发送client to client“端到端”的消息

（5）get-offline-msg：拉取离线消息

（6）on-msg-recieved：收到消息的callback回调接口

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

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

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

（1）keepalive：用于msg-sdk与消息平台的连接保持（对业务方透明）

（2）c2c-ack：用户c2c接口的应用层ack接口（对业务方透明）

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

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

解决方案：不再使用uid作为整个系统运行的key，而使用domain+uid，或者appid+uid来作为整个系统运行的key

潜在耦合点：这样的话，login接口的逻辑处理，消息平台需要switch case (domain或者appid)来进行不同的登录验证，与业务有一定的耦合，不过新增帐号体系的频度很低，远比新增消息类型低

【协议的扩展性设计】

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

（1）如何方便的增加接口？

解决方案：协议使用定长包头 + 变长包体，使用命令号cmd来扩展新接口【这个变化对业务层是透明的，是msg-sdk与消息平台之间的事情】

（2）对于同一个接口，能否增加参数，而不影响旧版本的APP？

解决方案：使用可扩展的序列化协议，例如protobuffer【protobuffer这个东西也对业务线透明】

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

例如业务线可能有这样的潜在需求：

a）推送一个运营消息

b）推送消息内容支持字体、字号、加粗、颜色

c）推送消息支持图片

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

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

四、分布式架构细节

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

如果你读到了这里，说明对消息平台还是有点兴趣的，58到家消息平台团队只有一个同学，奇缺人，欢迎有志之士加入。

一些说明：base北京，核心团队，技术导向，Java方向，和58沈剑一个团队

加入方式：（1）直接在文章下面留言（2）在公众号回复“招聘”获取加盟密钥

五、总结

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

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

（3）“端到端”消息投递步骤如下图：

“端到端”消息投递

a）先存离线消息防丢失

b）ACK机制保证可达

c）发送方消息重发

d）接收方消息去重

5）可扩展协议设计

a）定长包头，变长包体，随时增加接口

b）可扩展序列化协议，随时变化接口

c）可扩展消息协议，随时增加类型

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

（7）分层架构如下图