项目上线至今已有1年左右的时间了，回头查看自己以前写的比较low的东西，感觉确实可笑，但是当时也是形势所迫嘛。

现在为止，东西已经基本完善，不能说有多好吧，支持现在业务量肯定是没有问题的。

梳理以前东西的时候，偶然间发现了我们的推送业务，顺便整理了下，利用58速运和我们自己的对比了下，下面有原文地址，感谢对方的贡献。

简述：

（1）系统间各种信息的通知与交互，这种现在无非是采用MQ（消息系统）的方式，而在众多的MQ方案中，使用的比较广泛且性能较高的开源项目则是RabbitMQ了。

RabbitMQ是采用Erlang语言编写，天生的支持高并发，而且内部有不同其它MQ的独特设计。

 （2）实现推送的业务，现在的情况无非就是两种，一种借助第三方已经实现好的，去集成。或者就是自己购买相关设备，自己去实现。

推送逻辑：

我们业务量小点，是基于第三方的推送设计:

推送设计【原文地址：58速运】:

APP端，用户或司机会有下单的流程，有两类消息：第一类消息从APP端发起，用户下单，最终将消息推送给APP-server，另外一个就是从APP-server往APP端走。

msg-gate负责整合百万连接，维护与APP端的海量tcp连接；建立安全的消息通道，消息加解密、消息解压缩、消息流量监控、黑白名单；消息投递，接收APP端投递过来的消息，推送app-server投递过来的消息给APP端。因为要得到实时，优化了没有采用现有业务的方式上报。这边对于gate就是百万链接的流量整合。另外一个它会有逻辑层，将逻辑层转换MQ，这是整体的流程。

一般像我们服务的话，因为哪一个司机和哪个客户对接都要通过消息平台进行发送，所以对于gate层是比较特殊的，是有状态的。另外有一个逻辑层，主要职责也比较简单，就是跟业务相关的，逻辑层最核心的东西就是必须把gate层这边的消息重组到APP上，就是gate和APP有怎样的关系，这是server往APP端的东西。逻辑层职责比较简单，一个就是业务处理，还有也是业务相关的逻辑。

推送业务的逻辑设计