技術優化迭代
問題點
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 對應的業務類型 ，根據不同策略，選擇不同渠道 進行推送，做好服務降級 ，切換渠道的準備，做好消息優先級，消息兜底的準備。 這一層 其實整個平臺的靈魂。