通用接口开放平台设计与实现——（4）消息服务总体设计

如果只有API服务方面，调用方需要定期轮询，因为他们不知道物流系统中的数据何时发生或变化。定期轮询一方面不能实时交互，另一方面会给双方的服务器造成一定的额外负担。 基于上述因素，物流接口平台通过消息服务主动通知调用人数据变化。调用人收到消息通知后，调用相应的信息API服务来查询数据即可，从而规避定时轮询。 消息服务基于Socket技术，调用方系统与物流系统建立长连接，实时推送消息通知。

1.消息服务中心启动 2.物流系统LMS与应用系统(如承运商运输管理系统)TMS）分别发起登录请求 3.信息服务中心身份认证，发送登录响应 4.LMS创建委托单等业务信息，发送到消息中心，发送响应信息LMS 5.消息中心处理消息并转发给相应的信息TMS，TMS向消息中心发送响应信息

交互方式：WebSocket 信息传输协议：TCP 通信机制：异步 数据编码格式：UTF-8 数据传输格式：JSON

请求信息有七个属性，如下表所示：

前六个是系统参数，主要用于签字和安全控制。最后一个参数是业务参数，所有与业务相关的数据都包装在参数中。

执行结果如下SUCCESS ，从业务数据字段代表成功content例如，获取返回的业务数据ERROR ，代表界面执行错误， errorCode和errorMessage将错误编码和错误信息存储在字段中。

同API

同API

系统级错误定义如下：

业务级错误定义见具体新闻服务。

建立了应用系统和消息服务中心WebSocket通过心跳保持机制检测长连接的有效性。 心跳包由客户端系统发送，内容为PingWebSocketFrame，收到心跳包后，新闻服务中心会立即响应内容PongWebSocketFrame。 应用系统设置心跳响应超时间。如果超过指定时间，则认为连接失效，并执行重连操作。 心跳包发送频率和心跳响应超过时间，由应用系统视具体情况进行设置。

发送方在消息结尾追加字符串“\r\n”(即windows系统下的回车换行），接收方根据该字符串进行粘包的分离。

消息服务通信机制为异步，为保证消息传输的可靠性，需实现以下机制： a)发送方重发机制：消息发送方对未收到响应的消息进行重发，重发时保证消息内容不变 b)接收方消息去重机制：消息接收方依据消息的唯一性ID，对收到的消息进行验证，判断是否已处理过，如已处理过则不再进行处理