重构 - 美股行情系统APP推送改造
圖片來源：pexels.com
作者：梁鑫（資深架構師，多年云原生，微服務架構經驗，開源SIA系列產品owner）
前言
今年開始，由于工作內容調整。開始負責美股港股產品的研發。之前的兩篇文章，重構 - 在美股行情系統的實踐和美股交易架構實踐分享了行情系統的重構和交易系統的建設。按照計劃，接下來要改造的是 APP 的信息推送了。
APP 信息推送
目前行情產品采用的是定時請求機制，通過 HTTP 請求每隔若干時間從后端服務拉取一次行情數據，在這個時間間隔內數據是不會發生任何變化的。但當我們打開競品比較時，發現他們的行情數據是以肉眼不可捕捉的速度變化的。明顯這不是定時請求能夠達到的效果，一定是通過建立 TCP 長連接，把數據源源不斷的從后端服務推送到了用戶的手機上。
1
? ?
消息推送的方式選擇
熟悉信息傳輸的朋友肯定發現這種需求不需要實時返回數據，是典型的異步傳輸。一般可以采用兩種方式來處理。一種是后端服務直接采用 TCP 方式傳輸到客戶的手機上。另一種就是選擇合適的消息服務器，讓后端服務和客戶手機進行解耦。明顯我們會選擇后者。
MQTT 協議基本是手機端進行消息通信的標準做法，讓我們先了解一下消息隊列遙測傳輸協議，它是一種基于發布訂閱的輕量級通訊協議，該協議構建于 TCP/IP 協議上，最大優點在于以極少的代碼和有限的帶寬，為連接遠程設備提供實時可靠的消息服務。
2
? ?
選擇何種 MQTT 產品
實現 MQTT 協議的消息產品不少，選擇哪一款產品比較合適？我們的選擇是 EMQ，為什么選擇 EMQ 呢，我直接把 EMQ 官網描述照搬下來大家可以作為參考。
EMQ 設計目標是實現高可靠，并支持承載海量物聯網終端的 MQTT 連接，支持在海量物聯網設備間低延時消息路由:
穩定承載大規模的 MQTT 客戶端連接，單服務器節點支持 50 萬到 100 萬連接。
分布式節點集群，快速低延時的消息路由，單集群支持 1000 萬規模的路由。
消息服務器內擴展，支持定制多種認證方式、高效存儲消息到后端數據庫。
完整物聯網協議支持，MQTT、MQTT-SN、CoAP、LwM2M、WebSocket 或私有協議支持。
2.1
? ?
EMQ 的高可用方式
MQTT 服務器肯定需要支持高可用，我們是不能容忍單點故障的，但 EMQ 的高可用方式需要注意一個問題，EMQ 的集群需要一個 master 節點和若干個 slaver 節點，將 slaver 節點 join 到 master 節點組成集群，當 mater 節點宕機后需要 client 端進行重新連接才能正常 running。
EMQ 的高可用架構圖如下：
3
? ?
使用 EMQ 服務需要考慮的三個問題
當我們把 EMQ 引入到我們的系統后，我們需要考慮三個潛在的問題。
一，客戶端 APP 連接數。EMQ 官網數據號稱單個 EMQ 節點可以支持 50 萬到 100 萬個鏈接，我們目前搭建了兩個節點，按 50 萬計算，可以支持 100 萬個客戶端鏈接。可以預計的將來我們很難短時間內達到百萬用戶同時在線，所以判斷這個數據完全可以滿足我們的需求。
二，EMQ 服務器創建的 topic 數量。官網沒有給出 topic 的數量限制，可能覺得一般的使用情況應該不會創建超級大量的 topic，但我們的需求比較特殊，如果按股票創建 topic，很可能會讓 topic 數量暴增，從而導致 EMQ 服務出現問題。因此我們要最大限度的降低這個值。
三，Topic 的信息吞吐量，如果把所有的行情信息都傳送到 EMQ，相信 EMQ 無法承受這個量級，因此我們也要最大限度的降低這個值。而且降低這個值會減少用戶 APP 的流量。
4
? ?
五，如何降低 EMQ 服務的三個峰值
首先，我們不能把所有的股票行情消息都推送到 EMQ 服務器上。美股有數萬只股票。每只股票又都包含實時信息，交易明細新，交易買賣檔信息。如果把所有的信息都推送到 EMQ 上，需要創建十多萬個 topic，很明顯這樣處理是不合適的。那么最好的方式就是客戶在 APP 上查看那只股票的信息就把哪個股票的信息往 EMQ 中推送。
其次，我們不能把每只股票的所有行情信息都推送到 EMQ 服務器上。針對某些非常熱門的股票，開盤收盤時每秒鐘的交易信息可以到 4000+，如果把這些都推送到客戶 APP 上，手機可能打不開了。因此我們需要利用時間間隔每秒推送兩到三條信息，就可以讓客戶感受到價格信息的實時變化，優化客戶的體驗。
再次，采取續約的方式保證股票信息只在需要的時候進行推送。客戶一般關注某只股票一段時間就會關注其他股票或者做其它的事情了，因此我們采用續約的方式處理。客戶首先訂閱某只股票信息，然后間隔若干時間進行續約。如果服務端沒有收到續約信息，就不再推送該股票的信息了。
最后，保留拉取信息模式，非開盤時間不進行數據推送。非開盤時間股票信息基本不會發生變化，因此推送只在盤中時刻采用。
5
? ?
有效的避免安全隱患
首先要設置 EMQ 的防火墻，EMQ 的防火墻設置在官網有明確的介紹，我這里就不做贅述。其次我們將 EMQ 服務設置為只處理下行數據，不處理上行數據的模式。客戶 APP 進行的訂閱請求，采用 http 的方式。
6
? ?
APP 推送的完整架構設計
Redis 的作用是實現分布式鎖，保證只有一個行情 API 節點往 EMQ 中推送數據。
總結
美股行情竟然是公司第一個采用信息推送的 APP 產品，有一點出乎我的意料。（全文完）
精彩文章推薦
微服務架構設計總結實踐
2021-05-10
萬字長文精華之數據中臺構建五步法
2021-05-07
從零開始搭建創業公司后臺技術棧
2021-04-29
圖解 Kafka，看本篇就足夠啦
2021-04-28
代碼重構技巧寶典，學透本篇就足夠了！
2021-04-27
梁鑫：美股交易架構實踐
2021-04-26
王啟軍：云原生架構下如何拆分微服務？
2021-04-20
原創精華：剖析億級請求下的多級緩存
2021-04-19
梁鑫：重構 - 在美股行情系統的實踐
2021-04-09
淺談架構：架構的緣起與目標
2021-04-07
總結
以上是生活随笔為你收集整理的重构 - 美股行情系统APP推送改造的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java泛型擦除
- 下一篇： NYOJ 737 合并石子(一)