我在1月4日看到虎嗅推送"王思聰撒幣"的消息，然後開始推敲背後技術。其中涉及直播流、實時彈幕、OAuth2.0開放授權、SMS api、Push網關、支付接口等業務，其技術實現並不複雜，我們對此進行剖析。
UI設計
可以說衝頂大會是照搬HQ的商業邏輯、業務邏輯和UI設計。想必在短期內會有更多的知識問答APP蜂擁出現。對此我不做過多評論，只說背後的技術實現，無關商業。
Flutter
可以說我是谷歌的腦殘粉，據傳言Google的Fuchsia OS UI都是用Flutter設計的，在這裏，Android和IOS的適配都可以使用Flutter實現。具體設計可以完全模仿HQ。
業務邏輯
衝頂大會類APP的技術難點在於高併發和時效性。爲此我們要對業務進行解耦合，將註冊/登錄、直播、彈幕、問答、獎池、推送、分享全部進行業務分離，這樣有助於業務拓展，保證高併發以及後續維護問題。
其中主要的業務難點和重點在直播、彈幕、問答。直播和彈幕是主要的流量出口，將其分離有助於保證高併發和時效性。
直播
企業可以自行搭建直播服務，當然也可以購買雲服務。假設這裏選用阿里的視頻直播服務。直播環節將視頻流編碼傳輸、轉碼、加速後推送數據流到客戶端。
彈幕
彈幕可以做成簡單的request請求方式，也可以使用消息隊列。當然消息隊列也可以選取雲服務，但這裏我們使用kafka，部署到服務器集羣上進行負載均衡。對於網速較低的用戶我們可以默認關閉彈幕功能，以增強用戶體驗。關於高併發和時效性，我們後面再談。
問答
問答環節作爲用戶最相關的業務邏輯，我們要保證用戶"秒級"接收消息，這裏可以應用一個小技巧，即"同步推送，異步反饋"。也就是說，主持人在說出題目後由單一服務器進行問題推送，但考慮到用戶的網絡情況存在不同延遲，我們可以異步接收用戶的答題結果，我們可以將異步反饋的最大時效設計爲10s、15s。
其他業務
註冊/登錄：調用微信OAuth 2.0開放授權。具體參考微信開放平臺接口文檔，這裏不在贅述。
獎池：在問答環節結束後進行統一分配，業務簡單，不在贅述。調用支付寶提現接口。
推送：可以使用push網關，也可以使用http輪詢，也可以使用雲服務。
分享：調用各平臺分享接口即可。
高負載
我建議分別在北京、上海、香港進行負載均衡服務器的假設，北京服務北方用戶，上海服務南方用戶，香港服務港澳臺以及海外用戶。技術上使用hadoop、zookeeper、docker、nginx等。
對於不同地理位置的用戶IP，需要進行DNS解析，進行流量自動分發和適配。我們設置可以針對用戶的地理位置不同而進行彈幕的分區域顯示。
使用CDN加速。
運營
可以說每一次直播都是一次運營，因爲有"主持人"因素，所以問答推送和答題結果都是需要"手動"控制的。
具體操作是在直播前準備題目，並且將題目錄入數據庫，或者某個配置腳本中。在主持人互動過程中，進行實時題目推送，並將答題結果反饋到主持人。
最後
我們排除人力成本和獎金成本，單獨計算技術成本。單次問答直播大概20min，我們以10G流量峯值每天進行試算，大概每天的技術成本是1萬元。當然，這是在用戶數量達到一定規模之後。在互聯網行業，這並不高。所以，在短時間內，一定會有大量的知識問答APP問世。
本文只在整體角度考量技術實現，並未涉及過多細節。但對於一些有經驗的公司，特別是直播類公司，我想做出這種APP，不會超過一個星期。我們拭目以待吧。
本文歡迎註明出處的轉載，但微信轉載請聯繫公衆號:caiyongji進行授權轉載。