技术优化迭代
问题点
etcd 发号器安全性问题 。
解决方案 ：
使用其他 分段式id 生成方案替换。 详情参考 j39 分布式id技术选型
http://wiki.internal.taqu.cn/docs/wiki/id_gen（设计者：喻诗文）现在短信多渠道推送一般是remainder切换来做的 。没有优先级 ，也没有兜底的概念。，某一时间不可用了。 兜底渠道可以顶上 ，或者 具有动态切换切换优先级的能力都是可以的。
解决方案 ：
应用，推送类型 ，业务类型 3个维度 ，推送渠道优先级 。 设计 推送渠道优先级表 ，根据优先级动态变更 ，推送渠道优先级 。
建议 mysql 存储 应用，推送类型 ，业务类型 ，推送渠道优先级 数据 ， etcd 作为开关 ，决定是否刷新本地缓存 。 具体实现 各个设计者 负责 。将方法路由信息 ，实现类和方法 告知调用方 ，本身就不是一个好的方式 。使用反射的性能消耗也会比普通方法调用要高很多 。不利于提升整体性能
解决方案 ：
通过接口 解决反射调用代码 ，有利于提升整体性能。现在内部还使用了redis 作为 高优先级队列，低优先级队列，以及群发队列的实现，本身redis 不支持 至少一次消费，或者精确一次消费 ，推送任务 ，如果pod down了 ，这个pushtask永远不会完成，redis 也没有办法作为消息兜底，内存就那么点,个推渠道短暂挂掉了。消息现在都是丢失。如果可以 通过kafka 缓存 消息 ，通过消息兜底机制，保存最新一段时间消息推送 ，个人觉得有利于提高推送成功率。
解决方案 ：
用kafka替换redis 高优先级 ，低优先级队列 ， 可以做到消息兜底 ， 以及 至少一次消费 精确一次消费等事情的。
工作可以分成两块
消息兜底机制 （设计者： 喻诗文）
对接kafka 。（设计者： 范锐）
推送指标添加
1 实时性指标 - 消息进入j5 系统 ，以及到 j5 通过渠道推送 的时间 ， 消息实时性 性能指标 有缺失
2 吞吐量相关指标 - 进入j5系统消息量 ，从j5系统推送出消息量 ，以及之间的差值。
3 业务相关指标 - 目前j5 消息无法知晓 ，消息投递者是谁 。投递系统是谁。更不用提业务相关指标收集 ，比如某次运营活动消息的推送量，实时性 ，真实到达率等等。部分不合理流程优化 ，sql 优化 。 比如说 select count 是否合理 ，是否有走索引。 是否可以通过redis 替换。等等。
info日志的百分比收集 ，推送日志多，其实是必然的。 通过开关，开启或者关闭，有时候会错失掉某些日志。业务方反应没有收到，但我们这边也没有报错。 如果量较大的推送。 做到百分之50的收集 ，就能减少不少的日志空间了。同时也可以反馈业务方。
目前架构设计
其实 从架构体系上 这次迭代开发，架构上是没有变化，只是将某些组件做了替换以及增强 。未来可能会根据实际的需求，逐渐去演化。
我希望未来推送平台每一个组件都是职责单一的，可以扩展的 ，具备高可用的特性的，易于监控，开发，维护。 同时具备还具备较高的性能上 （吞吐量，实时性）。
推送服务接入层
当前业务方直接通过tqmq传递类名，方法名 ，通过反射的方式调用指定类下的方法。这种方式耦合了业务方以及推送平台，我更加希望通过soa 接口的方式去做这一层，推送平台的内部的类，方法，接口以及组件的改变和替换都不会影响和其他系统对接的协议。同时可以提供统一接口避免了没有约定消息传递而导致业务方以为消息推出去，其实传参没传对的问题，消息没有传出去，因为这一层soa接口会做基本验证，告知业务方，最后会通过app标识 ，业务标识 将消息异步发送指定对列
推送服务层
每个应用监听自己的队列，获取消息 ，生成推送任务push_task ,组装推送数据 pushdata（比如说范围推送的cid获取 ,验证，建议将所有业务相关验证放在这一层），实时消息通过mq的方式 交给推送网关 ，定时消息通过mq交给定时服务
推送网关
根据pushdata 对应的业务类型 ，根据不同策略，选择不同渠道 进行推送，做好服务降级 ，切换渠道的准备，做好消息优先级，消息兜底的准备。 这一层 其实整个平台的灵魂。