我们需要开发一款具有实时性能的多人游戏。这需要在全球范围内工作(服务器在美国、欧洲、亚洲)，并支持巨大的流量。使用Google Cloud服务作为主机
我们正在考虑像Jam with Chrome, Chrome Maze或Cube Slam这样的参考。
游戏:
- 2人挑战一场比赛
- 我们需要同时显示两个玩家的进程
- 每场比赛可以持续大约30到45秒
主机:
我们显然会在AppEngine上托管网站，自动扩展，但是我们正在考虑两种实时服务器的解决方案:
-
websocket server with Compute Engine
就像他们为Jam做的Chrome、Maze等一样
开发我们自己的websocket服务器(技术待定)，部署在欧洲，美国，亚洲的数据中心，处理扩展，它们之间的同步，计算服务器和客户端的延迟问题等。但这在技术上是相当具有挑战性的，因为我们的时间很短，而且现在还缺一个管理系统和网络的家伙。 -
或使用通道API
我们知道它不是websocket平台，实时性较低。
但这对我们和我们的时间来说会更简单、更安全。
所以，我们也想了解更多关于这方面的信息。
在任何情况下，我们认为我们可以在前端使用一些图形技巧，使其看起来像实时的，但这实际上取决于我们有100~500ms或500ms~10s的延迟。
问题:
- 对于不同的解决方案，延迟范围值会是什么样子?
(Jam w/Chrome使用GCE获得100ms，通道API可以达到几秒吗?) - 通道API服务器如何处理高流量，如何扩展工作，延迟会变得非常高吗?(没有关于频道文档的信息吗?)
- 如果有人在法国和美国的人玩游戏，连接到不同的服务器，等待他们同步，怎么办? 有什么建议或经验可以分享吗?有什么有趣的阅读或观看吗?(见过一些，但不是很精确)
感谢您的帮助!
编辑:
- 只有2个玩家连接在一起，可能来自不同的世界区域，不需要广播。我们可以找到一些前端技巧来避免服务器端处理。这是两名玩家之间的比赛，所以我们实际上只需要比较他们的进程，真正的赢家决心并不那么重要，因为没有真正的东西可以赢得，这更多的是为了好玩。
如果您需要一个服务器来处理数据:
我绝对会在Compute Engine上使用websockets !
Channels API要慢得多，而且非常不可预测(延迟因消息而异)!数据必须转到Channels服务器，后者将其发送到App Engine实例，后者必须向Channels服务器发出请求，后者将消息推送到客户端。如果你想降低延迟，那里有太多的事情要做!
这是一个通道API压力测试:
http://channelapistresstest.appspot.com/
试着多次点击"发送5"按钮，你会看到延迟数字上升到几秒钟。
channel API在高负载下也非常昂贵(它可能不能很好地扩展，即使Google当然可以用更多的实例解决这个问题)。
在降低延迟时，地理位置非常重要。使用Compute Engine的websocket服务器，您可以将欧洲访问者发送到google的欧洲数据中心，将美国访问者发送到美国数据中心(使用AppEngine将提供的地理位置标头)。使用Channels API(或所有消息都通过的应用程序引擎)就没有这样的控制。也许谷歌有通道API的边缘服务器(我不知道)，但如果你的AppEngine实例在地球的另一边，那就没关系了。
如果你不需要一个服务器来处理数据:
您应该与WebRTC建立点对点连接，直接在用户的浏览器之间发送内容。这就是魔方大满贯所做的。(WebRTC需要一些初始的握手("信令")，这样两个对等端就可以找到对方，通道API可以很好地进行握手，这只是建立点对点连接的几个消息。)
webbrtc DataChannels API将给你一个很好的类似websocket的接口，像channel.onmessage = function(e) { yadayada()... };和channel.send("yadayada");在对等体之间发送数据。
偶尔，WebRTC无法建立点对点连接。然后它将返回到TURN服务器，该服务器在对等体之间中继流量。Cube Slam正在使用运行在ComputeEngine上的TURN服务器(在欧洲和美国都是为了降低延迟)，但这只是在真正的点对点无法实现时的后备方案。
这还取决于其他因素，如可伸缩性。
Ingress是建立在应用引擎和偶尔的缓存故障的一部分，它是相当令人印象深刻的。
请记住通道api正在使用talk。hangouts是建立在Google上的。可伸缩和实时。
如果你的流量水平是不稳定和不可预测的，那就去应用引擎。如果你认为它可以被控制和预测，使用计算引擎或其他东西。
Alfred的回答在我提出的问题框架内是最好的。非常感谢!
然而，我忘记提到一些重要的点，范围改变了一点:
- 我们的开发时间非常短(大约只有1周)
- 这是一个只持续3周的活动(我们需要在几个月后保持在线，但这并不像我们需要一个持久的架构)
- 我们需要使其工作在更广泛的浏览器受众尽可能(WebRTC只运行在Chrome &Firefox(暂时)
根据这些要点，我们最终得出了第三个解决方案:
使用实时PAAS.
它的方式更容易和更快的开发，方式更便宜，因为我们不需要一个坚实的后端开发人员和系统/网络管理员，我们可以更专注于项目，而不是基础设施和平台。
有几个服务看起来不错，已经在世界范围内托管MMO RPG和类似的服务，具有低延迟和良好的扩展系统。
以下是提供商列表:
https://github.com/leggetter/realtime-web-technologies-guide/blob/master/guide.md