高负载java服务器

Question

我正在制作多人游戏。现在我正在尝试选择将 android 设备连接到服务器的技术。客户端运行安卓，游戏为MMORPG。我想用java编写服务器。 目前我只有 3 个想法：

1) 使用纯 java 和套接字创建多线程环境。这样在游戏客户端和服务器之间进行全双工连接会更容易。但我有以下顾虑：

1.1) 该游戏是具有大量对象的 MMORPG，如果有 5000 人同时玩，我不确定如何扩展此类解决方案。我可以在 java Machine 上运行多少个线程？我该如何近似计算？如果每个套接字有 1 个线程正在读取，而 1 个线程正在写入套接字（因此 1 个玩家有 2 个线程）。

1.2) 当玩家数量增加时，我将如何扩展我自己编写的 jar-archive 以分布在多个服务器上？也许有一些特殊的技巧可以做到这一点？

1.3) 大量的编程开销 - 套接字 API 非常低级。

2) 创建一个用于服务 HTTP 请求的 Servlet 接口。

2.1) 只要每个玩家都有自己的会话，就可以轻松控制会话（和授权）。

2.2) 可以连接到 java EE EJB 或其他 - 消除了系统级编程的许多复杂性。这样我就可以专心写业务逻辑了。

2.3) 可以使用 HTTP 服务所有类型的客户端 - 移动设备 + 浏览器。

2.4) 高速 - 即使是 1 个 servlet 容器每秒也可以处理几千个请求，因此速度非常快。

2.4) 但是这种方法不能提供全双工通信。我将不得不每 1 秒发送一次请求以检查更新。 1 秒的延迟对游戏来说并没有太大的区别，因为它是回合制的，但它仍然会产生大量的流量。有很多玩家玩的时候可行吗？听说过一些COMET技术，但是好像服务器要连续推送很多消息，我还是要每次都发送请求+这个技术还没有成熟。

3) 创建套接字并通过 JMS 将它们连接到 java EE 服务器。

3.1) 很酷，因为允许客户端和服务器之间的全双工通信 + 提供 java EE 的所有很酷的特性。以后可以通过servlet接口扩展到浏览器。

3.2) 这似乎是某种过度工程。人们真的会这样做吗？我的意思是它甚至是正确的方法吗？有理智的开发者会这样做吗？

我希望你能帮我做出选择。我没有太多做这样的工作的经验。并希望坚持最佳做法。

Answer 1

我认为想法 3 不会过度工程化，我会走这条路。

在 onMessage 方法中构建处理传入套接字连接的 @MessageDriven Bean“适配器”很容易开发，并且您可以从那里进入扩展良好的 EE 世界。

您的情况，您甚至可能想要依赖 UDP。请参见以下示例： http://www.apprigger.com/2011/06/javaee-udp-resource-adapter-example/

但在我看来，这样做还有其他重要的原因。一些建议：

1.) 正如你已经提到的。构建自己的处理线程和请求的 Socket Server 需要大量工作，最终您可能会构建自己的小型“应用程序服务器”。

2.) 不要害怕使用应用服务器。当然，人们倾向于称这样的平台为“架空”。虽然当我确实测量调用其他服务或消退的时间时，使用本地接口的调用成本确实不到 10 微秒。拥有自己的线程池和工作线程并自己处理它们可能会更快，尽管也不接近 0 微秒 ;-)

3.) 拥有一个 AS，您可以非常轻松地配置您的实例边界。更重要的是，您可以比自制软件更容易地扩展您的应用程序。想象一下有一个集群在 2 台以上的服务器上运行（如果你的 MMO 成功了，你就会这样做）。网络负载均衡器适用于所有类型的架构，尽管可以共享会话信息（可能不适用于游戏玩家连接，但为什么不用于登录用户会话）或集群节点上的实体管理器在 EE 包中只是“免费”的。

所有这些 EE 工具和模式都让您有时间开发游戏而不是框架 ;-)