Google Cloud上的实时游戏:渠道API还是计算引擎?

最后发布: 2013-06-13 18:40:23


问题

我们需要开发一款具有实时性能的多人游戏。 这需要在全球范围内运行(美国,欧洲,亚洲的服务器),并支持巨大的流量。 使用Google Cloud服务进行托管。

我们正在考虑使用Jam with Chrome,Chrome Maze或Cube Slam等参考文献。

游戏 :

  • 2名球员挑战比赛
  • 我们需要同时显示2名球员的进展
  • 每场比赛可持续约30至45秒

托管:

我们显然会在AppEngine上主持网站,自动扩展,但正在考虑为实时服务器提供2种解决方案:

  1. 使用带有计算引擎的websocket服务器

    就像他们为Jam with Chrome,Maze等所做的那样
    开发我们自己的websocket服务器(技术TBD),部署在欧洲,美国,亚洲的数据中心,处理扩展,在它们之间同步,计算服务器和客户端上的延迟问题等。
    但这在技术上具有挑战性,因为我们的时间很短,而且现在缺少一个管理系统和网络人员。

  2. 或者使用Channel API

    我们知道它不是一个websocket平台,实时性能较低。
    但对我们和我们拥有的时间来说,这将更加简单和安全。
    所以,我们也希望了解更多相关信息。

在任何情况下,我们认为我们可以在前端使用一些图形技巧,使其看起来像实时,但它确实取决于我们有100~500ms或500ms~10s的延迟。

一些问题 :

  • 对于不同的解决方案,延迟范围值会是什么样的?
    (带有GCE的Chrome与Chrome有100ms的距离,Channel API可以达到几秒钟吗?)
  • Channel API服务器如何处理高流量,缩放如何工作,延迟是否会非常高? (没有关于频道文档的信息?)
  • 如果法国有人在美国与某人玩,连接到不同的服务器,等待他们同步,如何处理它会怎么样?
  • 有什么建议或经验可以分享吗?
  • 有趣的阅​​读或观看? (看到一些但不是很精确)
  • 还有其他方法吗?

感谢您的任何帮助评论!

编辑

  • 只有2名球员连接在一起,可能来自不同的世界区域,不需要广播。
  • 我们可以找到一些前端技巧来避免服务器端处理。 这是两个玩家之间的比赛,所以我们实际上只需要比较他们的进展,真正的赢家分辨率并不重要,因为没有真正的东西可以获胜,这更有趣。
google-app-engine websocket channel-api google-compute-engine
回答

如果您需要服务器来处理数据:

我肯定会在Compute Engine上使用websockets!

Channels API要慢得多,而且非常不可预测(延迟因消息而异)! 数据必须转到Channels服务器,后者将其发送到App Engine实例,后者必须向Channels服务器发送请求,该服务器将消息推送到客户端。 如果你想要减少潜伏期,那里有太多的事情发生了!

这是一个Channels API压力测试:
http://channelapistresstest.appspot.com/
尝试点击“发送5”按钮很多,你会看到延迟数字达到几秒钟。

Channels API在高负载下也非常昂贵(它可能无法很好地扩展,即使Google当然可以通过更多实例来解决这个问题)。

在保持延迟时,地理定位非常重要。 使用Compute Engine上的websocket服务器,您可以将您的欧洲访问者发送到谷歌的欧洲数据中心,将美国访问者发送到美国数据中心(使用AppEngine将提供的地理位置标题)。 您对Channels API(或应用引擎,您的所有消息都通过其中继)没有此类控制权。 也许谷歌有Channels API的边缘服务器(我不知道),但如果你的AppEngine实例位于地球的另一边,那也没关系。

如果您不需要服务器来处理数据:

您应该与WebRTC建立点对点连接,直接在用户的浏览器之间发送内容。 那是Cube Slam的确如此。 (WebRTC需要一些初始握手(“信令”),因此两个对等体可以找到彼此,并且Channels API可以很好地进行握手,这只是用于建立对等连接的几条消息。)

WebRTC DataChannels API将为您提供类似websocket的界面,如channel.onmessage = function(e) { yadayada()... }; channel.send("yadayada"); 在同行之间发送数据。

有时,WebRTC无法建立点对点连接。 然后它将回退到TURN服务器,该服务器在对等体之间中继流量。 Cube Slam使用在ComputeEngine上运行的TURN服务器(在欧洲和美国都保持延迟),但这只是真正的点对点无法实现的后备。


回答

它还取决于可伸缩性等其他因素。

Ingress是基于应用程序引擎构建的,偶尔存在缓存故障的一部分,令人印象深刻。

请记住,频道api正在使用talk.Google,这是构建环聊的服务。 可扩展且实时。

就个人而言,如果您的流量水平不稳定且不可预测,请转到app引擎。 如果您认为它可以被控制和可预测使用计算引擎或其他东西。


回答

阿尔弗雷德的回答是我提出的问题框架中最好的。 非常感谢你 !

但是,我忘了提几个要点,范围有所改变:

  • 我们的开发时间很短(仅约1周)
  • 这是针对仅持续3周的广告系列(我们需要在几个月后将其保持在线状态,但这不像我们需要一个持久的架构)
  • 我们需要尽可能让它在更广泛的浏览器受众群体上运行(WebRTC目前仅在Chrome和Firefox上运行)

根据这些观点,我们最终得出了第三个解决方案:
使用实时PAAS

由于我们不需要可靠的后端开发人员和系统/网络管理员,因此开发更容易,更快,更便宜,我们可以更多地关注项目而不是基础架构和平台。

有一些似乎很好的服务,已经托管MMO RPG和全球范围内的低延迟和良好的扩展系统。
以下是提供者列表:
https://github.com/leggetter/realtime-web-technologies-guide/blob/master/guide.md