在講訂閱推送之前，我們需要先回顧一下前面提到的物流軌跡查詢功能，我們用2種不同的獲取物流軌跡的方式做一個對比。有對比才有差距。
先講一個生活中的小案例，我們都有去商場購買過商品，也遇到過想要買的商品缺貨的情況，比如隔壁王阿姨要買的口罩斷貨了，沒有買到，並且這樣的口罩只有這家商場賣，王阿姨首先會問商家大概什么時候有貨，商家不會給她一個承若，可能會給王阿姨一個大概時間，比如說3天內可能會到貨，因為阿姨急着要貨，3天內王阿姨多次去商場詢問到貨情況，去的次數多了，都失去信心了。
好不容易告知已經到貨了，走到商場發現一搶而空了。
這樣的場景跟快遞鳥物流軌跡查詢流程非常相似，我們需要主動去請求快遞鳥物流軌跡接口，才能知道是否有新的物流軌跡，每個物流公司的軌跡產生有自己的規則，所以每次軌跡查詢不一定能查到最新的物流軌跡，要想解決物流及時的問題，我們可能會想到提高查詢物流軌跡接口的頻率，原來每隔3小時請求一次快遞鳥接口，現在改成2小時，好不容易查到物流軌跡了，也及時發送了軌跡信息給客戶，結果遭到客戶投訴，說我們公司發送垃圾短信，客戶2小時前快遞就已經簽收了，搞的都是事后諸葛亮，后知后覺，也特別尷尬。
於是乎，我們繼續修改調用快遞鳥接口的頻率，這次來狠一點，改成3分鍾一次，哇！好開心，軌跡獲取非常及時，這個體驗真好，當你還沒緩過神來，接到快遞鳥官方的電話，通知你惡意調用快遞鳥接口，需要對你接口限速，其實這還不算什么，當我們業務量大的時候，對服務器有很大壓力，大量占用服務器資源。
如果每天有1000個訂單需要發貨，每天就有1000個運單要查詢物流軌跡，一個訂單從發貨到簽收周期是3-7天，我們需要查詢所有未簽收的運單軌跡，綜合統計，一天我們可能需要查詢5000千個訂單，如果我們對訂單時效要求非常高，需要實時了解包裹的簽收情況，我們就要反復調用接口，每3分鍾調用一次，一個單一天要調用480次，如果時效要求更高，調用更頻繁，5000個訂單需要調用240萬次以上，這樣的頻繁調用，快遞鳥的監控機制直接攔截，屬於惡意調用，后果就是快遞鳥直接停用對我們的接口查詢服務。因此，當業務量大，並且客戶對時效要求高的時候，我們需要從新考慮獲取物流軌跡的方案。
剛才我們說王阿姨空歡喜一場，沒有買到口罩，在他要放棄的時候，商場的一位小姐姐給他出了妙招，告訴他不需要自己跑過來問進貨情況，留個電話給商場銷售人員，把需求告知銷售人員，需要什么樣的口罩，買多少個，詳細的清單列給工作人員，一旦有貨進來，第一時間通知王阿姨過來取貨，這樣王阿姨就買到了他期盼已久的口罩。王阿姨把需求告知工作人員，這樣的方式在快遞鳥的業務上稱為訂閱，客戶把所有運單號告訴快遞鳥，這就是一次訂閱，我們只要通過快遞鳥的接口把運單按固定格式推送過去就完成了一次訂閱，后續一旦有新的物流軌跡產生，這個時候快遞鳥就會把最新的軌跡推送給我們，王阿姨留的電話就是用來通知購物的聯系方式，快遞鳥的通知方式是通過接口實現的，所以需要我們提供一個可以接收快遞鳥最新軌跡信息的接口，只要這個接口是按快遞鳥報文接收格式開發的，就能接收到最新的物流軌跡，具體的推送規則，以及接口報文，這里不做講解，
提供一個快遞鳥官網的接口說明地址給大家：http://kdniao.com/api-monitor
通過這樣的訂閱方式，我們不需要占用服務器太多資源，並且軌跡非常及時，快遞鳥官方介紹說，物流公司有新的軌跡產生就會及時推送給我們。
這個時候訂閱服務的優勢就提現出來了，我們只需要把每天的1000個發貨訂單推送到快遞鳥，讓快遞鳥去做這個比較繁瑣的事情，快遞鳥會監控我們推送過去的所有訂單，只要沒有被簽收，快遞鳥就會提供推送服務，假設目前有5000個訂單還沒被簽收，快遞鳥就會監控這5000個單，其中任何一個單有新的軌跡或者被簽收了，快遞鳥即時調用我們提供的接口，把軌跡推送到我們的服務器，這樣我們就實現了0延遲，真正做到了即時更新物流軌跡，我們利用這個功能可以實現很多產品服務，比如：短信提醒客戶訂單預計簽收時間，統計訂單的簽收情況，計算訂單的發貨時效……