前言：
遙想當年阿法狗戰敗一眾圍棋國手，風氣一轉，似乎所有人都懂AI。這次谷歌又放出了stadia，國內鵝廠再次跑步進場，貴州某xx雲提前佈局。
閒來無事，嘗試體驗了一下貴州某xx雲的雲遊戲（不打廣告），暫且不評論如何如何，剛好對流媒體技術略有研究，僅在這裡簡單聊一下這方面涉及的架構和技術。
架構設計：
總體架構自上而下大致分為四端：
1、雲遊戲主機端（雲遊戲執行端，或者叫雲遊戲畫面渲染端，需要接收控制指令並錄屏推流到流媒體服務）
主機端需要執行遊戲並讓通過錄屏推流程式把渲染好的遊戲畫面（其實就是錄屏）推流到流媒體服務進行實時視訊分發。
有人會想這個雲遊戲主機端可能會很複雜，其實也還好，只是包含了錄屏、推流、使用者控制指令接收和一些其他諸如計費此類的相關功能。
2、流媒體服務（用於轉發主機端推上來的遊戲實時視訊並分發出去，所有使用者都可以觀看這個視訊）
這個不需要多講了，只是用來轉發遊戲實時視訊，並不涉及雲遊戲主機的控制權。
3、控制指令轉發服務（使用者需要獲取控制指令服務的所有權才能控制雲遊戲主機）
這個是雲遊戲的控制核心，獲取某臺雲遊戲主機的使用者就可以通過鍵盤或者滑鼠進行雲遊戲的試玩（操作），理論上講能夠獲取該控制權的不是隻有一個使用者，完全可以支援多個使用者同時控制一臺雲遊戲主機。
4、客戶端（瀏覽器，pc客戶端，ios，安卓客戶端等）
客戶端需要從流媒體服務拉取實時遊戲視訊，使用者需要先獲取雲遊戲主機的控制權，才能夠傳送控制指令來試玩（操作）雲遊戲（滑鼠，鍵盤，手柄等）
靈魂畫師繪製結構圖：
架構示意圖-來自靈魂畫師的傾情手繪
難點或者叫待解決的點：
1、流媒體協議的選擇？高延遲才是最大殺手
從流媒體技術出身開始，實時視訊延遲一直是個比較棘手的問題，比如rtmp/http-flv等基於tcp的協議本身優化到極點也要幾百毫秒的延遲，hls這種超高延遲到幾秒的不提也罷。就目前看只有sip、rtsp以及基於udp的一些協議能夠滿足這種超低延遲的需求，但是這種協議就很難在瀏覽器上就很難實現了，除了webrtc，而webrtc協議是谷歌力推的下一代流媒體協議，不排除這次是谷歌webrtc技術的奠基之作，拭目以待。
2、雲遊戲主機控制指令的所有權？依然是延遲
這個所有權其實不算是難點，只是使用者獲取某臺雲遊戲主機的控制權而已。難點在於控制指令的延遲，沒錯，就是網路延遲。尤其是在拉取實時視訊時，在視訊已經佔用大量頻寬的情況下，在這種網路負載或者網路波動較大的情況下控制指令延遲或許值得重視。
跟很多朋友討論過雲遊戲這個話題，不約而同第一個想到的都是網路延遲，當然這個延遲不僅包含控制指令的延遲也指實時遊戲視訊的延遲。
後言（囉嗦幾句）：
其實這塊依然屬於共享經濟的後續，類似共享單車。
給大家舉個栗子：我有一百臺效能強勁的遊戲主機，每臺主機價值一萬，當二手貨賣掉可能還會虧點，好可惜。那麼我把他共享出來，假設現在有十萬個使用者想租我這一百臺機器，然後每人只收10塊錢月租，不考慮電費等其他成本，請問我什麼時候能回本？
作者：eguid
說明：原CSDN相關部落格文章已經全部轉移到部落格園