移动互联网实战--Apple的APNS桩推送服务的实现(2)

 

前记:
　　相信大家在搞IOS推送服务的开发时, 会直接使用javapns api来简单实现, 调试也直连Apple的APNS服务(产品/测试版)来实现. 很少有人会写个APNS的桩服务, 事实也是如此. 只是当时我所面临的应用场景有些特殊, 为了测试服务的性能和调试功能方便, 特地写了APNS的桩服务(其实主要原因是当时的iphone测试机, 被小组长"霸占"占为己用, ⊙﹏⊙b汗). 在此写一篇关于APNS桩服务的文章, 以此纪念逝去的"青春", 也希望对读者有所帮助.
　　有些事情回想起来, 历历在目, 清晰异常, 仿佛发生在昨天. 犹记一年前, 开发IOS的APNS推送后端服务, 吐血三升...

秉承:
　　上一篇文章, 详见: Apple的APNS桩推送服务的实现(1) 
　　文章简要介绍了APNS协议/证书管理/JSSE的API的一些基础概念和实现原理.

需求分析:
　　从开发者的角度去理解和分析需求. 对于IOS的消息推送的功能和性能测试, 大致可分为如下几种:
　　1). 推送平台QPS/RT的性能指标
　　2). Bad Device Token对服务的影响评估
　　3). 证书对服务的影响评估
　　4). 推送可靠性评估(推送弱ack机制, 丢消息和消息重复之间的折中)
　　通过记录日志来评估QPS/RT和服务的质量, 引入黑名单机制来模拟bad device token对推送服务的影响评估.

技术分析:
　　对APNS服务的理解和自身的功能/性能测试需求:
　　1). APNS推送服务采用SSL长连接/二进制流/异步的方式来实现, 追求推送消息的吞吐量.
　　2). APNS支持V1/V2两种二进制协议, 遇到异常时, APNS的默认行为不一样.
　　3). APNS客户端是TSL(SSL)的单向认证(客户端携带证书, 服务端信任检查).
　　结合桩的定位, 我们采用One Connection Per Thread的线程池模式去模拟处理它, 一方面能基本满足需求, 另一方面实现高效简单. 同时为了方便测试, 服务端关闭对客户端认证机制. 

服务实现:
　　APNS模拟桩的实现过程
　　1). 服务端证书引入

keytool -genkey -v -alias ssl-server -keyalg RSA -keystore ./server_ks -storepass server -keypass 123456 -dname "CN=Unknown"

　　生成效果如图

　　2). 自定义TrustManager的实现类

private class MyX509TrustManager implements X509TrustManager {

　　@Override
　　public X509Certificate[] getAcceptedIssuers() {
　　　　return null;
　　}
　　// 对服务端证书的认证, 抛出异常表示不通过
　　@Override
　　public void checkServerTrusted(X509Certificate[] chain, String authType)
　　　　　　throws CertificateException {
　　}
　　// 对客户端证书进行认证, 抛出异常表示不通过
　　@Override
　　public void checkClientTrusted(X509Certificate[] chain, String authType)
　　　　　　throws CertificateException {
　　}

};　

　　评注: 这边提供空实现, 对客户端的证书不进行任何校验
　　3). 创建SSLServerSocket代码片段

SSLContext ctx = SSLContext.getInstance("SSL");

// *) 创建KeyManagerFactory类实例
KeyManagerFactory kmf = KeyManagerFactory
　　　　.getInstance(KeyManagerFactory.getDefaultAlgorithm());

// *) 初始化KeyStore, 这边的KEY_PASSWORD为"123456"
KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
ks.load(ApnsStubServer.class.getResourceAsStream("/server_ks"), null);
kmf.init(ks, KEY_PASSWOR.toCharArray());

// *) 进行SSLContext类的初始化工作 
ctx.init(kmf.getKeyManagers(),
　　　　new TrustManager[] { new MyX509TrustManager() },
　　　　new SecureRandom());

// *) SSLServerSocket的生成 
SSLServerSocket serverSocket = (SSLServerSocket) ctx
　　　　.getServerSocketFactory()
　　　　.createServerSocket(serverPort);
serverSocket.setReuseAddress(true);
// *) 设置Client认证开关关闭
serverSocket.setNeedClientAuth(false);

　　评注: 把server_ks代码放到classpath目录下, 同时这边的key_password为"123456", 而不是keystore的密码"server", 注意keypass和storepass的区别
　　4). 服务端连接处理代码

// One Connection Per Thread的机制	
ExecutorService workerPools = Executors.newCachedThreadPool();

while ( true ) {
　　final Socket cliSocket = sslServerSocket.accept();
　　workerPools.execute(new Runnable() {
　　　　@Override
　　　　public void run() {
　　　　　　onHandle(cliSocket);
　　　　}
　　});
}

　　评注: serverSocket用于接受客户端连接, 并放入工作池去处理
　　onHandle函数定义如下:

private void onHandle(Socket cliSocket) {

　　DeviceTokenManager dtm = apnsStubController.getDeviceTokenManager();

　　DataInputStream dis = new DataInputStream(cliSocket.getInputStream());
　　int ch = 0;
　　while ( (ch = dis.read()) != -1 ) {
　　　　IVResult<ApnsMessage> result = ApnsProtocolUtility.readMessage(ch, dis);
　　　　ApnsMessage message = result.getValue();
　　　　// 属于不同版本的消息, 进行分发和处理 
　　　　if ( ApnsVersion.APNS_BINARY_PROTOCOL_V1 == message.getVersion() ) {
　　　　　　// *) 如果属于bad device token黑名单
　　　　　　if ( dtm.judgeBadDeviceToken(message.getDeviceToken()) ) {
　　　　　　　　break;
　　　　　　}
　　　　　　printMessage(message);
　　　　} else if ( ApnsVersion.APNS_BINARY_PROTOCOL_V2 == message.getVersion() ) {
　　　　　　// *) 如果属于bad device token黑名单
　　　　　　if ( dtm.judgeBadDeviceToken(message.getDeviceToken()) ) {
　　　　　　　　// 8 为令牌错误, 就是bad device token
　　　　　　　　ApnsProtocolUtility. writeResponse(8, message.getIdentifier(), cliSocket.getOutputStream());
　　　　　　　　break;
　　　　　　}
　　　　　　printMessage(message);
　　　　}
　　}
}

　　5). 黑名单的引入和接口定义

　　由外置黑名单文件来指定

public class DeviceTokenManager {

　　// 用于配置参数的初始化
　　public void init(Properties prop);

　　// 判断是否为bad device token
　　public boolean judgeBadDeviceToken(String deviceToken);

　　// 载入bad device token 名单
　　private void loadBadDeviceTokenFile(String filename);

}

　　总结: 难点在于JSSE和证书的理解, 至于APNS的网络协议, 处理还是相对简单的.

APNS推送服务平台:
　　对于APNS推送服务平台, 还是有些优化技巧, 这边并不深入展开, 仅从个人的观点描述几个.
　　1). 对gateway.push.apple.com的ip地址解析, 挑选rrt时间最短的服务ip进行连接
　　
　　2). 引入队列异步化/构建DadDeviceToken仓库
　　作为推送服务, 对于推送请求, 作简单的校验(消息格式合法/是否属于bad device token). 然后储存消息于队列中, 由后端worker慢慢消化. 不再等待真实的APNS服务反馈(APNS服务弱ACK机制), 立即返回结果(允许一定程度的推送成功误报率).
　　构建自己的Bad Device Token仓库, 一方来自Feedback服务接受, 一方来自APNS推送的响应结果收集.

后记:
　　感觉自己还是没有把自己想表达的事情说清楚, 甚是遗憾. 无论如何, 还是希望对读者有些帮助, 对我而言, 则是充满了回忆. Fighting, Let it go!!!