說說apns和http2

標籤：活躍   驗證   蘋果   失效   並且   網路   瀏覽器核心   自訂   配置   

相信以蘋果爸爸一貫的行事風格，必然在某一天宣布不再支援舊協議，所以各公司都會開始逐漸轉用新推送API，我很難想到會有那麼多人私信我一些關於nghttp2的問題，我也是萌新啊，雖然過了很久，想寫一些遇到的問題，記錄一下備忘。 人在做一件事的時候反倒腦子不清楚，過後回看，有些做法不合適，有些應該做的沒做。  僅考慮對接APNs做推送業務，用最不嚴謹的方式，粗略的分幾類：1.token量百萬以下，推到時間不要求假即時（幾秒內），單appkey這種是很多小型app的自用要求，一句話，只讓我能推，就ok。方案：搞一個推單條的工具，定時跑一下就行了。方案2：對接任意一個雲推送sdk（推薦：極光），省心，說不定這個app活不了幾個月。 2.token量千萬層級，有一定即時性要求，單appkey，還要有一些常規性質統計資料支撐，比如使用者送達率，token失效率（token失效意味著應用卸載，這個資料對產品狗們很關鍵） 這種是典型的一個成熟期app產品的推送情境，當希望產品能在自己把控下演化的公司，會想不開，選擇自研我們之後主要考慮這種情境，做一個最通用的東西，先起個名，比如說這個東西可以叫apnspx ，px是proxy的意思。它的形態從外面看，是一個單進程http服務，使用jsonapi跟外界通訊。最好不要搞特殊化，做後端6,7年了，唯一一個小經驗就是：所有同步介面，都應該用http json api，所有非同步介面，都要走MQ，如果團隊成熟想上rpc，都應該用grpc，不然的話，事情就會一團糟。 3.普適性推送平台，要處理成千上萬個不同的appkey，十億以上海量token，秒級甚至毫秒級送達，還要有詳盡的業務報表和漂亮曲線展示給你老闆，用來說明你的app非常牛逼或者快要死了。 這是類似極光，雲吧，個推等那幾家做雲推送公司的核心需求。然而，在這個層面上，apns只是這個複雜系統中的一個小服務，更多制約系統效能的，反倒不是apns本身了。常見的幾個關鍵問題，都是需要在系統層面去解決的。- 資料匯流排，系統的吞吐全部需要用訊息佇列來非同步化- token失效淘汰，需要有一套常規緩衝系統加合理的淘汰演算法- 長串連輪轉，需要有一套分析app活躍性和推送特徵的分析系統，反哺後端，指導資源分派- 億級app客戶的處理，高峰時期的系統伸縮，同上- 平台是開放的，當然還要有防攻擊防刷的那一整套東西- 到APNs的連通性，甚至跟代碼無關，快讓你的老大，去跟營運組的老大剛一波正面，讓他們把機房部署在美國或者香港，你看戲就好，保證推送速度飛快。 簡化情境3，這些東西想全做在apnspx，是想不開的行為，我假設系統裡核心部分是部署在容器化的平台上，只負責推送，和輸出原始統計日誌，別的策略由更高層的調度來處理，比如某app出現大推送的動態擴容這種問題。 從頭開始作一個小設計，並時刻謹記，只做情境2，不然會陷入無盡選擇恐懼的泥潭，其中為什麼這麼做我寫一下個人的理解 參數傳入時機的權衡，程式啟動了，帶有幾個初始參數：appkey，認證（現在生產開發也是一個認證了）評論：之前曾經妄圖運行中動態拉取認證，這樣可以支援多appkey，後來發現，認證的到期，失效與更新是又一個問題，反倒複雜化了。事實上這些邏輯應該做在另一個層面。細化至少要有如下可配置項：串連數，串連最大重試數，token失敗最大重試數 輸入未動，統計先行。功能本身甚至不如統計重要，服務本身的統計要能從一個/status介面輸出，最要緊的：當前批次隊列長度，就緒數，等待數，平均串連重試數，這些可以驗證是否網路通暢啟動到目前，推送批次量，推送總量，成功，失敗，重試，各自總量還有一組維度：每秒，每5分鐘內以上各指標。這些資訊是評判健康的最主要標準，到這個粒度暫時夠了。 輸入，一個json，起碼要支援兩種格式，一個payload+tokenlist，一個tokenlist，並且每個token有各自的payload第一種是推廣告和新聞最常用的，有必要單獨第二種是每個使用者會有所不同，類似出驗證碼，或者精細化人群推送也就是說：輸入進來要分好給每個token推什麼，細分人群不是apnspx的功能 核心的推送引擎，根據實現的選擇有兩種模式，多工無阻塞風格，語言級協程無論是哪一種，我都 **非常不建議** 使用http2的多路stream特性，除非google給我寫了一個庫，讓我用起來感受不到stream。一條串連，一路stream，失敗關閉，成功繼續。保持簡單多路stream，不好用，不適用就像nghttp2提供的六萬多個回調（其實大概是十幾個，難道我會去數嗎?），作為庫的使用者，應用程式層開發人員，要明白一個事實：這些不是給你用來寫那些掙工資的代碼的，除非你對有更高要求順帶說一下nghttp2，提供了協議中定義的每一個階段前後的鉤子，目的是給高效能伺服器h2o提供最精細的控制能力和手段，同理stream特性也是，是用來給web瀏覽器核心這種層級的項目來用的。 http2的本質複雜性，是由於它違反了網路分層模型，當然是由於迫不得已。http2在應用程式層協議上重新定義了一個串連策略層，然後再在上面定義應用程式層。如果使用stream，相當於在處理一個微型的tcp協議棧。 

第一步：網域名稱解析的問題，在3那個極端情境裡，阻塞的網域名稱解析也不可接受，但要認識到，這個問題是another problem，使用單獨的方案，getaddrinfo調用它就是阻塞的我能怎麼辦？我也很絕望啊！系統級的有skydns，小規模的亦可以自己維護一個表，或者無視阻塞，這一步之後在系統中，只考慮ip。

 第二步：socket串連，ssl串連，這一步出錯會有很多資訊，好好的返回詳細，說明蘋果爸爸認為你的認證有問題了 維護兩個安全執行緒隊列主線程將資料不斷的push資料進引擎，引擎將結果push進處理完畢隊列，失敗但未達到重試次數的，重新進輸入隊列最後結果集隊列全部完畢，將結果輸出，結果就是apns返回的那一坨，可以加一些自訂的，比如推送完成時間等。 當認為因為偶發服務掛掉等原因導致的狀態丟失不可接受，就使用一種快速的持久化隊列，替代記憶體隊列，比如redis，或者ssdb。這樣服務本身是stateless的，更好一些。 這一批推送完畢，中斷連線。或者延遲斷開，等待下一批，建議最好是主動做斷鏈重連。推送中斷鏈，重連重試，直到超過自訂次數上限。 結果做json序列化，返回。 使用時候控制每一批的數量，分批多次。一次推得太多，APNs會生氣，認為你在攻擊它，把連結關了。APNs到國內網路不穩定，可能就斷了。APNs自己有bug，就斷了APNs不高興了，就斷了不知道為什麼就斷了，比如海底光纜斷裂，奧特曼擊毀地球等。不要相信長串連的可用性，在可能失敗的地方都加入重試邏輯。任何重試都要設定上限，並給出統計結果。 以前做的是情境3，可惜種種原因，自己也很不盡滿意，根據上述，我會緩慢的寫一個滿足情境2需求的小項目，也算是一段工作的總結吧，有空就寫寫以前每次一想到，代碼量很大一塊在統計、異常處理哪裡，一點都不clean，就泄氣，我連蘋果手機都沒有，我寫個卵 無奈寫代碼就是跟現實世界做鬥爭，人生不是一個純函數 網路編程更是特別如此。  

說說apns和http2