大家好,小弟不才想在此請教各位有經驗的前輩們提供建議或給予鞭策
目前專案的需求是希望可以在全球各處的使用者可以在同一個場景下互相看到彼此,依照我所查詢的一些資料和其他公司的做法,大致上都是根據各區域進行分服各自處理該區的資料,但主管認為這不符合需求因此駁回,同時也有提供一個名為Zwift的騎車訓練用軟體給我參考,該軟體似乎也是全球同步的作法。
目前我的作法是:
目前我的疑惑是:
上述做法如果前輩們希望我可以多補充說明的地方可以向我提出,我會盡快補充上去,或是有哪裡很笨的地方也可以直接給予鞭策,感謝!
補充目前使用相關工具:
沒考慮用 Photon Engine 嗎? (不用自己重新發明輪子)
https://www.photonengine.com/zh-TW/Realtime
自架伺服器授權可容納不限人數用戶 (通常是你的頻寬在受限):
https://medium.com/photon-taiwan/%E5%A6%82%E4%BD%95%E6%8C%91%E9%81%B8%E9%81%A9%E7%95%B6%E7%9A%84-photon-%E4%BC%BA%E6%9C%8D%E7%AB%AF%E7%94%A2%E5%93%81%E6%96%B9%E6%A1%88-68b40b68053a
感謝提供相關工具資訊,Photon Engine也有在我們使用工具中的名單內,很抱歉上面內文沒有提到,稍後我會再補充上去。
依照目前Photon使用狀況來看確實是相當方便好上手,擴充上也相當方便,只是目前對於整體架構規劃方面比較有疑惑,因為目前歐美區的使用者反應延遲狀況很嚴重...
這樣就是你們架構設計的問題了, 延遲有兩種: Network Latency 和 Application Latency, 網路延遲是先天物理限制, 比較沒有改良的空間; 但應用延遲通常可以挖出很多可改善的點....
改善任何應用延遲之前, 都要先建立好準確的量測工具, 長期觀察測量出每一段 Micro service 的延遲狀況, 看是誰卡住最多? 再來想辦法排除....
如果你們覺得是 Photon Engine 造成延遲的話, 可以跟它們官方討論架構...或者, 你們也可以請官方提供, 跟你們應用場景類似的成功案例, 讓你們參考他們架構看看....
你們也可以用獎金懸賞方式, 徵求架構師幫你們解決問題....當然, 獎金不能開太少, 目前架構師的年薪普遍在 NT$250萬起跳到 NT$500萬之間...
延遲狀況的話,我在檢驗運算所有使用者狀態時間消耗約為5~15ms左右,這部分要看當時的連線人數。但在歐美伺服器與亞洲伺服器之間的ping約莫落在150~250ms之間,因此我也認為應該是在架構上有配置有誤。
最近的想法是試試AWS Global Accelerator這項服務,但主管認為消耗經費上想再多控制點,因此我把這個放在比較後面...
跨洲延遲已經撞上物理限制, 你不可能突破, 唯一方法就是提前把資料先送到歐美的 Edge 端點, 讓他可以立即拿到..
Global Accelerator 不見得是最優解, 因為他並不瞭解你們的資料特性, 只會傻傻地把存取量需求最高的派送到端點去, 但存取量最高是否就等於資料即時性最高? 這兩個不見得對等....而且你還是無法控制他的派送時間...
目前看來, 光是依賴現成工具似乎是辦不到你們要的...
你們需要設計一個: 符合你們特性, 專用的全球資料分派演算法, 而且可能必須自己搭建底層的資料傳遞系統, 來實現這個演算法...
(題外話, Zwift 去年七月也在徵求架構師, 不知道他們找到沒...)
簡單的數學算一下:
假設一個用戶產生的動作, 從一端跨洲傳送到最遠端, 我們可以控制的延遲是 250ms 的話, 加上兩端各自運算邏輯處理的時間, 假設各 25ms 延遲的話, 一個用戶的動作發佈到全球端點需要:
250+(25x2)=300ms
也就是說, 你的遊戲動作精細度(時間差), 不能小於 300ms, 才有可能辦到這個全球同步的要求. (通常全球同步我們都預期要抓 500ms 延遲)
Zwift 能做到有幾種可能:
以 Zwift 的遊戲特徵來看, 以上都很容易做到; 但換成別的性質, 就很難說了; 所以你們其實可以尋求 Unity 或 Photon 官方的協助, 看能否給你們一些案例參考?
此外, 如果要優先考慮低延遲, 可能就要容許某種程度的資料損失, 允許 UDP, 後補, 壓縮, 或者只傳送差異資料, 這些都是你們底層要設計的演算邏輯, 也是其他現成工具無法馬上取代掉的; Photon 有些思考方向可以參考:
https://doc.photonengine.com/en-us/pun/current/gameplay/synchronization-and-state
感謝您提供的這幾項分析!
我後續根據您建議的方向以及其他相關收集的資料,似乎MMORPG會有一個獨立的地圖伺服器作為管理所有玩家位置以及地圖上的相關物件,再加上您建議設計符合我們特性的演算法去推送玩家資訊,我目前的想法是類似主從式的架構,各區域伺服器(從)連接地圖伺服器(主)取得相關玩家資訊針對該區域進行分發,並允許各區域伺服器(從)依照目前資料延遲狀態進行玩家資料模擬。
不過這部分應該也是需要段時間去進行演算法測試及優化,想請教下您對這部分有沒有哪些建議?
看起來是想類似MMO那種多人同時線上?
目前我玩過的遊戲在伺服器架構上最強大的依舊是2012上市的GW2
原本GW2架構跟其他遊戲一樣伺服器只能看到同伺服器的玩家
現今依舊普遍的單一伺服器獨立架構
但開發商很快地在2014捨棄了這個架構,GW2搖身一變可以在同個地圖上看到不同伺服器的玩家,快超出上限就會自動產生地圖分流繼續容納陸續進來的各伺服器玩家
開發商稱為MEGA Server
https://www.guildwars2.com/en/news/introducing-the-megaserver-system/
FF14單純可以讓玩家傳送去別的伺服器遊玩和打副本,滿了要排隊
(我沒玩FF14所以描述比較少)
基於物理限制,不管何種架構都有Sync和ping的問題
不過GW2的網狀架構更為複雜但除了戰場伺服器外都運行的很好
GW2也是建在AWS上,你可以看一下MEGA Server介紹看能不能給你一些靈感?
其實如果是AWS的話,AWS本身就有對應的相關伺服處理了。
一般來說,我會資料庫直接RDS開多分區來處理(成本會很高就是了)
但一個地理區(如亞太、西歐....)同步連結一個地區。
因為不太清楚你的地理區情況。我只能先用這樣做範例。
再來就是考量頻寬區及機器效能區。
在不了解你遊戲的情況下。我會偏重使用M級的機器(記憶體加強)
能搭配負載平衡就搭配。降低一些成本。
最後再利用ROUND53的能力及VPN的能力來處理就行了。
基本上這些一整個系列的搭配。都需要要求很高的等級處理。
感謝您提供的建議!
我們的地理狀態大致就和您範例中的一樣,Route53的部分我還沒有去看過相關服務,我會再去確認相關功能說明試試後續搭配方式。
去看一下round53詳細說明文件,它有地理區特性連結(需要設定)
我之前開CN2線路(很貴的線路),其主要目的給大陸地區使用。
但那時還不會做切換。任何一條國際線都是透過CN2的線路出去。
其成本非常的高。
(CN2是採取流量計費)
後期有高人告訴我可以透過round53來區分跳轉所需線路。
可以切換大陸來的線路才跑CN2。其餘依常規線路跑。
設定完後,整體線路成本就下降到原本的一半以下。
(因為其實大陸區的會員並不多)
且 round53 可以幫忙你分配到專屬地理區。無需再用PROXY的方式轉接過去。
其它你的需求,其實你可以去問一下專門跑AWS的架構師。
他會做好一整體的規劃。當初教我的高人其實就是架構師。
在不了解你遊戲的情況下。我會偏重使用M級的機器(記憶體加強)
指的是ec2嗎
是的話 m 應該是 general purpose
r開頭才是 memory optimized