企業自建的蘋果通知推送系統的架構演化與探索

標籤：im   apns   ios   架構   蘋果   

企業的APP開發中，對於蘋果裝置有個獨特的通知推送功能要解決，尤其是在做移動IM時，對APNS(Apple Push Notification Service)的要求比較高，雖然有專門的第三方提供此類服務，但出於安全的考濾，有能力的公司寧願自建推送服務系統。本人結合工作中的開發經驗，在這探討一下其架構的演化與探索，希望能使此類系統更加完美。

IM系統自建蘋果通知推送服務系統的層級關係如下：

                                                                圖1層級關係

首先說明一下在我工作中APNS的使用情境：

對於最初的解決方案是我入項目組時就已經定好的，具體的應對方案如下：

                                                                        圖3  原始設計方案

雖然這個方法實現了功能，但對於APP的推廣後的大量的使用者使用，系統的承受能力和擴充能力很明顯就不足，雖然推送系統已經根據使用者的設定資訊，從最大程度上減少了壓力，但對於IM軟體來說仍然不夠，而且對於IM類的APP來說還有兩個特殊的要求：角標和訊息順序。

出於眾多的考濾，曆時兩個多月，我對推送系統做了如下的改進，首先從架構上：

                                                                      圖 4    單個認證解決方案

我利用了RabbitMQ的路由功能做系統的負載平衡支援，因為蘋果裝置的裝置號是固定64位長度，而且具有唯一性，所以的就用了使用者的裝置號來做Hash(散列)，具體的演算法如下：

public abstract class RouteKeyUtil {        private static Properties prop = ConfigUtil.getApnsConfig();        private static Map<Integer, String> map;        static {        String list = prop.getProperty("queues");        String[] queues = list.split(",");        map = new HashMap<Integer, String>();        int ii = 1;        for (String q : queues) {            if(StringUtils.isNotEmpty(q)){                map.put(Integer.valueOf(ii++), q);            }        }    }    public static String genarateRouteKey(String token) {        if (token == null || token.isEmpty()) {            throw new IllegalArgumentException("token is empty");        }        int random = token.charAt(0) * token.charAt(1);        int index = random % map.size() + 1;        return map.get(Integer.valueOf(index));    }        public static Map<Integer, String> getAllQueues(){        return map;    }}

由於蘋果的認證分為企業認證和開發人員認證，而且兩個認證的調用介面地址不一樣，如果調錯的話Apple Server會返回傳送失敗錯誤。所以對於兩個認證我們在一個系統裡做了區別，但兩者架構相同，如下：

                                                                                       圖 5  雙認證解決方案

但是利用MQ做負載平衡有一個致使命的缺點，就是不能相互感知，一但監聽伺服器宕機，訊息就會在MQ中積壓，為瞭解決此問題，我利用Zookeeper提供的訂閱功能做了一個監控方案，Zookeeper用於存放配置，健康檢測系統用於監聽服務狀態和動態修改配置，這樣可以簡單實現失效轉移（failover）功能，具體設計如下：

                                                                             圖  6 系統監控

此系統設計方案還有很多缺點，在此提出希望大家能給點寶貴的建議。

企業自建的蘋果通知推送系統的架構演化與探索