項目上線至今已有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端的東西。邏輯層職責比較簡單，一個就是業務處理，還有也是業務相關的邏輯。

推送業務的邏輯設計