我在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進行授權轉載。