企業的APP開發中，對于蘋果裝置有個獨特的通知推送功能要解決，尤其是在做移動IM時，對APNS(Apple Push Notification Service)的要求比較高，雖然有專門的第三方提供此類服務，但出于安全的考濾，有能力的公司甯願自建推送服務系統。本人結合工作中的開發經驗，在這探讨一下其架構的演進與探索，希望能使此類系統更加完美。
IM系統自建蘋果通知推送服務系統的層級關系如下：
圖1
層級關系
首先說明一下在我工作中APNS的使用場景：
對于最初的解決方案是我入項目組時就已經定好的，具體的應對方案如下：
圖3 原始設計方案
雖然這個方法實作了功能，但對于APP的推廣後的大量的使用者使用，系統的承受能力和擴充能力很明顯就不足，雖然推送系統已經根據使用者的設定資訊，從最大程度上減少了壓力，但對于IM軟體來說仍然不夠，而且對于IM類的APP來說還有兩個特殊的要求：角标和消息順序。
出于衆多的考濾，曆時兩個多月，我對推送系統做了如下的改進，首先從架構上：
圖 4 單個證書解決方案
我利用了RabbitMQ的路由功能做系統的負載均衡支援，因為蘋果裝置的裝置号是固定64位長度，而且具有唯一性，是以的就用了使用者的裝置号來做Hash(散列)，具體的算法如下：
由于蘋果的證書分為企業證書和開發者證書，而且兩個證書的調用接口位址不一樣，如果調錯的話Apple Server會傳回發送失敗錯誤。是以對于兩個證書我們在一個系統裡做了差別，但兩者架構相同，如下：
圖 5 雙證書解決方案
但是利用MQ做負載均衡有一個緻使命的缺點，就是不能互相感覺，一但監聽伺服器當機，消息就會在MQ中積壓，為了解決此問題，我利用Zookeeper提供的訂閱功能做了一個監控方案，Zookeeper用于存放配置，健康檢測系統用于監聽服務狀态和動态修改配置，這樣可以簡單實作失效轉移（failover）功能，具體設計如下：
圖 6 系統監控
此系統設計方案還有很多缺點，在此提出希望大家能給點寶貴的建議。