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

企業的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 系統監控

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